Home > Standards Blog

Advanced Search 

Welcome to ConsortiumInfo.org
Wednesday, June 28 2017 @ 02:39 PM CDT

Email Article To a Friend View Printable Version

Vendor Escalation, Process Politicalization, and What Needs to Happen Next

OpenDocument and OOXML

Not so very long ago, most standards were set in a largely collegial atmosphere by career professionals who met in face to face meetings over a period of years.  Along the way, they came to know each other as individuals, and established relationships that helped the process move forward and allowed for productive give and take.

While this process was not without its back scratching and game playing, at least the impact on interests other than those directly involved tended to be limited.  After all, if performance standards for light bulbs had settled out at 45, 65 and 95 watts rather than 40, 60 and 90, no end user’s ox would have been gored on the desktop, when it came to lighting.


During these more collaborative times, those that defined the rules for organizations such as ISO, IEC and ANSI (the American National standards Institute) tended not to favor simple majority voting to determine outcomes.  Instead, they put a high value on consensus, in order to lessen the chance that minority interests would be oppressed, or important technical matters ignored.  Other rules required that compliant processes provide a means whereby specific technical decisions could be appealed, so that the consensus process could not be abused.

The rules that included these principles were fairly high level, and often less than legally precise.  For the most part, this worked well enough over time, and allowed an already necessarily slow, surface mail-based process (in pre-Internet days) to move a bit faster than it otherwise would have if more detailed process protections were in place.


In much of the standards development world, which encompasses every area of products, services and activity, this is still largely the way the standards systems operates.  But sadly, that is no longer the case where information and communications technology (ICT) standards are created.

This is now:  What we have just witnessed with the OOXML adoption process is the catastrophic failure of a system built for one purpose that has been subjected to forces that it was not designed to withstand.  Those forces included intense pressure from vendors, and even political pressure.  The tactics utilized appear to have included taking advantage of rules crafted to foster openness, placing or outmaneuvering committee chairs, and recruiting employers to pressure committee members to vote their employers’ interests rather than their own technical judgment.

This is hardly the first time that such tactics have been employed in standard setting.  But it may be the most global, and is certainly the most public example in recent memory.  Given this publicity, there is a danger that such behavior could become viewed as acceptable by those new to the process.  And even old hands may wonder whether they need to adopt similar tactics on a defensive basis in the future, resulting in an increasingly sordid “race to the bottom” of the abusive practices barrel.

For these reasons, the OOXML process just ended represents a watershed event that needs to be addressed promptly and systemically, in order to lessen the chances of repeat performances, and to deal with them effectively if they nevertheless occur.

In future entries I’ll air my ideas about the specific reforms that will be needed.  First, however, I think we need to agree on what just happened, and what the problems are.  Only when that has been accomplished can we intelligently choose the path that to follow in designing and instituting the reforms that are needed.

Upping the stakes:  The multinational corporations that have acted as the principal players in the OOXML drama have annual revenues well in excess of the gross national products of many of the sovereign nations that cast their votes on that specification.  Just like those nations, these powerful corporations together engage in alliances, diplomacy, and the commercial equivalent of wars (sometimes even concurrently), deciding when to escalate, and when not.  As they do, they take calculated risks.  If the assumptions they make about what their rivals will do in response prove inaccurate, these gambles can blow up.  And when they do, there can be collateral damage, just as in the real world of nations.

In this case, what we have seen is an example of commercial escalation not very different in scale and economic consequences than a trade war among nations.  And just as a major international crisis can grow from a minor event in an out of the way corner of the world, so did the ODF-OOXML standards war arise from a simple procurement decision in a small US state (Massachusetts) in the late summer of 2005.

As a result of that decision, ODF suddenly became a credible weapon that could be targeted at the soft underbelly of Office, one of the two great profit engines of Microsoft’s ongoing success.  IBM, Sun, and, less publicly, companies like Oracle and Google recognized an opportunity to undermine Microsoft’s hegemony on the desktop, and acted to support ODF.  Microsoft, predictably, pulled out all the stops to defend its franchise.

One of the steps that Microsoft adopted was to accelerate the announcement of commitments it was already finding it needed to make to its government customers by way of opening up its products.  As part of that strategy, it revealed in late 2005 that it would submit its OOXML formats to Ecma, a standards body that represented an apt choice in two respects:  first, it advertised itself as a rapid and willing conduit for introducing standards to ISO/IEC that had not been created through an accredited standards body.  And second, it enjoyed a special “Class A Liaison” relationship with ISO/IEC, which granted it specification submission rights equivalent to those held by the National Bodies themselves.

