Related link: http://blogs.msdn.com/mikechampion/archive/2005/11/01/487718.aspx
The funniest post of the week award goes to Mike Champion's
>Two Approaches to Standardization in which he advocates standards made by rubberstamping whatever
MS comes up with behind closed doors, after MS has graciously incorporated casual feedback from various stakeholders at progressively increasing distance from the people with the power.
It is funny for two reasons. First because, even though it is 'definitely what is in favor at Microsoft these days' Michael doesn't give any examples of the process actually working (are there any examples at Microsoft?) I don't think informally chatting to people at a developer's conference counts as a credible approach.
The second reason it is funny is because the essense of a standard is agreement, not dictatorship. At any stage before ratification, a standard has to be amenable to be changed in ways that the originator didn't like. And all the parties who buy into the standards process should have a commitment to track the standard.
A standards process for new technologies is credible only when an interested outsider can become an insider and have a formal influence with just as much strength as the original proponent of the technology: ISO=good; OASIS=good; W3C=good; JCP=good; chat in the donut line at PDC = no good.
To me, the two credible approaches to standardization are
either for a standards organization to rubberstamp a
mature and multiply-sourced non-proprietary technology (such as TCP/IP) or to collaborate on consolidating existing experience into a new standard. The whole point of a standard is to prevent one party from having control: it is difficult to see PDF as a standard in that sense for example.
Obviously, post-Mass., standards are suddenly not the flavour of the month at MS and I advise my gentle readers amuse themselves by spotting more slagging of standards over the remainder of 2005. Standards by Committee! Only produce large monstrosities!! err but XML was a very large committee and made a very small thing? No: XML is enoooormous, bigger than the planet, it must be because it was made by committee!! err, but XML came about because of users having the freedom to revise an existing technology, and that techology (SGML) itself came about because of people having the freedom to revise the company-provided base technology (GML)? Then Look at XML Namespaces!! err, but didn't XML Namespaces get resolved outside the committee process? (Fill in your own flimsy examples and counter examples ... )
Categories
Web
Comments (1)
Read More Entries by Rick Jelliffe.
re: the donut line
" the essense of a standard is agreement, not dictatorship. At any stage before ratification, a standard has to be amenable to be changed in ways that the originator didn't like."
That's a good point. My counterpoint is that changes that undermine the conceptual integrity of the spec in the name of gaining consensus are not a good thing. I don't have success stories to cite, bjt I will predict that in the hindsight of history, the C# development and ECMA standardization process (over which one person essentially maintains veto power) will prove more successful than the Sun / JCP committee-driven process. We shall see.
More importantly, the marketplace is the "dictator" in either case. Ultimately it is industries, not companies or organizations that create "industry standards".
Nobody laments the passing of The Bad Old Days of IBM or Microsoft or Adobe just having their proprietary stuff labeled "standards". I for one won't lament the passing of the Bad New Days when people agree in advance to accept whatever some committee comes up with as a "standard", sight unseen. This literally happened with Microsoft and XSD, and it left a bad taste in people's mouths. We all suffered because MS's premature support for XSD gave the spec credibility it would not have earned on its own merits. (FWIW, my biggest surprise when joining MS was how the developers here hate XSD as badly as developers everywhere; no one believes me when I tell them that many on the outside hold MS largely to blame for the wretched thing. This was a classic case of good intentions all around paving the road to Hell).
" The whole point of a standard is to prevent one party from having control: it is difficult to see PDF as a standard in that sense for example"
I agree that the whole point of standardization is to remove a spec from proprietary control. As I understand it, PDF is a "standard" because Adobe has ceded control over the published spec (it can't somehow invalidate the PDFs that conform to the published spec or prevent others from supporting it), even if it retains the right to evolve the spec further. I think that's the situation with C# as well -- MS can't prevent anyone from doing what they want with the ECMA standard, but reserves the right to evolve the language further. ECMA of course retains the right NOT to rubberstamp the next version. Something like this, where standards organizations *evaluate* specs and decide whether to give them their imprimatur, but don't convene committees to design them from scratch, is what I'm suggesting as a better approach to standardization than what W3C typicaally does. (The W3C could do something like what I suggest, by using XG's to do the design by committee stuff and convene Recommendation-track WGs to evaluate and refine specs that have some actual track record, so don't take this as a dismissal of W3C itself).
As I indicated, the closest thing to an actual example of what I'm talking about in the XML world is the process that creates most of the WS-* specs. Admittely, these are not clear success stories at this time. I don't think their lack of obvious success stems from the process in which MS, IBM, and generally a couple of other companies maintain something of a veto power. (The review process is much more stringent and open than "the donut line at PDC", but I like a good tag line so I won't complain). All I can say that it now seems that the IBM-MS-etc. original W3C Notes for things like SOAP 1.1 are more widely adopted "standards" than the eventual W3C Recocmmendations, but admittedly there are a lot of complicating factors here.