Is OpenDocument an Open Standard? Yes!

by David A. Wheeler, 2006-02-09 revised 2008-05-14 (published in Growlaw)

Ever since the OpenDocument standard was ratified by OASIS in May 2005, it’s been gathering steam. In May 2006, ISO formally approved a draft of OpenDocument as standard ISO/IEC 26300. KOffice has completely switched to OpenDocument as their native format (OpenOffice.org did this long before), and more implementations are being announced each month. Massachusetts continues to plan to switch to it in spite of some nasty politics, and all evidence suggests increasing use worldwide. Wikipedia’s article on OpenDocument gives more information about it, including OpenDocument adoption.

But is OpenDocument really an open standard, or not? For example, can anyone implement it? Was its development process completely controlled by a single party (which would not be open), or is there evidence that it’s a consensus result by many? It’s generally accepted that OpenDocument is an open standard, but recently I’ve been told that some people are claiming otherwise. So let’s figure out what the criteria are for an open standard, and then see if OpenDocument meets those criteria.

What’s an Open Standard?

There’s no single definition of the term “open standard”. That’s true for most words and phrases, actually. But lots of documents hint at what it means, for example:

Let’s first look at the two definitions of “open standard” that seem to be the most widely used. The first is by Bruce Perens; the second is by Ken Krechmer (Fellow of the International Center for Standards Research). These two are so widely used that when I did a Google search on “open standards” these were the second and fourth results respectively (the first and third were OASIS and the W3C, two standards bodies that create open standards). We’ll then look at the European Commission’s definition of open standards, which is a formally approved definition of the term (and one that European governments use).

Then, after we’ve looked at these three definitions, we’ll create a merged definition that includes all of their requirements (from all three sources). That way, if the specification meets this merged set of requirements, we can be very confident that we have an open standard; such a specification would meet all three definitions.

Perens

A very popular definition of the term “open standards” -- according to Google the most popular -- is Bruce Perens’ “Open Standards: Principles and Practice”. You’re best off reading the actual paper for its full content, of course. Let me summarize it by quoting its list of principles that it states a specification must meet to be an open standard:

  1. Availability: Open Standards are available for all to read and implement.
  2. Maximize End-User Choice: Open Standards create a fair, competitive market for implementations of the standard. They do not lock the customer in to a particular vendor or group.
  3. No Royalty: Open Standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee.
  4. No Discrimination: Open Standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor’s implementation. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.
  5. Extension or Subset: Implementations of Open Standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions (see Predatory Practices).
  6. Predatory Practices: Open Standards may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute, and sell software that is compatible with the extensions. An Open Standard may not otherwise prohibit extensions.

Krechmer

Another popular definition is the set of requirements for open standards created by Ken Krechmer, Fellow of the International Center for Standards Research (University of Colorado). He’s published several versions; here I’ll summarize the February 7, 2005 version of “Open Standards Requirements”. He looked at standards from the viewpoint of recognized standards-setting organizations, implementors, and users, and tried to find some middle ground merging their desires. He claims that an open standard must meet the following requirements:

  1. Open Meeting - all may participate in the standards development process.
  2. Consensus - all interests are discussed and agreement found, no domination.
  3. Due Process - balloting and an appeals process may be used to find resolution.
  4. Open Intellectual Property Rights (IPR) - how holders of IPR related to the standard make available their IPR.
  5. One World - same standard for the same capability, world-wide.
  6. Open Change - all changes are presented and agreed in a forum supporting the five requirements above.
  7. Open Documents - committee drafts and completed standards documents are easily available for implementation and use.
  8. Open Interface - supports proprietary advantage (implementation); each interface is not hidden or controlled (implementation); each interface of the implementation supports migration (use).
  9. Open Access - objective conformance mechanisms for implementation testing and user evaluation.
  10. On-going Support - standards are supported until user interest ceases rather than when implementer interest declines.

Clearly, these definitions have a lot in common. Ken Krechmer wrote his paper after Perens, and compares his list to Perens’. Krechmer maps each of Perens’ 6 points to his own list of ten as follows:
PerensKrechmer
AvailabilityOpen Documents
Maximum end-user choiceOpen Access
No royaltyOpen IPR
No discriminationOpen Meeting, Consensus and Due Process
Ability to create extension or subsetOpen Interface
Ability to prevent predatory practicesOpen Change
Krechmer in particular notes that Perens doesn’t include any requirement about wanting “One World” or ongoing support. Rick Jelliffe claims that Krechmer’s “open interface” doesn’t map to Perens’ “ability to create extension or subset”, but I think it does... and so does Krechmer!

However, Krechmer’s list has very serious failure. Krechmer’s list omits one of the most important factors of all: the ability of anyone to implement the standard. The whole point of open standards is to allow anyone to implement the standard, and to allow any user to have unfettered selection and switching between many implementations. Krechmer’s list notes the importance of patents and copyright (“IPR”), but his definition allows “open standards” to forbid competitors from implementing the standard. This is a fundamental flaw in his definition; defining “open standard” as “a standard that some competitors are forbidden from implementing” is nonsense, and conflicts with most other sources. Perens’ definition explicitly forbids this, as does the Valoris report, which required as a minimum that the format “may be implemented in programs without restrictions, royalty-free, and with no legal bindings.” It also conflicts with the European Commission’s definition of open standards, which also required royalty-free use (we’ll get to that definition in a moment).

The most economically obvious example of this conflict is open source software (OSS). Today, in a vast number of software markets, the dominant or #2 program is OSS, including web servers, web browsers, mail servers, and DNS servers. Yet OSS are legally forbidden from using royalty-bearing patented works, so obviously specifications requiring royalty-bearing patents or other legal restrictions preventing OSS or proprietary implementations are obviously not open standards. A standard cannot be “open” if it is illegal for the dominant or #2 supplier to implement it.

This conflict between patents and open standards only makes sense, when you think about it. The purpose of patents are to prevent competition, while the purpose of open standards is to enable open competition. The purposes of patents and open standards are fundamentally in conflict. Open standards are not the same as open source software; you can choose open standards and use only proprietary software. But selecting open standards lets you choose between implementations, including OSS, and lets you switch to another implementation later.

European Commission

The European Commission (EC) has defined the term “open standards” as part of the final version 1.0 of the European Interoperability Framework. Newsforge ran a short article about it. The EC declared that “to attain interoperability in the context of pan-European eGovernment services, guidance needs to focus on open standards” -- in other words, the EC views the use of open standards as a significant policy issue. They define the following as “the minimal characteristics that a specification and its attendant documents must have in order to be considered an open standard”, and I quote them here:

The document also suggests that open source software (OSS) compliments open standards. It says: “Open Source Software (OSS) tends to use and help define open standards and publicly available specifications. OSS products are, by their nature, publicly available specifications, and the availability of their source code promotes open, democratic debate around the specifications, making them both more robust and interoperable. As such, OSS corresponds to the objectives of this Framework and should be assessed and considered favourably alongside proprietary alternatives.” Both the definition and explanatory text make it clear that the intent was that any open standard must be implementable by both OSS and proprietary programs, especially given the requirements for royalty-free use and lack of constraints on re-use.

Merging the definitions

So let’s use a definition of “open standard” merging the best of each, and so that a specification would meet all of these definitions to qualify. Comparing Krechmer’s list to Perens’, Perens’ list is shorter, clearer, and doesn’t have the serious defect of forbidding open competition. We’ll then add the two points of “One World” and “Ongoing support” stated by Krechmer as important issues.

Most of the EC’s requirements also map well to Perens’, except that the requirement for a free or nominal-cost specification isn’t explicit:
PerensEuropean Commission
No discrimination (though doesn’t explicitly require not-for-profit) The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
(No match) The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
No Royalty The intellectual property -- i.e. patents possibly present -- of (parts of) the standard is made irrevocably available on a royalty-free basis.
Availability There are no constraints on the re-use of the standard.
So again, let’s add “No or nominal cost for specification”. Perens doesn’t explicitly say that a standards maintainer has to be not-for-profit, but he does require no discrimination, with essentially the same notion; we’ll add that as an implicit requirement to no discrimination.

The result is a slightly stricter definition of “open standard” than any of the three definitions by themselves. Thus, so if any specification meets this merged definition, then it’s clearly an open standard.

Definition of “Open Standard”

Here’s a definition that merges the points of these various widely-cited documents:

An open standard is a specification that enables users to freely choose and switch between suppliers, creating a free and open competition between suppliers. To accomplish this, an open standard must have the following properties:

  1. Availability: Open Standards are available for all to read and implement.
  2. Maximize End-User Choice: Open Standards create a fair, competitive market for implementations of the standard. They do not lock the customer in to a particular vendor or group.
  3. No Royalty: Open Standards are irrevocably free for all to implement, with no royalty or fee {or other legal tricks to inhibit implementation}. Certification of compliance by the standards organization may involve a fee (as long as it’s not required for implementation).
  4. No Discrimination: Open Standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor’s implementation. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services. The standard is adopted and maintained by a not-for-profit organisation, with open meetings (all interested parties may participate in the standards development and maintenance process), consensus (all interests are discussed and agreement found, with no domination by any party), and an open decision-making process with due process (balloting and an appeals process may be used to find resolution).
  5. Extension or Subset: Implementations of Open Standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions (see Predatory Practices). I would add that users definitely should be told when an implementation only implements a subset, and what the nonstandard extensions of an implementation are, since these can cause interoperability problems. But it is critical that implementations be allowed to implement subsets or supersets of standards, because without this permission, standards cannot respond to changing conditions, and many open source software licenses are incompatible with software that cannot be modified. In practice, useful standards are updated, based on experience based on real implementations that create subsets and supersets (XML is a subset of SGML, for example, and all useful updated standards are based on extensions created by implementors). There are lots of ways to address the needs of both users (who need to know about the subsets and supersets) and implementors (who need to create them). For example, a standards body might say that an implementor of only a subset would have to say “implements a subset of standard X” instead of “implements standard X”, and they can require implementors to document their extensions. The biggest danger here are intellectual rights (patent) agreements that grant patent rights to implementors “only to implement this standard, exactly”. These agreements are often a trap; the organization granting the intellectual rights then becomes the only organization that can make improvements on the standard, and can entrap everyone else who uses the standard.
  6. Protection from Predatory Practices: Open Standards may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute, and sell software that is compatible with the extensions. An Open Standard may not otherwise prohibit extensions.
  7. One World: The same standard should be applicable for the same capability, world-wide. It must not be devised as a “barrier to entry” by those from other regions.
  8. On-going Support: The standard is supportable until user interest ceases rather than when implementer interest declines.
  9. No or nominal cost for specification. (This may soon become a requirement for no-cost specifications that can be copied further. Fees innately discriminate against many users and implementors, particularly in the third world; with the rise of the Internet fees have become a completely unnecessary discrimination.)

Is OpenDocument an Open Standard?

