Who should decide what standards should be developed?

The group decided to break this question down into two parts. The first relates to the question of who decides that something should be standardized. The second relates to who decides which organizations should develop a given standard. The first question has to do with how the problem is conceptualized. Spring[26] has suggested that we might look to interface and standardization issues in four areas -- interconnection, interoperation, interchange, and interaction. This kind of model would suggest the standards that need to be developed and their relations. Given this, or any other model, once the suite of standards to be developed is made clear, it would be necessary to decide which of the standards should be developed by what organization.

Oksala provided a carefully reasoned set of arguments about deciding what to standardize. After an extensive review of the various possibilities, he concludes with what might be defined as the traditional US market driven approach. He concludes that:

when organizations providing the resource deem the issue of sufficient importance, they will come. If they don't, then you didn't really need it.

Rutkowski also favors the tradition of viewing standards as business instruments. Rutkowski continues with the position that he favors competition among standards development organizations as well, going so far as to say:

I think we should generally be disturbed by oligopolies - and justify their existence only where really necessary. It's not clear the case has been made that in today's highly dynamic and highly competitive information systems field that they are necessary. Indeed, it's been pretty obvious that they are counterproductive.

Oksala sees the matter in a little more complex fashion. Given a decision to develop a standard, he acknowledges that there may be no way to avoid competition in development, but feels it is essential that competition be eliminated at the level of approving or selecting a standard. ``[U]nfettered competition'', although it may be justified at the development level, ``amounts to companies essentially paying two sets of mercenaries to fight each other.'' He believes that ``designation as a formal national or international standard may be the carrot that can be used to get people to cooperate.'' Oksala favors tougher coordination at the national level to avoid duplication of work, but sees little hope of this occurring:

1. Companies probably won't force the coordination for two reasons. First, it raises antitrust questions. Second, it reduces the options if a standards project is turned down. (Currently, companies can ``shop'' for a sponsoring organization.
2. The government could do it, but they don't have the talent to make the ``wise'' decisions, and the private sector would rather live in a very imperfect world before turning control over to a bureaucracy.

This question tends to raise more questions as opposed to generating answers. It highlights the fact that standards development can be separated from the acceptance or approval process. One might imagine that the whole process of standards development could be outsourced leaving the standards ``developing'' organizations to oversee the process of approving a standard. While the authors do not favor specialization of functionality, Spring points out that one might imagine the following conceptualization as one way to clarify who decides what standards to establish:

1. ANSI accredits organizations to certify standards and develops guidelines for the form and format of standards.
2. Organizations that certify standards will not engage in the process of developing standards directly.
3. Organizations interested in the development of standards may proceed to develop them, but are encouraged to register their intent and to use the form and format provided by ANSI if they wish to have them certified.
4. Any standard developed by any organization, providing it is in the appropriate form and format may be submitted to the appropriate ANSI accredited organization. This organization will assure the vote of all involved parties, and will provide feedback on changes needed to the developers who may then decide either to accept and accommodate the changes or withdraw the document from consideration as a standard.