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 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 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.