Article

Golden's Rules: The real story behind the Massachusetts ODF flap

Bernard Golden, Contributor

You've probably been exposed to the brouhaha going on regarding Massachusetts' decision to mandate use of the OpenDocument Format (ODF) as a file storage mechanism for documents created by all state agencies.

Bernard Golden

    Requires Free Membership to View

Boiled down, the discussion goes something like this:

Massachusetts has a responsibility to make its documents available to all interested parties. In addition, it must make them available for extended periods. Just as you now can see 200-year-old documents relating to the state, future generations will need to have access to documents created in the 21st century.

Concerned that current computer file formats may become outmoded and inaccessible due to application unavailability in the future, the State Information Technology Division (ITD) decided that, starting in 2007, all state-generated documents would need to use ODF. Based on XML, ODF is a standard created by OASIS.

Using a standard format to store documents increases the likelihood that it will be possible to view them in the future since many different applications can access the files. Proprietary vendor-specific formats run the risk of being abandoned as vendors update or abandon their application, leaving no viable way to view the documents.

While ODF is mandated, the application used to create documents is not; any application that can read and write ODF can be considered for use by state agencies.

So far, so good.

Except Microsoft is very upset with this. It insists that its XML-based file format should be included as an acceptable file format. While the ITD considered the Microsoft format during the deliberations and hearings that were part of the decision process, it ultimately decided against including Microsoft's file format.

Now Microsoft has counterattacked on three fronts.

First, Microsoft has made disability advocate organizations aware of this decision; quite rightly, these organizations are concerned that they would lose the accessibility-oriented features of Microsoft Office if other less capable applications were mandated as part of this policy.

Second, Microsoft has reached out to a couple of politicians in Massachusetts and gotten them to object to the process of this decision. The politicians have raised issues that mandating ODF would also mandate use of OpenOffice and that OpenOffice's open source license would mean that any commercial product that attempted to comply with the mandate would also become open source. This would certainly cause commercial vendors to avoid participating in Massachusetts IT tenders, thereby reducing choice for the state.

More Golden's Rules:

Golden's Rules: Helping open source 'cross the chasm'

Golden's Rules: Open source sendmail in the enterprise

Third, Microsoft has stated that its XML file format supports richer functionality than ODF. If Microsoft was forced to use ODF, it would be unable to offer this richer functionality. Furthermore, Microsoft believes that the licensing conditions of its XML file format are open enough for the state's purposes.

With respect to the first two arguments, Microsoft is going to have some very angry ex-allies when they become aware that there is a significant difference between application and output, and that mandating an output format has nothing to do with the application creating the output. Nothing irritates a political player more than finding out that he or she has been taken advantage of for someone else's agenda. In any case, these two arguments are just cover for the real issue Microsoft has, which revolves around the third issue: control of file formats.

Microsoft quite clearly understands that controlling the file formats of documents is a life-or-death proposition. If it is forced to support an externally defined standard, the company's office products become one of a number of potentially acceptable applications for office productivity requirements. For Microsoft, the ODF decision by Massachusetts is the thin end of a wedge that will splinter its desktop monopoly.

Furthermore, Microsoft wants its office products to be part of an all-Microsoft IT infrastructure. Office-created files will be shunted around .NET-based applications, made available by Microsoft-based SOA services, and stored in Microsoft-provided databases. Without special Microsoft file extensions, the whole hairball becomes significantly less intertwined. Standard file formats enable a mix-and-match infrastructure.

Finally, of course, Office is a huge business for Microsoft. It is one of its two franchises, bringing in billions of dollars of profit to the company. Reducing the torrent of Office cash threatens the entire panoply of money-wasting Microsoft initiatives.

So it's easy to understand Microsoft's motivation in this whole matter. Of course, it's going to drag in every possible argument, coerce every possible ally, voice every possible threat.

What of the rest of us? When I think of this situation, I'm reminded of two words: Token Ring. Twenty years ago TCP/IP and Ethernet weren't the obvious solution for networking as they are today. IBM, which had a default monopoly for computing, offered a complete technology solution based on its proprietary architecture. It had a grand, overarching vision called SNA. It had a transmission mechanism that it claimed was better than Ethernet called Token Ring. IBM derided TCP/IP and Ethernet as too simple and insufficiently scalable.

What TCP/IP and Ethernet had going for them was that they were simple, open standards that anyone could create products for. We all know how the story turned out. The simple, cheap solution defeated the complex, expensive one, because organizations like to save money and implement infrastructures that are easy to manage.

But there's more to this story than cheap and simple beating expensive and complex -- and that's why the ODF situation is important to everyone.

Because TCP/IP are simple, cheap standards, it meant that many players could innovate in many different places within the network infrastructure. So switches were swapped in to avoid the collision issues present in early Ethernet networks. Routers interconnected networks. And because this cheap infrastructure was available, new products and services could be plugged in and obtain volumes that enabled low pricing, which spurred adoption, which spurred more volume and even lower prices.

Without the victory of TCP/IP, things we take for granted today would never have been possible -- Ebay, Itunes, VoIP. None of them could have been price competitive enough to achieve adoption. And none of them could have been predicted at the time of the TCP/IP vs. Token Ring shootout. (Incidentally, Microsoft did its part in this victory by incorporating a TCP/IP stack into its operating system, enormously simplifying the rollout of networks. It's unfortunate it isn't playing the same role in this situation.)

Similarly, standardized file formats like ODF will enable applications and services we can't predict. With massive amounts of information available with a structure that enables easy trawling by an enormous number of applications, who knows what will come about? We do know, however, that restricting ourselves to a single vendor solution limits us to the imagination of that vendor rather than the shared imagination of the entire world.

About the author: Bernard Golden is CEO of Navica Inc., a systems integrator based in San Carlos, Calif. He is the author of Succeeding with Open Source (Addison-Wesley, August 2004) and the creator of the Open Source Maturity Model (OSMM), a formalized method of locating, assessing, and implementing open source software.


There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: