Microsoft's "Mission Lock-in" is Accomplished

Summary: Further to this week's Microsoft Office crimes (and conviction) in Germany, the return on investment in OOXML corruption is debated

ONE YEAR after the climatic peak of the OOXML corruption, a person who attended the BRM reveals that Microsoft has no intention to even properly maintain OOXML. It's just a proprietary format that Microsoft needed an ISO stamp for; it's not intended for actual use and it remains awfully buggy, by admission that is made openly (it bears repeating that Microsoft will never ever implement OOXML). This would be truly amazing to an outsider but hardly surprising to those who watched how Microsoft bullied, lied, blackmailed, and bribed to pass OOXML past ISO. it's all documented. Here is where things stand today:

The document N1101/N1168 contains for example, several items in which they recognize that there are decisions made in the BRM (BRM resolutions) which were not incorporated into the final published text of the standard. In other words, even taking almost a year after the aproval of the standard to publish the text (yes, approved without reading), there wasn’t time/attention or anything else necessary to assure that the changes were published in the text (most of those changes, “conditioned” the approval). What makes me much more angry about this is that during the BRM I asked about who would be responsible for verifying that all these changes would be part of the final text and the answer was ITTF (kind of joint ISO/IEC secretariat). When I asked if the ITTF would really make this work, I received as a reply the intimidating: “You are doubting the ITTF, kid ?”…

[...]

I saved the best for the end: document N1187. This one says that OpenXML “as is” contains unintentional errors that may prevent existing documents to be fully represented in this new format. It is amazing because the legacy support was alleged as the main reason for OpenXML development and approval at ISO, and also the reason why several countries supported the development and approval of the standard. In this document, they also explain the criteria that will be used to specify the changes that will be developed, so that they can do it all really quickly (in other words, they go trough the breaches of the JTC1 directives to get these changes incorporated into standard already approved without making much noise about it).

Unfortunately I can not put all these documents here, to allow access trough the blog, because they should be restricted SC34 documents (yep, zero transparency), but I believe that sooner or later they will be published somewhere (and of course, NB members should already received those).

Speaking of OOXML, which can be seen as almost synonymous with white-collar crime, here is a good new article about -- and against -- lobbying, where Microsoft is the shamed industry leader (meaning that it manipulates governments the most, primarily in the United States [1, 2, 3, 4]).

There’s a reason why lobbying has boomed so much over the last decade. The potential return on investment is just too lucrative to pass up. Some things are easy to quantify, a contract, an earmark, or a direct payment for services. But other things, like tax breaks, can take a little bit more time to figure out (at least for now). For example, a University of Kansas study, to be released today, will show that firms pushing for a “tax holiday” in 2004 received a 22,000% return on their lobbying investment. I’ll write that number again: 22,000%.

The cost of breaking ISO, breaking the law, and making more enemies is perhaps belittled by the high margins of Microsoft's most profitable product, Microsoft Office. So again, to Microsoft, all this crime was a case study or a textbook example in RoI (return on investment). It's the economics of crime.

When it comes to the OOXML fiasco, the regret is not to do with the misbehaviour; it's probably to do with getting caught. ⬆

"I have lost my sleep and peace of mind for last two months over these distasteful activities by Microsoft."

--Professor Deepak Phatak