SUBCOMMITTEE ON TECHNOLOGY

COMMITTEE ON SCIENCE

U.S. HOUSE OF REPRESENTATIVES

 

September 13, 2000

10 a.m.

2318 RHOB

 

The Role of Standards in Today's Society and in the Future

 

 

Carl Cargill

Director - Corporate Standards

Sun Microsystems, Inc.

Palo Alto, CA 

 

 

Evolutionary Pressures in Standardization:

Considerations On Ansi's National Standards Strategy

 

EXECUTIVE OVERVIEW

- Section I: Standardization is a constantly evolving activity. The Open Source movement is the latest evolutionary activity in Information Technology standardization, following (most recent first)  alliances, consortia, international formal organizations, national formal organizations, and trade associations. The ability to evolve organizational types is the heart and genius of the U.S. standardization process.

- Section II: The Information Technology (IT) industry is investing heavily in standardization; expenditures of both financial resources and people in consortia, alliances, and Open Source initiatives continue to grow as the World Wide Web and the Internet continue to expand. 

- Section III:  The Information Technology industry is a multi-national activity, in which formal national standards organizations are playing a less and less significant role. 

- Section IV:  The role of the government in standardization must be increased to address concerns that relate to the 'web based standardization environment', including those issues of monopoly, anti-trust, and intellectual property.

 

Section I:  Standardization as a healthy and growing discipline

 

A. Attributes of Standardization Models:

All standardization models - from the time  the discipline started - have shared several basic beliefs.

It should be noted that all of these beliefs are based upon an economic model that assumes that the market finds cooperation among market competitors less distrustful than the activities of a single vendor.  It is also based upon a model which says that the market will not, over the long run, tolerate proprietary practices by any single vendor.  The IBM, AT&T, and Microsoft anti-trust cases all tend to substantiate these assumptions.

 

Basic beliefs by standardization groups:

 

1. RULES: There are rules to participate in a standards organization and you agree to accept these rules. The most common feature of any standardization movement is a set of rules that attempt to set/simplify/clarify relationships between the participants. The existence of rules allows some order to be brought into a chaotic situation.

2. COMMON INTEREST: There is a set of common interests which bind the standards organizations participants. This belief is absolutely necessary; without it, there is mutual distrust by the participants and an inability to progress.

3. CHANGE AGENT: The result of the organization's work will result in change to the current situation from which all participants (and the market generally) will benefit.   The non-parenthetical statement is axiomatic for any organized activity; however, standards succeed only if the market changes and accepts/uses the output of the standards group.

4. PLANNING: An organization will help to set direction and guide the market by publishing standards, which will be accepted by the market. The whole reason for standardization organizations lies in the assumption that they guide/lead/structure the market through the creation and promulgation of common procedures and methods called standards.  The belief that the market will accept and use these standards is predicated upon the industry leaders being part of the standards organization.

5. OPEN: Participation by multiple independent groups legitimizes the activities of the organization, when compared to a standard offered by a single entity. By expanding the base of participants,  a wider trust (on the part of the market) can be built, and more influence to behave 'openly' can be brought to bear.

 

All of these beliefs feed the key theme of standardization: a group of well intentioned people, in an organization, can accomplish more in a more trusted manner than any individual acting alone, no matter how well intentioned or competent the individual is.  The group also believes  that their activities serve a larger good - such as  making the market more open, or safer, or bigger, or more equitable. The belief in a 'quasi-idealistic mission that succeeds through group synergy' is absolutely necessary to inspire people to strive against long odds in what, at times, seems to be opposed to common sense and reality.

 

B. Evolution of the Standardization Organization:

The history of standardization is reasonably lengthy[1], but the evolution of the organizations that create standards has been little examined. It is the organizational evolution , rather than a set of specific process attributes (such as openness, decentralization, non-governmental, etc.)  that is the hallmark, genius, and strength of the U.S. process.  Each stage of the organizational evolutionary activity has spawned a different type of organization, each with its own Unique Selling Proposition (USP), which it uses/used to garner supporters and participants and differentiate itself from what came before.

 

Trade Associations:

