Dispelling Myths Around ODF

Recent articles, reports and documents show that there are still a lot of misperceptions regarding ODF in the market. Apparently, many people are still not well informed about ODF even though they choose to write about ODF. Therefore, I thought it can't hurt trying to dispel a couple of myths around ODF.

ODF is controlled by Sun

Considering how actively a company like IBM is involved in the standardization process and the whole file format debate, I doubt that IBM would allow Sun to control ODF. Nevertheless, Sun is not in the position to control ODF.

1. The TC accepted multiple proposals that are not implemented in OpenOffice.org, and did so without larger discussions.

2. Sun has only three votes out of 8 to 10 in the TC. Even if Sun wanted to prevent that certain proposals get added to the specification, Sun would not have the power to do so.

ODF equals Open Source

ODF's strongest benefit is that it has been designed for vendor, platform and application independence right from the beginning. As a consequence there is a long and growing list of applications that do implement and support ODF, both commercial and open source. A few prominent examples are:

• KOffice

• OpenOffice.org

• Sun StarOffice Office Suite

• Sun ODF Plugin for Microsoft Office

• IBM Lotus Notes / Symphony

• Corel WordPerfect (beta)

• Apple Mac OS X Leopard / TextEdit

• TextMaker

• AbiWord / Gnumeric

• Google Docs & Spreadsheets

• Microsoft / Clever Age ODF Plugin for Microsoft Office

• Mobile Office by Odendahl SEPT-Solutions

Thus, ODF does not equal open source and therefore, ODF should not be confused with open source or one of its open source implementations like OpenOffice.org.

However, the existence of solid (!!!) open source implementations is indeed a benefit because the open source implementations give minorities access to ODF. Good examples are the broad platform support for ODF including exotic platforms like FreeBSD and OS/2 as well as the broad language support including the 11 South African languages. In addition, open source implementations like OpenOffice.org and KOffice reduce the barriers of entry for new market entrants and thus help to increase customer choice and vendor independence.

ODF is very closely related to OpenOffice.org

David Faure from KDE recently told me the following in an email exchange which he fortunately allowed me to quote and which nicely corrects the myth that ODF is very closely related to OpenOffice.org:

“[Question by me:] In this context, what is your answer from a KOffice point of view if someone says that ODF is very closely related to OpenOffice.org and StarOffice the same way OOXML is closely related to Microsoft Office. Do you agree? Do you disagree?

[Answer by David:] This is a misleading statement. ODF is very closely related to the OpenOffice.org original file format. OOXML is very closely related to the Microsoft Office implementation. This makes a huge difference.

The OOo-1.0 file format was already designed to be as implementation-independent as possible. This is what I always liked about it, and this is the reason why it made perfect sense for it to be the base of the ODF format. It uses many existing standards (HTML, CSS, XSL-FO, SVG), and is rather well documented. On the other hand, OOXML is an "xml transcription" of the old binary formats, which themselves were simple memory dumps of MS Office's data structures. There is still a lot in OOXML which shows the legacy (VML, BIFF, OLE...) and that relies on the MSOffice implementation -- [...]

[Comment by me] I need the answer for a request by someone who believes that ODF is just some kind of "rebranded" StarOffice file format.

