Vendor Escalation, Process Politicalization, and What Needs to Happen Next
Saturday, April 05 2008 @ 10:41 AM CDT
Contributed by: Andy Updegrove
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 here , click