Politics behind standardization

Stephen McGibbon has an interesting blog post based on his observations of the politics behind standardization. He's been involved in a lot of the ODF and Open XML discussions and started looking deeper into the reasons behind ODF going through ISO even though it was not yet feature complete.

I think there was a good amount of pressure to wrap things up and say that version 1.0 was ready to go. It will be interesting to see how much further they are able to get with version 1.2. It sounds like there will be a draft of that ready for review next summer and approved by OASIS in fall 2007 (http://lists.oasis-open.org/archives/office/200605/msg00005.html). I'm sure they will be able to make a lot of progress over the next year or so.

As I talked about earlier this week, it doesn't make sense for us (Microsoft) to join the ODF committee in OASIS. In the original post some folks felt that I didn't really clearly provide reasons why this was the case, but lower down in the comments I took another stab at trying to explain the reasons and I think most folks felt it helped to clear things up. Here is what I said (for those of you that don't feel like reading through comments).

"Bruce, Wouter, Simon,
I'm sorry if it appeared like I didn't answer the question. I thought I had actually made it clear why we weren't participating directly in the OASIS committee, but let me try to clear it up.

We ultimately need to prioritize our standardization efforts, and as the Ecma Office Open XML spec is clearly further along in meeting the goal of full interoperability with the existing set of billions of Office documents, that is where our focus is. The Ecma spec is only a few months away from completion, while the OASIS committee has stated they believe they have at least another year before they are even able to define spreadsheet formulas. If the OASIS Open Document committee is having trouble meeting the goal of compatibility with the existing set of Office documents, then they should be able to leverage the work done by Ecma as the draft released back in the spring is already very detailed and the final draft should be published later this year.

To be clear, we have taken a 'hands off' approach to the OASIS technical committees because:  a) we have our hands full finishing a great product (Office 2007) and contributing to Ecma TC45, and b) we do not want in any way to be perceived as slowing down or working against ODF.  We have made this clear during the ISO consideration process as well.  The ODF and Open XML projects have legitimate differences of architecture, customer requirements and purpose.  This Translator project and others will prove that the formats can coexist with a certain tolerance, despite the differences and gaps.

No matter how well-intentioned our involvement might be with ODF, it would be perceived to be self-serving or detrimental to ODF and might come from a different perception of requirements.   We have nothing against the different ODF committees' work, but just recognize that our presence and input would tend to be misinterpreted and an inefficient use of valuable resources.  The Translator project we feel is a good productive 'middle ground' for practical interoperability concerns to be worked out in a transparent way for everyone, rather than attempting to swing one technical approach and set of customer requirements over to the other.


Now, all that said, I think there are still plenty of ways we can help out the OASIS folks with the ODF format. The entire translator project is open source, so the conversion will be completely transparent and everyone will have the ability to benefit from what we discover as the transformations are built. In addition to that, as I've looked through our Ecma documentation, I've also been looking at the ODF spec as a point of comparison. As I come across areas that are either missing, or just not fully specified, I'll be sure to point them out on my blog. That should help them in creating a list of areas to improve.

I think we will really see some good discussions over the summer and fall. The Ecma spec is really getting close to completion, and we of course still have a large number of ways for the public to comment on the spec. Now with the open source translator project we'll all be able to clearly follow along with how the two formats compare and how you can go back & forth between the two.

BTW, for those interested in providing feedback on the Ecma spec, the main way to comment is via this e-mail address (mailto:ecmatc45feedback@ecma-international.org). You can also provide comments here on my blog and I'll pass them on. Of course the best approach though would be to join us in Ecma!