Why multi-party stewardship of the OpenDocument Format matters so much

Why multi-party stewardship of the OpenDocument Format matters so much

Summary: Massachusetts' recent decision to standardize on the OASIS-chaperoned OpenDocument Format (ODF) as its statewide standard file format for saving and exchanging documents that are typically created by productivity applications has generated a huge amount of controversy.

TOPICS: Microsoft

Massachusetts' recent decision to standardize on the OASIS-chaperoned OpenDocument Format (ODF) as its statewide standard file format for saving and exchanging documents that are typically created by productivity applications has generated a huge amount of controversy.  Microsoft and its supporters have vociferously argued that the ODF format isn't technically up to the task of handling the document formatting requirements of a large enterprise as well as Microsoft's competitor to ODF: its Office XML Reference Schema.  The implication is that settling on ODF is mistake that any enterprise may later regret.

Despite questions regarding ODF's technical prowess, Massachusetts has moved forward on both ODF and Adobe's Portable Document Format (PDF) as a standard.  A big reason for this is that the degree to which a file format is open for use by all developers (as in open standards) is important to the Commonwealth's overriding goal of state sovereignty.  In the Commonwealth's eyes, it needs to be guaranteed that its 173 agencies, 80,000 employess, and more than 6 million citizens will have unfettered access to all of the state's public documents in perpetuity, regardless of what software they want to use to access those documents. 

To assure itself of attaining that goal, the state developed its own test for openness and one of that test's criteria was multi-party stewardship of the file format. This is where no single vendor or person is in complete control of the format.  Since ODF is stewarded by a multi-party technical committee at the OASIS consortium involving Adobe, IBM, Sun, and others (Microsoft has been invited but has so far declined the invitation), ODF passes the multi-party stewardship test.  The state is obviously comfortable with letting its goal of sovereignty trump any questions of technical prowess and here's why.

One of the beautiful things about the degree to which ODF is open is that developers are free to do whatever they want with it. For example, they can deconstruct it and come up with some new derivative.  They can also extend it to make it better (in the developer's and maybe even the end users' eyes).  They can remake it however they want to.  It's exactly that freedom to innovatively remix the format that eventually leads to improvements in the standard and hundreds if not thousands of interesting solutions that are in some way, shape, or form, connected with the ODF ecosystem. The same goes for the PDF format (Adobe just says you can't call it "PDF" if you remix it in a way that's no longer 100 percent compatible with the PDF format).   This stands in stark contrast to Microsoft's license for Office XML Reference Schema which has some open attributes.  For example, it is open to royalty-free use by any developer. But, Microsoft's license demands 100 percent compliance of its licensees thereby preventing any sort of remixing of the technology. 

So, why does this matter?  Well, lets say that a wiki solution provider like JotSpot decides it wants to support ODF so that its customers can make Jotspot interoperate with other document-oriented solutions.  For example, let's say you want to be able to use Corel Wordperfect Office to edit your JotSpot documents before saving them into a JotSpot wiki.   What if ODF doesn't support all the functionality that Jotspot has to offer?  Jotspot is not only free to tear apart ODF and rebuild it as they see fit (perhaps maintaining full ODF-compliance when exchanging documents with other ODF-compliant solutions), JotSpot can suggest and even contribute its enhancements to the ODF standard to make that standard better.  Further to the point of multi-party stewardship and such contributions, just look at the list of contributors to the final ODF specification.  It lists people from Sun, KDE, Boeing, the Society of Biblical Literature, the National Archive of Australia, the New York State Attorney General's Office (is New York next?) and Corel.  With such diverse interests represented in the development of the specification, it would be difficult for the single steward of a competing specification to argue that it knows better about what the world wants better than a multi-party stewarded specification.

Given ODF's multi-party stewardship, the ODF standard is far more open to incorporating such changes than would be a single-party controlled format since that single party may have other offerings that are threatened by the enhancements.  Although such conflicts of interest are not completely avoided by multi-party stewarded standards, their likelihood is significantly reduced by the transparency of the standards setting process.  For example, any single party's attempt to stand in the way of a worthy feature would have to be justified to the other stewards and ultimately the public.  That sort of transparency leaves little or no room for private agendas.  With single-party stewarded specifications -- for example the Office XML Reference Schema -- the steward is under no obligation to justify its rationale. 

The point here isn't to single out Microsoft.  In the case of ODF, it's just the best example because the Office XML Reference Schema is the only other productivity app format in the running in Massachusetts (by the way, it's still in the running, according to Massachusetts officials: more to come).  The point is that if a multi-party stewarded specification is technically under-serving its users in some way, there's a greater likelihood that the innovation that's encouraged by that specification's wide-openness will not only help to resolve those deficiencies, but will also take the specification to places that a single steward might never imagine.  Massachusetts knows this, which is one reason why its test for openness weighed much more heavily in its selection process than any of ODF's technical shortcomings.

Topic: Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • M$ Office is done

    I use it for document compatibility. I hate its UI...which always does things I don't want...or makes it hard to find how to do the things I do want. As soon as a standard format is widely accepted...I'm done with Office, and I expect many others are thinking the same way. Why pay so much for a sub-standard tool?
  • Interesting article for those following this issue

    I found this article by following some links that followed from David's article here. It's written by Andrew Updegrove, talking about MA's decision.

    But calling it "MA's decision" is a misnomer, as it turns out, because the decision does not involve the whole of the MA state government, just the executive branch. Still there are tens of thousands of computers involved. Updegrove reveals some other facts that haven't been talked about anywhere else.

    At the Sept. 16 meeting, Johnathan Zuck of ACT said that the enterprise standard looked like "a late paper". From reading Updegrove's article, I get a similar impression of the standard.

    The standard clearly states that the Executive Agency must commence migrating their systems to use applications that save to ODF by default, starting in Jan., 2007. Yet, in Updegrove's article he says the committee's FAQ on the subject says that users can continue using Microsoft Office after that date, and can even save in native Office format, but only need to convert to ODF when archiving documents. He also says that outside parties (contractors, lawfirms, etc.) can continue using whatever file formats they are now, to send documents to the state. There is no requirement that they change to using ODF in order to submit documents, even after Jan., 2007. He also says the standard does not mandate that all existing documents be converted to ODF. It may have been changed to say this. They're going to just leave them in their existing format. He says that only new documents, created in Jan., 2007 and after need to be saved in ODF for archiving.

    This sounds like a more reasonable policy, given their goals, and the difficulty of migrating technologies. I just wonder why they didn't state a lot of this up front in their standards document. Just from reading it, it makes it sound very cut and dry, but from reading Updegrove's article, it's not. Just a guess, but it looks like MA didn't communicate its intentions very clearly.
    Mark Miller