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.