Game over for OpenDocument?

The problem is that requirements differ at the enterprise level, which are heavily invested in fully automated business processes. In such situations there is no opportunity for manual inspection of documents for conversion artifacts. Flawless integration of applications is mandatory, and the existing inventory of enterprise documents is stored in Microsoft binary formats. The quality (fidelity) of document format conversions must be very, very high. Does it matter? Would you want your doctor to perform surgery on you while making decisions from an automatically generated history of laboratory testing results that contained errors due to data conversion corruption?

And from a legal standpoint, laws around the world effectively mandate 100% fidelity in migrating binary documents to XML. See e.g., E-SIGN Act, 15 U.S.C. 7001(d)(1)(B) : (electronically preserved records must "accurately reflect[] the information set forth in the contract or other record" and be "in a form that is capable of being accurately reproduced for later reference, whether by transmission, printing, or otherwise"); Sarbanes-Oxley Act, 15 U.S.C. 7261(b) (financial information must "not contain an untrue statement of a material fact"). In fact, it is rare to find a records retention law that does not require stored records be accurately preserved.

From a broader view, the world has 15-plus years of building business processes with fully integrated applications and other client/server integration, all atop the MS Office application suite. These business processes are hard-wired to MS Office, the familiar monopoly vendor lock-in product.

So the barrier for ODF applications and ODF is twofold. Any implementation of ODF must overcome both the barrier of converting Microsoft's legacy binary documents to ODF, then be able to integrate with the MS Office-bound business processes, without corruption of data. This entails virtually flawless round-trip interoperability, without loss of data, what has been referred to on the OASIS OpenDocument TC as the "high-fidelity migration and business process use cases."

The cost and disruption of a rip-out-and-replace migration to ODF at the enterprise level is impossibly high. The City of Munich, Germany, for example, spent more than $3,500 per seat to migrate from Microsoft Office to OpenOffice.org, with most of the expense attributed to file conversion expenses and the costs of replacing business process scripts. See also Finland Ministry of Justice, Migrating a Ministry to OpenOffice.org. ("A complete migration to OpenOffice.org was not considered a practical option due to the Microsoft technology based application integrations in the document handling of the Finnish Government.")

Yet rip out and replace is the only solution ODF vendors offer governments with high-fidelity integration and migration requirements. But as was said by one of IBM's experts in service-oriented architecture: "Because most companies have a significant investment in their legacy infrastructure, management is typically not open to ripping out and replacing legacy systems, regardless of the level of shortcomings evident in the infrastructure. Rewriting or significantly modifying large portions of a legacy environment is neither practical nor realistically accomplishable in a reasonable time frame."

It's too bad that IBM's office productivity software executives never got that memo. IBM and Sun Microsystems remain the staunchest advocates of rip-out-and-replace migration to ODF and of a continued interoperability barrier between ODF applications and Microsoft Office. They apparently believe that excellent support for ODF in MS Office would prolong the life of that product. They seem oblivious to the fact that high fidelity interoperability is key to ODF applications' infiltration of Microsoft-bound business processes.

Is there a way around this impossibly high double barrier? Yes, but it involves the use of an internal ODF plug-in for MS Office.

This should not come as a surprise to the file format cognoscenti because the internal plug-in route is exactly how Microsoft migrates existing documents and business processes to their own OOXML formats, MOOXML. Internal ODF plug-ins are simply clones of the MOOXML plug-in, installed through the MS Office 2007 Compatibility Pack in earlier versions of MS Office.

Massachusetts decided to go the plug-in route after conducting a year-long ODF Pilot Study. Before the Study was even complete, Massachusetts ITD realized the impossibility of the dual barriers. They issued an unprecedented Request for Information concerning the possibility of a ODF plug-in for MS Office. They wanted a plug-in that would be able to internally convert documents so transparently and with such high fidelity that there would be no disruption to existing business processes. That would allow time for a phased migration to other ODF applications as business process scripts were adapted or replaced.