During the last quarter of the 19th century, a group of mechanical engineers formed to create the American Society of Mechanical Engineers (ASME), which had as one of its goals the publication of 'good engineering practices', which included boiler building, construction of bridges, and the first 'management training. (Fredrick Taylor, the father of formal management training, was a member of the ASME).  By 1920, many of these societies existed, all publishing 'standards', many of which were incompatible with one another.  None of these groups had as their primary goal the creation of standards; in most cases, they were educational/professional associations who published standards as a sideline.  The modern day IT equivalent is the Institute of Electrical and Electronics Engineers (IEEE), which publishes standards to complement its major business, which is to be an educational and lobbying group for electrical engineers.  Many associations carry over from this time, however, including the American Society for Testing and Materials (ASTM), the Society of Automotive Engineers (SAE), the American Welding Society,  and so on.  These groups publish standards - and the royalties from the publications have become a major source of revenue for these groups.

 

In many cases, the publications of these groups have, over time, acquired a  regulatory patina that permits them to be used as defense in liability cases; if you followed the National Fire Protection Code, you can be accepted and a permit will be issued by a local building inspector - who was also trained under the auspices of the NFPA code. Trade associations are fine for stable, structured, and time insensitive standardization issues. Their USP - at the time - was that they were (and continue to be) the collection of experts in a specific trade.

 

Formal national organizations:

Following the First World War, there was a standardization initiative sponsored by Herbert Hoover to make sense of the chaotic state of standards in the US. Voluntary cooperation between the organizations was a goal; it was initiated in the Twenties and then stopped as the Depression began. However, following the Second World War, the initiative took off again and eventually the American National Standards Institute (ANSI) came into being. While not a governmental entity, ANSI was meant to regularize standardization in the US. Several serendipitous legal incidents happened to strengthen ANSI's hand (an anti-trust case, a Congressional investigation), and eventually ANSI came out as the first among equals in U.S. formal standardization.  At the same time, other nations (especially Germany, France, the U.K., and Japan) began to strengthen their nationally chartered bodies to pursue standards as a part of their industrial policy. 

 

A national standards body makes sense in the context of the post-W.W.II industrial environment.  Nations were trying to strengthen their individual industrial capacity; many were rebuilding after a devastating war. The creation of 'standards' allowed an industrial policy that could be controlled (to varying degrees) by the nation.  The exception was the U.S., where the quasi-official federation lead by ANSI rejected any 'governmental help', choosing instead to lead by encouraging the private sector to enter into standards partnerships. This allowed the trade associations (see above) to continue to act as 'standards organizations', while encouraging the formation of new organizations devoted only to standardization. Examples of this last include the Accredited Standards Committee (ASC) X3 (IT), X9 (Banking), X12 (EDI) and so on.

 

The benefit (or USP) of the 'formal National Body' was that it allowed the industry in a particular sector to coalesce around a set of standards which could then be cited in national procurements, and which became the standard of choice among the proponents. Many of the original hardware and software standards were created using this route. Within the U.S., the use of rules of openness and fairness allowed the participants limited immunity from anti-trust, and the national bodies of other governments (such as Germany and Japan) began to use the standards as a basis for a national industrial policy.

 

International Formal Organizations:

National organizations were soon eclipsed by international formal organizations, partially as a result of the Uruguay round of Tariff and Trade talks, and partially because the multinational companies in the IT industry needed a world wide market for products. Unique requirements for each nation made a global market for IT products impossible. By using international standards, providers could produce a globally acceptable offering.  By participating in the international standardization arena, users in the various countries could achieve economies of scale and become part of the mainstream of IT change. The USP was ubiquity of the offering, serving both the provider and the user.

 

The downside of this standardization model was that achieving consensus on a global scale was difficult and time consuming, and, as more and more complex issues were dealt with, became harder and harder. Fewer and fewer standards achieved commonality, and the entire process became lengthy and painfully slow, just as the IT market began to accelerate.

 

Consortia:

Consortia initially were created to deal with the 'clarity and time to market' problem of the formal organizations.  Consortia, originally collections of like minded companies, gathered, paid money, and joined a 'specifications club' to create specifications on a particular topic of computing. Some early consortia were created to oppose another technical effort (Open 88 and OSF), to initiate or  complete an offering (Corporation for Open Systems or the Object Management Group), or to make tested profiles possible and available (X/Open).  The USP of consortia was speed and the ability to produce a good specification that resembled what the market wanted and which usually had at least one implementation.  Over time, however, consortia began to have the same problems that faced the formal organizations - the common purpose was weakened or obscured, and it took more and more effort to create less and less of a specification.

 

