Blogger: Guy Creese
What follows is Burton Group’s response to the ODF Alliance’s response to our “What’s Up .DOC?” overview report on ODF and OOXML. At the outset, we’d like to clarify some things before getting into the point-by-point responses:
- The utility of a model is assessed relative to stated objectives in a given domain; a modeling endeavor never has a simple right or wrong answer (page 18 of our overview). A key part of this debate is the subjective assessment of how important Office file format interoperability is—we believe it will be very important for most enterprises—and that Office file format interoperability was not a goal for the group that designed ODF.
- Standards initiatives participants are often at least partly politically motivated, generally with significant business issues at stake. That’s certainly not new to the ODF/OOXML debate.
- We reviewed the current versions of the published standards, so the intention to more completely integrate ODF with RDF in the future is not an immediate consideration for enterprises making format decisions today. Burton Group believes that ODF 1.2 is a much richer and useful specification than previous versions, and we will update the overview to reflect that when ODF 1.2 is approved.
Responses to the ODF Alliance points follow. To keep this post from being horrendously long—and since we haven’t finished all the responses at this point—we’ll post them in series. This post covers points 1-6. [Update: points 7-12 are covered in Part 2; points 13-18 are covered in Part 3.] To make it easier for readers, we’ve listed the ODF Alliance comments in italics, followed by the Burton Group replies in a non-italicized font.To make it easier for readers, we’ve listed the ODF Alliance comments in italics, followed by the Burton Group replies in a non-italicized font.
Point 1
Page 5 says "...[L]ibraries and large businesses, faced with storing and using years of Microsoft Office legacy documents, will prefer OOXML, as OOXML can more faithfully recreate the look and metadata (such as spreadsheet formulas) stored in Microsoft's binary file formats."
This statement confuses file formats and applications. Surely, OOXML cannot faithfully recreate the look of anything. It is a file format, not an application. Microsoft Office is the application that interprets OOXML, and it can also render legacy binary file formats, except when Microsoft decides to remove support for them, as Microsoft recently did with Office 2003 SP3. There can be further problems when Microsoft decides not to support legacy features, such as when they removed support for Visual Basic scripting in Office 2008 for the Macintosh.
The authors fail to note that no other application supporting OOXML has been able to faithfully or fully recreate the look of Microsoft's legacy binary documents. So the statement that OOXML--a file format--is the solution for rendering legacy documents is simply false.
The key issue here is the sophistication of the payload that the file formats can carry. A better phrasing within the report would have been, "...[L]ibraries and large businesses, faced with storing and using years of Microsoft Office legacy document, will prefer OOXML, as OOXML can more faithfully transfer the information needed to create the look and metadata (such as spreadsheet formulas) stored in Microsoft's binary file formats." We agree on the need to clearly distinguish between applications and file formats, but OOXML is much more expressive than ODF. For example, OOXML specifies formulas; the current standard of ODF does not. OOXML has a much more sophisticated way of expressing graphics; ODF has difficulty passing along the information necessary to fabricate complex vector graphics such as pentagons and chevrons. It’s true that both formats are defined in XML, and that they can thus be extended, but we believe it’s important to note that OOXML is a more expansive model to start with, since extensions mean more complexity for application developers. The comment about Microsoft dropping support for legacy file formats in Office 2003, incidentally, is a good example of blurring the distinctions between applications and file formats (and, since Microsoft made the changes – since relaxed – to improve security, it’s difficult to find fault with Microsoft’s goals in that context).
Point 2
Page 5 asserts that OOXML will win because, “...OOXML is an extensible standard. It allows vendors and enterprises to extend the standard within an OOXML-defined framework... This built-in ability to augment the OOXML standard is a safety valve for future innovation, allowing new features to be added without forcing vendors to invent yet another separate file format or wait for standards bodies to give their approval.”
Why does the report argue that OOXML is preferred over ODF for extensibility reasons, but fail to mention that ODF's extensibility features are just as rich? This lack of balance is disconcerting. ODF has extensibility features that are just as powerful as OOXML's, and, what is more important, ODF's features are based on existing industry standards, such as the W3C's RDF and XForms. Further, it is not clear to us what the statement about not waiting for standards body to give their approval means. Surely the authors are not suggesting that we repeat the problems of some earlier efforts where multiple “user defined extensions” to a standard meant that we really didn't have a standard at all?
Implying that the custom XML extensions Microsoft developed in conjunction with Ecma International are unimportant, while neglecting to mention that one of the cited ODF extensibility features has not yet been approved (RDF is planned for ODF 1.2), does not seem objective to us. In addition, the frequency of user-defined extensions will be in part a function of the expressive scope of the model; since OOXML is much broader in scope, we believe it will need fewer extensions. In fact, ODF 1.1 and 1.2 could be classified as “catch up” specifications, needed to add features that OOXML already supports (e.g., accessibility, detailed spreadsheet formulas).
Point 3
Page 5 also discusses OOXML's support for “custom schemas” and suggests that “OOXML is more ecosystem- and application-oriented than ODF.”
We think it is unwise to consider exclusively Microsoft's particular “custom schema” feature. We should instead ask what the underlying business problem is that we are trying to solve. For example, if you wish to programmatically update a stock price in a document (what the paper suggests is solved by custom schemas) then there are many other approaches, from custom spreadsheet functions, to document transformation, to DOM manipulations, to tagging, to mapping to an XML database, and so on. The underlying problem is how to take what is ordinarily unstructured document content and impose an organization's structured view on it. Suggesting that only Microsoft's custom schema support solves the problem, while ignoring ODF's support for alternative and standards-based approaches to the same underlying business task, is misguided, in our opinion. In particular, the paper fails to note ODF's XForms support and how it can be used to enable users to add data to a document in a user-defined schema and then submit it to a web service. XForms is a W3C standard. Here again, a sense of balance is missing, as is consideration of fully capable modern programming techniques that employ ODF to solve real business problems.
This point is a mischaracterization of what we said, as it implies that the use of custom schemas is the sole reason for saying, “OOXML is more ecosystem- and application-oriented than ODF.” As readers of the report know, the complete sentence, “In short, because OOXML is more ecosystem- and application-oriented than ODF, most vendors and enterprises will see it as more useful than ODF,” applies to all three points we made in that paragraph, not just one.
The paragraph starts by noting, “Within the larger market, OOXML will lead,” and then lists three reasons for that assertion. First, Microsoft Office 2007 defaults to saving documents in OOXML format, so given Microsoft Office’s dominance, the vast majority of documents that enterprises create over time will automatically end up as OOXML documents. Second, OOXML is designed to allow vendors and enterprises to extend the standard within an OOXML-defined framework, rather than redefining the standard. Third, we note that OOXML’s “overlay” custom schemas will “…more easily perform tasks such as programmatically updating a ‘Stock Price’ element or corporate logo within a document, compared to ODF’s method of serially inspecting and updating the document itself.” While there are always many ways to programmatically solve a business problem, the options that the ODF Alliance suggests are not limited to the ODF format—they could be applied to OOXML documents as well—which gets us right back to the distinctions between ODF and OOXML.
While XForms is a type of custom schema, it is not a separate mechanism to the side like the OOXML design, so it adds additional parsing and processing to the process. ODF proponents must think that the overlay mechanism has value, as it is included in the yet to be approved ODF 1.2 standard.
To summarize, we believe that “most vendors and enterprises will see [OOXML] as more useful than ODF” because: (1) millions of OOXML documents will be generated over time by Office 2007 and so it’s the path of least resistance, (2) OOXML offers built-in extensibility, and (3) the overlay custom schema mechanism consumes less processing resources than the competing ODF XForms mechanism.
Point 4
Page 5 says of the OOXML standard, in a section pointedly called “What's In a Name?: Innuendo,” that “IBM and Sun reference it via its Ecma name of “Office Open XML” (as reminder of its origins in the proprietary Microsoft Office file formats).”
This is a curious statement, but there is no need to suggest the name is used for some propagandistic purpose. Many people call the standard “Office Open XML” because that is in fact its correct name, both in ISO, and in Ecma, and even its legal name as used by Microsoft in their own Open Specification Promise.
Speaking of names, nothing is said about Microsoft choosing a name for their specification which was obviously destined to cause continued confusion with ODF's first implementation, Open Office.
This section was put in for two reasons: as a literary device to help readers remember which acronym is which, as well as to allude to the “Battle of the Names” that has characterized the ODF/OOXML debate. (Two examples: Gary Edwards’ blog post in which he names OOXML MSECMAXML, and Ephraim Schwartz’s note of the battle lines in “ODF vs. OpenXML”). In fact, the ODF Alliance’s assertion that Microsoft picked a specification name “obviously destined to cause continued confusion with ODF’s first implementation, Open Office” is a perfect example of the jockeying for name ownership that has characterized the behavior of both sides of this debate. (Microsoft’s attachment to the word “open,” as well as the ODF Alliance’s implying that the ODF-based office suite had first dibs on the Open Office name. Actually, Wang Laboratories concatenated the two words first, with its OPEN/office e-mail solution in the 1990’s.)
In the course of talking to our clients about ODF and OOXML, it became very clear early on that business-oriented CIO’s and others unfamiliar with the standards had a hard time remembering which acronym stood for which standard. Although we called them ODF and OOXML in early drafts of the document, midway through we changed the nomenclature in the report to ODF and Open XML. Microsoft’s “branding” of Open XML seemed to have taken hold in the business community, and we felt that piggy backing on that term would cause less confusion for our enterprise readers. However, when we sent out a draft of the report for review by IBM, Microsoft, Novell, Sun, and others, we were surprised by the strength of at least one vendor’s objections to our using the “Open XML” term in the document. This vendor called it “worrisome,” and rather than just commenting on it, unilaterally replaced all mentions of “Open XML” with “OOXML.” Given that the Ecma name for the standard is OOXML, we decided to go with acronym names for both standards, so we wouldn’t be accused of naming favoritism. Once Microsoft heard that we’d changed to using “OOXML,” they came back asking us to reinstate “Open XML,” which we refused to do. Given that experience, buttressed by blog postings that highlight that such name jockeying is not an isolated instance, we thought that a short reference to the “Battle of the Names” was worthwhile, and would help clarify which acronym went with which camp to our enterprise readers.
Point 5
Page 12 says, “...[M]any Microsoft competitors have attempted to exploit the transition to open, XML-based file formats in order to more effectively compete with Microsoft Office. While some of its competitors have very little hope of establishing successful products that directly compete with Microsoft Office, they may still seek to disrupt Microsoft's business by making Office less profitable, thus depriving Microsoft of opportunities to use Office profits to subsidize product development efforts in other market segments.”
The report seems to suggest that it is somehow improper to compete against Microsoft. We find that view puzzling and confusing. ODF vendors are not “exploiting” the transition to open, XML-based file formats. They were the source, the vanguard of the transition to open, XML-based file formats, having initiated standardization of ODF within OASIS over 5 years ago. Also, according to the authors' own statements earlier (bottom of page 6), OpenOffice has had 100 million downloads compared to Office's 500 million estimated users. How can it be said that there is “very little hope of establishing successful products that directly compete with Microsoft Office”?
We certainly do not believe it is inappropriate to compete with Microsoft. However, given that Microsoft Office has over 90% market share, we think that displacing Microsoft Office with another productivity application software suite will be an uphill battle. In fact, we think the greater long-term threat to Microsoft Office will come from SaaS-based solutions that sidestep the ODF vs. OOXML debate by storing documents in the cloud. Microsoft is not oblivious to this shift, and helps explain the rise of its “software plus services” mantra. Furthermore, we did not assert that there will be no successful ODF-centric vendors competing with Office; we noted, for example, that Novell is likely to have robust market opportunities for its version of OpenOffice.org, especially on client platforms Microsoft does not support. One hundred million free downloads is certainly an impressive number, but far less so than 500 million paid client licenses; a download does not always imply an active user, while a paid license generally signals a stronger level of commitment.
Point 6
Page 13 says, “ODF is currently somewhat simple (and simplistic) compared with alternatives such as OOXML”.
The rather negative term “simplistic” is asserted with no backing argument or evident motivation. In our opinion, this does little to establish a sense of objectivity in the report. We might also ask when did “simple” became bad thing in a standard? XML is simple. HTML is simple.Moreover, Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP) and other essential IETF standards are explicitly named that way because of their simplicity.
In our opinion, the best word to describe these global standards and ODF is not “simple,” but rather “elegant.” There are considerable liabilities associated with unnecessary complexity: increased development and maintenance costs, increased difficulty to program, more complex (and therefore possibly negative) security implications, and generally buggier implementations. A more balanced approach would have examined the negative effects of a more complex standard. “As simple as possible, but no simpler” was Einstein's advice, and is worth heeding. You can always build complex applications from simple pieces, but you cannot easily build simple applications from complex pieces.
On “simplistic:” while Wikipedia states “The word ‘simplistic’ often means beyond simple, as in way too simple. The word is often used offensively and not with kind solitude” (http://en.wikipedia.org/wiki/Simplistic), dictionaries (such as The American Heritage Dictionary as quoted by Answers.com -- http://www.answers.com/simplistic), provide more detailed definitions, e.g.,: “The tendency to oversimplify an issue or a problem by ignoring complexities or complications” (Answers.com). Given the stated purpose of the ODF group was to create a robust XML model for file interoperability among productivity applications, we believe the decision to not support trading files with Microsoft Office, the application used by the vast majority of information workers, was simplistic. We also believe the decision not to specify a robust formula language in ODF 1.0 was simplistic. (In that case, the ODF specification doesn’t offer simple pieces—it offers no pieces.) We agree with the Einstein quote (“… as simple as possible, but no simpler”) and believe, at least within the context of addressing complex enterprise IT requirements, ODF is too simple.
Microsoft has over 90% of market share according to Microsoft, based on a comparison of licenses and not counting open source software. These figures should be updated with a more realistic calculation. For instance, in Italy in 2007 Microsoft sold around 1.4 million licenses of Office 2007 (based on data provided by Microsoft on a global basis) and downloads of OpenOffice were over 1.8 million. While it's true that you cannot compare a license with a download, you should also take into account that licenses acquired with a corporate program do not necessary equal the number of users, and a single download may count for hundreds of users as you can install the software as many times as you want.
Posted by: Italo Vignoli | February 10, 2008 at 07:16 AM