So, is OpenDocument an open standard? Let’s walk through the list of requirements.

  1. Availability: Open Standards are available for all to read and implement. This one is easy. You can download the OpenDocument specification for free from OASIS. Absolutely anyone can implement OpenDocument; if you look at the IPR statements, they clearly state that absolutely anyone can implement it, and there are no limits at all.
  2. Maximize End-User Choice: Open Standards create a fair, competitive market for implementations of the standard. They do not lock the customer in to a particular vendor or group. The fundamental question here is, is this designed to permit multiple interoperable implementations? The most obvious way to determine if this is true is to determine if there multiple implementations available on multiple different platforms. The answer to the latter question is emphatically yes; there are already multiple implementations of OpenDocument, with many more in progress. OpenOffice.org/StarOffice and KOffice are office suite applications that support reading and writing OpenDocument, and are completely independent implementations. There are also many specialized products that implement their relevant portions, for example, AbiWord and Writely are word processors that can read and write the word processing portion of OpenDocument; Gnumeric is a spreadsheet application whose implementation of the spreadsheet portion of OpenDocument is in development. (Wikipedia has a list of applications supporting OpenDocument.) You can also look at other evidence to help gain more confidence in this:
    1. Were multiple implementors involved in its specification to help prevent lock-in? Yes; Sun, KDE, Corel (vendor of Word Perfect), IBM (vendor of IBM Workplace and Lotus SmartSuite), and others. I’ll discuss more about the participants later, but that’s enough to prove the point.
    2. Does the specification maximally reuse other open standards (otherwise it may end up creating unnecessary dependencies on nonstandard components)? Yes; other standards OpenDocument reuses include SVG, SMIL, XSL, XForms, MathML, XLink and the Dublin Core Meta Initiative.
  3. No Royalty: Open Standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee. There’s no royalty or fee to implement OpenDocument, so this is met 100%.
  4. No Discrimination: Open Standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor’s implementation. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services. I believe this one is also a clear “yes”, however, it’s more difficult to measure this than most other points. We’ll explore this one further in a moment, to see why I believe this is “yes” as well.
  5. Extension or Subset: Implementations of Open Standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions (see Predatory Practices). Implementors may implement subsets or supersets of OpenDocument, without any special requirements, so this is clearly met too.
  6. Predatory Practices: Open Standards may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute, and sell software that is compatible with the extensions. An Open Standard may not otherwise prohibit extensions. The OpenDocument developers chose to not embed any protective measures against subversion by external parties. However, all the members of the technical committee that created the standard were required to grant royalty-free licenses to implement it. This prevented anyone from quietly inserting a requirement in the standard and after ratification announce that they would extort payments from implementors. Thus, this requirement is easily met.
  7. One World: Same standard for the same capability, world-wide. The OpenDocument specification was specifically designed to be used worldwide, and not limited to any region. It includes capabilities to support arbitrary locales and arbitrary languages, and in fact was developed by representatives from many different countries. For example, OpenDocument supports Unicode/ISO 10646 characters (whose purpose is to support the characters of all languages), Ruby text (important in supporting some Asian languages), and text written from right to left (important in supporting Arabic and Hebrew). Reusing many open standards helps this, too. Also, by working to avoid patented techniques, the developers of OpenDocument made it more likely that everyone in the world could use the standard (otherwise the standard might only be usable in countries that don’t tolerate software patents). We’ll discuss more about patents in a moment, because patents fundamentally conflict with the previously-noted requirement for no discrimination.
  8. On-going Support: Standards are supported until user interest ceases rather than when implementer interest declines. The OpenDocument standard is supported by OASIS, a standards body, rather than any one particular vendor. Thus, as long as there are users who wish to support the standard, they can work with OASIS to continue its support. There’s absolutely no indication that this is a problem anyway; there is a massive amount of interest in OpenDocument. No or nominal cost for specification. OASIS posts the specification at no charge on their website, clearly meeting this requirement.

In short, we get “yes” answers for all of these points. All but one of them are trivially answered as “yes”. One point, however, is harder to measure - the “No discrimination” point. This isn’t because there’s a problem with OpenDocument on this point; the challenge is that “no discrimination” is harder to measure for any standard. So let’s drill into the “no discrimination” point to see if OpenDocument meets this requirement -- if it does, then it is clearly and unambiguously an open standard.

No Discrimination

Perens requires that open standards have “no discrimination”, that is, that “Open Standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor’s implementation. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.” There’s no certification issue, so we don’t have to deal with that.

The European Commission had an explicit requirement that the administering organization must be a not-for-profit, which is easy to show in this case: OASIS is a non-profit! But there’s more to preventing discrimination than simply creating a specification via a not-for-profit organization.

What about the whole first part of Perens’ requirements?

Krechmer maps this single requirement to three requirements:

We can deal with “due process” easily enough. OpenDocument was developed in OASIS, which has clear balloting and appeals process, so that’s clearly met.

The “open meeting” requirement that “all may participate in the standards development” is a little more interesting, but it seems to be met, too:

But that leaves us a mixture of requirements: “do not favor one implementor over another,” and “Consensus - all interests are discussed and agreement found, no domination.” If there’s a single vendor who controls all real decisions, then clearly we have a problem. Thankfully, I think we have good evidence that there wasn’t domination in the case of OpenDocument. If there was no domination, then OpenDocument is an open standard without question. So let’s look at the evidence, shall we?

No Domination