As noted, consortia became a way of achieving a marketing advantage. Initial success spawned more and more imitators, and soon there were consortia being created at least once a month. However, consortia can be expensive, and dissolution requires that all participants disengage simultaneously to avoid being pilloried in the press. As a result, a consortia tends to remain; participation by the founders is necessary to preclude something bad from happening while you're not looking.  And since they can't be closed down easily, it becomes necessary to continue to keep them on life support, especially if you've invested heavily in the creation of the consortia. The weakness of consortia was that, once they'd had their shot at the initiating specification, they didn't go away and they rarely continued to justify their existence.

 

Alliances:

Alliances are like consortia, but with a more transient nature. Their USP was this very transient; their weakness is that, because they are designed to be transient, they rarely succeed in achieving what they were intended to do before their creators lose interest in them and move on.

 

Open Source:

Open Source mythology ascribes the beginning of open source to sometime in the past. I believe that there was an activity that was a prototype activity that foreshadowed the re-activation of Open Source in the Linux world - the X Consortium.

 

The Project X at MIT originally started as a research program, but had some significant predecessor activities to the open source movement. The X-Consortium pioneered a method of using a multiplicity of independent programmers contributing their time and effort to a complex program. It also published source code and documentation for that code freely, and ensured that  the code was of sufficient quality to actually work.  Bug fixes were published within the community, and the code formed the basis of a rationalized Graphical User Interface (GUI).

 

The X-Consortium - the successor to the MIT X-Project - continued in the same vein for several years.  Although roundly condemned by Richard Stallman for their refusal to embrace 'copyleft' (and hence his philosophy), they did achieve a significant following among developers. By embracing the concept of  'an open source specification', the X-Consortium put in place the basic underpinnings of the mechanics of the system - and showed that it could work in a corporate (for profit) arena. They anticipated the 'Open Source' use of the internet as the virtual team, had Bob Scheiffler and his staff as the 'gurus',  published both books and specifications, and  proselytized the technology through the companies upon whose technologists they depended.  The role played by Robert Scheiffler cannot be overstated; he once described himself as a 'benevolent dictator' for the project.

 

Following the proof of concept demonstrated by X,  it is reasonably easy to watch the Linux phenomena launch. Raymond, in the Cathedral and the Bazaar[2], describes the underpinnings of open source. Needless to say, the creation and the ferment engendered by the World Wide Web did not hurt the cause of Torvalds and Raymond; both used the web as a significant communications media. Jamie Zawinski of Netscape probably provided the largest boost to the open source movement when he convinced Netscape's management to make the source for Netscape's browser into open source - a move partially born of desperation, since Netscape realized that it could not compete with Microsoft in engineering resources.

 

However, if you examine all of the virtues ascribed to the open source movement - from  Raymond to   Heckler to  Zawinski's bold statements - they all come down to this:

