Burton Group's Response to the ODF Alliance (Part 3)

Blogger: Guy Creese

What follows is part 3 of Burton Group’s response to the ODF Alliance’s response to our “What’s Up .DOC?” overview report on ODF and OOXML. This post covers points 13-18. Points 1-6 are covered in Part 1 (which includes a short preamble); points 7-12 are covered in Part 2. 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 13

At the bottom of page 17, the authors present a list of prior protocol and API disputes with Microsoft, such as VIM, IDAPI, OpenDoc, etc., and suggest, “In these and other earlier encounters, when Microsoft's competitors sought to collectively compete with Microsoft by leveraging standards, the everybody-but-Microsoft standards have generally failed to achieve significant market momentum.” 

The examples given are ancient history. Also, note that VIM (1993), IDAPI (1992) and OpenDoc (1992) were not formal standards. The report fails to note that the market has evolved in the past 15 years and that that customers are better educated in the liabilities of vendor lock-in, and are now more aware of the important role that open standards play in ensuring interoperability. Whereas 15 years ago, it was enough to require the use of COTS software, today procurement is increasingly requiring the use of open standards. 

In our opinion, it would be far better to look at the example of Internet and web standards to see how Microsoft's competitors, and Microsoft itself, have succeeded. ODF has the potential to be the same competitive force for office productivity applications, using the same standards-based approach. 

We believe earlier attempts by groups of Microsoft competitors to establish control in key domains through consortium standards are pertinent to the ODF/OOXML debate. In our experience, enterprises spend money to embrace standards only when they feel that proprietary formats significantly constrain business action. With Microsoft Office’s large market share, the constraints are minimal, as virtually every partner that an enterprise would do business with can read and write Microsoft’s longtime binary formats, and increasingly its OOXML formats as well. In short, many enterprises do not see the need to move to ODF to gain interoperability, as in their view they already have it (albeit by using a de facto standard). That said, some organizations are worried about depending on a de facto standard, and so are demanding standards-compliant solutions, of which both ODF (ISO) and OOXML (Ecma) are options. 

In general, it would be helpful to see more information from the ODF community on why ODF is a better fit for customer requirements, and less positioning based on the assumption that Microsoft will invariably seek to inappropriately or illegally subvert standards processes. 

Point 14

On page 18 the authors introduce a section by saying, “If productivity application evolution had peaked around the feature set of Office 97, and if there weren't exabytes of files captured in earlier Microsoft Office file formats, it's possible that ODF could have succeeded as a global standard for productivity application file formats.” 

This point is not argued, it is just asserted, without any supporting evidence. We suspect that many of the arguments being made today in the report for Microsoft and against ODF would also have been made in 1997 had we been in that situation then. The network effects were smaller, but they were big for the time. 

Projections are by definition subjective; we stand by this projection in question, and believe there is ample room for innovation in productivity applications. 

Point 15

Later on page 18 the authors state, “OOXML will be more pervasive than ODF for several reasons. It's a better form-follows-function fit for most productivity application usage patterns”. 

This is a bold claim without argument or analysis to back it up, as far as we understand it. On what basis is the assertion that more than 50% (“most”) uses of documents cannot be represented in ODF? We believe, for example, that the entire Burton Group report could be represented in ODF without any loss in fidelity. Do the authors believe that more than 50% of the documents in use, today and legacy, are more complex than their 37 page report? 

We clearly established the context for our projections and recommendations – Burton Group’s customer audience, which is primarily composed of large commercial, government, and higher-education organizations. We believe these large organizations do indeed routinely exploit beyond-the-basics capabilities in word processor, spreadsheet, and presentation applications. The context for Burton Group’s overview, incidentally, is a good example of a non-revisable, print-oriented context, one we believe is well suited to the PDF file format. 

Point 16

Further on page 18, the authors note, “OOXML will gain market momentum as vendors such as Altova and Mindjet introduce products that support OOXML. Altova, the leading vendor of tools for XML-focused developers and designers, added OOXML to its XMLSpy product line in 2007.” 

This statement misrepresents market momentum by citing niche application support. While they may be fine products, will it really be the case that an XML programmer's editor and mind map software will drive the adoption of an XML office document format like OOXML? Will someone in a university or a business office adopt OOXML as a word processor format because they can edit it in Altova? That would be remarkable, considering the relatively small percentage of all end users who edit XML at that level. MindJet already supports the legacy binary Office formats. By what mechanism does MindJet supporting OOXML cause someone to move to OOXML? Certainly, if a user wants to move to OOXML, having this support removes a potential obstacle to migration. But it alone can do nothing to cause market momentum. We believe, in fact, that many users will simply stay with the .doc, .xls, and .ppt formats if they wish to use Microsoft formats, as was recommended by the recent Becta report in the UK. 

We did not say these applications would “drive the adoption” (be the main force); we said they would increase market momentum (add speed to an already moving body). Our point was to note the power of a surrounding ecosystem that is OOXML-compliant. The presence of Office 2007 has already started the creation of OOXML documents; the ability of many tools to accept or generate OOXML files will make the use of OOXML more attractive, especially as enterprises recognize that XML formats allow them to programmatically work with documents much more easily than they could in the past. That’s why we don’t believe enterprises will stay with the legacy .doc, .xls, and .ppt formats—XML-based formats (whether ODF or OOXML) are intrinsically more useful than their binary counterparts. 

