Rethinking Open Systems
David Chappell - August 1995

Open systems technologies, those not tied to any single vendor, have been the holy grail for many users. With a near-religious fervor, some organizations have spent the last dozen years crusading for this belief. To be free from a single vendor, goes the cry, is to live in the best of all possible worlds.

But is this really true? Are open systems the great boon they promised to be? Or have they in fact been less effective than their supporters hoped? And when they are effective, what exactly are the conditions that allow the creation of successful open technologies?

Defining an Open System

Answering these questions first requires defining exactly what it means to be open. This is easy if you're a vendor, since whenever any vendor says "open" , they always mean the same thing: their products. This definition isn't quite what most users have in mind, however. To users, an open technology commonly has the following attributes:

• it's not controlled by any one vendor;
• the basic functionality is the same regardless of which vendor the technology is purchased from;
• the technology allows interoperability and/or portability among products from multiple vendors.

It's this last point that most lights up the eyes of users. If several different vendors all sell essentially the same technology, then competition among them will lead to lower prices. High tech products can
become commodities like wheat, which in turn, the argument goes, will benefit users. (It's worth pointing out that this in no way benefits vendors--quite the opposite. Unsurprisingly, then, despite protests to the contrary, vendors have often done their best to avoid implementing truly open systems.)

Opening the World

The roots of the open systems movement date from the late 1970's. At the time, each hardware vendor had its own proprietary processors, operating systems, network architecture, and more. When a user bought a system, that user was entering a long-term relationship with that vendor in many areas, a relationship that was very difficult to break. The vendor was well aware of how hard it would be to switch and so priced its products accordingly.

The situation today is very different. The industry has stratified, and while many of the old-line monolithic vendors still survive, they are largely living off past glory, i.e., their large installed base (further evidence of how difficult it is for users to break away). For a new system, it's quite possible that the processor, operating system, and networking software all come from different vendors. Indeed, the most profitable companies in the industry today are those that dominate somedimension of this new partitioned world, firms like Intel in microprocessors, Microsoft in PC operating systems, and Novell in network operating systems. The days when a single vendor could effectively build and sell completely proprietary systems are fading fast.

In some ways, the current world is exactly what was hoped for by the original proponents of open systems. Users are free from the dominance of a single vendor. But to a large degree, this freedom is not the result of open systems. Instead, it comes from something that looks a great deal like a group of monopolies or, put more politely, technology franchises.

What Do Users Want?

Contrary to popular opinion, users never wanted open systems. What they were after was the benefits that open systems could provide, chiefly competition among vendors and the lower prices that would ensue. And after years of being beholden to a single vendor for everything, many organizations wanted freedom, too, the ability to easily buy elsewhere if a vendor's service or support or general attitude were substandard.

But consider: in what market have we seen the greatest competition, the fiercest price wars, and the fastest increase in value received per dollar spent? The answer is obvious: the world of IBM-compatible personal computers. But by the definition above, there's just no way to argue that this competition was made possible by open systems. Instead, it's the result of a de facto standard for building a system, a standard that's ultimately based on two franchises: Intel processors and a Microsoft operating system. The key things that users wanted from open systems are present here: fierce competition, lots of choices, and the absolute commoditization of hardware. (A side effect is that the owners of those franchises get very rich, but this is a concern only for their competitors, not their customers.)

The thing that's missing in this market, and an attribute that many open systems advocates say is essential, is complete vendor independence. Everybody who buys a PC is dependent on Intel and Microsoft, as both the recent Pentium brouhaha and the eager anticipation of Windows95 make clear. But while this certainly offends many open systems purists, it doesn't seem to have stopped them from taking advantage of the very real benefits these dominant technologies provide to their users.

The Beat Goes On

And those benefits show no signs of stopping. Just as Windows played an essential role in commoditizing PCs, so might Microsoft's Windows NT lead to the commoditization of server hardware. Unix, ostensibly an open technology, has gone a long way in this direction by providing a quite similar environment on hardware from multiple vendors. Those vendors have always made sure, however, that the user and programming interfaces, administrative tools, and other details were just enough different from those of their competitors to provide product differentiation. In practice, this has meant that moving from, say, Hewlett-Packard's HP-UX to IBM's AIX has entailed some pain. Since both systems run only on a single vendor's hardware, this was good for that vendor.

Windows NT has the potential to change this. Unlike the various flavors of Unix, Windows NT really is the same on multiple systems: user interface, programming interfaces, etc. Moving an application from NT on one vendor's hardware to NT on another vendor's hardware requires at most a recompile. This is the openness that Unix has always promised but never quite delivered. Just as the ubiquity of Windows reduced the market for PC hardware to a dog-eat-dog competitive level, Windows NT may well produce the same effect for server hardware. Users get what they want in this scenario, even though open systems are nowhere to be seen.

Innovation and Open Systems

Why haven't open systems met users' expectations? One reason is that in dynamic, rapidly changing technologies, they just take too long to develop. Since most standards are produced by committees of some kind, they lack the ability to respond quickly to a changing market. And since many of those committees reach decisions by consensus, the end result can sometimes reflect internal politics more than market realities. A single agile vendor can often do a much better job of establishing and advancing a franchise technology. Whatever criticisms can be made of product delays from companies like Microsoft, they pale in comparison to the glacial pace of many standards committees. Since the business problems that users need to solve don't wait for a committee to finish deliberation, those users can't, either.

There are many examples of these kinds of delays. One of the more well known occurred in the development of version 2 of the Simple Network Management Protocol (SNMP). The small group that was primarily responsible for creating the original SNMP standard attempted to repeat the process that had produced their initial success, working essentially on their own to develop version 2. When the fruits of their labors were presented as a fait accompli to the relevant working group in the Internet Engineering Task Force (IETF), they were deemed to have been developed in an insufficiently open manner. The result was a significant delay that produced little in the way of technical improvements.

Making Open Systems Work

Open systems are not the panacea they were once thought to be, and they aren't the only path to achieving users' true goals. It's absolutely true, however, that some open systems technologies have made the world a much better place. Especially good examples of this can be found in networking, where standards for LANs, WANs, and more have, despite delays in their development, proven effective.

Based on the experience so far, it's possible to list some of the criteria for creating workable, successful open technologies. They include:

• a reasonably stable technology: where technologies are very dynamic or where basic issues in a technology are not yet well understood, trying to define standards is unlikely to succeed. As mentioned above, most standards committees are too ponderous to really be effective in a fast-moving area. And if there's no real grasp of fundamentals, it's easy to end up doing research by committee, something that's proven to have a very low success rate.

• design by experts: the members of the committee must truly have expertise in the area. Too often, the quest for openness is interpreted to mean open enrollment in the committee. If at least the dominant developers aren't engineers with experience in the area, it's unlikely that the results will be usable.

• avoiding slavery to consensus: whatever the political pressures, decisions cannot be made by strict consensus. Achieving complete agreement is very difficult and, more important, takes too long. Producing a perfectly harmonized standard is meaningless if it's completed too late.

• technical, not political criteria: standards produced by agreements among competing vendors often don't work. Vendors have every incentive to fight for proprietary advantage or, failing that, to agree on a very loose specification, one that all but requires proprietary extensions. The most effective standards have been produced by groups of engineers, usually from different companies, but working together as individuals, not as representatives of their employers.

• a devotion to prototypes: nobody's design is right the very first time. Being willing to build actual implementations of early attempts and to learn from them is a crucial step is producing an effective final product.

• common code: for software-based standards, having a common code base has proven very effective. Allowing vendors to license or otherwise acquire the same implementation, then port it to their systems both shortens the time to market and makes interoperability and portability problems less likely.

Perhaps the best example of a standards organization that has embodied these criteria is the IETF. More recently, though, they've been the victims of their own success, as their importance in the market has made it more difficult for members to not represent their employer's position. Another successful example is the Open Software Foundation (OSF) during the original development of the Distributed Computing Environment (DCE). Unfortunately, OSF has changed its development model to one that requires complete agreement among competing vendors. This unsurprisingly has led to a slowdown in planned enhancements to DCE.

A counterexample, an organization that embodies few of these criteria, is the Object Management Group (OMG), creators of the Common Object Request Broker Architecture (CORBA). The group is developing standards for very dynamic technologies, and while the participants include many smart, experienced engineers, the important decisions are largely made by consensus among company representatives. As a result, the OMG standards are riddled with holes, places where vendors are all but required to add proprietary extensions. And while OSF offered to provide a common code base for CORBA, the offer was rejected. Given this, it's not surprising that the current crop of CORBA products offer limited portability across vendor implementations and very little interoperability. With the nature of the OMG process, it's hard to imagine any other result.


Especially in networking, open technologies can work. Often, though, the chief benefits of openness--competition and lower prices--can be better achieved through single-vendor technology franchises, particularly with dynamic new technologies. And when open systems are a viable option, their history seems to indicate that only certain kinds of processes work to create them. For users, a clear understanding of their true goals, coupled with an agnostic, pragmatic perspective, will produce better results than blind faith in the creed of open systems.

This article appeared in a slightly different form in the August 1995 issue of Business Communications Review.