I sometimes hear claims like:

“KOffice and OpenOffice.org have poor interoperability, and thus ODF is not ready for being adopted as a standard.”

I'd like to personally comment on this claim, because I think it is misleading and also ignoring important issues.

It might be true that the interoperability between OpenOffice.org and KOffice is not perfect yet, but I'm sure that it will evolve and improve over time. Now that more and more applications and vendors are adopting ODF, more and more people will have to deal with interoperability issues between different implementations. In some cases interoperability issues are caused by missing features in some of implementations. Gaps in the specification itself can cause interoperability issues as well. No matter what the reason is, over time interoperability problems will get fixed as part of the open and transparent discussions and negotiations between different vendors and implementations.

A different approach would be to take one implementation and to document everything that this one application does. On the one hand this has the advantage of getting all kinds of feature areas specified in a very short amount of time. Thus, this reduces the interoperability issues caused by something not having been specified yet. However, this increases the other risk, i.e. that other vendors might not be able to implement all the specified features. In addition, by creating a specification that is almost exclusively based on one particular implementation, all other implementation have to follow concepts that are dictated upon them. Why should one vendor know what is best for the rest of the world? For example, why should a traditional office suite vendor that focuses on just one platform know what is required for web based office suites, office suites for other platforms, office suites for other devices, the future of office productivity, etc.?

Sure a standard derived from one particular implementation can evolve as well, but using one particular implementation as the basis for a specification puts boundaries on the innovation, i.e. it becomes much more difficult to think outside of the box.

If I look at things like Java EE, it also evolved over time based on the input of many different vendors participating in the JCP. The first version of the Java EE specification did no specify everything. Application server vendors implemented the existing Java EE specification and added their own solutions for things like clustering, deployment, etc. Over time more and more of the first proprietary features moved into the Java EE specification based on the discussions and negotiations between the different vendors. Even today's version of the Java EE specification does not specify everything. Thus, features get added to the specification based on experience and best practices from different vendors, instead of just specifying (documenting!?) the first available implementation for a feature area. There might be better approaches to a problem than the one chosen by the first available implementation.

Another example is HTML. In the early days of HTML developers had to create/generate different HTML content for each of the browsers. Over time the HTML standard has become richer and more mature based on the input and experience from various parties, so that nowadays developers only have to create/generate one version of HTML content.

Some people use the claim I mentioned above to justify that ECMA Office Open XML is the better and more complete standard. I personally disagree with that position due to the arguments just made. In addition, how many different full implementations of ECMA Office Open XML are there again? How many platforms and languages are already supported? How many vendors ship products that support ECMA Office Open XML? I personally haven't seen any proof yet, that ECMA Office Open XML provides a higher level of interoperability between independent implementations.

This leads me to one other topic. I think that having one or more open source implementations of an open standard available is very useful. For example, multiple vendors are shipping products based on OpenOffice.org source code (e.g. OpenOffice.org, Sun's StarOffice, Novell's edition of OpenOffice.org, Red Hat's edition of OpenOffice.org, IBM Workplace). Since these ODF implementations share the same core code base, interoperability issues are less likely. In addition, governments don't have to wait for vendors to develop products that implement a standard for their local native languages or can be afforded by the citizens. Governments can just use the source code to create their own implementations.

All in all, I'm convinced that ODF is ready for adoption today. Sure, it will evolve and mature over time, but that is a natural process. Over time there will be a healthy competition in the office productivity market again with great interoperability between different implementations and new applications and concepts that nobody is even thinking of today.