As might be expected, there were significant disagreements on this question.
Indeed, it takes little modification of the words to see diametrically opposed
arguments. Oksala suggests that it is a lack of order in the
process. He sees a real danger in the growth of
self-designated standards bodies
and the refusal on the part of public procurement people
to distinguish between groups on any formal basis.
As a result there is no simple standards process--just
lots of standards, many of which are incompatible.
In contrast, Rutkowski points to the ``ossification'' of the
process in some standards developing organizations.
What needs most to be fixed has two heads. On the one hand, organizations are building solutions with minimal regard for what others are doing, there is a lack of organizational and professional coordination. On the other hand, some of those with apparent responsibility for action appear slow to respond.As examples of these issues, one might ask where in X3 responsibility to coordinate the development of standards for human-computer interaction is being exercised. Similarly, one might ask how the efforts of all those concerned with interconnection standards are being coordinated.
At a more operational level, Oksala pointed to the need for better automation of the development process. Most agree that the IETF has demonstrated the ability to develop standards more quickly in an electronic environment. Spring[29] has suggested a variety of mechanisms that might improve the process. The SPA system being developed by the IEEE, the NSSN being developed by ANSI, and CASCADE being developed at the University of Pittsburgh all look to address this issue in different ways. While it is clear that technology can be made available to speed the standardization process, it is not clear that the involved individuals are really ready to accept radical changes in the process. In addition, how technological mediation of the communications process will impact user satisfaction with due process and consensus is as yet untested.
Oksala also sees problems related to the cost of standards development. He holds that the question is not whether standards should be free, but who should pay for them. From the point of view of a corporation, there are the costs of membership in a variety of organizations -- some of which have substantial membership fees and others of which have nominal fees. In addition, from a corporate point of view, the cost of redirecting engineering expertise to standards development coupled with the out of pocket costs for travel can be significant. Rutkowski generally ignores the the perspective of a corporate sponsor where one sees multiple fees, some of them significant, and a drain on technical staff committed to multiple concurrent efforts. Rutkowski sees the situation as follows.
In virtually all organizations, the preponderance of the costs are those contributed by the participants. The institutional costs are comparatively minor, and can generally be amply covered by nominal participant fees. In today's world, standards whose dissemination are controlled for the purposes or garnering additional revenue sow the seeds of their own demise. To quote Malamud, ``secret specifications are not standards.''
Spring and Weiss[30] identify a
framework for the analysis of the cost of
standardization. The study supports the contention
that the major cost is in participation, not fees.
At the same time, it
clearly supports the contention that the cost of standards is extremely high
and that the costs are not evenly distributed.
The study raises a series of
questions about ``free-riders'' in the process --
organizations that use standards but don't
participate in the development process. It also provides
a model which suggests that some critical standards
will not be developed because their cost-benefit
profile does not justify them from a business
perspective. Specifically, there is little
incentive for business to develop reference models
to guide the development of sets of interrelated
standards. Thus, under an economic model, it is clear that there was a high
cost without significant return to those
companies who contributed over the long
run to the OSI development effort. Yet, there is a
value to the OSI models, if not to the specific
protocols. It would be interesting to determine
how much the existence of the OSI Reference Model,
and some of the more detailed models developed under the OSI umbrella, have
been used in the development of IETF standards. Spring notes that in
the academic environment, students are taught about
the TCP/IP standards using the OSI framework.