Eric Raymond’s famous formulation in the Cathedral and the Bazaar was “given enough eyeballs, all bugs are shallow”. Since Code is text and Spec is text, so it is reasonable to ask if this same law might apply to reviewing a specification as well.
This proposition was put to the test this last weekend at GrokLaw, where a team of volunteers attempted to review the 6,000 page Ecma Office Open XML specification. Since the specification is already two-weeks into a 30-day review in ISO/IEC JTC1, a parallel approach was the indicated solution. The alternative, for each individual to review the specification in its entirety, would have required them to read at the rate of 200-pages/day for a month.
The team of around 20 contributors logged nearly 1,000 edits on the wiki they set up for their collaboration. The wiki received a further 4,000 page reads. This was done over a few days, but the bulk of the work was done just this weekend.
What they found is amazing. As you know, I have been reading the OOXML specification, on and off, for a few months now, noting in this blog the problems I’ve seen. I thought I had a good grasp of the problems. But I was wrong. I was just scratching the surface. The Microsoft guys think I have been complaining too much. But it now looks like I wasn’t complaining enough.
Take a look at the report. I’ll need a few days to read through the details and research some of the items. You can be sure I’ll follow up with some new posts to explain, in plain English, the significance of the new issues.
Also, GrokLaw has put out a call for concerned individuals to write to their nation’s JTC1 representatives, to give informed thoughts on whether OOXML should continue the process toward an ISO standard, or whether it should be taken off its current “Fast Track” because it contradicts existing standards. If you are a regular reader of this blog, you know what is at stake and you know what to do.
One final note. I’m so impressed with the results of this collaborative approach to standards review, that I’m going to investigate whether we can do the same thing at OASIS. We’ve been using a wiki internally for drafting new parts of the ODF 1.2 specification, and that has worked well. But I’d love it if the next time we had a public review period for ODF we could have the public also participate in editing content in the wiki and organize the process that way. It is a much better method than the non-interactive, linear pattern of a mailing list.
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.