"Open" 'Cause We Say So

So the recent feeding frenzy related to "open" networking devices started me thinking. What, exactly, do we mean by open?

This is one of those times in the market where a bandwagon starts to develop and everybody is hopping on board. Marketers around the networking industry are suddenly rushing around with yellow PostIt™ notes to stick the word "open" onto anything and everything. You half expect commercials such as, "The Global Networking Conglomerate 3000, now with improved 'openness.'" All this labeling of everything open really begs the question of what we mean by openness. And more to the point, what do consumers want "open" to mean? The answer from most of the vendors making announcements lately seems to be, "It's 'open' because we say so."

Over the next few paragraphs, let's examine what "open" could possibly mean, and then we'll try to triangulate the positions of the various companies that have announced "open" products.

It seems to me that there are at least two dimensions for openness: hardware and software. There may be more, but those are certainly the most obvious and having two dimensions makes for a good graph. Along each dimension, there are (at least) four degrees of openness.

For instance, along the hardware dimension a company could have:

• Proprietary hardware -- This represents the most-closed hardware. Developing for this sort of platform requires an embedded development kit because the architecture is non-standard. Note that proprietary hardware may use standard components, such as x86 CPUs, but because of the way the hardware is designed, it's still an embedded system, not standard.
• x86 blade -- When proprietary companies want to "open up" the hardware, they often do so by adding an x86 blade to the system. While the "host" hardware system is still very proprietary, the blade uses a more standard PC architecture and may use more standard development tools.
• x86-based -- In this model, the hardware is completely standard, but is sold as a proprietary system. Many security and traffic management appliances use this model. The vendor buys a white-box PC, adds a branded label to it, and then loads their own software onto the system. While the hardware is completely standard under the hood, there is no suggestion from the vendor that the user is able to swap components or perform system upgrades using standard components.
• Commodity hardware -- This is the final model. The system uses completely open hardware and the supplier and customer both expect that users will be able to perform system upgrades with components from different vendors. The current x86 server market delivers this kind of hardware today.

Similarly, along the software dimension, the following four models can be seen:

• Proprietary software -- In this model, the software is completely closed. It's sold only in binary form. Users use the software and there is no ability to develop extensions without acquiring a proprietary license.
• Country-club API -- In this model, the company opens some APIs that allow external developers to interact with its otherwise-proprietary system in a programmatic way, but the API or SDK must be licensed from the company. Typically, the company tightly controls who is allowed to participate in the program and may charge a multi-thousand-dollar "program fee" to participate. This makes the program as exclusive as a country-club.
• Open API -- In this model, the API is completely open, with no strings attached in order to get it an use it. A public SDK, posted for free download from a web site would qualify here. The code you're interfacing with would still be closed-source, but at least you could get ahold of the SDK without paying any fees or being "approved." Note that you may still have to buy oodles of proprietary hardware in order to do any development, but at least the SDK is freely available.
• Open source -- This is obviously the most open. The source code is readily available and there are no fees to develop with the system.

Now, given all these definitions, we can make a chart that describes the landscape graphically:

I've also plotted some of the recent announcements according to how I think they stack up.

• Vyatta -- Vyatta first launched its product in July 2006. Vyatta has been open source and running on open, commodity hardware since the get-go. Want to download our software? You can do it from the web site. Want to download the source code? We have instructions in plain view. Want to run your Vyatta system on whatever hardware you want? That's fine by us, and we have even published a hardware compatibility list to help you choose something known to work well, but you're free to go off-menu as well.
• 3Com -- 3Com was early out of the gate, over a year ago (1Q07). 3Com announced an x86 blade for its routers and a country-club API software program, called OSN. OSN has a couple membership different levels, with the lowest level free to join, so it may be that OSN is walking the line between a country-club API and an open API.
• Juniper -- Next up was Juniper in December 2007 with the PSDP program. The PSDP was a country-club API program delivered on the same proprietary hardware they had shipped previously (no blades required). There are a couple of positions for Juniper on the chart because they have different product lines with different implementation techniques and different capabilities. From what I have read, the PSDP only applies to the high-end service provider routers; the Juniper J-series routers are essentially PCs with a proprietary software load. Juniper does change the connectors and form-factor of the add-in cards so they look proprietary, but they're just standard PCI hardware under the hood. The processor is a stock Intel x86 CPU.
• Riverbed -- In February 2008, Riverbed started making noise about opening up with its RiOS Services Platform (RSP). Riverbed is a good example of an appliance vendor using stock PC hardware with a proprietary software load. The RSP program puts Riverbed into the country-club API on x86-based hardware category on this chart.
• Cisco -- Finally, in April 2008, Cisco announced its Application eXtension Platform (AXP) program. This is another good example of a country-club API paired with an x86-based blade to plug into proprietary hardware. Of course, the AXP is only available on the ISR series; the rest of Cisco's product line remains locked up tighter than Fort Knox and finds itself down in the Proprietary/Proprietary category.

This post is already getting pretty long, so I'll cut it off here. The major takeaway of all this is that there are different degrees of "open" that are running about the networking market these days. With everybody using the same word, and being intentionally vague (and sometimes misleading), it's easy to confuse one "open" for another. But they're not created equal. Don't be afraid to ask a vendor why they think they're being particularly open. If you don't like the vague, "'cause we say so" answer you're likely to get initially, don't be afraid to press ahead. At least at Vyatta, we have no trouble answering that question. The other guys...? Well, who knows.

In a follow-on post, we'll discuss the implications of being more open. Are there really differences between an x86-blade with a country-club API versus open source software running on commodity hardware? The short answer is you betcha! See you next time.