Why Open Document Failed In Massachusetts and How it Could Have Been Different

Overview

When the State of Massachusetts announced that government agencies would adopt Open Document Format (ODF) -- an open, XML-based word processing file format developed by the OASIS consortium -- as the official format, talks of a domino effect across the country quickly ensued. The idea was that Massachusetts would become a pillar of open standards, and too large of a market for Microsoft to ignore -- the current monopolistic vendor of the Microsoft DOC format. Many concluded that Microsoft would need to support ODF because the demand created by Massachusetts would be large and "delaying support for OpenDocument [would] drive people to ... OpenOffice.org", as said by one ZDnet article.

In my blog, I took the lonely position (as an open-source advocate) with disagreeing with this view. I argued that Microsoft did not have to bow down to any standards body because they already monopoly on the market, and adopting it would give competitors an edge. While quite symbolic, the actual user base transitioning away from Microsoft would be equivalent to a mid-cap company. Also, most of the public will probably access government documents with the PDF format, a closed format which Massachusetts made an exception for. I suspected that if the state went forward with implementing ODF statewide Microsoft would wait for as long as possible and not "legitimize" the format by adopting it. Microsoft would then prey on the problems caused by the transition (as with most transitions) and keep to its message that ODF is an "immature format", not worthy of their suite. The battle continued in multiple fronts. Microsoft insisted that they would not support ODF, but suspicion grew that they would.

The state recently sided with Microsoft, but the battle has continued.

Although I admire Massachusetts for standing up to Microsoft and supporting open standards, I think that in their rush to be the first state to snub Microsoft they missed many important details to have a successful transition. The policy took the top-down approach, which is ultimately more difficult implement because if it encompasses the entire organization would most likely expose a wider array problems. The policy change did not address the needs of the users and focused on the importance of the movement.

Taking Microsoft to war over document formats meant that Massachusetts was tying itself to ideology and not technology. Although ODF was an international standard, no one really knew if the office suites that supported ODF were going to address the diverse user needs in wide scale deployment. Supporters of ODF taunted Microsoft to support ODF. They argued that Microsoft was locking itself from a large market, but Microsoft knew that if it did, it would create more competition and a lower of price in office software. Not surprisingly the biggest problem that arose on many of the suites that supported ODF was lack of comprehensive support for users with disabilities. Even The director of Web technologies, Tim Bray, at Sun Microsystems said that StarOffice and OpenOffice do not yet address all the needs of the disabled.

Although ODF is an OASIS standard and not necessarily tied down to open source, in it's current state both are currently very closely tied. The biggest implementers of ODF are open source projects, such as OpenOffice.org and KOffice. Sun's StarOffice 8 is so far the only notable proprietary commercially-supported product but has even smaller market share than OpenOffice.org. Eric Kriss, Massachusetts' secretary for administration and finance told the Washington Technology: "We want to put more focus on thinking about where open-source products can fill some of our needs." Except that you must be sure that hose open-source solution covers all your needs and the move isn't modivated by ideoligy.

One thing that I have learned over the years that most people are not interested in ideology or politics, especially when it comes to software. A user does not care whether an application is programmed by a bunch of hobbyists, scientists or a corporation and they do not care if an application follows some international standard. I think this is perfectly demonstrated by the fact that Internet Explorer has never rendered a page properly, yet most people don't care. What people care about is that the program does what they want. I, like most FOSS guys, try and sell the great benefits brought by open source to friends and family. I also often sprinkle some ideology to for those who it might strike a chord with. But in my experience, when a user says he uses Photoshop my monologue changes tone. I force anyone to use the the Gimp and explain "it's not bad it's just different" or "the UI is a bit different you'll get used to it" as some people do (and I used to). I also do not want to explain that they can use Photoshop with this program called Wine, which is like an emulator but not really an emulator. Why? Because I rather that they get an good idea of open source projects with projects I believe are superior to their proprietary counterparts. I prefer to show people the great features Gaim, Eclipse and Firefox. These people often become fans and tells their friends and so on. Open source has always been a grassroots movement and it's strengths are in the ability to begin small and grow into the market.

Which brings me back to the state of Massachusetts and ODF. If we start using ideology before technology when it comes to making decisions about applications then this fiasco in Massachusetts will happen over and over again. OpenOffice.org, for all it's great features, is not yet as feature filled as Microsoft Office. It might be good enough for you and me, but thorough testing must be done before deployed at a wide scale.

I think these steps would have resulted in a better outcome for ODF in Massachusetts:

1. Deploy an ODF compatible Office suite, such as Open Office in smaller departments. Save files as DOC format by default.
2. Deploy an ODF compatible suite to all major departments, minus those with special needs. Save files as DOC format by default.
3. Analyze user feedback and begin incorporating features into ODF compatible suite. Save files as DOC format by default.
4. Deploy across all agencies with ODF compatible suite. Save files as DOC format by default.
5. Change policy to use ODF as official format of government and deprecate DOC.

Full Story