SUBCOMMITTEE
ON TECHNOLOGY
COMMITTEE ON SCIENCE
U.S. HOUSE OF REPRESENTATIVES
10 a.m.
2318 RHOB
The Role of
Standards in Today's Society and in the Future
Director - Corporate Standards
Sun Microsystems, Inc.
Palo Alto, CA
- 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.
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
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.
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
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'.