The following article has just gone up on Groklaw, one of my favorite news sources, and is mirrored here for convenience. Permanent URLs for this article are:
- http://www.groklaw.net/article.php?story=20061208135621706
- http://www.fsfe.org/fellows/greve/freedom_bits/novells_danaergeschenk
German is an interesting language, and many of its words have made it into English. Novell’s recent deal with Microsoft is begging to add another one: Danaergeschenk. The term translates to "Gift by the Danaer" and has the same roots as "Greeks bearing gifts," which goes back to the siege of Troy.
Novell’s Danaergeschenk to the world is the recent announcement to implement OpenXML support in OpenOffice.org.
Bob Sutor, IBM’s Vice President of Standards and Open Source has written a good analysis why the specification is more akin to a denial of service attack than an Open Standard. OpenXML basically represents a change of strategy: Instead of trying to hide information by not telling anything about their products to anyone, they’ve apparently now switched to hiding information in noise, which is by far the more effective method.
This is consistent with Microsoft’s strategy in the European antitrust case, where the interoperability information for the workgroup server communication at the time of the hearing in April 2006 was said to amount to 12.560 pages and counting, put together by hundreds of people working "day and night" according to Microsoft. During the court hearing, Microsoft made clear that it would be impossible to make use of this documentation unless one had access to their specific form of representation, which was patented by Microsoft and would require a patent license, which they were not planning to give any time soon.
So in the case of OpenXML, Microsoft now seems to be using Novell to put a pro forma implementation of OpenXML into OpenOffice.org, which will make it easier to migrate from OpenOffice.org to Microsoft Office but can never be sufficient to read all Microsoft Word Documents.
One reason for this is the sheer size of the implementation; another reason relates to the containers used within OpenXML, which make use of Microsoft’s proprietary implementations instead of industry standards such as SVG. Moreover, there is really no knowing what kind of hooks Microsoft has put into the specification that people will not detect at first reading. Indeed, it is quite possible that OpenXML will allow what Bruce Perens refers to as "Predatory Pratices" in his definition of an Open Standard.
And while there will be a migration path from OpenOffice.org to Microsoft Office, Microsoft avoids opening the inverse path to any other ODF-compliant Office program, by neglecting ODF support in Microsoft Office.
It appears that with the help of Novell, Microsoft has found a way to use the freedom to modify the software against Open Standards and the Free Software community.
Two of the mechanisms I expect they will seek to employ in this attempt to undermine Open Standards are well-known and comparatively powerful:
- 1. Incompatibility is always the fault of the competitor
2. Weaknesses in political decisions regarding technology
Point one is well-known as the fear of not being able to interoperate with colleagues, family, or other companies. This is a common fear especially among non-technical users today, who often feel (and are!) helpless in case of incompatibilities, no matter who caused them or for what reason.
With OpenXML, it appears as if there will be interoperability on paper only, but in reality people will experience numerous difficulties unless they use Microsoft Office. Because most users rightly fear and loathe incompatibilities, out of a sense of false security and lack of technological background, they will often choose the dominant product, effectively punishing the competitor for the behaviour of the dominant player.
The second point is slightly less obvious to people who have not had much interaction with the legislative process. The criteria of what constitutes an Open Standard are under permanent debate in various regions of the world and generally conclude at a set of principles that should be adhered to, but mostly without compliance checking.
The OpenXML specification was written to fulfill these criteria in theory, but in reality, will it prevent Open Standards? If so, it will undermine the expressed will of the political debate, which was intended to serve interoperability.
But understanding this and reaching a correct conclusion requires some grasp of technology, and the apparent strategy behind OpenXML obviously counts on the fact that politicians either are isolated from technology or not interested in the technological background and will apply a "the truth must be somewhere in the middle" approach instead of considering the technical facts.
The result of this then is the "mistaken salomonian solution" of accepting both ODF and OpenXML as sufficiently Open Standards, which is no solution, at all.
A common joke about Open Standards is that they are great because there are so many to choose from. In fact, a situation where each vendor has their own "Open Standard" is a situation in which there is no Open Standard, because having a standard means that multiple competing vendors all use the same protocol, format or specification.
As the various standards for power plugs used around the world demonstrate, standards are an area where too much choice can be detrimental to competition and society at large. That is why standard setting efforts generally try to arrive at only one standard for any given purpose.
From a naive stance, having two standards for documents may not seem so bad. But when considering that only ODF really is an Open Standard fully supported by multiple office applications and that the OpenXML format will be pushed with all the power of the dominant desktop vendor, it becomes obvious that accepting both ultimately means undoing the political efforts on Open Standards that have been undertaken in the past years.
Given that the strategy to undermine Open Standards and freedom of choice is comparatively clear and obvious, what is there to do?
On the governmental side, in my view it will be necessary to continue the debate on Open Standards and review the current policies to do assessment of levels of interoperability, and to come to one preferred standard for each purpose.
Criteria that should be used for making such a preference are the number of independent programs providing a complete implementation of that standard and length of the specification with a strong preference for concise definitions.
From a vendor’s side, it will be necessary to provide clear, concise and understandable information on why OpenXML is not truly a standard and have default settings that discourage its use.
OpenOffice.org should refuse to add OpenXML to its main branch, and we should avoid OpenXML while spreading information about the problems as far as we can.
And finally, we will need to enlarge the global multi-stakeholder discussion about the subject of Open Standards. The Dynamic Coalition on Open Standards (DCOS) that FSFE helped initiate at the recent UN Internet Governance Forum (IGF) may be a first step for that.
Let us return this Danaergeschenk to the store.
