Interoperability

Software does not stand in isolation. One manufacturer’s software typically must interact with, and even depend on, some other manufacturer’s software. The standard example is a program that is written to work with a particular operating system. This example generalises readily to a building-block model that has higher-level (application or client) software tending to depend on lower-level (system or server) software.

It happens sometimes that the system software to be interacted with is not documented very well. Indeed, once an operating system becomes entrenched, its manufacturer has little need to document it very well and may even see an interest in documenting it less than well. On the one hand, the system’s manufacturer could bear the cost of preparing accurate, comprehensive documentation so that programmers in all their generality may write software for interaction with that system. On the other hand, since the system is entrenched and the manufacturers of software that runs on that operating system have let themselves become captives, any cost of overcoming inaccuracy, imprecision and omission would be a cost that they must grin and bear. It is at least conceivable that if the manufacturer of an entrenched operating system also produces applications for that operating system, in competition with other manufacturers, then this transfer (and even amplification) of costs might seem strategically desirable.

Through advance analysis of system software, those who write dependent software have a more certain (and possibly cheaper) means to discover information that may be crucial to their product’s commercially viable development and correct operation.