Up to this point, Microsoft’s conduct was not very different from that of its rivals, some of which had used Ecma for a similar purpose.  Most famously, Sun Microsystems had sought to use Ecma as a conduit for the standardization of  Java.  In that case, it was Microsoft that played hardball, successfully opposing Java’s progress as a standard unless Sun released greater control than it was willing to offer.

But Microsoft went further, embarking on a strategy that sought to secure ISO/IEC approval in the absolute minimum time possible, regardless of the technical challenge or feasibility of that approach.  In so doing, it hoped to limit the window of opportunity during which ODF-compliant products might make incursions into the market of government purchasers that give preference to ISO/IEC certified products.

But unlike the specification for Sun’s Java, OOXML was still in a far more primitive state of documentation, due in part to the fact that not even Microsoft’s existing products were based on OOXML.  Not until Office 2007 would Microsoft release a version of Office based upon extensible markup language (XML) formats, rather than the binary versions upon which Office had previously been based.   As a result, much more work was needed would be needed before the OOXML specification could be as complete and polished as would normally be the case before Ecma would become involved.

Nor did that strategy change once Ecma became involved.  Instead of bringing OOXML up to full industrial strength, the Ecma working group concerned itself primarily with converting the specification into the proper format for ISO/IEC submission purposes before it was adopted by Ecma.  Finally, Microsoft chose ISO/IEC JTC1’s  “Fast Track” process for what was intended to be the next and final approval step for what had now become a 6,000-plus page specification.  From the perspective of achieving the needs of anyone other than Microsoft, there was there never a valid reason for such inappropriate speed.

The result was that at every step of the way, Microsoft generated ill will and a great deal of extra work for those in National Bodies around the world who were saddled with evaluating the formidable specification.  During a one month “Contradictions” period, many criticisms were offered - but Ecma concluded that none needed to be addressed at that time.  As contradictions were ignored (during the one month “Contradictions” period), and as the specification was pushed through the five month comment and voting period that followed, great pressure was brought to bear around the world on those in a position to approve the specifications, regardless of its many remaining flaws.

Ultimately, more than 900 substantive comments were registered by many of the 87 National Bodies that voted on OOXML.

Escalation:  While Sun was largely neutralized by pre-existing agreements with Microsoft (a fact largely missed by the press, which continued to speak as if Sun’s ongoing efforts were as significant as IBM’s), IBM decided to make the defeat of OOXML a public part of its global competitive strategy, even though Microsoft had not itself acted to oppose ODF.  And IBM was uniquely positioned to do so, possessing the most extensive and coordinated network of standards professionals at work in its far-flung global facilities.  Those employees set to work to press for the stringent evaluation of OOXML in National Bodies around the world.

In doing so, IBM was able to capitalize on the rise of a populist reaction to OOXML fueled in large part by the open source community.  This placed IBM in the enviable position of wearing the white hat in a commercial battle with a competitor that already had an image problem, as well as ongoing problems with European regulators. 

That said, the public opposition to OOXML that grew around the world was genuine and was instrumental in generating much of the attention that the standards battle generated, and differentiated it from other purely commercial standards-based conflicts that were ongoing in the same time period (e.g., between WiFi and WAPI in China, and between the Bluray and HD-DVD video formats).

As the process continued, more and more reports of unsavory conduct emerged from around the world, dozens of which have been well aired, and in some cases well documented (and even admitted, as in Sweden, where Microsoft admitted that an employee offered “marketing incentives” to business partners willing to join the Swedish National Body and vote for OOXML).  The majority of the charges have been leveled against Microsoft, but Microsoft has alluded generally over the past six months to similar conduct by the opposing forces, and in the past week more specific instances have been alleged by various Microsoft employees in their blogs.  For example, some bloggers have alleged (or pointed to allegations) that anti-OOXML companies joined National Body committees late in the day as well (to which some anti-OOXML readers replied that this was a necessary defensive reaction).

Rationalization:  Now we are entering the stage where we need to determine what happens next.  Jason Matusow argued earlier this week that entering into an appeals process is simply an example of a continuing, healthy exercise in standard-setting in a commercial environment.  To his credit, Jason does not accuse IBM of engaging in evil behavior (although he inaccurately state that all calls for appeal ultimately lead back to IBM).  Instead, he states – accurately but not sufficiently – that both IBM and Microsoft are simply pursuing their own commercial self interest.

