NIH as a corporate culture

By: Scott Bradner

A while back I talked about the types and importance of standards. Well, I'm not done yet, for there is more. (For you literary folk, that last phrase is a quote.)

One feature not mentioned last time is that a standard protects the buyer. It can ensure that products purchased from various sources or at various times will be compatible. At least that is the theory. If there are too many options in the standard this guarantee of interoperability can fall short. One vendor can pick a set of options to implement that does not match the set picked by another vendor. Both vendors can claim compliance to the standard and yet not be interoperable.

The OSI standards often exhibit this type of problem. For quite a while interoperability between versions of X.400 was problematic because of the extensive set of optional features. A number of governments have attempted to reduce the probability of incompatibility by issuing an options checklist for these protocols. In the U.S. this checklist is the Government OSI Profile, better known as GOSIP. Purchasers of OSI "compliant" products would do well to insist on GOSIP compliance in addition.

On a completely different topic. A standard is only as good as its acceptance. There are a numerous reasons that a standard may not play in the marketplace, from the simple case where a standard defines an unneeded or unwanted function to the all to common case where the standard is written in gibberish (and often unclear gibberish at that.)

Unfortunately, there is another common reason that some standards are not as widely adopted as they might be: the corporate Not Invented Here (NIH) syndrome. 'If we did not do it, it can not meet our needs.' In addition, some companies fear the open marketplace and create their own "standards" in an attempt at product differentiation.

Historically, Novell could be found in this camp. For example they created their own protocol rather than use any of the existing standard ones. On this front at least Novell is coming around. They are adding much better support for the use of TCP/IP, even for client to server interaction. But they have not completely chosen the open path. They recently introduced NLSP, a new routing protocol. This protocol solves a number of problems associated with building large Novell internets but, from a few feet away, is almost indistinguishable from the existing international standard routing protocol IS-IS. Of those features that do differentiate it from IS-IS, many of them could be supported by the proposed Integrated IS-IS extensions to IS-IS.

The vendor most constantly exhibiting the NIH syndrome is Apple Computer. I've mentioned Apple's reluctance to support TCP/IP in this column before but an even better example is the much anticipated Open Collaboration Environment (AOCE). AOCE contains a lot of 'almosts'. Its security is almost the same as MIT's Kerberos and its basic function description is almost the same as the Open Software Foundation's Distributed Computing Environment (DCE). If AOCE was DCE, Macs (like the one I'm writing this column on) could be part of a corporate distributed computing environment involving computers from a dozen other vendors. Instead, my Mac will remain effectively a standalone device, unable to make use of the resources starting to become available in the University through DCE. Apple claims that it will (eventually) produce AOCE interface to other systems, but why should we have to wait for Apple to program software for an IBM mainframe?

Standards, by the nature of their adoption process, do not answer every need for every vendor. Even so, those vendors who embrace standards grow the market for their products. Take TCP/IP and UNIX as examples. This writer wishes that Novell and especially Apple, would learn that lesson.

The disclaimer of the month is for the C programmers among you and comes from many sources: #include <std-disclaimer.h >