How can you tell if there’s domination by a vendor in a standards body? There are several signs that if present give strong evidence of vendor domination. For example, vendor domination is very likely if the rules or processes controlling the standards’ development strongly limit the range of technical changes, forbid changes that would affect only one particular vendor, or give one particular vendor a sole veto power. The OpenDocument development process had no such problem; the rules in placed allowed anyone to propose changes, even if they forced any or all vendors to change their implementations. But there can be unstated rules that effectively limit others’ participation, even if there’s no obvious written rule enforcing it.

You could also check to see if other implementors involved in the process are complaining about the process locking them out, though that isn’t always a valid indicator. In this case, there seems to be no such problem. IBM’s Bob Sutor reports that, “IBM and Sun are working together happily and effectively on the OpenDocument Format. I think we’ve made a terrific amount of progress in the last year and that’s because of the broad cooperation by the community.” In fact, Andy Updegrove reports that it’s central to Sun and IBM’s strategy “to have many applications that support ODF. Remember - it’s a good thing, and not a bad thing, for there to be many different implementations - both proprietary and open source - so long as they all support ODF. That’s one of the big reasons why ODF matters - to have multiple choices (and not just one - Office), each with its own independently valuable features.”

What we need is direct evidence that there was no domination in the development of OpenDocument.

One easy way is to see if there’s only one party making essentially all the changes, or if in fact others are making proposals that cause technical changes to the specification that affect implementors. Particularly telling are changes that cause all implementors to make significant changes to their products. If all implementors are changing their product to meet the specification, then clearly no one implementor is calling all the shots.

So let’s start by looking at who proposed the original base document, and who proposed changes that were accepted. The original base document was contributed by Sun and the OpenOffice.org group, so clearly they were involved. Their base document was based on actual experience of using the format as their primary format, which is absolutely perfect... here we have a base document based on actual experience.

But did Sun and OpenOffice.org control everything, or were changes made to the specification by others? Sun and OpenOffice.org did contribute the original document, as well as some later changes, but I asked a number of TC members and they easily showed that many other organizations made substantive changes to the specification. In some cases it’s hard to tell who was the proposer or proponent, but there’s more than enough evidence to show that many others were involved. Even in the cases were I have not identified the proposer or proponent, it’s obvious that changes were made that caused implementors to change their implementations.

