Of Open Standards, Interoperability and Open Source

June 04, 2009

Posted by: Glyn Moody

One of the key moments in the rise of open source was when Massachusetts announced that it was adopting an open standards policy for documents.

Since this was a gauntlet flung down for the dominant supplier in this space, Microsoft, it was inevitable that a battle of epic proportions would result. In fact, it turned out to be a very dirty fight, degenerating into ad hominem attacks on the person behind this move to open standards.

In some ways, it was a prelude to the equally ugly struggle that took place over Microsoft's attempts to ram its OOXML standard through the ISO process – another important moment in the rise of open standards.

The attempt to bring in open standards in Massachusetts largely failed; just why that is the case is the subject of an interesting new essay in First Monday:

Governments around the world are considering implementing or even mandating open standards policies. They believe these policies will provide economic, socio–political, and technical benefits. In this article, we analyze the failure of the Massachusetts’s open standards policy as applied to document formats.

The central thesis of the feature is the following:

In the case of Massachusetts, the ODF mandate was set in 2005. At the time, ODF was an immature standard. ODF 1.0 was approved as a standard within Organization for the Advancement of Structured Information Standards (OASIS) in May 2005 and ISO in May 2006. Only OpenOffice.org could natively save documents in the acceptable document format (ODF) at the time of the policy. ... The other implementations of ODF shared the same source code as OpenOffice.org therefore they were not independent. There was no running code for ODF in 2005.

This is certainly a fair point: when Massachusetts opted for open standards, ODF was the only option, but was still somewhat rough. In particular, OpenOffice.org was the only full implementation of ODF.

But the authors of the paper then go on to draw an erroneous conclusion:

In other words, the process in Massachusetts was akin to switching vendors for office software. While ODF was an open standard, multiple implementations did not exist, so Massachusetts was effectively locked into OpenOffice.org. This is why we believe in the case of Massachusetts, the open formats policy, as constituted in 2005, was better understood as an OpenOffice policy rather than a policy seeking competition and choice for government.

Whether or not the Massachusetts was indeed a move to OpenOffice.org rather than to ODF is a side issue: moving to either ODF/ОpenOffice.org was *not* “akin to switching vendors for office software”, with a similar lock-in before and after. The point is, OpenOffice.org is open source, so at the very worst, Massachusetts had the option to *commission* a third party to fork the code and develop it as they wished. This was – and is – never possible with Microsoft Word. So Massachusetts always had an essential freedom with OpenOffice.org/ODF that was absent with Microsoft Word.

It's true that at the time of Massachusetts' move, there was only one full implementation of the ODF standard; it's also true that even today, things are not perfect:

The OpenOffice.org lock–in has still not disappeared in 2008. In another study, we have shown significant interoperability issues between various ODF implementations, e.g., OpenOffice, WordPerfect, and KOffice (Shah and Kesan, 2008).

We found considerable variation among how well each implementation performed. For ODF, the compatibility scores ranged from a raw score of 151 for OpenOffice.org (100 percent — weighted percent) to 48 (55 percent — weighted percent). As a result, the study warns that adopters of ODF will effectively be locked–in to OpenOffice.org, unless they are willing to suffer problems in translating documents between implementations.

To call this “lock-in” is even more misleading: since there is no lock-in with one open source implementation, there is even less when there are multiple open source solutions, albeit imperfect. Unless, of course, you want to call it a lock-in to freedom.

In fact, this obsession with perfect interoperability misses another crucial point, which is that there will *never* be anything like a perfectly-compatible solution with Microsoft's OOXML, given the 6000 pages of documentation, and the presence of opaque binary blobs. Compared to that situation, ODF is *already* far better, in that there are multiple solutions with good, if not 100%, interoperability.

Moreover, their open source nature means that any user can, if they so desire, make any of them better in precisely the areas of concern – that doesn't sound like lock-in to me. This is a fundamental freedom for open standards implemented in open source that Microsoft's rival solutions will never have (unless they, too, are released a truly open source code – something I believe will happen one day, in fact).

Follow me @glynmoody on Twitter or identi.ca.

Newsletters

Our Daily & Weekly Newsletters highlight breaking news, vital issues, expert analysis and solutions to help you stay ahead of developments in the industry.