A group of well intentioned people (the open source believers in an organization, can accomplish more in a more trusted manner than any individual acting alone, no matter how well intentioned or competent the individual is.

 

The key to understanding the open source community is understanding that the differentiator of open software is the license. The licensing itself is complex; there are at least five variants which are[3]:

1.  no license at all (i.e., releasing software into the public domain)

2. licenses like the BSD License that place relatively few constraints on what a developer may do (including creating  proprietary versions of open source products)

3. the GNU General Public License (GPL) and variants which attempt to constrain developers from "hoarding" code, i.e., making changes to open-source products and then not contributing those changes back to the  developer community, but rather attempting to keep them proprietary for commercial purposes or other reasons;

4. the Artistic License, which modifies various of the more controversial aspects of the GPL

5. the Mozilla Public License (MozPL) and variants (including the Netscape Public License or NPL) which go further than the BSD and similar licenses in discouraging "software hoarding" but which still allow developers to create proprietary add-ons if they wish.

 

The intent of these various forms of licenses was to ensure that the code remained open for all to use, validate, modify, and improve.  And it is these license forms, more than anything else, which are the USP of the Open Source standards movement. They encourage the community to act together, and act as a re-enforcing mechanism for 'open source behavior' (which is a larger good to which all standards organizations must subscribe).  By tying their unique behavior to licensing activities, they are then freed to espouse rules that re-enforce the benefits of open source licensing - including rules on how to write code, how to publish code, how to correct code, and so on.


c. 
Conclusion:

All of these organizational structures serve to unify a need of the community, and all have a place in the hierarchy of IT standardization.  All hold to the fundamental tenets of standardization. However, these underlying principles that guide the various forms of organizations usually take several years to mature to the point where they are capable of being abstracted and routinely deployed.  The interesting thing about all of these structures is that they appear when they are needed , yet are primarily practiced only in the U.S.  Of the major consortia, most are dominated by U.S. companies; the Open Source movement migrated with Torvalds to the U.S. when he moved; alliances are  started by U.S. multinationals; consortia are usually heavily dependant upon U.S. firms for their existence.

 

This ability to transform to meet market needs reflects the industry itself, with its high innovative content.  European firms, failing the innovative background that U.S. firms seem to require for existence, are less sympathetic to the creation of these variant forms of standardization, preferring their formal national bodies.  However, these same firms scramble to join in alliances and consortia once they've been created.

 

The U.S. leadership position in IT depends in large part  upon our ability to continue to innovate on our approaches to standardization. Favoring a 'single right or preferred way' will produce no real result, except to weaken all standards regimes.  The ways that are being used -Open Source, alliances, consortia, international formal organizations, national formal organizations, and trade associations - all play a role in market evolution.  By choosing one to be  'more equal', there is the substantial and real  danger that the system would be harmed and its ability to evolve  be threatened.

 

 

Section II: Investment in Standardization

 

The Information Technology industry is investing heavily in standardization, especially on an international level.  (One need only listen to the advertisements about E-Commerce, which are based on standardized interfaces and interoperating implementations,  to realize where the investments are focused.) The investments are being made in groups that are not constrained by national boundaries; there is no such thing as a U.S. only Web, or a Japanese only internet. 

 

On the average, I believe that at least one new consortium is born every two weeks in the Information Technology industry. The Corporate Standards group at Sun Microsystems has, over the past year,  funded (joined) at least four of these consortia, and we fund only the consortia that cross product lines. Sun has probably joined (or helped to create) at least 10 consortia or alliances over the past year, and we have staffed each of these with at least two or three engineers and/or marketing people.  We belong to at least 40 consortia or alliances; in several of these, we hold officer positions (Chairperson, Board member, and so on).  Major growth in the consortia and alliance areas occurred in the areas of wireless internet (groups such as The Open Group, WAP Forum,  and the European Telecommunications Standards Institute [ETSI]), the Web [W3C], the Internet [Internet Engineering Task Force]).

 

We have significantly downgraded our participation in the activities of ANSI; Sun withdrew from ANSI in January of this year when we could no longer justify Sun's continued participation.  On the other hand, we have increased our participation at the management level in both the National Committee for IT Standardization (NCITS) and in the ISO/IEC JTC1 U.S. Technical Advisory Group, where activities that are relevant to Sun are occurring.  Our participation in the IEEE Computer Society standardization activities continues to remain significant as we conclude the implementation of POSIX.

 

I do not believe that Sun is alone in its change in emphasis.  We know that we regularly see our partners and competitors in the same consortia to which we belong, and we know that many of them are doing as we are doing - rationalizing their standards investment so that participation occurs where a return can be demonstrated.

 

The IT industry has also demonstrated that it can and will tolerate more than one group trying to provide a solution to a problem. It is not uncommon to find several consortia attacking the same problem space, but arriving at different technical solutions. The use of multiple groups to focus on a problem and to seek a viable technical solution is used in many companies; the use of it in the standardization arena is not unusual.  Section III provides a three stage model of standardization which speaks to this issue.

 

Under the 'cost of standardization', the creation of the standards is itself a minor cost.  The industry does not sell specifications, but rather provides products based upon specifications. This productization takes time and money,  and is where the real cost of standardization comes in. The installed base must be protected from disenfranchisement, the future must be protected from being made impossible, and users must be satisfied with a robust implementation.  All of this takes skill and experience, which means senior engineering talent, already a scarce commodity.

 