[David's answer] I always said: it would be, if I wasn't part of the TC and if KOffice hadn't switched to ODF as its native file format. Okay that's probably exaggerating my role since others have also contributed to the format of course, but still, KOffice implementing ODF (not as a (lossy) import/export, but as the native file format which therefore has to store all of KOffice's features), is the proof ODF isn't just OOo-1.0 rebranded. Because there were two real (and independent) implementations, (not just a converter or a viewer, but two real office suites using the format natively), we have a proof that the format is implementable, and that the spec is implementation-independent. If OpenOffice disappears (sorry, just hypothetical :) , people will still be able to read their files using KOffice (okay, after implementing a bunch of missing features, but the point is that the documents can be read as is). If Microsoft Office disappears... well, too bad, your OOXML documents are good for nothing, currently.”

See also an earlier interview where David basically said the same:

http://dot.kde.org/1097051569/

Customer care about features, not formats

That customers increasingly care about formats and actually consider open standards support a key feature and requirement becomes for example evident in the Valoris study conducted by the European Commission in 2003 as well as the workshop about document exchange formats as part of the German EU presidency earlier this year. At the very least, government agencies around the world consider open standards support to be a key product feature just like spell checking or printing.

ODF is not being adopted

The recent ODF Report as well as the press release about the 1st International ODF Users Workshop by the ODF Alliance, the OpenOffice.org Market Share Analysis and the OpenOffice.org Solutions wiki page clearly show that there is a huge momentum around ODF. More and more governments are standardizing on ODF, and an increasing number of software vendors is adding ODF support to their solutions. In addition, a growing number of hardware vendors starts shipping desktop computers with ODF capable software pre-installed. The recent product announcements for the ASUSTeK Eee PC, the XO / OLPC as well as the gPC and Cloudbook by Everex - which are sold at Walmart by-the-way - are just a few very prominent examples. Finally, OpenOffice.org is being downloaded several hundred thousand times every week, and education ministries as well as universities are distributing open source tools to their students, like in Portugal and France. Oh, and not to forget the fact that the Google Pack includes StarOffice.

Thus, ODF has become a very significant force in the market place! It is hard to overlook or ignore that!

ODF has a very limited feature set

First, I want to repeat what has already been said multiple times. ODF strongly reuses open standards and concepts instead of reinventing the wheel again and again. As a consequence, the ODF spec is very lean and developers can reuse existing knowledge about different standards from other domains.

For example, some people believe or have been made believe that having a different table concept for each document type is an advantage. I, however, strongly believe that the opposite is true, i.e. that using one table concept for all document types is the better and cleaner approach. The following quotes from a Dr. Dobbs article provides a good example, why:

"The ODF reuses concepts throughout the different document formats it supports. For example, the definition of a table in a spreadsheet is almost equivalent to a table embedded in a text document.

... In ODF the content of your office document is stored in the content.xml document.

... This query constructs an HTML document with all tables from the ODF text document, usedcars.odt. Figure 4 is an example of the result, usedcars.html.

... And by simply changing the container document you want to access, you can use the same function to query your ODF spreadsheet, usedcars.ods. Look similar?"

If a developer has already written code to process tables in one document type, he or she can easily apply the same code to a table in a different document type. Thus, the learning curve is less steep and productivity increases significantly.

A very annoying myth around ODF is that some people say, “ODF has only a limited feature set” or “ODF is simplistic”. Actually the exact opposite is true.

Sure, ODF 1.0 was not 100% perfect. Like with any open standard, the more people start implementing and using a standard, the more potential areas of improvement are being identified. However, ODF is maturing rapidly with version 1.2 being on the horizon. ODF 1.2 will be a very mature standard with a very broad but standards-based feature coverage.

Yes, ODF 1.0 did not specify a formula language but allowed arbitrary formula languages instead. This was recognized as an interoperability issue and is thus being addressed by ODF 1.2. However, many ODF 1.0 based products from different vendors even don't have an interoperability issue in the formula area because they are based on the same code base. It would have been fast and easy to define a formula language by simply documenting the formula language of one single application. However, ODF chose to specify formulas based on broad industry experience and best practices.

The formula language in ODF 1.2 is based on the following applications:

• Microsoft Excel (many different versions)

• OpenOffice.org / StarOffice

• Lotus 1-2-3

• Quattro Pro

• Gnumeric

• Koffice Kspread

• WikiCalc

• SheetToGo

• Mathematica

• Macsyma

• Octave

And the key benefits of the ODF 1.2 formula language are:

• Broad application coverage, incl. Microsoft Excel, Lotus 1-2-3 and OpenOffice.org

• Innovative functions, e.g. XOR, BASE, SEC, etc.

• Reuse of standards, e.g. ISO 8610 date and time representation

• Support for supplier-unique namespaces, enables rapid, decentralized innovation

• Avoids bugs like the „1900 leap year bug“

• No limitation to the number of rows and columns

• No constraints on the user interface

• Predefined function sets for different application areas

Thus, the ODF 1.2 formula language covers all key areas without sacrificing vendor independence and openess.

Another often heard criticism is that “ODF does not support custom schemas”. Statements like this seem to ignore the XForms support in ODF 1.0. In addition, ODF 1.2 adds W3C standards based metadata support for which the following scenarios were analyzed:

• Accessibility Information

• Asymmetric metadata

• Automatically generated metadata

• Bibliographies and Citations

• Content Tagging

• Conversion Metadata

• Document as Web Service

• Enhanced Search

• Extrinsic metadata

• Intellectual Property

• Metadata templates

• Ontology Validation

• Realtime Collaborative Editing

• Revision Metadata

• Rich Semantic Metadata

• Security metadata

• “Semantic Web”- Ready Documents

• Workflow Management

All these scenarios give a hint of what the metadata support in ODF 1.2 will be capable of. The key benefits of the metadata model are:

• Reuse of existing standards like RDF/XML (W3C) and OWL (W3C)

• Interoperability with other RDF-supporting applications (RDF is for example the basis of RSS and is being used within Adobe's XMP technology in applications like Photoshop)

• Strong tool support (many development tools for RDF, good RDF support in/for relational databases)

• Flexible text-metadata binding, e.g. assign different types of metadata to the same document element, i.e. one-to-many relationships

Finally, as chapter 11 “Database Front-end Document Content” of the current ODF 1.2 draft shows, ODF 1.2 will be leading the document format space by even adding database support. Thus, all in all, with version 1.2 of ODF it will be difficult to find feature areas of existing office productivity applications that are not covered yet.

The Web makes ODF irrelevant

Some people believe that the advent of Web 2.0 applications including web office tools like Google Docs and Spreadsheets will make ODF irrelevant. I believe, that at least for a long while the opposite will be true. It will take a couple of years or probably even decades until broadband Internet becomes ubiquitous. As a consequence people will use a mix of local desktop applications and web-based tools. However, in order to allow users to move back and forth between desktop and web applications, it is important that these applications agree on common open standards. Google Docs and Spreadsheets for example support ODF. Thus, users can easily upload and use documents created with OpenOffice.org or KOffice within Google's web tools and vice versa.

In addition, since the web is strongly influenced and dominated by W3C standards, ODF has a huge advantage compared to other document file formats because ODF heavily reuses W3C standards like HTML, SVG, XForms, XSL-FO, XLink, MathML, XML Signature, RDF/XML, etc. The following diagram created by my Sun colleague and OASI ODF TC co-chair Michael Brauer illustrates this nicely:

ODF is incompatible with Microsoft Office

Many people also believe that ODF is incompatible with Microsoft Office or that Microsoft Office documents cannot be represented in ODF. As many people know, OpenOffice.org has a very high level of compatibility with Microsoft Office. Some users even use OpenOffice.org to “repair” Microsoft Office files that cannot be opened in Microsoft Office any more. Microsoft Office compability has been a key goal for OpenOffice.org for a very long time due to the current market situation. However, OpenOffice.org uses ODF as the default file format and therefore all features that currently can get imported by OpenOffice.org from Microsoft Office files can be represented in ODF. As a consequence, even though Microsoft has not been participating in the ODF TC at OASIS, ODF can already represent close to all Microsoft Office features that someone typically uses for the creation of day-to-day documents.

I hope the information above has helped to dispel a few myths around ODF and helps people reading articles, blog entries and analyst reports about ODF. From my point of view, ODF provides all an office suite user needs, and I'm sure that we will read a lot more great and encouraging news about ODF in 2008.