I believe that such a characterization is both simplistic and dangerous.  In fact, this is not an example of a healthy process in action, nor is the system constructed in such a way as to permit effective appeals in some of the instances in which they are most needed, in light of the actual abuses that have been alleged.  To give but a single example, it appears that the only way that an appeal against the vote of Standards Norge, in Norway, may be for the appeal to be brought by the same individuals whose actions would be the subject of the appeal – making it clearly an appeal that is highly unlikely ever to be filed.  Moreover, by all accounts, ISO/IEC JTC1 would be far happier to see things simply die down and go away, then to engage in a vigorous process of self-examination.

What has changed:  In order for any sort of reform to be effective, a fundamental shift in the landscape needs to be recognized, at least in the case of what I have previously referred to as “Civil ICT Standards” (i.e., those ICT standards that play a vital role in the preservation on line of civil rights such as freedom of speech, freedom of association, and freedom of creativity).  That shift is one from a time when standards were set predominantly by vendors that could be left to butt heads to their hearts’ content without having much of a deleterious effect on public welfare (health and safety standards being subject to more careful scrutiny, as a rule), to one in which profoundly public impacts can be expected.  As a result of what we have just seen, we need to recognize what is essentially the politicalization of the standards development process.

There is both an obvious and a less obvious leg to this characterization.  The obvious leg is that all manner of pressures and tactics have been applied that are more typical of the political process than the standards process.  Because the standards process, and its rules, were never constructed to deal with such tactics, the rules will need to change to incorporate the same sorts of protections that the political system has evolved in order to defend itself.  Until that happens, not only can abuses be expected to attain their goals (and therefore to continue), but existing avenues of appeal will be unsuccessful to curb them.

The second leg is just as important, but to my knowledge has not as yet been called out for discussion.  That leg recognizes that with the elevation of certain technical standards to the level of Civil ICT Standards, more voices and more balance needs to be introduced into the standards process, and more protections provided to ensure that the Civil ICT Rights that these standards serve are in turn safeguarded. 

What needs to change:  Politicalization and the recognition of Civil ICT Rights and Standards is a game changer for standards development.  What this means is that we need to pay far greater attention to concerns such as balance, representation, and process.  For example, it would be no more acceptable for open source advocates to “stack” a committee than for advocates of a single vendor, or group of vendors, since all of these groups – and other groups not present at the table at all – have a stake in the outcome.   

While engaging in appeals in the case of OOXML may expose the inadequacy of the system to address such concerns, they will not solve them, nor necessarily result in a change of the vote in question, since existing rules may not in fact have been violated.  Instead, what is needed is a neutral, systemic review of how the process failed - and how it needs to change - so that future abuses can be avoided before they have an impact, and so that avenues of appeal can be designed that would permit even National Body votes to be challenged in the appropriate case.

The time to begin that review is now.  And the way to undertake it is not through the existing appeals process.


For further blog entries on ODF and OOXML, click here

sign up for a free subscription to Standards Today today

Vendor Escalation, Process Politicalization, and What Needs to Happen Next | 24 comments | Create New Account
The following comments are owned by whomever posted them. This site is not responsible for what they say.
Vendor Escalation, Process Politicalization, and What Needs to Happen Next
Authored by: Anonymous on Saturday, April 05 2008 @ 03:01 PM CDT

Instead, they put a high value on consensus, in order to lessen the chance that minority interests would be oppressed.

17 of 41 ISO JTC P countries ( Participant countries, not mere Observers ) didn't approve DIS 29500 ( OOXML ), either abstained ( in many countries with controversies [1] ) or disapproved [2]:

New Zealand
South Africa

[1] http://www.openmalaysiablog.com/2008/03/the-minister-of.html
[2] http://www.scc.ca/Asset/iu_files/29500-OOXML-Cdn-Pub-Stmt.pdf

This is 41% of NOT-CONSENSUS in P-members. A big number, and a huge number if you consider that 8 of the 59% P-members that approved this beast were the ones that upgraded to ISO JTC P status few days before September-ballot-closing just to cast unconditional-yes to everything Microsoft/ECMA proposed:

Jamaica island
Cyprus island
Malta island

