Maybe it’s the popularity and impact of open-source software, or maybe it’s just that the word “open” makes you think of being wild, happy, and free—whatever it is, the concept of openness in networking is catching on. Hence, obviously, this definition is getting fuzzier every day.

When we talk with enterprises, they seem to think that openness in networking is the opposite of proprietary, which they then define as a technology for which there is a single source. That suggests that open networking is based on technology for which multiple sources exist, but as logical as that sounds, it may not help much.

Let’s take the ever-popular concept of white-box switches and routers. Are these open networking in action? Probably not as much as you’d think. Are all white boxes from all sources equivalent?  No, and in particular they often use different networking chips that have different interfaces to the software.

Everyone knows hardware these days is just something you run software on, so what is open software for networking?  Is it open source or is there another criteria to be applied?  For high-performance networking, it’s actually hard to find a true open-source package because of those pesky network chips.  The chip interfaces are different, so you need a PC-like “driver” concept to create a consistent software interface across the chips.  There are initiatives, like the P4 flow programming language, that could support an open higher-layer switch or router with a licensed P4 driver, but not all chip vendors support P4. Broadcom, the biggest, has its own P4 competitor, Network Programming Language or NPL.

Should we admit that true open networking is doomed, then?  Maybe not, because there are other more complicated criteria for openness, and we get to it by looking at what users don’t like about proprietary networking.

What locks you into a proprietary device is obvious; you can get it from only one vendor.  What creates the lock is that the costly hardware and the software are bundled.  Suppose you let users buy the “proprietary” hardware and software separately, and run other software on a vendor’s hardware or vice versa?  If there were really alternative hardware/software mixes that could be created with a “proprietary” and separate hardware/software offering, is that at least more “open?”

The same thing applies to white boxes.  Suppose that you have a white-box router that, once purchased, could run a half-dozen different network software components?  The major investment users would make–the hardware–is at least somewhat protected from lock-in.  Since there are probably only two major chip forwarding languages (P4 and NPL), it’s hardly impossible to create a software package that would work with either of them and make a software router implementation technically portable across most devices.  And a proper “driver” could make the same router software run on Cisco or Juniper gear, in theory.  Cisco blogged about its P4 support, but most of the comments on the blog questioned whether Cisco itself would use it, which surely casts some doubt on Cisco’s commitments.  Juniper has also blogged on its P4 approach, and they seem a bit more committed to using it in their own integrated hardware/software solution.

This raises the whole disaggregation craze. You disaggregate a router or switch and the parts become part of a pool of interchangeable elements from which you can build all sorts of stuff.  Your independence is guaranteed by the existence of a pool to select from. That means, of course, that to be meaningful you have to actually have a pool of choices for the parts, at least for hardware and software. That’s the first test of whether a given strategy is really more open, whether disaggregation has addressed the risks of lock-in or stranded assets. If a vendor tells you it has a disaggregated router, ask what white boxes their software is certified to run on and what other software runs on their hardware. Then ask them if they support and supply P4 and NPL drivers.

It’s not the only test, of course. Pricing also matters. If a router vendor disaggregates its router software but charges 95% of the total cost for the hardware, you’ve not gained much by having the promise of multiple software options because most of your cost is already sunk. Similarly, if there’s a router software vendor who charges most of the cost of a proprietary router for its software, you may not be eliminating lock-in, just choosing who’s doing the locking.

The whole openness thing gets harder when you’re talking about a network or section of a network, rather than a device.  A good example is Open RAN, the popular open specification for the elements of the 5G radio network.  Some vendors are promoting enterprises to adopt private 5G based on Open RAN, and the openness sure sounds good to most.  The problem is that it’s possible to have multiple implementations of an open standard or specification, but where each is a complete implementation whose low-level components can’t be exchanged, despite being implementations of the same specification.

At the network level, you also have the problem of integration. If you’ve ever put together a jigsaw puzzle, you know that one that has five pieces is a lot easier than one that has 500.  Things have to fit together properly, and in a network, most users would agree that there has to be someone responsible for the operation of the whole thing. Open RAN implementations can involve a dozen or so vendors, so imagine how much fun a fault-isolation meeting would be. The air would be filled with fingers.

How can enterprises make smart decisions on open networks? First, you have to separate the hard benefits and disadvantages, things that you can quantify, from “soft” benefits and risks, like “supporting open-source” or “my router vendor won’t like me”.  It’s OK to make an open-network decision with an unfavourable hard-benefit-and-risk balance, but don’t expect the CFO to be smiling at the end of the presentation.

The second thing is to assess your open options against your quantifiable benefits and risks. Get the vendors or integrators to sign off on their own responses. You’d like a choice that ticks off all of the former and none of the latter; if two options have similar scores, go back and assess each again to refine your view.

The final thing is to write your benefit-and-risk presumptions into the contract and have all parties commit to a way of addressing situations where a vendor doesn’t deliver on its promises. If there are multiple vendors, make sure that problem isolation doesn’t become a field of gladiatorial combat. You do that by writing the rules of engagement into the deal. If somebody doesn’t like all this formalism, look to the next choice. Remember that “open” doesn’t mean “no commitments” because you are always the committer of last resort.