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:
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.