Basically, organizations fund and participate  where the market (defined as the users and the other competing/cooperating providers) direct.  The growth of consortia, as noted above, was an expensive proposition for the IT industry.  The most expensive and oldest of these consortia is The Open Group, a merger of X/Open and Open Software Foundation.  Depending upon participation, annual dues can be as high as $200,000.  Annual dues at other major consortia  routinely run as high as $60,000.  The Open GIS Consortia, W3C, Object Management Group, and ECMA all fall in this range.  And yet, all of these consortia are seeing an increase in membership as they become increasingly relevant to the market. The Open Source movement is expensive as well.  In open source, there is no payment of dues; the cost incurred is in engineering expertise  and in the willingness to surrender intellectual property, something that no company will willingly do without an expectation of a significant market reward for this behavior.

 

During this time, membership in National Committee for IT Standardization (NCITS) and in the ISO/IEC JTC1 U.S. Technical Advisory Group has fallen to the lowest point that I've seen. The reason is that there is no perceived value from participation, and no known penalty for non-participation.  The concept popular within the formal standardization community that there is a 'free rider' phenomena (that is, people who use the standards anticipate not having to pay for their development and therefore  should be taxed to use them) is absurd if one looks at the industry as a whole. The development of HTML and HTTP, the core standards for the Web, was fought out in W3C and the IETF - and the interested parties came to these groups.  The reason they came was that there was something happening which directly and materially impacted their ability to survive and prosper:  the creation of the standards.

 

Simultaneously, there has been very little contribution of 'significant technology' by U.S. headquartered companies to the U.S.  formal process in the past several years. Sun did not take Java to ANSI, Netscape did not take JavaScript there, Microsoft rejected ANSI for C#, and Hewlett Packard created a consortium for its extensions to Java. The reason for at least two of these (where I made the actual decisions on where to take the technology) was the arcane and potentially obstructionist processes that the formal process insists are its strength.

 

The process - with its Byzantine structures, considerable delays for review, reconsideration, and re-vote - is another consideration for a company.  This is where the real and significant expense (as contrasted to cost) of standardization occurs. If a company wants to bring a technology to market, and wants to make that technology common, the formal process can take up to 48 months to complete, resulting in lost market opportunity.  Contrast this with the creation of your own consortium (which takes 12 months to establish and legitimize) and which happens in parallel with the legitimization of the specification. This was the rationale behind the creation of WAP Forum - which gave the market the WAP Phone.

 

As far as the wide-spread review of the specification, it is possible to have all interested parties heard, to comment, and to be considered by using commonly deployed technologies (such as the World Wide Web) and processes similar to those used by the IETF. Most companies routinely use their web sites for such activities.  Recently, Sun put a piece of trial code on the Sun Labs web site for developers to download. We  spiked, doubling visits to the site in three days.  The developers used the Internet to tell one another about the site - and they then hit the Sun site. Formalizing this process is not difficult; Sun's Java Community Process  (JCP) uses the idea of Internet review, which was started by the IETF, picked up by the W3C, and is now widely used by most consortia. The formal process is expensive, and for a vast majority of technologies, absolutely unnecessary.  Attempts to use a 'fast track' process are usually unsuccessful within the U.S. arena.

 

In conclusion, the success of the consortia, alliances, and Open Source is indicative of a willingness of U.S. industry to expend resources (both money and people) for standardization - if it has a perceived value. These groups do have this value; at this time, the formal process does not.

 

 Section III - A MODEL FOR STANDARDS DEVELOPMENT

 

The following model for standards development was created at a meeting of The Open Group Board of Directors Marketing Committee. Participation on the committee was from Sun, H-P, Tivoli, Motorola, and staff members of The Open Group and  NCITS.   The model looks at software standardization, but may, with modification, be applicable to some hardware standardization efforts.

 

This is a three stage model which positions where the various Standards Setting Organizations (SSOs)  participate in standardization, and what forces the transition from one stage to the next.  It is based on both user and provider viewpoints, and reflects the current practice in the industry. The model does not specify how the first stage is populated - this is a market issue and is Brownian motion.

 

