|
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:
There is often a membership fee for participation. Members sometimes complain about this fee, but it is often the cheapest of the various expenses.
It takes clock time away from work to participate in a standard. Usually this is done by paid employees, so an employer is usually paying “real money” for salaried time to someone to participate, to travel to meetings, etc. For those who chair a committee, author or edit text in a standard, or otherwise contribute in a material way, this cost can go higher since such individuals often spend additional time and resources in between meetings in order to keep things moving along. One would hope that the reason for doing this work is that it will eventually do something positive for the industry paying for this work, but such gratification can often be delayed by a substantial time.
It delays time to market. If you don't know how a standard will come out, it can take a long time before you can conform. During all of that time, you may have an ongoing problem of not knowing what to conform to. This is the biggest cost of a standard. Asking an industry participant to hold back until all members of the community agree is a very hard thing to do in a community that moves as fast as the modern computer science marketplace. This is a big expense.
It inhibits diversity. A subtle effect of consensus building is that it may be that 60% of the community likes proposal A and 40% likes proposal B. Under a consensus system, the 60% will get their way at the expense of the 40%. This favors commonality over diversity, on the assumption that commonality is essential and diversity a luxury. This is a assumption that often goes unquestioned, but that I argue should periodically be questioned because there is some cost in diversity.
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.
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.
Copyright © 2007 by
HyperMeta Inc.
Click for important legal notices.