Publication of my article "Novells Danaergeschenk" on Groklaw.net has spurred quite some interesting reactions, like this interview with the Futurezone of the ORF, Austria’s national public-service broadcaster, titled "Streit ums Dateiformat der Zukunft" ("Controversy about the file format of the future" — sorry, German only). But there was also a very lively discussion on Groklaw with some very interesting and good comments, some of which I’d like to pick up and/or reply to.
Additional information
Many of the comments were focussed on exploring all the angles of the problems caused by and related to OpenXML, such as:
Fidelity of implementation
This comment points out that the article could also have highlighted a very common practical problem: Even if the specification is commonly known, the dominant player can easily introduce small incompatibilities that will break interoperability for competitors, strengthening the "Incompatibility is always the fault of the competitor" mechanism that I outlined in the article.
This is indeed quite common, and Microsoft’s treatment of Kerberos is good evidence that such a behaviour can be expected for OpenXML. As this comment points out, Microsoft appears to have reserved the right to take legal action against competitors that implement the actual instead of the published specification. But that may not be the only legal angle. Since the OpenXML format contains DRM "functionalities," this comment fears there might be ways to bring up TRIPS/DMCA/EUCD-like legislation against reverse engineering of the true format.
I did not examine these issues in depth for two reasons: I wanted to keep the article as short and simple as possible and to keep it as OpenXML specific as possible. That being said, there is significant economic gain for the dominant player in "not quite" adhering to any standard, and few sanctions for such behaviour. Precisely for this reason establishing and maintaining Open Standards is so difficult.
In my view, this experience makes a strong point for mandating Free Software reference implementation(s) as one of the criteria for Open Standards in software, as I have also explained in my article "Sovereign Software" for the first UN Internet Governance Forum (IGF):
The only way to prevent this sort of thing seems to add one more criterion to the definitions above: ”The standard must have at least one Free Software implementation and all implementations that seek to be compliant with the Open Standard must be regularly tested against the Free Software implementation(s), which act as the common reference base.”
Because Free Software is, inter alia, defined by the freedom to study its implementation, this allows all players in the market to study the common reference base not only in specification language, but also in language, and regular tests against that base can help curb deviations from the Open Standard.
Free Software also provides the freedoms of use, modification and distribution, therefore most vendors can also simply include that implementation in their own software, further reducing interoperability barriers.
More examples for wanting only one standard
As Groklaw reader Toby Thain points out in his comment, the internet itself could also have served as an example for why having more than one standard for any given purpose is harmful. This is quite true and you might want to keep this in mind for debates. In the article I avoided it deliberately, though, as I sought to use an example that was closer to daily life for non-technical people.
Doing the math on OpenXML
This comment on LWN.net points to a blog entry by Andrew Shebanow of Adobe, titled: Is Office Open XML A One-Way Standard? Ask Microsoft. Based on the article by Microsoft’s Rick Schaut that explains why the Mac version of Microsoft Office will not support OpenXML until sometime next year, Andrew Shebanow does the math and comes to the conclusion that implementing OpenXML amounts to 150 work years.
In conclusion, Andrew Shebanow not only questions the economic viability, but also voices scepticism about the chances for a truly compatible implementation that maintains fidelity between the implementations of different vendors. So overall it seems that Rick Schaut has essentially confirmed the issues raised by IBM’s Bob Sutor about OpenXML being a one-way standard for migration to Microsoft.
Principles of standardisation
Another insightful comment was this explanation by Diehl Martin about why Open Standards are important to break the vicious cycles of forced upgrades.
There were also some comments that are better described as related or follow-up articles, and very good ones at that. This anonymous article deals with standardisation on a more philosophical level, from the article:
I don’t, however, think that it’s inappropriate to ask a vendor to change their software to comply with a standard. Do we seriously give MS Office the standing of a national language? The standing of English, or French, or Spanish, or Chinese, or Japanese? Do we really have no right, in the standards process, to ask Microsoft to change their software? Well, not so much change their software, but to implement the standard the other way around – for MS Office to implement the standard, not for the standard to implement MS Office, which is obviously why it’s 4000+ pages, and getting bigger.
Difference to .doc import?
Related is also this comment that discusses how OpenXML (unlike ODF) has never been meant to be a universal document format. Putting OpenXML up against the Open Document Format is described as pure marketing spin, and referring to OpenXML only being incremental change to the old ".doc" and ".xls" formats.
The comment continues that importing an OpenXML file will be no different from importing ".doc" and ".xls" files into OpenOffice or some other program. In fact, I also received a few questions asking why I consider it a good thing for OpenOffice.org to support reading .doc files, while I disagree with the notion of adding OpenXML.
The answer is simple: The two questions have entirely different backgrounds and situations. Before there was an ISO standard universal document format, all applications had to try and support as many formats as possible, because this was the only way to achieve interoperability. And while there were some file formats that would have allowed better interoperability, e.g. the Rich-Text Format (RTF), they were not used by default by the dominating vendor. So writing import/export filters for OpenOffice.org was the only way to get a foot into the door, and has helped the technology field arrive at a truly universal Open Standard: Open Document Format (ODF).
Now an Open Standard exists, is ISO certified and supported by many different applications. It should be the only format used by governments and companies — for all of the reasons outlined in the Groklaw article and this one. And while it is good to maintain support for legacy formats from the time when there was no standard, including ".doc," adding support for OpenXML only serves to help undercut the existing Open Standard by use of market power, technological tricks and political efforts.
Additional reading
Of course some comments also suggested additional reading, such as this comment, which references an article by Nicholas Petreley that is based on an Information Week article by Cory Doctorow, discussing the wider picture in which this debate is taking place.
Ways forward
Creating public discussion and awareness of a problem is often the first step in solving it, but it is not sufficient. In the comments there were several practical suggestions, which I’d like to support and encourage people to participate in.
Support Open Document Format (ODF)
As several people have pointed out, constructively supporting the use, spread, adoption and legislation for truly Open Standards, such as the Open Document Format (ODF), is one of the most useful things people can do. This includes using ODF yourself for cooperating online with others, as this LWN.net comment proposes.
Funny enough, all of this brings to mind RMS’ essay We Can Put an End to Word Attachments of 2002, only that it would need updating to recommend the Open Document Format, boiling down to: I am very sorry, but I could not read your attachment because it was saved in a format that my office could not read. Could you please resend the document in the universal document format "Open Document Format" (ODF), the international ISO standard for document exchange?
Naturally the message should be adapted to the situation, recipient and context in order to have the right tone. If people feel attacked or criticised for having used the "wrong" format, such reminders may end up being counterproductive. But discarding the possibility of changing social habits is no less counterproductive, and ignores evidence to the contrary: Just ask all the people who are now sorting their garbage for recycling and compare that to the position they took 30 years ago.
Support ODF plugin for Microsoft Office?
Although it might seem strange to suggest that anyone should improve a Microsoft product, we should also consider the usefulness of improving the ODF plugin. Making it very easy for all users of Microsoft Office to interact via ODF would provide a major advantage for ODF over OpenXML.
Community comments to the ISO process
Another comment on Groklaw proposes to turn the incorporated denial of service attack that is OpenXML back on Microsoft by extensively commenting on each of the 6000 pages of specification during the review process prior to the ISO vote.
Preventing ISO acceptance of OpenXML could indeed be an important step, and while one might have sufficient confidence in the ISO process to work better than that of ECMA, some support on this side might be very helpful.
Linguistics
Finally, I was (for the most part positively) surprised by the interesting discussions that arose from my usage of the terms "Danaergeschenk" and "Salomonian," including Bob Sutor making Danaergeschenk the word of the day on his blog.
Danaergeschenk
Although I think some people might have taken this a little too seriously, there was some interesting discussion regarding my use of "Danaergeschenk" in my article.
Some people felt that I should have used "Trojan Horse", which is a common expression in both German and English, but that never really occured to me for various reasons. I checked this page for a translation of Danaergeschenk, and ruled out Trojan Horse for various reasons: The Trojan Horse wasn’t Trojan, it was Greek, for which Danaer or "Danaos" is original Latin term. It also isn’t common to return horses to the stores around christmas. And as some people right pointed out, the terms have different connotations and emphasis.
So after some consideration, I decided to go with "Danaergeschenk", even though I knew this was entirely unknown to English speakers, which is why it was briefly introduced in the beginning. Given that words like "Fahrvergnügen" made it into English, I thought this might prove to be a fun addition, even if people followed this advice and simply called it D12K.
Salomonian
As far as "Salomonian" is concerned, I did not expect it to be that difficult, as king Solomon is a very common reference in German. For those who’d still like to know how it was meant, I believe this comment explains it quite well.
I guess that usage of both these words are owed to my humanistic education, which had me study Latin for six years. My apologies to all who felt I subjected them to the pain of that education subsequently.
