September 6th, 2007
ZDNet reader: Don't let OOXML vs. ODF shenanigans tarnish other standards setters
I’ve been a watcher of the great many standards setting processes for a great many years and there’s a lot that goes on behind the scenes that most people don’t know about. In 2003, I even won an award for my coverage of standards from the American National Standards Institute: the Presidents Award for Journalism.
When I say the “great many standards setting processes,” it’s important to realize that, although some uber-organizations exist, there is no single reigning standards body that oversees all standards. In each of its uses, even the word “standard” merits additional attention since it doesn’t always mean the same thing. Is that a de jure standard (one set by committee), a de facto standard (one set by the market), or both? Or, is it a standard at all? What one person sees as a standard may be little more than a documented specification or technology to another.
While there are many de jure standards that are ratified by organizations that are recognized as legitimate standards setters (for example, the World Wide Web Consortium — W3C), there are also many specifications put forth by organizations that like to describe themselves as standard setting bodies, but that are really nothing of the sort. Rather, they fall into a range of vendor-organized consortia many of which are designed to advance a particular technology or agenda in the marketplace under the guise of what appears to be a standards setting organization, but really isn’t. Telling a real standards body apart from a pretender is difficult if not impossible to do, even by the trained eye (in other words, some trained eyes would disagree). As a side note, not even the W3C refers to its ratified specifications as standards. Instead, it refers to them as less assertive “recommendations.”
When it comes to the work that’s actually performed within these organizations, it’s not as simple as a bunch of people sitting down, looking at a PowerPoint presentation, and then rubber-stamping what they’ve just seen as a standard. Well, some would argue that it is as simple as that in the case of certain imposter standards bodies. Although I won’t point fingers (you can Google my long history of standards coverage to see who I’ve called out in the past), that is true based on my observations.
Earlier this week, the Office Open XML specification (OOXML) suffered a fairly significant setback in its bid to become an International Organization of Standard (ISO) ratified standard. OOXML started as a Microsoft-developed format for the storage and retrieval of productivity documents like those created by word processors, spreadsheets, and presentations. In the course of the Redmond company’s attempt to assuage concerns that OOXML was proprietary, Microsoft says that OOXML is now as non-proprietary as the leading alternative (the one that forced Microsoft’s hand in the first place) — the OpenDocument Format (ODF). There are differing opinions over this claim — opinions that were strong enough in content and numbers to cause OOXML to stumble at its first major hurdle in the ISO standards setting process.
Microsoft, which has been loath to bake-in-earnest ODF compatibility into Microsoft Office is obviously disappointed by this setback but remains undeterred in its mission to see OOXML through as an ISO standard (the game isn’t over yet). ODF is already an ISO standard. Notwithstanding the obvious question of why we need more than one ISO-ratified standard for the same thing (strangely, there are plenty of precedents for this at the ISO), the bid to make OOXML into another ISO-ratified office file format standard is far from over.
Over the last couple of years, in other forums, the company and its supporters have proven to be quite tenacious in their ability to pull OOXML off the canvas after what most certainly appeared to be a knockout punch and move on to what could often be described as a draw with ODF. In essence, Microsoft is seeking the same outcome at the ISO. Getting to this juncture has not been easy. Because of the stakes involved (Microsoft’s ODF-supporting mortal enemies such as IBM and Sun looking to loosen the grip of Microsoft Office in the marketplace), enormous sums of money and time have been spent by supporters and detractors of OOXML to keep it on track for consideration as an internationally recognized standard or to derail it. That by itself is not unusual. What is unusual is where that money and time have been spent and the uglier side of the technology industry that has been exposed as a result.
ComputerWorld’s expose of Microsoft’s tactics is part of the story. I’m certain that Microsoft isn’t the only company to have played hardball in this affair. There are two sides to every story. I’m not here to debate them. What I am doing is setting up a contribution by one of ZDNet’s readers. In terms of specification showdowns, OOXML vs. ODF reigns supreme above all other standards debates in terms of the attention it has garnered and drawn to the standards setting process.
Much the way all professional cyclists are condemned after a handful of them test positive for performance enhancing drug usage, there are some who are quick to condemn the whole lot of standards setters on the basis of the saga of OOXML vs. ODF. As ZDNet reader D.C. Sessions writes, that would be a terrible mistake and I agree. In getting to know the many people that are deeply involved in the standards setting processes at a variety of organizations, I’d like to personally vouch for the hard work and dedication to excellence of many of these people. In many cases, they have a thankless job. They are sent into politically charged environments to do yeoman’s work for the combined good of their employers and the world but rarely get credit for what they do. Here is D.C. Sessions’ personal treatise on the issue, sent to me via e-mail earlier this week. Sessions is the Former Chair to JEDEC JC-16.
Libel and the Real Standards Community
In the drama surrounding the ISO fast-track standardization process for DIS-29500, aka ECMA 376, aka “Office Open XML,” there have been a lot of charges launched. Charges of corruption in government, charges of bribery, charges (by both sides) of cynical manipulation of the standards process. Aside from the personal observation that I am pleased to have served with Microsoft employees on the IEEE 1394 committee, I will not address those charges.
However, the one charge that I will address is that this whole affair is “business as usual” for standards bodies. Unlike those who (often anonymously) repeat this libel, I am not afraid to state my name and the source of my knowledge: I served on JEDEC JC-16 (Electrical Interfaces) and JC-42 (Memory) for ten years, eight as the chair of JC-16; I served for five years on the IBIS (interface modeling for integrated circuits) committee, and shorter times on a few others. Based on that experience, I can state with certainty that the alleged irregularities in the DIS-29500 process are anything but “business as usual” and that I take personal offense at any ignorant, malicious, or self-serving pretense that they are. More to the point, they are an insult to the hundreds of honest and hard-working engineers I have had the honor to serve with.
In the course of more than forty weeks of JEDEC memory-industry meetings, with a business amounting to more than $50 billion a year at stake, I have seen nothing less than the highest degree of professionalism on the part of the participants where technical issues were concerned. No, I won’t pretend that we have no politics or egos involved. Far from it! Only that I have yet to see politics stand up even briefly in the face of technical reality. One good lab experiment trumps a dozen simulations, and one good simulation trumps all the politics in the room.
And, yes, I mean weeks. A standard “JEDEC week” actually starts with the deadline for ballots, about eight weeks before a face-to-face meeting. A six-week ballot process follows, with the deadline the week before the face-to-face meeting. As with ISO votes, a “yes” may have a comment attached, but a “no” must have a comment attached; unlike with ISO, all comments must be addressed. The week before the meeting, the ballots are counted and comments collated for the meeting. Then there’s travel, many of the attendees having to spend the weekend getting to the meeting site. None of this “Monday travel, Tuesday meeting, Wednesday play, Thursday home” stuff. The meeting starts at 08:00 local on Monday morning, goes until 18:00 each evening, repeat until Friday. Sometimes we wrapped up early, but too often ran right up until the deadline. Some weeks had so much business that the first meeting actually started Sunday afternoon.
During that week, we weren’t playing golf. It was nonstop technical content and the only reason that we knocked off at 18:00 was because, being geeks, we would otherwise go until midnight. As it is, our other duties aren’t on hold so we generally get up and do e-mail before the meeting and wrap up the day with e-mail afterward. I’ve spent whole weeks on Maui and never left the meeting except for dinner.
It’s hard work and it’s addictive. I’ve moved to other duties, but I confess I miss it.
However, in the course of my standards work I’ve seen companies come and go who tried to force their wills on the committees. When the membership reads like “who’s who in technology,” you see just about everyone: AMD, Dell, IBM, Intel, Samsung, the whole list. Every now and then one of the “big dogs” comes up with a “my way or the highway” position. I am proud to say that not once in ten years did that kind of hardball budge the committees from their responsibilities, either for or against the company trying it (and, no, I won’t divulge details. If you want them, join the committee and go over the past minutes.) Strictly on the merits in all cases, thank you, and frankly not one of those “finished proposals” emerged without major revisions because they were technically the right thing to do. I’ll repeat that, with emphasis: the proposed, “ready for prime time” specifications would have failed as products. They would have failed the semiconductor vendors with poor yields, they would have failed the system vendors with crippling application limitations, and worst of all they would have failed the ultimate customers with lost data and downtime.
That’s what a good committee process does, and I seriously doubt that JEDEC’s are remarkable in keeping to that degree of professionalism. Anyone who tells you otherwise is at best ignorant, at worst pursuing a dishonest agenda.. You’re welcome to guess why if you like; I have better examples to follow.
