ODF Spreadsheet Bickering: What It Means to an Enterprise

Given that Microsoft's recent release of Office 2007 SP2 includes native support for the ODF file format, it was only a matter of time before Rob Weir (IBM) would find something he didn't like about it. On Sunday, May 3, he wrote a blog post entitled, "Update on ODF Spreadsheet Interoperability," saying that Microsoft had coded to the wrong behavior. He notes, "But I cannot fail to notice that the same application -- Microsoft Excel 2007 -- will process ODF spreadsheet documents without problems when loaded via the Sun or CleverAge plugins, but will miserably fail when using the "improved" integrated code in Office 2007 SP2. This ain't right."

Doug Mahugh (Microsoft) issued a returning salvo on Tuesday, May 5, in the form of a blog post entitled, "ODF Spreadsheet Interoperability." When Doug walked through Rob's documented steps, he found that Office 2007 did a better job of rendering the OpenOffice.org-created spreadsheet than Lotus Symphony (e.g., Days to Go equals "102" [Excel] rather than "of:B4-B3" [Symphony])."

I recommend that you read both blog posts, in that they highlight the complexities of coding to an ever-evolving open standard. However, look at the blog posts as an educational exercise--try to understand the arcane details, but don't get taken in by them. While the vendors would like you to believe that, "We're right--and they're wrong," the takeaway is the larger picture of, "ODF interoperability isn't here yet." Let me explain.

The whole reason for this debate is that ODF did not initially define formulas. If early versions of ODF had defined formulas, we’d never have this battle of the blogs. At the time that ODF came into being, it was clear that coming up with a standard for formulas was going to be a long and contentious battle. There were two schools of thought—(1) the "let’s take our time and do it right school" and (2) the "we can’t afford to wait; we’ll figure it out later" school. School #2 won.

In the ensuing standards vacuum most people decided to accept what OpenOffice.org was doing. That de facto standard strategy worked quite well for awhile. OpenOffice.org and Sun StarOffice used the same codebase, and then Lotus Symphony pulled its code from OpenOffice.org as well. However, this strategy started to fall apart as others (especially Microsoft) started to use the ODF spec and questioned the huge hole of, “How do I a write a conforming spreadsheet app if there’s no standard for formulas?” The Open Formula syntax (included in the yet to be approved ODF 1.2 standard) is the eventual answer.

To summarize, this in-between time (between the OpenOffice.org de facto standard and the wait for the officially approved 1.2 standard) means there isn't one way to handle this problem. The vendors would like you to believe that there is (their way), but in reality there isn't. Ultimately, this will resolve itself over time. ODF 1.2 will be approved, and there will finally be an approved standard that everyone--IBM, Microsoft, Sun (Sun/Oracle)--can follow.

Until then, if an enterprise does want to use ODF, the best strategy is to stick with one productivity suite as a way to avoid these interoperability problems. That way, even if formula support is idiosyncratic, it at least will be consistent within the enterprise.

Comments

[Dwight Wilbanks]

I agree with Arnd, Microsoft intentionally broke the compatibility, in the same way that IBM intentionally broke the compatibility with Symphony.

My only question is, why would IBM intentionally break compatibility and if IBM did not intentionally break compatibility and just made a mistake of some sorts, Microsoft surly should not be allowed to make the same mistake. Only IBM is allowed to make mistakes.

Oops, maybe the argument is just mud slinging and nobody did anything intentional.