How to urinate on a violin

The story of OOXML and in general the story of proprietary formats and protocols being used and promoted to control the market and the access of citizens to digital re sources is a long but fascinating one. The three (yes, three) last episodes of the OOXML story are a good example of that.

Ever since Wednesday night, three important news were announced. Let me comment each of them as briefly as I can.

• Microsoft will not support the ISO standard sometimes referred to as OOXML in its current set of office solutions, Microsoft Office 2007 and 2008 (for Macs). The formats used by Microsoft are also called OOXML, but they are not the same as the ISO/IEC 29500 standard. Confusing? Hmm, yes. That one, about which we know very few besides that the ITTF refuses to share it with the world, will be implemented by MS Office 14, the next version Office around 2010 or 2011. And me who thinks there were hundreds of OOXML implementations? Where are they? Gone, gone, gone, with the wind, just like the Old South of Scarlet O’Hara, a fantasy of past times, which OOXML today turns out to be.
• I willingly put the news item on the lack of support of OOXML by Microsoft Office 2007 first, because I get the feeling that these are the most important news here. But if you check the source , you will also see the other very important news item: Microsoft will integrate the native support of ODF in Microsoft Office 2007. This calls for several comments. First, what Microsoft will do exactly is left to be seen. We are told that the ODF support will come with the Office 2007 Service Pack 2 that will be released in 2009. That’s a long time before the market can benefit from ODF in Microsoft products. Perhaps more disturbingly, Microsoft announces the support for ODF 1.1. I understand that’s the majority of the ODF documents out there, and I would understand this as being a very pragmatic choice if its support was not scheduled in 2009, that is, months and months after ODF 1.2 will be released (at least as definite specification). That is something I have trouble understanding. The second question I have is what kind of native support we’re talking about. I am inclined to think that we might have an actual quality support of ODF in Microsoft Office, but integrating a converter such as the existing ones or providing lousy support -on purpose- will not do the job. The market wants real, native, effective support of ODF (real-world version) in MS Office as soon as possible and with no strings attached. All things considered, I do however genuinely applaud Microsoft’s move and find it useful and welcome provided that no games are played and transparency and openness are respected.
• Microsoft is also announcing its participation to the OASIS ODF Technical Committee. One less well contemplated element in this news is that Microsoft announces that their OSP (Open Specification Promise) will cover ODF. I don’t know what to think about it at this stage, so my opinion will be transitional (no pun intended here). I am not sure how useful this is, as the OSP conveys no rights and is notably unsafe for Free Software implementations, dixit the Software Freedom Law Center. In short, I don’t like that announcement about the OSP. It smells bad, or at the very least dubious. In the same train of thoughts, I believe the OASIS should be wary of what Microsoft really wants to do inside the ODF TC. But here again, I am applauding the move by Microsoft, although I suspect them of having ulterior motives.
• Last but not least, the South African Bureau of Standards (SABS) has filed an appeal to the ISO/IEC today against OOXML . This is an important decision. I believe that the whole OOXML standardization process has turned into a farce, and many think the same. Perhaps the ISO will deem this appeal receivable, unless their strange world-logic will make them feel offended by this request. In short, the latest announcements should not all of a sudden redeem Microsoft for what they did to the standardization, the industry, and the citizens at large. The software vendor has actually managed to destroy trust of many people, including the European Commission, who now wants to check how well Microsoft will play with ODF . Old world’s paranoïa? No. But somebody’s got to do something about it, somehow.

The points above call for some closing comments. How will this affect the industry? It is too early to tell, and besides, these are just announcements. We will see what kind of beef will be served later on. On the front of open standards, this could be a moderate success. If Microsoft walks the line, we will see an expansion of interoperability across the industry, the users and the vendors; but we’re still waiting for Microsoft Office to use ODF by default.

In the end, this will have been a tremendous waste of time. I’m sure that Microsoft will try to gain some advantage from OOXML, as broken as it is. They could try to reproduce what they managed to do with .NET and CLR by standardizing and opening only a subset of the .Net API , thus letting Novell create a very limited .Net implementation, Mono. Regardless of what the future options could be, the OOXML standardization will prove to be the single most destructive episode of the standardization history. No other standard will have been paid so dearly to achieve so few, while in the real world, the unspecified file format called OOXML and used by Microsoft Office 2007 will continue to lock in generations of users; Sharepoint will not stop using OOXML, as Matt Asay points out. All this, to put it to rest, begs one and final comment, led to nothing more than what we had start off with: a real open standard (ODF), a proprietary format, and the vague premise of an ISO standard. Urinating on a violin would not have taken us any further.