Standards & Technology

A Look Behind the Scenes

Should Consortia Create Standards?

Consortia and other groups are encroaching on the standards role of traditional SDOs. This is changing the standards climate.

By Carl Cargill

Recently I presented at a conference held by the Standards Engineering Society, during the Annual Standards Week celebrations in Washington, DC. It was an interesting conference, more because it reflected the state of standardization in the United States than because anything really new came out of it. However, there were some undercurrents that have begun to upset the normally placid world of standardization.

The most interesting of these was the growing resistance to the proliferation of consortia and standards-developing organizations (SDOs) within the United States. The difference between the two is that SDOs are allowed to publish American National Standards, while consortia are relegated to publishing "public specifications." This difference has significance in federal government procurement, because procurements usually specify formal standards. However, within the private sector, there is the increasing perception that a "standard is a standard is a standard," to paraphrase Gertrude Stein. And this is the heart of an increasingly nasty--but oh, so polite--debate.

Creeping Consortia

Consortia now account for about one-third of the standardization groups in the United States. They are responsible for a small fraction of total U.S. standards--approximately 2,000 out of a total of 93,000--but their specifications are being increasingly cited and used, especially within the IT arena. The dilemma faced by the "computer" SDOs wouldn't have bothered the majority of more traditional SDOs, except that these traditional SDOs are starting to see the same phenomena in their own backyards; this is what concerns them.

The problem, as one might suppose, is one of economics and greed. Essentially, SDOs have managed to live well on their publishing revenues. There is the probably apocryphal story that American National Standards Institute (ANSI) coffers fill every time the national Boiler Standard and the National Electrical Code are revised. Truth be told, ANSI makes over a quarter of its total revenue from royalties and publishing, according to 1995 data. On the other hand, some other prominent SDOs (such as the American Society of Testing Materials [ASTM] and the American Society of Mechanical Engineers [ASME]) are believed to earn a majority of their revenues from selling their standards.

The proliferation of consortia has had a somewhat confusing effect on the whole picture of the legitimacy of specifications. It turns out that users might not care about whether the standard was arrived at by an open process, voted upon (appealed to death) and then published. It is becoming apparent that many users (who, in the opinion of the SDOs, are misinformed) consider the consortium specification to be the equivalent of a formal American National Standard. These "barbarians" (for this phrase describes them best) seem to believe that the rationale for a standard is not in the purity of its creation and the loving care to which the process is subjected, but rather in its use and ultimate utility.

Whose Standards?

It is this use and utility of a standard, rather than its heritage, that should constitute the rationale for its creation and existence. In the mid-1980s, as SDOs became more and more convinced that their processes were sacrosanct, they began to believe that they could control the supply of standards to the market. For example, you must agree to a certain set of onerous operating procedures if you want to create an American National Standard--and ANSI is the sole-source supplier of such accreditation. Over time, I honestly believe, the people who wrote these rules came to believe that they had the Truth on fairness and openness, and became convinced that they were the ultimate source of these qualities. The SDOs forgot that the whole purpose of a standard is to be implemented and used to expand the market for providers and to provide a second source to users.

Fortunately, there is one standard SDOs could not revoke: that of supply and demand. When the products provided by these standards organizations stopped meeting the demands of the market in the late 1980s, a new source of supply arose--consortia. Consortia provided two things that SDOs did not: speed of creation and tests to validate the specifications. Needless to say, this was well-received by the market, until it became apparent that the consortia were failing to deliver on their promises. One of the problems with both consortia and SDO specifications was the number of "compromises" necessary to achieve consensus; standards and specifications began to be cluttered with "yes" bits, "no" bits and "maybe" bits.

To counter this trend, new consortia began to be formed. The heart of the matter at the meeting in Washington was the idea that a consortium could "invade" an established SDO or consortium's space and just "start creating specifications." This arrogance--for that is how they see it--was hard for the SDOs and established consortia to swallow. SDOs would love to retreat to the good old days when people really cared about process; the problem is that users are not cooperating any longer and instead are demanding functionality. This, of course, puts the established SDOs and consortia in the same boat, trying desperately to meet the requirements of the market while hauling their traditional heavyweight process along. They would love to give them up, but their members won't let them, because they joined just for the protection offered by these processes.

Users Change the Rules

These groups carry too much baggage, in the form of an inability to discard the "maybe" bit philosophy and get on with creating implementable specifications. These groups were so schooled in the idea of consensus among the members that they've forgotten that it's the users who need the standards, not the vendors. Vendors implement standards because users demand them. Before the mid-1990s, users were rather lax in mandating and requiring standards. Users seem to have discarded this attitude with the advent of the World Wide Web. Now they are demanding interoperation of standardization efforts and singularity in specification. Rather than having a standard that overspecifies, users seem to be mandating a single, tight, interpretable specification, along with vendor compliance to that specification. Additions to the base specification are acceptable to meet user requirements, but variations within the specification are no longer tolerated.

And there's the rub. It turns out that alliances and coalitions can produce these base specifications faster and better than the consortia and the SDOs. From the SDO and consortium viewpoint, what is really bad is that the alliances are making the specifications available on the Web, putting pressure on the older groups to do the same. If this were to happen, these groups would lose the revenue from standards publishing and would either have to downsize or find some other way to replace lost revenue.

This is the amusing part of the whole controversy. There isn't a company in the United States that has not had to confront the concepts of customer service and downsizing over the past 10 years; many have had to radically alter their structures. The SDOs and consortia seem to believe that they are immune from this.

What we're looking at is a massive denial of reality on the part of the standardization groups; an unwillingness to face the fact that what worked in 1990 may not work in 1997. The results of this inability to change will be very interesting by Standards Week 1998. Lacking change--or the ability and will to change--the delegates will be able to meet, not in a hotel ballroom but in a hotel guest room. And the people doing the work in the new alliances, coalitions and "new consortia" won't identify themselves as "standards people," but rather as engineers and business people who are finally working together to solve user problems.

Carl Cargill is standards program manager at Netscape Communications in Mountain View, CA. He can be reached at