Stage 1:  This is the 'proprietary standard', where specifications are derived from an implementation, where a single company or organization controls the technology and its evolution.  The current products in this stage are those, such as Windows or NT, which are clearly the intellectual property of a single vendor who controls the specifications and who may, or may not ,  make all of the necessary interfaces available. There is a very high business risk in using a specification in this arena, since it is fundamentally a 'single source' supply situation.  The product incompatibility risk is considered low, since the technology and its evolution is under the control of a single entity who can legally require that all implementations of the specification are interoperable.  The technology obsolescent risk is also considered low, since it is likely that the single vendor will continuously upgrade the technology to maintain customers.  (A risk here is that the user may have compatibility issues, and the providing vendor may obsolete previous versions.)

 

The first stage is usually a logical outcome of a company fielding a successful product - its implementation of its specification.  Over time, if the company wishes to have more widespread acceptance of its technology, it can either go a marketing route (striving to maintain a lock on the technology and licensing the technology) or it can attempt to open the technology up.

 

If the 'open' route is chosen,  implementation fragmentation may begin to occur.  This is where different implementations appear, each reflecting a different versions of the specification.  It happened in the UNIX market, in the management systems arena, in the geospatial market, and with Linux. The question that faces the market is how to bring the various incompatible implementations (and often, specifications) back into agreement. This is usually the place that standardization is considered and initiated.

 

Stage 2 (De facto or industry standard) The desired goal of search for a SSO is for a rule based environment with an open[4] control mechanism.  This is usually a consortium, although it can sometimes be a formal standards organization. Upon completion, the agreed to specification (with, it is hoped, little ambiguity) is declared a 'publicly available specification', a 'standard industry practice', a 'standard', or any of a host of other names that indicate that it has a different status than when it was the property of a single entity. The overarching term is 'de facto standard'. Because of the possibility of multiple sources of supply, the business risk declines, since the user is no longer held hostage by a single company. The obsolescence risk is judged to be moderate, since it is in the interest of the sponsors to update the technology, since there is the possibility one of the competitors will do so and gain market share. The compatibility risk is less, since there is usually a mechanism provided for attempting to ensure compatibility.

 

A second reason for using an organization for standardization is to allow cooperative competition to take place.  Cooperative competition allows companies to cooperate to create a market need for the technology - and then to compete for a share of that newly created or expanded market.  One of the common failings of technology marketing is to create a solution and then to seek a problem that needs solving. The use of a SSO can help mitigate this problem by allowing implementations of the technology into different markets, well beyond what was thought of by the original creators.

 

Third stage (De jure standards)   Over time, the specification becomes stable, and should, at this stage, be passed to a formal organization for processing. The value of the formal organization is stability and institutional memory.  Again, it is rule based, has multiple company control, and has a permanence that many consortia should not (but do) have.  By this stage, there should be widespread deployment of the specification and products containing the technology, so the business risk should be low.  However, there is a substantial technology risk that the technology being specified my be obsolete with respect to what else is happening in the market.[5]

 

Finally, if the technology continues to be valuable, someone will innovate with it, modifying it and adding to it to meet market demands.  It is at this stage that  the model predicates that the iteration will start again - with the changes to the original specification possibly receiving widespread adoption for some reason (Brownian motion) and then starting though the same cycle (open-proprietary, what organization, who to participate, how to create a specification, and so on.)

 

As can be seen, there is nothing to prevent multiple organizations from tackling the same general topic (i.e. wireless internet communications).  This is encouraged by the organizations who fund organizations, since having multiple solutions sometimes mitigates the impact of catastrophic technical change.  What the industry does not like is two SSOs solving the same problem using the same specifications (dueling specifications) or a specification being bifurcated and modified.  This is where much of the concern about standardization comes in - and the old tired rubric of 'The nice thing about standards is that there are so many of them' is brought up.[6]  It is duplicative standards - not duplicative standardization efforts - that are the bane of the industry.

 

As can be seen, each of the SSO types (open source, alliances, consortia, international formal organizations, national formal organizations, and trade associations) have a role.  There is more interest in Stages 1 and 2 among the industry, and this is where the bulk of the resources are funneled, since it is here that the industry is focused.  These two stages are marked by speed, change, a gentle appreciation of process, a desire for limited structure, and the ability to try new options and structures.

 

