Given latest in OO-XML vs. ODF, Microsoft must reconsider its support for ODF
OO-XML is a new Microsoft-authored XML-based productivity format that Microsoft would prefer to see the world adopt as a standard. Its position of strength is Microsoft's market share and its ability to drive new defacto file format standards into the market with Microsoft Office. For example, even though there are other productivity formats in the market today, the defacto standards for document interoperability between different entities is usually one of Microsoft's existing formats for Word, Excel, and Powerpoint. ODF has its roots in the Sun-chaperoned OpenOffice.org but garnered support from the tech industry and a limited number of big customers when it was completely unencumbered from any intellectual property strings and it was placed under the stewardship of multiple parties under the auspices of OASIS, an industry consortium.
Over the years, ODF has proven to be a thorn in Microsoft's side. With the executive branch of Massachusetts' state government as one of the first key battlegrounds, Microsoft had to level the intellectual property playing field by "opening up" OO-XML and putting it on near par with ODF in terms of who could implement it and how. That capitulation was borne out of the customer concern that software developers (including open source developers) were not completely free to develop software that supported Microsoft's file formats.
Then, in an effort to address concerns that Microsoft's sole stewardship of OO-XML could lead to evolutionary steps in the format that prioritized the interests of Microsoft over the interests of the industry and customers, Microsoft handed stewardship of OO-XML to Ecma, a multi-vendor consortium based in Europe. I won't dwell on this move here. But if you Google Ecma, Office Open XML and Microsoft, you'll find a plethora of news and pointed commentary including some from me that puts the move in a critical light. Even so, the bottom line is that it was another capitulation on Microsoft's behalf in its effort to keep ODF from derailing OO-XML.
Eventually, the battleground moved to the international stage where the vendors behind ODF put the format in front of the International Organization of Standardization (the ISO) for consideration as an international standard: an imprimatur that it eventually earned. Although it's behind in the race, OO-XML is also on the ISO's list of technologies to consider as an international standard (ironically, the ISO has no compunctions about ratifying multiple international standards for doing the same thing). I've had a thing or two to say about this situation as well.
As the list of customers interested in ODF grew and in recognition of the business it could lose if those customers were unable to use Microsoft Office to work with ODF-based documents, Microsoft again capitulated by contributing resources to third parties who were working on ODF/MS-Office interoperability. While Microsoft's contribution of resources to such efforts was once again another olive branch to the ODF community, the move was widely misconstrued as Microsoft supporting ODF in the classic sense of the word support. As I wrote said in July 2006, there's a difference between actually offering support for something in a product vs. being supportive in other ways. Third party products that improve the interoperability between ODF and MS-Office may exist thanks to Microsoft's contribution of resources. But currently, you can't expect Microsoft to help you if it doesn't work (At least one strong proponent of ODF is questioning the technology's market viability based on its performance. Meanwhile, Sun just released an alternative solution).
Microsoft's reluctance to support ODF is understandable. In terms of market-share, MS Office enjoys a sizable lead over competing products and the last thing Microsoft needs is Office customers taking advantage of one of ODF's chief selling propositions: the ability of customers to easily switch from one ODF-compliant solution to another. Particularly since the growing list of ODF-compliant solutions includes products and services that are available at a much lower cost to customers than MS Office is (in some cases, free).
Historically, Office's proprietary formats have been one of the keys to its ongoing success as well as its ability to drive high margin revenues for Microsoft. Between acquisition, conversion, and training costs, the price to switch to other solutions (many of which themselves involved proprietary file formats) was simply too steep a price to pay for most organizations. It was just easier to stay with MS Office, regardless of its cost. It's a formula that has made MS Office one of Microsoft's two key franchises (the other being Windows). Not only does Microsoft want (and need) customers to stay with MS Office, it must also keep an eye on the ripple effect that any marginalization to the Office franchise might have on Windows. ODF-compliant alternatives to MS Office don't necessarily require Windows. Some run on other operating systems. Others need nothing more than a Web browser.
Other OSes and the Web are two other relatively new forces that are currently conspiring against Microsoft's dynamic desktop duo. Not to be underestimated, if you ask me, Nicholas Negroponte's One Laptop Per Child project is another (granted, it's orthogonal to OO-XML vs ODF). From just a market-share perspective, millions of school children growing up on non-Microsoft technologies is one global challenge Microsoft faces given the way that could create certain adult predispositions down the road. Even worse is how some percentage of those kids -- the whippersnappers -- will deal with the OLPC's limitations: they'll innovate. Platform vendors (not just Microsoft) with ecosystems to look after can ill-afford rising tides of innovation taking place on other platforms.
Although I've left a lot out of this epic saga, this sort of catches us up to the present day where Microsoft and OO-XML face a new set of challenges and challengers that may force the software giant to give yet another inch. Two of those are code contributions to the ODF community that will make it easier for developers both small and large to not just develop ODF-compliant applications, but ones that have some measure of accessibility to people with disabilities (PWDs).
One pressure point that Microsoft claimed worked in its own favor (particularly during the "Massachusetts Phase") had to do with Office's lead on accessibility to PWDs. While that was true based on the availability of certain third-party applications that work with Office (but not competing products), Microsoft's own track record when it came addressing PWDs looked more like a skeleton in the closet rather than something to write home about. Even so, when combined with certain third party utilities, MS Office was significantly more accessible to PWDs than was any ODF-compliant solution. Even more in Microsoft's favor was the fact that adding such accessibility to any application is not a trivial task. If one of the selling points of the ODF ecosystem was how developers both small and large were free to develop ODF-compliant apps (potentially leading to more customer choice), one of the downsides to that was the effort it would take developers to make those applications accessible to PWDs (a particularly sensitive issue in cases where laws or corporate policy require such accessibility), something most developers know little about.
Enter IBM. Last November, IBM contributed a boatload of accessibility code to the ODF community so that developers would have an easier time snapping such accessibility into their applications. But making programs PWD-accessible is a challenge, try making them ODF-compliant. Developers need to be rocket scientists to plow through the entire ODF specification and create implementations of it. Back in March of last year, I talked about how, if ODF had any hope of getting the sort of traction with developers that proponents of the specification were saying was one of the advantages of its openness, then someone (anyone) needed to come forward with a software development kit that makes it much easier to snap that functionality in. Otherwise, if developers were forced to build implementations of the ODF specification from scratch, ODF-compliant applications would be slow in coming, if at all.
Enter Sun.
Approximately two weeks ago, Sun's Chief Open Source Officer Simon Phipps broke the news that an ODF Toolkit was now officially happening. In fairness to OO-XML, it still remains to be seen just how easy it will be for third party developers to simply snap ODF-compliance into their applications using the ODF toolkit. But, if it works as advertised, the pressure on Microsoft will certainly increase. This is particularly so given the flood of Web-based productivity applications that are beginning to come on line. For entrepreneurs and garage-based innovators thinking of entering the productivity space with a browser-based application, having a toolkit that covers the heavy lifting that goes along with saving and retrieving files with all sorts of formatting (boldface, italics, underline, bullets, tables, etc.) is probably 75 percent of the battle. A solid ODF Toolkit will make ODF a much more formidable opponent to ODF.
But the ODF-favorable news (or should I say the OO-XML unfavorable news?) did not end there. Over the course of the last year, there has been no shortage of news around ODF endorsement and adoption, particularly in the government sector. But this week, Minnesota and Texas officially began their own open file format initiatives. According to Andy Updegrove (disclosure: Updegrove serves as general counsel to OASIS, the steward of ODF), OO-XML may not satisfy the states' criteria for an open file format.
While the OO-XML and ODF camps wait to see how that plays out (it could take years if Massachusetts is a barometer to go by), OO-XML hit another speed-bump today -- this one a bit more critical than any of the others that came before it. It appears as though OO-XML's road to becoming an officially recognized ISO standard won't be the cakewalk that some had hoped for. ComputerWorld's Eric Lai reports that several nations (19 to be exact) have voiced their opposition to ratification of the current OO-XML draft:
Nineteen countries, including some that have already adopted the alternative ISO-approved OpenDocument Format (ODF) standard, submitted comments and objections regarding Open XML, according to an official letter sent out yesterday by the ISO and viewed by Computerworld.
Stacy Leistner, director of communication for the American National Standards Institute (ANSI), which is helping the ISO manage the Open XML approval process, declined to comment on how many of the 19 submissions were "contradictions." In ISO terminology, contradictions are serious objections to ratifying Open XML. Submissions can also include more general comments....
....The nations that submitted comments and objections to Open XML constitute more than half of the 30 countries in the ISO's information technology committee -- the gatekeeper that will determine whether to allow Open XML's 6,000 page proposal to get a general vote by ISO's 157 members.
Those countries include Denmark, France, Malaysia and Norway, which have all in the past year moved to adopt nonproprietary document standards such as ODF.
Also on the list were Australia, Canada, Czech Republic, Finland, Germany, Hungary, India, Japan, Kenya, Netherlands, New Zealand, Romania, Singapore, Sweden and the UK. The news shouldn't be officially interpreted as nails in the coffin for OO-XML as an ISO standard. Those who are responsible for OO-XML's submission to the ISO are no doubt plowing through the objections and comments in order to come up with a new draft that will assuage the concerns of the 19 countries.
Even so, it is a sign to Microsoft that the international technology community is not as ready to embrace OO-XML as it is ODF. More government adoption of ODF in particularl is not something that Microsoft can take likely. Given how it's an ISO standard (something governments look for), additional governmental organizations are likely to embrace ODF in 2007 and as they do, it's not just those governments' IT operations that will be impacted. In many cases, ODF requirements could ripple out to the businesses and individuals that those governments exchange electronic documents with. As such, there will probably be a meeting this week or next involving Microsoft executives (like Office top dog Chris Capossela, who, at CES, answered my questions regarding this topic on video) who will be weighing the changes that must be made to the ISO draft against the idea of simply providing real support for ODF in Microsoft Office. In either case, more capitulation will be involved.