Philosophy

Conventional standards have two essential components:

Establishing Consensus

Getting a community to agree on a consensus document.

Publishing

Publishing a consensus document permanently under a well-known name so that anyone in the world community can refer to it by just its name without anyone failing to understand what's being referred to.

Conventional standards can be very good for situations where two things have to fit together in exactly one way. It's useful to know how an electrical plug should fit into an electrical socket so that the two can be manufactured independently and yet end up working together in modular fashion. And the problem is that such careful coordination among manufacturers, however well-intended, can run afoul of antitrust legislation. Consequently, voluntary standards organizations such as ANSI exist as a way of mediating discussion among vendors while assuring market fairness and helping to avoid antitrust issues.

The problem with conventional standards is that they are expensive in several ways:

The modern marketplace involves enormous amounts of what computer people would describe as “parallel processing”, that is, activities going on at the same time, often unsynchronized. However, a standards effort is a “synchronization step” that can bring parallel activity to a standstill. Most computer experts would probably agree that large synchronization steps are to be avoided except where absolutely needed because they tend to hold back progress that could be usefully proceeding.

Which begs the question: Is this synchronization step really needed?

The theory behind “substandards” is that it's probably better if the consensus step is bypassed, and someone wanting to create either side of a protocol or interface just publishes how you interface works so that someone else wanting to adhere to it can voluntarily do so. Nothing requires anyone to adhere, and this allows work to proceed independently, with individual market players voluntarily conforming or not to various ways of doing things without excluding the possibility of other mechanisms. Computer sockets, for example, are not like physical wall sockets. People don't want 15 kinds of electrical sockets in their walls, so agreement is needed. But most people don't realize there are dozens of software sockets on their computer allowing the software equivalent of different, incompatible kinds of communication protocols to co-exist side-by-side without any problem.

The notion of substandards, then, is just to write down what something is or does in a fixed and referenceable way. If there's a competing idea, the idea is just to create a competing substandard rather than to force the two communities to agree. In that way, if 60% of the people want one thing and 40% want another, that's how the usage patterns will play out just like that, rather than 60% getting their way and 40% being forced to accept that.

After all, there are only two things to the FORTRAN 77 standard, for example: (1) the knowledge that at some time in history, some number of people got together and thought it was a good idea, and (2) the fact that if you search the right place with the right name, you can find out what they thought it was. Except for the number of people who agreed it was a good idea, any work of fiction you can buy in a bookstore has about the same things going for it: (1) at some point, some people agreed it was a good idea (author and publisher), and (2) if you search the right place with the right name, you can find it.

It may still be useful for some software markets to begin with a base standard as a common core to get started--that's a personal preference thing. But the name “substandards” is offered as a way of thinking about the notion of just saying what you're doing and then doing it, as a low-tech alternative to formal standards. Substandards are not full standards... That's why they have the name that they have.

Genesis of This Idea

This idea came up at all for the Lisp programming language, which has a base standard and where people are always talking about needing a new standard to accommodate recent change. It's not clear why that should be necessary.

The Scheme programming language has a system called SRFI (Scheme Requests for Implementation). Although much more lightweight than conventional standards, it still requires some community permission. Substandards involve none of that. The idea is simply that if you want to make one, you are limited only by your own imagination. You oughtn't need anyone's permission to make a substandard. Publishing might have some small expense associated with it, but that's true with all publishing.