Tineke Egyedi, senior researcher of standardization at the University of Delft, The Netherlands, president of the European Academy for Standardization and vice-chair of the International Cooperation for Education about Standardization, send an open letter (PDF) to software vendors with the title Who pays for interoperability in public IT procurement. In her letter she calls upon vendors to submit their implementation of the OpenDocument standard and the Office Open XML standard in software products for independent conformance testing and to verify the interoperability. She feels this is needed to make sure that governments and it’s citizens do not head into a new vendor-lock and to ensure vendors do not alter the open standards along the way.
The letter is as follows:
Who pays for interoperability in public IT procurement?
A public letter to the IT industry about document format standards
Delft, 16 November 2008
It is not uncommon for governments to voluntarily head for vendor lock-in. As a citizen, however, I have a direct stake in my government basing its public procurement of IT on open standards. This stake may be most evident for â€˜civil ICT standardsâ€™ (Andy Updegrove), i.e., for standards that support access to government information and exchanges with government such as document formats (e.g., sustainable digital data). However, I also have a standards-related stake in IT procured for government-internal processes because, first, in practice government-internal and â€“external IT processes cannot be separated. Second, because of the increasing costs that accompany vendor-lock-in. Third, because government procurement is good for 16% of the European IT market and is therefore a means towards a more competitive and sustainable IT market.
A main reason for voluntary vendor lock-in is the fear of lack of interoperability of IT products in a multi-vendor environment. Experience shows that standard-compliant products from different vendors need not necessarily interoperate. As is known, a dominant vendor may design in incompatibility to break the integrity of a standard (e.g. Java platform). But usually incompatible standard implementations are the unhappy outcome of good intentions.
Problem of document format standards
In the field of document formats there is an additional complexity. For the external reader: ISO4 has ratified two competing XML-oriented standards for document formats. The first one, the Open Document Format (ODF, ISO/IEC 26300) was ratified in 2006 and stems from OASIS, a standards consortium. The second one, Office Open XML (OOXML, ISO/IEC 29500) originally stems from Ecma International, another standards consortium. Although ISOâ€™s OOXML process has been widely contested, which caused a delay in its final approval, according to the ISO website the standards is to be published shortly.
ISOâ€™s approval of a second, overlapping standard will not have lessened government fears about interoperability in a multi-vendor environment. The market has become less rather than more transparent by means of this standards effort. To re-create some transparency about the interoperability of applications and reduce the fear of post hoc expenses in public procurement, conformance and interoperability testing is needed. Plug-test events are needed to test the factual interoperability of standards-based products from different vendors. To be credible to all concerned, a neutral, independent testing centre such as ETSI may need to be involved to e.g. develop test-suites and coordinate plug test events.
Interoperability between multi-vendor OOXML applications
Current discussions on open standards highlight that multiple implementations are an important sign that standards are really open (see presentations by Rishab Gosh and by Thiru Balasubramaniam, The Power of Procurement). Regarding ISOâ€™s OOXML, the contention is that no company has yet implemented the full standard, not even its primary sponsor Microsoft; and that the six thousand page specification is too complex and too inconsistent to implement. Are these contentions true? If not, governments will want more than verbal claims to the contrary. Moreover, they can easily be countered with third party conformance and interoperability tests, including a plug-test event with multiple OOXML-compliant IT vendors.
Interoperability between ODF applications
All major vendors, Microsoft included, have agreed to support ODF ISO/IEC 26300, or are already doing so. That is, the availability of multiple implementations is not a problem here. Moreover, interestingly, two weeks ago OASIS initiated a technical committee to organize conformance and interoperability tests. Given its scope, this committee will provide transparency to governments about the degree of conformance of applications to ODF and the interoperability of ODF-documents. Less clear is whether the committee also intends to address interoperability between standards versions, or more general: what policy it has on standards change. To my knowledge, such policies have not yet been defined by any standards consortium or standards body. They would befit the area of civil ICT standards.
The OASIS committee explicitly does not address â€œidentifying or commenting on particular implementations” or any certification activities. Government procurement officers will ultimately need testing at this level and want to involve an independent third party testing centre for this purpose. Moreover, OASIS, too, might at a later stage want to involve an independent third party in order to avoid credibility problems.
Having two overlapping standards brings about its own problems, as testifies a review of current ad hoc solutions – converters, translators, plug-ins – to re-create compatibility between ODF-products and Microsoftâ€™s partial implementation of the OOXML standard. Those who develop a low quality and overlapping standard, qualifications which also OOXML supporters use, are not the ones who pay for the consequences. Regrettably, citizens will be paying the price for lack of interoperability.
Although there is no formal accountability to fall back upon in standardization, those who initiated the duplicating effort may feel a – corporate social – responsibility for what happened. Their help is needed to shift interoperability costs from governments and citizens (post hoc) back to IT vendors (ex ante), the source of the interoperability problem. As a start, will they fully cooperate and support OASISâ€™ initiative of conformance and interoperability testing? Are they prepared to shoulder the costs of independent, third party conformance and interoperability tests, tests that are needed to assure governments that no unexpected problems will arise ex post?
Delft University of Technology
(T.M.Egyedi at TUDelft.nl)
The letter was send to HP, Microsoft, Sun Microsystems, IBM, ECMA and OASIS.
I completely agree with Tineke on this. I do believe it is time we see the end of vendor-sponsored ICT research on various issues. One can hardly expect independent verification of perfomance claims or -in this case- conformance claims by sponsored researchers. Tineke is correct to point out that the problem isn’t simply open source or open standards, but also the implementation of open standards in applications. Recent research already showed that issues that open source developers have with implementing open standards don’t necessarily reach the proper agencies to remedy the issues.
Thus, feel free to spread the new about this open letter and forward it to whomever you think needs to hear it.