Microsoft's ODF shotgun wedding

Well, by now most have read that Microsoft will be sponsoring a third-party open source add-in for Office which will enable its Office products to read and write ODF files. This capability will be made available to older versions of Office through compatibility packs. For Office 12, the feature will be downloaded from a page devoted to third-party add-ins reached through menu options in the new product. This is the same method of distribution used for Microsoft's PDF conversion add-in, though that product is a victim of Adobe deciding that antitrust is a useful way to prevent large competitors from implementing open standards (which PDF supposedly is).

My opposition to Massachusetts' decision to standardize on ODF, and to a lesser extent, PDF, is fairly well known. I don't oppose so much that ODF is on the list of approved document formats. Rather, I question whether it makes sense to shut the maker of a product that accounts for over 95% of the marketplace, and who can be reasonably concluded to know a fair bit about Office document requirements.

My opposition, however, doesn't change the facts on the ground. All I have to say is: be careful of what you wish for.

Many fans of ODF hope that its spreading popularity will boost usage of OpenOffice, an open source office suite that supports ODF natively. That seemed more likely while Office stuck to its guns and refused to support ODF. With ODF support not just available as a third-party add-on, but sponsored by Microsoft, that makes Office a great tool for generating ODF.

That matters, because Office popularity in businesses isn't just due to its file formats, but it's status as an application development platform, a host for office-related business applications, and it's huge array of features. As Microsoft has noted:

...OpenDocument still has gaps that are being worked out by OASIS, such as spreadsheet formulas, macro support and support for accessibility options. Citing Open XML's accessibility features for disabled workers, file performance and support for integrating external XML data, Microsoft says ODF "focuses on more limited requirements."

Now that Office supports ODF, at least as an add-on, there's one less reason to use another tool, particularly if it doesn't have all the features of your current product.

On the feature front, Microsoft is also likely to stay further ahead due to the slow process by which standards are advanced. Therein lies the blessing and curse of standard formats. Standardized formats are a fixed target at which software developers can aim. It is so fixed, however, that it can be difficult to advance iwithin reasonable timeframes. That is less of an issue if the market in question moves slowly. TCP/IP, as an example, is not a technology that requires rapid innovation. It is more of an issue, however, if the market still has lots of innovation left in it.

Some will claim that Office products now do everything they need them to do. Perhaps. On the other hand, never underestimate the power of people interested in finding new ways to convince customers to part with dollars to find life in formerly stale product lines. In 10 or 20 years, do you think Office suites will still be doing the same sort of things they do today?  I don't think so, and I think even OpenOffice will have to veer from the standardized straight and narrow in order to keep up with a Microsoft product which will move as fast, from a feature standpoint, as it wants (yes, Office XML will be standardized, but then again, so is PDF, and Adobe continues to update the format).

Microsoft clearly didn't want to support ODF. The fact that they now do, however, is a sign that they have realized that ODF is less of a threat than they once thought. That's a good thing to realize, and I hope that realization percolates elsewhere across the Microsoft product ecosystem.  Microsoft will always want control over the formats it uses in its products.  That doesn't mean, however, that the right option is to make it hard to use other file formats.