Below is a long list of examples of the many changes made to the original base document contributed by Sun/OpenOffice.org on the way to its becoming OpenDocument. You don’t need to read this information in detail; the very point is that it’s a long set. Anyway, here’s a table showing some of the changes:
ChangeProposer/Proponent
Modified to allow multiple metadata fields. The original specification did not allow list, e.g., there could only be one author for a document. At the first face to face meeting, strongly urged that this be changed, and the first OASIS draft included this change. Patrick Durusau (Society of Biblical Literature)
Added SVG to support vector graphics using an already-existing standard, and worked to resolve issues involving SVG use. Paul Langille (Corel)
Set of requirements for business charts. Paul Langille (Corel)
Embedded support for a subset of the XForms standard was added. XForms add the capabilities typically desired for custom schemas, which were requested by Europe, but without the horrific interoperability problems that uncontrolled custom schemas can cause. Gary Edwards reports, “It turns out that XForms is an elegant solution to the ‘custom defined schema’ problem, able to address both the “collaborate with yourself” ... model, and, the infinitely more important shared business process schema model. The binding model in XForms is extraordinary... we were quite unaware of this potential [at first]... [but once we began to understand it] oh what a treasure we found.” In particular, its approach manages to be portable among many different systems, and not tied to any one. XForms is also a standard in its own right, which is a good thing; it’s generally a very good sign if a standard tries to reuse existing standards instead of recreating its own incompatible components. European Commission requested support for “custom schemas”; Daniel Vogelheim (Sun) recommended adding XForms.
Attribute fo:margin was added; this improved margin handling. David Faure (KDE)
Numbered paragraphs/headings without number and the text:numbered-paragraph element (an alternative to <text:list>) added more flexibility, for example, numbered-paragraph is better suited for independently numbered paragraphs. David Faure (KDE)
Table templates were added; this makes it easier to control and modify the appearance of tables. David Faure (KDE)
A “sequence of page styles” and support for copy-frames was added, a new wrapping mode was added for graphics, and a desktop publishing mode was added (using the draw:page element). All of this improved support for desktop-publishing-based layout. David Faure (KDE)
Hyphenation became a boolean character property, for more control over hyphenation. David Faure (KDE)
Diagonal lines in table cells were added, providing another helpful option. David Faure (KDE)
Added a line style for the footnote separator. David Faure (KDE)
Added a number:denominator for fractions with a fixed denominator. David Faure (KDE)
Added a new date formatting option (number: month number: possessive-form=”true”), David Faure (KDE)
Added draw:regular-polygon, improving the shape-drawing capabilities. David Faure (KDE)
Added more document statistics (sentence-count and syllable-count). David Faure (KDE)
The original specification’s ordered-list and unordered-lists were replaced by a single list element, with ordered/unordered information conveyed entirely through styles. This made the specification simpler, and also made it easier to switch a list from one form to another. -
A per-paragraph list wrapper element Phil Boutros (Stellent)
Support for the SMIL standard was added as well, even though Sun and OpenOffice.org’s implementations didn’t support it. These aren’t the sort of things you add if you just wanted a rubber stamp. -
OpenDocument changed the older OpenOffice.org format in how style:properties were handled. Originally there was a single properties element, which contained a mix of all style properties. OpenDocument has properties per style family (paragraph-properties, etc.), which allows for a cleaner separation of properties and better handles dependencies within style families Proposed by Phil Boutros (Stellent)
A style:display-name attribute was added and a rule that style names had to be XML tokens was added. Supporters included Phil Boutros (Stellent) and Paul Grosso (ArborText).
The structure of documents was changed so that the type of document (word processing, spreadsheet, etc.) could be trivially determined without looking at the filename ending. This wasn’t in the original base document, and required a structural change, but it was added. Phil (Stellent) recommended this.
The original format had only footnotes and endnotes; this was generalized to notes with a general note-class value, which makes it much easier to support additional type of notes. -
The original format had several different frame-like elements (e.g. images or text-boxes) that shared certain attributes. This was generalized to support a single draw:frame element which would then contain the actual frame content (textbox, image, etc.) plus an optional replacement image. This eliminated unnecessary complexity (by eliminating duplication) and would make it much simpler to implement consistent user interfaces. -
Frames were changed so that they could list a sequence of different format options (e.g., a vector drawing and a bitmapped drawing) so the viewer/processor can choose the ‘best’ format that it can support. -
OpenDocument formulas now use a “namespace prefix” to identify the formula language used. This makes it much less likely that the wrong meaning would be applied to a given formula. -
Lots of other small changes. The style:default-outline-level attribute for heading styles was added, making it easier for users to use templates. The original style:properties was refined into style:paragraph-properties, style:text-properties, and so on. Also, page-master was renamed to page-layout for clarity (and to avoid mixing with master-page). - (David Faure thinks that he commented that the name page-master was confusing, and that Michael Brauer (Sun) then offered to rename it.)

I am sure that there are many other changes not listed above, but I think I have enough listed here to make the point: this specification was a work of many, not a specification controlled by any one vendor.

Various other changes were made to the document to improve it as a document, too. A big change was that the schema definition language changed to RELAX-NG, a standard specification language which is more powerful than the older DTD language yet is very easy to understand. One advantage of this additional power is that automated validation tests of OpenDocument files using the specification can be much more rigorous. It’s also more likely to result in interoperability; RELAX-NG can be much more specific about the permitted values in constructs, eliminating many potential misunderstandings by implementors.

Clearly, there were many changes made after the initial submission of the base document, due to interaction of all the members. The first draft of the original specification was about 108 pages and its schema was 69K. The final version is about 723 pages and its schema is 529K. This growth to a full standard happened through careful review by a large number of experts from different backgrounds.

A risk of making many changes to a specification is that the result may be too hard to implement. The OpenDocument process avoided this problem by having implementors actually implement the changes as they went, and in particular used multiple open source reference implementations as proving grounds. One participant commented, “it was clear that the proprietary [vendors] had gone into the source code or at the least downloaded [OpenOffice.org], and were studying the implementation and methods. ... Explanations, rationale, and techniques were exchanged in ways that would be impossible if not for a common reference application and code base everyone had access to.”

