ISO approval: A good process gone bad
by Melanie Chernoff
Contributing author: Jonathan Robie
You may have read our background article about ODF and OOXML and why Red Hat believes OOXML should not be approved as an ISO standard. This time, we focus on how the standardization process has been compromised at ISO.
ISO’s JTC-1 directives were designed to provide a fair, consensus-based way to design standards that are portable, interoperable, and adaptable to all languages and cultures. The OOXML proposal has suffered from two basic problems: (1) voting irregularities, and (2) the use of a fast-track process for a complex, new, large specification that has not received adequate industry review. The resulting specification was driven almost exclusively by one vendor, has not achieved industry consensus, and has had thousands of issues logged against it, largely due to issues involving implementability, portability, and interoperability. Although resolutions have been proposed for many of the issues that have been raised, there is virtually no time to review these resolutions to determine whether they fix the problems. And the voting irregularities have raised serious issues with the fairness of the process.
Stuffing the ballot box
For a standards body to have credibility, the procedures it follows need to be credible. ISO’s JTC-1 directives say that the “objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.”1 Clearly, there has been no achievement of consensus regarding the adoption of OOXML as a standard, and therefore ISO has turned to a voting process.
We believe that the flaws in the ISO voting process for OOXML are so serious that they must be addressed in order to maintain ISO’s credibility as a standards body. For a standards body to review a proposal adequately and achieve consensus, the participants need to be involved in the entire review process, not merely show up to cast a vote.
Unfortunately, the ISO voting process is not restricted to those who have participated in the past.2 Thirty-six new countries joined the JTC-1 technical committee–just in time for the OOXML vote3– and 90% of these voted in favor of the OOXML proposal. Only 36% of the original membership voted in favor of approving OOXML as a standard.
Allegations have been made that Microsoft encouraged new countries to join the JTC-1, or to upgrade their status (from O-status to P-status) to influence the vote. Contrary to what has been demonstrated, the JTC-1 directives say that the “objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.”4
Before an individual country votes in the ISO process, it holds a vote within its own national body. An employee of Microsoft Sweden admitted to offering incentives to business partners to encourage them to vote for OOXML5, leading the Swedish Standards Institute (SIS) to declare its vote in favor of OOXML invalid. Critics have speculated that similar practices occurred in Italy, Switzerland, Spain, and other countries. Such allegations have prompted the EU to launch an investigation into Microsoft’s practices during the ISO vote.
Fast track
OOXML was submitted to ISO using the fast-track process, which was intended to make it easier to approve an ISO standard if it has already been approved by an existing standards organization. This was meant to speed up the process for standards whose problems have already been resolved and where consensus has already been achieved. The process generally requires three years or more; fast-track can cut this time to six months.
The first review of the 6,000-page OOXML proposal resulted in a disapproving ballot by national bodies on September 2nd. There were over 3,500 comments. The issues identified with OOXML did not stop there.
After the 3,500 comments during the initial ballot, one delegate wrote, “I and my reviewers found 13 additional errors in the original specification. However, national bodies were not allowed to submit new comments (and rightly so, otherwise there would have been total chaos). Therefore, there was no way to submit and correct them.”6
In response, ECMA submitted a proposed Disposition of Comments report that was close to 2,300 pages long. This Disposition of Comments contained proposed changes scheduled to be discussed at a Ballot Resolution Meeting (BRM) in February. This gave only six weeks to review this documentation (that’s a rate of 55 pages per day) before the BRM; it was impossible for all technical issues to be addressed or resolved in that timeframe.
The BRM meeting itself only lasted one week, even though the JTC 1 Directives impose no such time limitation. The normal course for a BRM is to meet, recess with email discussion, and to meet again until consensus is reached on the changes to a proposal. (Remember, the JTC 1 emphasizes consensus in its standardization process.)
Complaints have been lodged with the ISO by some national bodies alleging that the BRM process was inadequate for the number of issues needing resolution. In the final vote at the BRM, only six of the thirty members voted to approve the changes. Four voted to disapprove, and 20 either abstained or refused to register and vote at all.
Obviously, ISO should have referred the proposal to a working committee for further improvements before it was placed on a fast track ballot. But the relevant ISO process was not designed to make this possible. When this is combined with the addition of new members at the last minute in order to influence a vote, the process is fatally flawed.
Start from the goal
The IT industry clearly needs systems so that companies can work well together, and these systems need to work well in all countries. The ISO process for IT standards was designed to promote interoperability, portability, and cultural and linguistic adaptability,1 using a consensus process. We believe strongly in these goals, but the current process is not designed to achieve them. The OOXML proposal has exposed serious flaws in ISO process–especially in the fast-track process–and we believe these flaws need to be fixed.
The credibility of ISO is at stake.
March 24th, 2008 at 7:59 pm
Very well put. More evidence, if any was needed, that the ‘one vendor’ (MSFT) is more of a criminal syndicate than a software company and should be prosecuted under the RICO statutes.
It should be noted that the Gnome people, in addition to apparently pushing .NET (as mono) and c#, are in favor of OOXML. Given that NOVL owns Ximian and is very friendly with MSFT, this is not surprising. Me, I’m switching over to KDE (kde4 is much cooler than anything gnome has anyway).
March 24th, 2008 at 11:51 pm
It was suggested some time ago before this fiasco of a ’standards approval process’ really got started, that we, the disillusioned, leave ISO behind and start our own approval process for standards within the computing market. I wish I would have saved that person’s email or, at least, the article that prompted the response, because this is sounding more and more viable to me. ISO, with the help of with Microsoft, has destroyed its credibility. Now there is no place for them in the world market. And the FLOSS community has more influence world-wide than ever before. I say ‘dump ISO.’ Make them irrelevant. Let’s move on.
March 25th, 2008 at 9:36 am
And we had a preview of Microsoft’s chicanery in Massachusetts, where ODF was set to become the commonwealth’s official file format for saving government documents, and then after much politicking and lobbying money changed hands, suddenly the state’s CIO was out, as was ODF, and Microsoft’s formats were back in the mix.
ISO must be revamped no matter what with regard to technical standards. There’s nothing in place that would prevent this from happening again unless the structure of the process is either changed or scrapped.
March 25th, 2008 at 11:38 am
“Something wicked this way comes…”
March 25th, 2008 at 2:54 pm
I’m having a bit of trouble making sense out of the phrasing in this piece of the article:
“The ISO process for IT standards was designed to promote interoperability, portability, and cultural and linguistic adaptability,1 using a consensus process. We believe strongly in these goals, but the current process is not designed to achieve them.”
It seems to me like it says the process is designed to promote certain goals, but then turns around and says it is not designed to achieve them. I guess there’s a fine distinction between designing to promote and designing to achieve, but it might be a bit too fine; I had trouble making it anyway. If the distinction between promote and achieve isn’t what is intended, perhaps it should be reworded—something like “intended to promote”? I’m not exactly sure since I’m not entirely clear on what is being said right here.
March 25th, 2008 at 4:20 pm
Typos, in case you want to fix them:
“Four voted to disapprove, and 20 either abstained or refused to register and vote at all.”
should say “… refused to register ANY vote at all.”
“The ISO process for IT standards was designed to promote interoperability, portability, and cultural and linguistic adaptability,1 using a consensus process.”
the digit “1″ near the end of the sentence seems to be extraneous
March 25th, 2008 at 5:58 pm
Has anyone considered that a discredited or neutralized ISO serves Microsoft’s purposes nearly as well as a shiny ISO approval of OOXML?
If OOXML fails to receive status as an ISO standard, then MS would surely like to see that status rendered meaningless. Destroying the credibility of the ISO would serve that purpose nicely, especially since ODF’s approval is relatively young.
Given this, it’s not hard to see how Microsoft’s strategy here will be to force an approval of OOXML by ISO, or, failing that, destroy ISO in the attempt.
What’s repeatedly frustrating is that people are so willing to forgive MS’ clear abuses. Everyone should be up in arms about the very attempts MS is making to shipwreck the process, when all they’re doing is waiting to see if the sabotage is successful. It baffles me.
What we need to do is point out the damage being done to the ISO, shine the spotlight on the parts of the process that are vulnerable to abuse, then demand that they are fixed. We need to get behind the ISO and insist that it serve the industry, not abandon it.
March 29th, 2008 at 11:17 pm
Micorsoft has been getting things done by backdoor for quite a time now and the ISO process just one of them. OOXML standard was developed nly to counter the treat caused to it by the open source community. In recent week the largest democartic country in the world, India national body rejected the approval of OOXML as a national standard and this was the second by Beauro of Indian Standards(BIS).
If a developing country like India and the number of institutions can adopt ODF then why don’t microsoft adds support the ODF format. This shows microsoft’s non-commitment towards the normal people who can’t afford to buy office 2007.
I wish and pray this second round of voting also favours ODF and not OOXML..
April 1st, 2008 at 11:45 am
I hope that Wednesday’s announcement will acknowledge the voting irregularities and problems with the approval process and define a more manageable path to consensus (and thus approval).
Opponents of approval should at least consider the possibility that they would probably not have voted for it regardless of the quality of the standard, due to their dislike of the company that proposed it. Given that atmosphere, the consensus “requirement” seems impractical at best, and thus we’re left with a formal vote that has exposed a whole new set of flaws in the standardization process.
Taking about 3 steps back from the ISO situation, readers need to recognize that where we are now is a direct consequence of the Massachusetts debacle. A large majority of the business community quietly viewed the MA ODF manifesto as a triumph of theory over reason, and was not sorry to see everyone who promoted it canned. Massachusetts may have in turn been influenced by companies promoting their own implementations of ODF architectures, most of whom are visibly involved (as opponents) in the ISO process.
Reasonable people seek reasonable solutions to problems. Unfortunately, there seem to be few reasonable parties involved in the ODF vs. OOXML debate.
April 2nd, 2008 at 12:59 am
Comment to Jinesh and suppliers:
>If a developing country like India and the number of >institutions can adopt ODF then why don’t microsoft adds >support the ODF format. This shows microsoft’s non-commitment >towards the normal people who can’t afford to buy office >2007.
>
Whether a programm is open/closed, for free/commercial has nothing to do with the file format used.
Customers should be able to choose between the difference in FUNCTIONALITY in the software. The result (your documents) could be used by different people in different software.
So every developer should be able to write software that is FULLY capable of reading and writing documents in that standard. This is not possible with OOXML. So OOXML can not be and may not be a standard.