03.12.08
Dirty OOXML Tricks Revisited; “Embrace, Extend, Extinguish” Strategy Redefined
The press is far from over discussing some of the misbehavior we have witnessed over the past couple of years. Although discussions about OOXML ought to have been just technical, they ended up getting mixed in the face of endless misconduct. Which shall one criticise more and bring more attention to: the technical hoax that is OOXML or the corruptions which OOXML has revealed?
Pieter has published a good new piece which looks at both aspects of this.
To conclude, Microsoft have, with OOXML, shot themselves in both feet, then put the bloody stumps into their big mouth and chewed, hard and long. They created a fradulent process by corrupting ISO at a high level. They engaged national bodies in this process, then bought and bullied those bodies into voting “properly”. And when the committees refused to be intimidated, they went to ministers and tried to bribe them. They used their press and astroturfing budgets to sell this as a fair and necessary process. They pretended that they were the victim, of an autocratic ODF and a manipulative IBM.
This excellent summary is all very truthful, and it can be accompanied by well-documented evidence to back the claims. IT Pro has published a new article as well and it emphasises the failures of the standardisation process. Here is a portion of the text:
A toxic leech
OOXML is controversial for a number of reasons. Critics argue that OOXML is not so much a specification as a description of Microsoft’s existing proprietary data formats, complete with the replication of historic bugs, the most notorious being the treatment of 1900 as a leap year. The specification was derived internally to describe Microsoft’s current data formats, and has not benefitted from the usual wide-ranging debate and participation from competing interests, hammering out their differences to find the points they have in common, that accompany the conventional definition of a standard.
A standard is intended to facilitate multiple implementations of a protocol or data format, not to give validation to the one existing implementation of that format. There have also been complaints that, despite the fact that over 3500 comments were raised against the original specification, delegates weren’t able to suggest amendments that contradicted Microsoft’s current implementation.
[...]
In truth, the opposition has come from all quarters, and has been most vocal among those interested in open standards, which includes everybody from governments through to representatives of the free and open source software movement, and also includes many parties with an interest in maintaining open access and network neutrality for civil or commercial reasons, including the likes of IBM, Google and Oracle.
Rob Wier reminds his readers that OOXML is saturated with the same characteristics one typically finds in “Embrace, Extend and Extinguish” tactics. OOXML’s licence [1, 2, 3, 4, 5] and dynamicity, not to mention Mono dependencies in broken and lossy translation, may all be signs of things to come. They justify the need to intercept OOXML, which is falsely advertised as a case of opening up (realistically, more like broadening, as in ‘extending’ and moving goalposts).
Here begins the lesson on Embrace, Extend and Extinguish (EEE). Classically, this technique is used to perpetuate vendor lock-in by introducing small incompatibilities into a standard interface, in order to prevent effective interoperability, or (shudder) even substitutability of competing products based on that interface. This EEE strategy has worked well so far for Microsoft, with the web browser, with Java, with Kerberos, etc. It is interesting to note that this technique can work equally well with Microsoft’s own standards, like OOXML.
[...]
So, by failing to include this in their conformance clause, OOXML’s use of the term “implementation-defined” is toothless. It just means “We don’t want to tell you this information” or “We don’t want to interoperate”. Conformant applications are not required to actually document how they extend the standard. You can look at Microsoft Office 2007 as a prime example. Where is this documentation that explains how Office 2007 implements these “implementation-defined” features? How is interoperability promoted without this?
Groklaw has some good articles covering “Embrace, Extend, Extinguish”, so you are encouraged to read older stories such as this one.
You’ll hear some emails read aloud, one of Bill Gates’s, an email from 1996 about Java, where he says he was losing sleep over how great Java was, and you’ll see a strategy he suggested — “fully supporting Java and extending it in a Windows/Microsoft way”.
[...]
Well, when applets are cross-platform, it expands the number of applications that are available to you so you can go to a website. And if you have a Linux computer or a Macintosh computer or a Windows 3.1 computer, you can get an application and it will run.
You don’t have to either select a specific application or hope that the independent software vendor or the website created the application for your platform. So it would increase the number of applications available to you.
“Ronald Alepin, an independent consultant and former CTO for Fujitsu, disputed the idea that Microsoft had been an innovator in the field. He said that interoperability protocols were developed by companies other than Microsoft, and that Microsoft has simply extended the protocols and then refused to disclose the extensions. In so doing, he told the court, Microsoft “has hijacked standard interoperability protocols agreed by the entire industry.”
As the previous post from an anonymised contributor insists, it is very unlikely that Microsoft has changed its ways (nor that it ever will). It’s the same old tricks, with the addition of software patents. in a disguise named “open”, or “interop”. And there is always some invasive Microsoft agent who tries to sell this to us. █
Content is available under CC-BY-SA