In the initial stage of adoption, both ODF and OOXML are on a level playing field, by dint of being XML formats. However, over time, if complementary applications—whether they’re an XML editor, a mind-mapping tool, a report generator, etc.—support OOXML and do not support ODF, then the network effect starts to take over and OOXML will gain market momentum as enterprises decide that the OOXML ecosystem is larger—that their interoperability and programming options are less limited. While there are more office suites that are ODF-compliant than OOXML-compliant, OOXML seems to be winning the ecosystem battle, because these ecosystem vendors (characterized as niche vendors by the ODF Alliance) are implementing OOXML support (and postponing ODF support) based on customer demand. (As a rough comparison, here is a list of OOXML-compliant products; here is a list of ODF-compliant products.) In talks with us, Altova co-founder and CEO Alexander Falk noted that Altova had not seen customer demand for ODF; Gareth Horton of Datawatch noted the same thing in a comment on a blog post: “There was no interest from our users. In the future, that may well change, and we will duly implement ODF. Until that becomes a decision we can make on a sound financial basis, we can't expend development time on it.” 

Point 17

Page 19 says that “ODF represents laudable design and standards work. It's a clean and useful design, but it's appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn't a requirement.” 

The authors here contradict their own argument. On page 8 they stated, “In many cases, the productivity application file is ephemeral, used only to present and capture user actions for business transactions that are ultimately captured in enterprise systems rather than stand-alone productivity application files (that is, the files are destroyed when the transaction is complete and captured in other systems of record).” We believe, and follow the practice of, authoring a document in ODF and publishing it as a PDF file. For us this is a not an “unusual scenario” nor does it necessarily involve “full Microsoft Office file format fidelity,” 

Further, what does “full Microsoft Office file format fidelity” even mean? This seems like a circular argument, that ODF is only useful in cases where you are not using Microsoft Office file formats. 

We are working to compile a detailed list of interoperability issues, but for now reiterate the context we established for the report: large enterprise organizations that routinely engage in workflow scenarios that entail sharing Office file formats both inside and outside the company. Because most organizations are using Microsoft Office (and hence OOXML in the long run), we view using ODF (and hence introducing OOXML to ODF and ODF to OOXML translation processes) as a needless step that may introduce information loss. Examples of potential information loss in going from OOXML to ODF within a word processing document include the loss of image rotation, text wrapping in tables, and text watermarks. Examples of potential information loss in going from ODF to OOXML within a word processing document include the loss of hidden sections, text blinking, and table columns (ODF supports up to 8, 192 columns; OOXML supports up to 63). For a more detailed list of translation issues, see the Known Issues page on the Open XML/ODF Translator Add-ins for Office web site. 

Point 18

On page 21, the authors claim, “Even Adobe's own Buzzword service will likely add support for OOXML—again, if only for Office 2007 file compatibility.” 

This tells only half the story, again. Adobe has stated publicly that it plans on adding ODF support. The cherry-picking of statements, ignoring positive facts about ODF, while speculating on positive futures for OOXML, is puzzling and goes against the paper's claimed position of objectivity and vendor neutrality. 

This was an inadvertent omission on our part. Adobe is well known as an ODF advocate—it serves on the OASIS OpenDocument Technical Committee—and in the course of writing this section we assumed Adobe would be supporting ODF. We should have made that assumption explicit. Because ODF support was a given to us, that’s the reason for the phrasing, “Even Adobe’s own Buzzword service will likely add support for OOXML…”. We thought it notable that a vendor strongly identified with ODF and PDF would also be supporting OOXML. 

In fact, a test version of Buzzword (Preview 7) already supports OOXML, according to a thread in the the Buzzword Discussion Forum. While Adobe has officially announced that Buzzword will support ODF, it doesn’t appear that such support is in the product yet. 

Closing Comments

There are also issues not raised that cause concerns. For instance, why is there no discussion on accessibility issues raised by the disability community with respect to office documents? These issues have raised worldwide consciousness of the impact of information technology decisions and standards on the lives of people with disabilities. We hope it is not because the authors did not wish to acknowledge either (1) the issue's importance, or (2) that ODF v1.1 has established a new high water mark for document formats, a high water mark that should not be allowed to recede with the acceptance of anything less from any other office document format. 

For accessibility concerns, we also believe Microsoft’s recent success with the DAISY Consortium (see, e.g., http://www.disabilitycoordinationoffice.com.au/content/view/881/295/) is a useful example of how OOXML can be used to advance accessibility for all productivity application users. We certainly didn’t mean to discount the importance of accessibility.

 

Comments

[JJ]

I see you mention enterprises a lot, but I don't see you mention governments / charities / individuals at all. I would imagine especially governments would prefer to use a standard that:
1) doesn't force their citizens into using specific applications with their associated licenses and costs
2) supports extensibility to cater for their needs of integrating different governemnt domains without running the risk of a single vendor changing it whimsically, making all investments in integration moot.

So I'm very interested in your follow-up report indicating what standard you expect governments to adopt, as with the current breeze of paranoia their requests for information from enterprises will only grow in years to come. I'd say that'd be a decisive factor for CIOs to determine what horse to bet on, don't you?