{"id":230,"date":"2009-06-26T16:30:00","date_gmt":"2009-06-26T21:30:00","guid":{"rendered":"http:\/\/2d823b65bb.nxcli.io\/2009\/06\/odf-plugfest.html"},"modified":"2009-12-28T23:38:40","modified_gmt":"2009-12-29T04:38:40","slug":"odf-plugfest","status":"publish","type":"post","link":"https:\/\/www.robweir.com\/blog\/2009\/06\/odf-plugfest.html","title":{"rendered":"ODF Plugfest"},"content":{"rendered":"

\"\"<\/p>\n

Although the term may be alien to some<\/a>, “plugfests” have been around for around 20 years. A plugfest is when implementors of the same interface get together and test the interoperability of their products. In the beginning this was done with wired standards, USB, etc. (thus ‘plug’). Over the years the term was applied to networking at all higher levels of the protocol stack. The concept is also applicable to document exchange formats like ODF.<\/p>\n

We had an ODF Plugfest<\/a> last week in the Hague. Although we’ve had interoperability workshops and camps before that attracted a handful of vendors, this was the first one that had nearly universal participation from ODF vendors. I’m not going to recap the details of the plugfest. Others have done that already. But I will share with you some of my conclusions, based on long discussions with other participants, from whose insights I have greatly benefited.<\/p>\n

In an ideal world, specifications would be perfect and software applications would be bug-free and users would read the manuals and we would achieve perfect interoperability instantly by anointment of the salubrious unction of standardization. But to the extent this planet’s population obdurately persists in imperfection, we are resigned to make additional efforts in pursuit of interoperability. We are not alone in this regard. The only standards that don’t need to work on interoperability are those standards that no one implements.<\/p>\n

We should use every licit technique at our disposal to give the user the best experience with ODF we can. In a competitive market you can not get away with telling your customer, “Sorry, your spreadsheet doesn’t work because page 652, clause 23 says ‘should’ rather than ‘shall'”. If you did that you would not have that customer for long. (Unless, of course, you have a monopoly, in which case many seemingly irrational, anti-consumer actions<\/a> can occur, seemingly without consequences.)<\/p>\n

Further, I assert:<\/p>\n

    \n
  1. Users want real-world interoperability, and not excuses<\/li>\n
  2. Real-world interoperability is what users see and achieve in practice<\/li>\n
  3. Where vendors have the will to interoperate, achieving interoperability is a known technical problem, with known engineering solutions, but where the will to interoperate is lacking, there are no technical means of compelling interoperability<\/li>\n
  4. Interoperability lies at the intersection of technology, engineering standards, competition law, intellectual property and economics. There are no silver bullets, although there are a arsenal of proven techniques that can help to improve interoperability<\/li>\n
  5. Achieving interoperability is facilitated by a variety of cooperative activities, including standardization, test case creation, implementation testing, online validators, plugfests, defect collection and reporting<\/li>\n<\/ol>\n

    Going forward there is a promising constellation of efforts converging around ODF interoperability:<\/p>\n