Commercial Open Source Software

ODF Plugfest: Open Standards and Interoperability

Orvieto last week hosted the second ODF Interoperability Workshop, an international event bringing together ODF implementers from all over the world. My talk “open standards and interoperability” opened the first session on day 1, just after Fabio Pistella - President of the Italian National Center for ICT in Public Administrations (CNIPA) – welcomed the international audience.

To serve the purpose of highlighting the need to depecrate ‘de facto’ standards and to foster open standards’ definition, implementation and interoperability, I put in my talk a number of concepts underly the purpose and the motivation for open standards. This blog entry is aimed to recap some of the issues raised and possibly extending them.

Why we need standards.

Rosetta stone, the importance to decodify the (internal) message by · skëne ·

Understanding the need of a decodification mechanism – required to extract the information implicitly carried by the configuration of symbols and structures of the “external message” (see “Gödel, Escher, Bach: An Eternal Golden Braid“) – is fundamental to receive the “internal message”. In fact to make explicit the implicit information contained in the external message we do need detailed specifications of the format. File formats are the “external message” and in order to create a “mechanism” able to extract the internal message, typically a computer or device carrying a specific program software. Only if all information needed to create such mechanism is available, the internal message could eventually be received and understood.

What is Interoperability?

Interoperability: Which Standard do you Use? by gruntzooki

ISO/IEC 2382-01 defines interoperability as:

The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units.

Other definitions are more oriented towards data exchange or predictability of results:

the ability of two or more systems or components to exchange information and to use the information that has been exchanged.(IEEE Standard Computer Dictionary).

[a]n essential communications link within public safety and public service wireless communications systems which permits units from two or more different entities to interact with one another and to exchange information according to a prescribed method in order to achieve predictable results. (US Federal Communications Commission).

All these different definitions are worthy, but when we talk of interoperability in the context of file formats managed by desktop applications it becomes complex. Interoperability is comprised of maintaining the consistency of a number of qualities, ranging from the visual appereance of a document, its structure while editing it, the behavior and capabilities of embedded images, objects, etc.

ODF Plugfests are playing a crucial role for the promotion of ODF interoperability, as I happened to figure out joining it, and I think that European Public Administrations should take part in the process to certify standards’ compliance. Otherwise they risk to adopt products implementing a ‘dialect’ of the original standard, putting at risk interoperability.

Are Open Standards enough?

Standards de facto: Toothpaste’s caps invariably drop into the sink drain! by The Adventures of Kristin & Adam

Open standards‘ specifications are the result of a process. Only if creators, implementors and end-users are all given the opportunity to participate. What we need to create an open standard is an “open standardization“. Ken Krechmer‘s excellent papers are a must reading in this field.

The evaluation of the ‘openess’ of standards settings organizations (SSO), commissioned to IDC by the Danish government, use Krechmer’s definition on open standards to assess ten different SSOs, included OASIS.

IDC’s study says that OASIS’s Technical Committee guidelines do not contain information on the subsequent procedures. But ODF OASIS TC is already committed to continue to develop future versions of the standard, granting that for changes all rules apply. More important, ODF OASIS TC welcomes users proposing changes.

While Conformance governance is not always part of a standard at OASIS, the OASIS ODF  Interoperability and Conformance TC (OIC)  is actually testing the value of conformance also through ODF Plugfests. ODF Plugfests are events gathering together multiple implementers – both commercial vendors and open source projects – to check the level of interoperability.

Participate in Standards Development.

Participate in standards definition by (I Am)

The following table – excerpted from above mentioned Krechmer’s work – shows how creators, implementers and users see openness differently. On a case by case basis different SSOs might have different approaches. SSOs having among its members not only implementers can better balance stakeholders’ interests, though.

Even when all stakeholders have an interest in a specific criteria, their own interests may vary a lot.

“Open Change” – the ability to extend a standard – could be seen as an opportunity to enrich, diverge or customize a standard, depending on who you are. On the same line of thought “One World” – a single world-wide standard for a single purpose – is a users’ genuine desider, maybe a chimera for creators or a thread for some implementers and opportunity for others.

Last but not least “Open Interface” – requiring backward compatibility to previous systems and forward compatibility to new ones – is of interest to users and implementers, again from a different perspective, but it is rarely seen as a major issue from pure creators.

Conclusions and recommendations.

Conclusions and recommendations by ecstaticist

European Public Administrations urge to join Standards Settings Organizations, in order to avoid poor interoperability and also to influence standards definition, if needed (signature enabled version of ODF, just to name one of them).

Open Standards are first and foremost about participation, implementers’ good-will is a good thing, but maybe not (always) enough. Until now standards compliance in this field is only a self-certification process, maybe Europe should start think ing about a more formal approach.

Tomorrow’s data availability depends upon today’s standardization policies and practices.