Section IV:  The role of the government in standardization

 

A. The Rationale for government participation in standardization

In a major Congressional Office of Technology Assessment (OTA) study completed early in the 1990's, the following comment commands attention:

 

 Other goods, like education and standards, are impure public goods. These combine aspects of both public and private goods. Although they serve a private function, there are also public benefits associated with them. Impure public goods may be produced and distributed in the market or collectively through government. How they are produced is a societal choice of significant consequence. [7] [Emphasis mine]

 

If standards are accepted as an impure public good, then there is a rationale for activity by the Federal government,  if the earlier arguments that standardization in the IT arena is, by nature, international.

 

The basis of this observation lies in the differing ways that standards are perceived in the U.S. and the rest of the world within the IT community. I believe that the open (de facto and de jure) IT standards - both formal and informal - which U.S. based companies produce are exceptional pieces of technology, and can create markets.  I also believe that standards that the EU produces in the IT arena - standards dealing with Quality, Security, Privacy, to name three - will overwhelm the ability of the U.S. to continue leadership in the high technology arena.  The EU is producing what I call 'use standards'.  These standards do not deal with the technology; Europe has generally forfeited claims of leadership here to the U.S.  However, use standards describe the way that technology can be used - and this drives technology direction (and the ability to create and or control markets) more effectively than technical expertise. 

 

To cite a limited example:  The EU Privacy Initiative sets legal terms on the deployment and use of data mining in Europe.  As a result of this directive, certain technical avenues are closed, since the solutions they might have provided/enabled can no longer be sold in a world wide market. 

 

Taken individually, this ability to set limits on the application of technology is not too grievous. Taken collectively, it  becomes a 'societal choice of significant consequence' - but a choice imposed on the U.S. by Europe, through use of standards.  I believe that the use of standards as an instrument of social policy is a growing threat to the technical leadership of the U.S.  It is not a problem which admits of a simple solution.   However, I believe that it is a real and significant issue which the Federal Government must address as a matter of public policy.

 

B. The Role of the Government in participation

 

 I believe that there is a need for governmental participation and action within standardization. I would suggest that this action breaks into two distinct areas - the proactive participation by the government and a 'watchdog' function.

 

The proactive portion of the agenda is focused on the participation and procurement policies of the government.  Currently, there is minimal governmental participation in consortia due, I believe, to the plethora of consortia which exist[8].  However, it would help if the National Institute for Standards and Technology (NIST) was given adequate funds to send their employees to consortia meetings.  I do not believe that there is a consortium which would refuse to invite NIST to participate on an individual basis if it could be assured that a NIST engineer would/could contribute.

 

The other end of the agreement, however, is that governmental agencies be allowed to specify the specifications produced by these consortia.  At the current time, agencies are discouraged from specifying consortia based specifications because they aren't 'open'. This could be countered by allowing NIST to publish a source book of consortia, specifying the openness, membership, and other pertinent facts about the various consortia. A recent study[9] done for the Information Society Standardization System (ISSS), a working group of the European Committee for Standardization (CEN)[10], which lists all of the fora of the standardization arena would be a good model.  This publication would let a purchasing agency determine if they could/should specify a consortium specification by allowing  the purchaser to judge if there really is a 'legitimate' second source engaged.  Note that the idea is not 'open', which is not a business term.  Rather, the idea would be to ensure that there is no 'proprietary solution' which can masquerade as a de facto or de jure standard. This activity would clarify much of the governmental procurement policies and permit a wider base of product for standardized procurements.

 

In the role of a watchdog, the government has a role in the creation and protection of Intellectual Property Rights (IPR). SSOs have widely varying IPR regimes; where the rules of an SSO are silent, the rules of the nation in which the SSO is incorporated/recognized/originated become active.  While this was acceptable with a single nation or a single IPR regime, it is not acceptable in the world of the Web and of e-Commerce.  The problem cuts both ways: in some cases, IPR can be seized because rules were unclear; in others, false grants of IPR can severely limit the functioning of the web. There was a statement made by an official of the W3C to me , in which was stated 'After all, this has been the purpose of the patent mechanism: to encourage innovation over the years. It just so happens that the innovation process in the Internet world is different than in other industries and that a new framework is thus needed.' The issues here are non-trivial, and are becoming more and more important as the web  and its potential come to be realized.  While the issue is important for standardization, it is also important for the web and the technology that drives the web.  A singular policy for standardization, acceptable to all parties, is an area that needs clarity; the current policies, with their focus on patents, are woefully inadequate in the world of software standardization.

 