Another Tack: Look at the Participants

I stated above that the most important measure was to see if there were changes made from many different sources, and I think I’ve proven that very conclusively. But for some additional evidence, let’s look at the participants themselves -- do we see the multiple implementors, multiple users, and diversity of views that we’d expect to see from a standard not dominated by any one organization?

Once again, I think the answer is “yes”. The OASIS website gives lots of details; Wikipedia summarizes the people involved in creating the OpenDocument standard.

First, a quick background. Version 1.0 of the OpenDocument specification was developed after lengthy development and discussion by multiple organizations. The first official OASIS meeting to discuss the standard was 2002-12-16; OASIS approved OpenDocument as an OASIS standard on 2005-05-01. This is about two and a half years of hard work; it’s not easy to create a good specification.

The standardization process included the developers of many office suites or related document systems, including (in alphabetical order):

That’s a lot of implementors, some of whom are direct competitors, and they represent a very broad range of concerns. That’s a very good sign, when competing implementors work together on a standard.

Another good sign is that there were users with specific issues who were involved:

My personal favorite is the “Society of Biblical Literature”, because they’re so unexpected -- I would never have thought to invite them! Yet this group worries about dealing with large multilingual documents in any living language as well as many long-dead ones, and they worry about long-term retrieval issues in terms of millenia. The National Archives of Australia was represented, too. If their needs are met for internationalization and long-term retrieval, then my needs will be met too.

Another way to show that they really had diversity is to see the different goals of different groups all getting met. Michael Brauer, chair, insists that the only objective of the group was to support “Desktop Office Suite work”. Others, such as Gary Edwards, believe OpenDocument really covers three areas:

Gary Edwards has claimed that Boeing was actually primarily interested in the second area (SOAs), for example. Interestingly enough, there’s no need to declare which set of goals is “right”. Different organizations joined the group because they had different goals, unsurprisingly, yet in the end all believed their (different) goals had been achieved. That is very good news! A standard that can meet the different goals of different organizations tends to be a good standard as long as it’s implementable... and since it’s been implemented, there’s no question there.

Also, the fact that Boeing wanted the specification to be so good that it could be a “universal transformation layer” is excellent evidence of OpenDocument’s capabilities. To fulfill this role, OpenDocument has to be so expressive that it’s able to capture the information from many different document formats, not just Microsoft Office or any other single format. The result is a more general and flexible standard.

Although it’s not part of the definition of “open standard” I can’t help but be impressed by the expertise of many of the participants. Tom Magliery (Corel/XMetal) was on the original W3C XML 1.0 working group (as well as the original NCSA Mosaic browser team). Phil Boutros (Stellant) is an expert on Microsoft’s file formats. Paul Grosso (founder, ArborText) was chairman of the XSL:FO effort. Doug Alberg (Boeing) well-understood the needs for enterprise publication and content management software systems. Patrick Durusau is a well-known SGML expert. And so on. This is why it’s a good idea to create standards through an open process -- by gathering the experts together, in a way that lets them truly fix problems they find, a group of experts can develop a very good result.

Digital Standards Organization (Digistan.org)

Since this original document was developed, the Digital Standards Organization (Digistan.org) has stood up and developed a much simpler definition for open standard (aka "free and open standard"): "a published specification that is immune to vendor capture at all stages in its life-cycle". More specifically, they define an open standard as one meeting the following criteria:

A key defining property is that an open standard is immune to vendor capture at all stages in its life-cycle. Immunity from vendor capture makes it possible to improve upon, trust, and extend an open standard over time."

Note that this specifically makes clear that it must be available at no cost, and that it must implementable irrevocably on a royalty-free basis. Although I didn't specifically analyze OpenDocument against this particular definition, it should be clear that OpenDocument meets it quite handily.

Indeed, the Software Freedom Law Center published an "OpenDocument Opinion Letter" , which analyzed the various OASIS and Sun license terms and found that they were fine. In particular, "Under the relevant OASIS patent policy, all Essential Claims held by OASIS Technical Committee Obligated Members are available to all implementors of ODF on terms compatible with free and open source software licenses [and] Sun’s license terms for access to its Essential Claims are fully compatible with free and open source software licensing." This is in marked contrast to its report on OOXML; Software Freedom Law Center's Analysis of Microsoft's Open Specification Promise says that the Microsoft Promise Provides No Assurance for Developers.

