‘The noisiest of those competitive battles (between suppliers) will be about standards. The eyes of most sane people tend to glaze over at the very mention of technical standards. But in the computer industry, new standards can be the source of enormous wealth, or the death of corporate empires. With so much at stake, standards arouse violent passions ‘
The Economist, February 23, 1993.
It is rare for the friction that is inherent in any standards-making body bursts out into the open. When Eran Hammer wrote his blog post ‘OAuth 2.0 and the Road to Hell‘, he was articulating the frustration of many developers who see standards evolve in the direction that suits large commercial interests rather than the individuals that use the standards. OAuth is something we very much need, but it must be clear, simple, and functional. OAuth 2 isn’t, though it can be made to work.
The IT industry doesn’t like standards, even though we all believe that they are, in principle, a good thing. There is always going to be a difference between the standards that developers want, and the standards that the vendors want to provide, and the vendors are far better placed to have their views put in front of the standards committees. This is as true of HTML5, or SQL as it is of OAuth and Eran just drew attention to a process that seems to seasoned IT professionals as being part of the human condition.
Carl Cargill’s brilliant essay on Why Standardisation Efforts Fail identifies several causes,
- The standard fails to get started.
- The standards group fails to achieve consensus and deadlocks.
- The standard suffers from “feature creep” and misses the market opportunity.
- The standard is finished and the market ignores it.
- The standard is finished and implementations are incompatible.
- The standard is accepted and is used to manage the market.
Just occasionally, starting with PL/1 the industry looks at what is done in disgust and adopts a simpler system, Cobol in this case. With Algol 68, it was thanks to members of its design committee such as C. A. R. Hoare and Edsger Dijkstra speaking out against its overbearing complexity; the result was Pascal’s widespread adoption. XML spawned JSON as result of the revulsion at its complexity. At other times, the Standards Bodies fail altogether, as has happened with the task of providing an open standard alternative to the proprietary MPEG4.
The most enduring standards are those that were made retrospectively on existing successful technologies. Committees make bad technologies, especially when they don’t even share the same goal. Eran Hammer isn’t the first to discover this, but it is great to make a new generation of IT Pros aware of the downside of the standardisation process.