Standardization is also a potential remedy for what might be monopolistic or anti-trust market situations. Completely exposing the interfaces in a specification permits the specification to be implemented by multiple competitors, giving multiple but similar products, allowing the market a choice of implementation. The conditions of the exposure - whether they are licensed, free, conditional - should be situationally determined. However, a true open standard will allow product competition to occur, with its attendant benefits.

 

 

CONCLUSIONS:

Standards are a remarkably powerful tool for the IT industry.  We have, in the past, taken them for granted. However, recent events, including the birth of the Web, E-commerce, privacy, security, and the interdependent nature of the global critical infrastructure all indicate that standardization - within the IT framework - will begin to once again become an important discipline.

 

This is a multi-billion dollar discipline.  It impacts the ability of every member of society, and yet it is little understood and practiced with skill by less than a 1000 people world-wide.  It is  largely ignored in the academic community, and generally overlooked in professional education.  However, over time, its effects are widely and increasingly felt, and once established, are very difficult to undo.

 

Note:  The views and opinions expressed in this article do not necessarily reflect the views of The Open Group, it's members or it's sponsors.

 



[1] Cargill, Carl F. Open Systems Standardization: A Business Approach Prentice Hall PTR, Upper Saddle River, NJ, 1997, Chapter 2, has a description of the history of standardization, as an example.

[2] available at http://www.tuxedo.org/~esr/writings/cathedral-bazaar/

[3] Hecker,  Frank 'Setting Up Shop: The Business of Open-Source Software', 6 December 1999, Revision 0.7  DRAFT, http://www.hecker.org/writings/setting-up-shop.html

[4] 'Open' is NOT taken to mean any affected party; 'open' is meant to indicate that it is not under the control of a single entity.  If only four organizations participate, and two or more separate competing implementations come out of the activity, the effort has succeeded.  The other consideration on 'open' is that the effort is focused on standardization of 'current practice' - that is, what the market is currently implementing. Changing the 'current practice' to make it 'better' while breaking the installed base is a problem; it has prevented at least one consortia from even considering submitting their specifications.  In the case of HTML 3.2 and standardization by ISO, ISO tried to standardize HTML 3.2 with 'improvements', after W3C had standardized HTML 3.2, the market had implemented it, and W3C was working on HTML 4.0 to follow-on HTML 3.2. The need for gratuitous change that marks the formal 'open process' is one of the greatest impediments to the use of formal standardization by consortia.

[5] The danger is exemplified by the emergence of XML as a W3C based consortia standard, replacing SGML from ISO as the annotation method of choice. If a user was now to choose SGML as a business practice, it would face a shrinking source of supply as more and more vendors turn to XML.  The same could be observed in the bias ply versus radial ply tire battles, or in the replacement of LP records with CDs.

[6] Many people forget that standards are produced by fellow workers and colleagues, usually in response to a perceived or real market need.

[7] U.S. Congress, Office of Technology Assessment (D. Linda Garcia, lead researcher), Global Standards: Building Blocks for the Future,  TCT-512 (Washington DC: U.S. Government Printing Office, March 1992), p. 14, footnote 23.

[8] The addition of 'the U.S. government' as a member of a consortia would legitimize a consortia rather quickly, and all of the suppliers concerned with selling to the government in that area would flock to that group. If the government didn't join, it would immediately cast doubt on the longevity of the consortium.

[9] Available at http://www.cenorm.be/isss/Survey.htm

[10] CEN is not a formal SDO in the normal sense of the word, being a creature of the European Commission.  However, it does have the power, under the Vienna agreement, to 'compel' European nations to accept CEN norms in lieu of national body standards.  This has been a sore subject with many in the U.S. who see this as 'bloc voting'.