Conclusions

Without doubt, OpenDocument is an open standard. It meets every requirement of a rigorous (merged) definition of “open standard,” with lots of evidence. In particular, there is significant evidence that it was not controlled by any single vendor.

And that’s a good thing. When I send a pure text file, nobody asks “did you create that using WordPad, vim, or emacs?” When I send a bitmapped PNG file, nobody asks “did you create that using the GIMP or Paint Shop Pro?” Why? Because it doesn’t matter. Data formats that are fully open standards can be implemented and understood by all. By using them, I’m free to use whatever tool I want.

Governments have started to realize how important open standards are:

  1. EU Commissioner Erkki Liikanen said, “Open standards are important to help create interoperable and affordable solutions for everybody. They also promote competition by setting up a technical playing field that is level to all market players. This means lower costs for enterprises and, ultimately, the consumer.”
  2. Europe’s Telematics between Administrations Committee (TAC) said: “Because of its specific role in society, the public sector must avoid that a specific product is forced on anyone interacting with it electronically. Conversely, any document format that does not discriminate against market actors and that can be implemented across platforms should be encouraged. Likewise, the public sector should avoid any format that does not safeguard equal opportunities to market actors to implement format-processing applications, especially where this might impose product selection on the side of citizens or businesses. In this respect standardization initiatives will ensure not only a fair and competitive market but will also help safeguard the interoperability of implementing solutions whilst preserving competition and innovation.”
  3. Neelie Kroes (European Commissioner for Competition Policy)'s presentation "Being open about standards" at OpenForum Europe, Brussels, 10th June 2008 made the following comments: "If voting in the standard-setting context is influenced less by the technical merits of the technology but rather by side agreements, inducements, package deals, reciprocal agreements, or commercial pressure ... then these risk falling foul of the competition rules... As purchasers, we need to be smart when we buy technology. We need to be aware of the long term costs of lock-in: you are often locked-in to subsequent generations of that technology. There can also be spill-over effects where you get locked in to other products and services provided by that vendor. That is just bad purchasing. The Commission must do its part. It must not rely on one vendor, it must not accept closed standards, and it must refuse to become locked into a particular technology -- jeopardizing maintenance of full control over the information in its possession. This view is born from a hard headed understanding of how markets work -- it is not a call for revolution, but for an intelligent and achievable evolution. But there is more to this than ensuring our commercial decisions are taken in full knowledge of their long term effects. There is a democratic issue as well. When open alternatives are available, no citizen or company should be forced or encouraged to use a particular company's technology to access government information. No citizen or company should be forced or encouraged to choose a closed technology over an open one, through a government having made that choice first. These democratic principles are important. And an argument is particularly compelling when it is supported both by democratic principles and by sound economics. I know a smart business decision when I see one - choosing open standards is a very smart business decision indeed... Standards are the foundation of interoperability... When a market develops in such a way that a particular proprietary technology becomes a de facto standard, then the owner of that technology may have such power over the market that it can lock-in its customers and exclude its competitors. Where a technology owner exploits that power, then a competition authority or a regulator may need to intervene. It is far from an ideal situation, but that it is less than ideal does not absolve a competition authority of its obligations to protect the competitive process and consumers... In addition, where equivalent open standards exist, we could also consider requiring the dominant company to support those too. Better, much better, than trying to sort out these problems, is preventing them from arising. And we all have a responsibility to ensure that this type of perpetual lock-in does not happen, and, where it does happen, we have a responsibility to minimise the damage."

In short, open standards create freedom from control by another. That’s a freedom we should all experience.

My thanks to the many people who helped me find the information in this paper, including Daniel Carrera, Patrick Durusau, Gary Edwards, J. David Eisenberg, David Faure, and Daniel Vogelheim.

This article released under the Creative Commons “Attribution-NonCommercial 2.0” license. You can find this article on Groklaw; this article is also available on David A. Wheeler’s web site.

See also Rob Weir's "The Recipe for Open Standards (and Why ISO Can’t Cook)" (September 9, 2010).