Be careful. The assumption here is that there be open collaboration among ALL stake-holders in order to fix ANY problems with the standard (eg, potential interop problems). Standards don’t come perfect and complete (future proof) out of the box.

An otherwise publicly viewable standard that is broken (inconsistent, ambiguous, etc) AND NOT fixable by the stakeholders will NOT result in interoperability by independent implementations.

Also, interoperability among independent parties within the context of any fully and well-specified open standard does not at all equate to interoperability with a *specific* closed source software.

Also, in practice, many standards allow for extensions. Interoperability with extensions that are not (obviously) similarly standardized (open and well-specified) is not achievable.

Avoid OOXML because it is such a mess. It’s inconsistent, ambiguous, underspecified, and not very open to changes as the ECMA and ISO fast-track process demonstrated. Its only attraction from the user perspective is the completely misplaced hope that it will somehow lead to good and lasting interop with Monopolyware. [Avoid Monopolyware.]

Keep a leash on ODF because the current 1.1 version has an extension mechanism that can function as a loophole the size of the Grand Canyon. Loopholes allow flexibility but also allow abuse.

Access to the actual source code of an application has real value within the context of open standards. This should not be overlooked or even downplayed. Those not revealing the source code must be trusted to provide bug free and standards compliant apps without significant extensions. Meanwhile, open source code means that even the extensions (notably, the good, stable extensions) come with open specs, making interop by others realistically possible even when bugs and extensions exist. [Bugs always exist. Extensions are frequently desirable.]