Standards, Stability, and Confusion
There are lots of articles and weblogs about standards-related issues recently. Simple news/weblog content syndication "standards" are in the midst of a power struggle, ... Web services management vendors may be squaring up for a standards fight ... Reliable SOAP messaging politics are bogged down or stupid, and so on. A few thoughts ..
Lots of people get annoyed that it takes a group so long to do what any competent individual could do more quickly and cleanly. The point is, uh, standardization. Sure you, or your favorite tool's vendor, can define terms, formats, APIs, etc. quicker and in some ways better than a committee can. There's a bazillion jokes on the basic theme "there would be so much less discord if the rest of you would just do it MY way! But then you usually end up with dozens of ways of doing the same thing, and that invites gravitation toward the biggest vendor in a space..
Standardization is hard -- it requires people with different perspectives and interests to (usually very laboriously) figure out what they really have in common and what that implies for the standard terminology (or data format, or API, or whatever). Even I (after 6 years of spending about half my working time on various W3C groups) am continually amazed at how hard it is to get agreement on seemingly trivial issues. Uhh, that's usually because they only look trivial ...
Standardization is messy. There plenty of jokes about standards and sausage making, along the lines of "those who appreciate sausages or the law should not watch either being made". Personality / politics is a big part of the process, don't let anyone tell you otherwise. But that's life: Lots of profound accomplishments were achieved by highly flawed personalities, groups, and processes. Just picking the first examples that come to mind, Isaac Newton was a seriously disturbed man and quibbled constantly about his "intellectual property," but he built the foundation for modern science and math; the politics that produced the US Constitution were pretty intense and gave the document itself some embarassing warts, but the overall result was extremely successful; and the interpersonal processes in the group that discovered the structure of DNA were pretty ugly, but again the result was profound. (Oops, I see that http://www.tbray.org/ongoing/When/200x/2003/08/04/RSS-Story ">Tim Bray made this point better than I could while I've been fiddling with this article).
The result of a standards process is rarely elegant. Here there is one canonical joke: "A camel is a horse designed by a committee." The analogy between racehorses and camels is actually a good one, but I'd turn it around: If you want to go fast around a well-prepared track, get yourself a racehorse. If you want to reliably reach a distant destination across unknown terrain, you are probably better off on a camel. Those committees can be sortof surrogates for evolution, pruning out the beautiful but high-maintenance features and insisting on the "humps" that look strange but add real value.
As much as I sometimes wish that we could somehow avoid all this, it's increasingly clear that well-defined specifications (not universally adopted legal standards!) are increasingly necessary. Some argue (see the RSS article linked above) that a formal standards process primarily benefits the big vendors who can invest in it and promote their own technologies. That's true enough, but the alternative is even worse: without rigorously defined criteria for what a "valid" document, message, or API is, the dominant vendor's implementation becomes the de facto standard. Furthermore, you can hardly benefit from test driven development if the tests themselves are best guesses based on what works with the dominant vendor's implementation; you'll never know if the test is right and your code is wrong, or whether you're simply introducing "bug for bug compatibility" that will hurt you if the original bug is fixed.
So what is to be done? I don't presume to think that much can be done to change the standards processes, but I do think that consumers of "standards" can adjust their attitudes in ways that work for them in the short run and the overall Web standardization culture in the long run.
- Ask yourself "can I reject documents that don't conform to the standard" before worrying too much about the details. The numerous variants and decendents of "RSS" are a case in point. I'm not going to ignore a source of news or opinion if they don't conform to one of the many alleged standards in this space, I'm going to use the most "libaral" tools that manage to extract useful information. But in other cases -- especially those involving money or security, or when transaction volumes are very high -- validity of a message against an agreed-upon standard is a prerequisite for accepting it, and the details matter very much.
- Judge the specs on their results, not their inputs or processes or the legal standing. The SAX XML API is a case in point -- it has no official standing whatsoever, but is so simple and useful that it is almost universally supported. That makes it more of a "standard" than something like ISO DSSSL or W3C XLink that simply haven't generated much of a network effect. If, somehow, the messy politics of the content syndication or web services sectors result in specs that are clean, useful, and widely supported, then the process has succeeded despite itself.
- Vote with your feet for or against specs based on whether they solve real portability and interoperablity problems. Vendors don't really have the luxury of ignoring official standards, but users do. (Actually, recent specs are more likely to have "interoperability profiles" or "minimum conformance levels" that reflect the business realities in the field rather than the political realities in the conference room, but that's another essay!).
- Accept that diversity, competition, and evolution is inevitable. No matter how convenient it would be for there to be one universal, stable standard in each domain, it ain't gonna happen, fuggidaboudit. In the early days of a technology, premature standardization is a worse problem than confusion. When a technology is mature, the way forward often involves taking a few steps backward. ( The Innovator's Dilemma has numerous examples that illustrate this). Knowing when it's time to non-standardize or un-standardize to allow innovation to flourish is as important as knowing how to create consensus and standardization when it's time for the network effect to work its magic.
At least one group of analysts more or less agrees, making the additional point that "the whole point to Web Services is to be interoperable. 'Fragmented Web Services standards' is an oxymoron that makes no business sense. And if there's no money to be made, then companies won't do it. "