[ # ]
Vendor Escalation, Process Politicalization, and What Needs to Happen Next
Authored by: Anonymous on Saturday, April 05 2008 @ 03:15 PM CDT
Thanks for this great summary of the most essential issues. The OOXML saga raises a debate on standards themselves that goes beyond the technical merits.

It is my understanding that the consensus rule is not just to protect the minority interests. It is also a tool to ensure technical quality. People that notice technical deficiencies are often in minority, at least when they make the initial report of the defect. When the minority is allowed to vetoe a deficient standard, there are strong incentives to fix it.

With OOXML, we have witnessed that undermining the consensus building process results in inability to ensure technical quality.
[ # ]
Vendor Escalation, Process Politicalization, and What Needs to Happen Next
Authored by: The Mad Hatter on Saturday, April 05 2008 @ 09:31 PM CDT


This is a great explanation of the situation - thank you very much for writing it.

[ # ]
Vendor Escalation, Process Politicalization, and What Needs to Happen Next
Authored by: Anonymous on Sunday, April 06 2008 @ 12:46 AM CDT
I've been following this through your blog and other sources right from the start with the Massachusetts decision.  I still learned something new.

Well thought out.

[ # ]
Responses to comments
Authored by: Andy Updegrove on Sunday, April 06 2008 @ 06:01 AM CDT
To the first comment:  unfortunately, consensus rules can be abused, just as majority rules can be abused.  I spoke to the chair of one National Body while I was in Geneva where the vote was 8 to 1 to disapprove OOXML last summer.  The one vote was cast by an employee of, how to say delicately, the most interested company in the vote.  Unfortunately, the rules of that NB required unanimity - and hence the vote changed to an abstain.  Obviously, any rule that is based on the assumption of good faith and fair dealing is vulnerable to those that choose not to act in synch with those underlying assumptions.

One of the challenges in any rules reform will be not to sacrifice the good reasons for rules to the detriment of the normal situations where the new rules would hurt, or at least impede progress, rather than help.  That's one reason why I think circuit breakers could be useful.  What I mean by this is introducing a mechanism where two or three participants could call for a quick decision by a neutral overseer that could say "yes, we need to look deeper," or "no, you're the one playing games - get back to work!"

And, of course, no rules can be totally successful in any event.  The US Congress is an excellent example of a democratic institution where all manner of procedural tricks of the trade can swing a vote to one's advantage or add in some self-interested rider.  That is why bringing transparency to the standards development process is so important, in my view, so that when abuses do occur, then come to light   And finally why some sort of appeals option - that is accessible to affected, but otherwise disinterested, stakeholders - is a necessary part of the solution.

Wayne and Terry: 

Thanks for the kind words.  I think it's worth pausing from time to time and reviewing what's happened to get things back in some sort of perspective, especially when so many new things are happening so quickly.

  -  Andy
[ # ]
Vendor Escalation, Process Politicalization, and What Needs to Happen Next
Authored by: Anonymous on Sunday, April 06 2008 @ 06:33 AM CDT
<p>Hi Andy,</p>

<p>Work commitments have forced me back into lurker mode for the past few months, so I'm not as well versed on details as I used to be, but I'm making an exception here because this seems quite important.</p>
<p>I think I agree with the principle of Civil ICT Rights, but I wonder if this particular problem can't be solved much more simply: automatically disallow any standard over 30 pages from any of the fast-track processes.</p>

<p>My inspiration for this idea comes mainly from the UK NB's old argument that large standards are inappropriate for fast-tracking. Alex Brown occasionally mentions that they lost this argument, so I would be interested to know the counter-argument to their position.</p>

<p>Over the past year, two interesting facts I've learnt are that most standards are very short - on the order of a handful of pages - and that producing a good standard takes about one day of work per page. As such, limiting standards to a maximum of 30 pages would allow the majority of standards that can be effectively processed within the one month contradictions period, and deny the minority where the politicians have the capacity to overwhelm technocrats.</p>

<p>Obviously, this would mean ODF couldn't be fast-tracked either. This strikes me as beneficial for two reasons:</p>

<p>First, it makes it harder for ISO to play favourites. An important issue in this process has been that access to the fast track provides a significant competitive advantage. Disallowing that access to almost any standards of comparable sizes serves to reduce the temptation for people to game the system.</p>

<p>Second, 850 pages is still 850 days of work, not 30, or even 180. I've never really heard a good rebuttal to Brian Jones' argument that a lack of such basic features as formulae makes it more like ODF 0.8 than ODF 1.0. Whether or not he was right, the very lack of such a rebuttal suggests that the 6 month review period wasn't enough to address such issues.</p>

<p>Limiting fast-tracked standards to 30 pages strikes me as a simple, practical way of protecting the ISO system, that can be enacted without asking anyone involved to eat crow.</p>

<p> - Andrew</p>
[ # ]
Vendor Escalation, Process Politicalization, and What Needs to Happen Next
Authored by: Anonymous on Thursday, April 17 2008 @ 06:48 AM CDT

You lost.  Get over it.

len bullard

[ # ]