How Open is Open Source? Watch Out for Hidden Hooks.

Among the pain points we hear from our Service Provider customers, vendor lock-in—and the pricing and flexibility constraints that come with it—tops the list. It’s the reason so many standards bodies and open source communities are working in the networking space today. It’s one of the biggest reasons Lumina Networks exists. And yet, if Service Providers (SPs) are clamoring for open standards and interfaces, and the industry is (supposedly) working to implement them, why are most SPs still locked into closed, proprietary environments?

The short answer: because that’s how vendors want it. And they have a long list of tricks and hooks to keep you stuck inside their ecosystems. Let’s take a closer look at what’s happening and what we can do about it.

 

The Stickiness of Single-Vendor Models

Probably the biggest reason SPs stay inside vendor ecosystems is just inertia. It’s the way SP networks have always worked, and it doesn’t require much effort to just keep doing things that way. It’s a lot more expensive, and a lot more restrictive, but it’s simpler.

Beyond that though, there are things like the proprietary “secret sauce.” As SPs work with a given vendor's equipment over the years, it’s common to find vendor-specific features that network teams grow to rely on that don’t exist or are not fully realized in open standards models. For example, a vendor may offer a planning tool with a slick interface for pre-provisioning services before they’re instantiated that your operations team likes. You may be sold on the benefits of going open, but if that vendor feature has come to play a big role in your operations, it can be tough to leave it behind. It’s a tradeoff, and you’re going to have to find a balance you’re comfortable with.

Finally, there’s just the fact that open standards and open source are very different from the way SPs have always operated. And it’s not a change that happens overnight. Committing to openness means learning new skills, working with open source and open standards communities, making decisions, and owning processes in different ways than you’re used to. It takes time to build those muscles.

 

Blurring the Lines Between Closed and Open

Another big factor keeping SPs locked in: “open” can mean different things in different contexts. As the push for openness grows, vendors have found lots of ways to proclaim their commitment to open standards, without, you know, actually implementing them.

In the past, vendors weren’t shy about pushing strictly closed systems. There was no way to get inside their equipment or open up their environment to third-party tools. If you wanted to use their products, you did it their way or you didn’t do it at all. Most vendors now recognize that won’t fly in today’s marketplace. But they’ve found plenty of space to exist between “closed” and “truly open:”

  • Kind of open: In what they’d like you to think is a major concession, some vendors now allow you to bring open source tools and standard interfaces to their equipment—but only via their proprietary EMS, which acts as a mediation layer between the open source control plane and the devices (see Ciena’s MCP management platform). In this way, they can claim to support open standards, while preventing them from ever directly controlling their equipment. Effectively, they’re saying, “Sure, you can use open standards and tools—just keep paying us licensing fees, and we’ll retain ultimate control over what you can do with your network.

 

  • Halfway open: Along the same lines, some vendors implement support for standard APIs, but only for the service API (for example, T-API). The device API remains closed and proprietary. This can provide some benefits for orchestrating services across domains and layers that are historically single-vendor (such as optical networks). But you still can’t directly control the equipment, so you’re still locked into their proprietary framework.

 

  • Pretend open: Another common tactic vendors use is to create their own quasi-standards. We described this in detail in our blog on Open Standards and Open Source. Basically, one or two vendors will work together to create a new specification, which they can now claim is an “industry standard.” Except they just skip over the part where any outside community audits it or enforces common structures across vendors. Unsurprisingly, these quasi-standards still manage to preserve those vendors’ proprietary mechanisms and margins.

Half-measures like these can be good PR for vendors, but they don’t do much for SPs looking to take back control over their networks. Even when a kind-of-open model lets you bring in open source tools, that proprietary mediation layer adds another layer of complexity to your environment. Worse, when SPs accept half-measures, vendors can continue avoiding truly open standards and interfaces. If the history of this industry has shown us anything, it’s that if you don’t hold vendors’ feet to the fire and force them to support a standard, they’ll never engage.

 

Demand Real Openness

We will ultimately get to open source networks; the benefits are just too great. When you can control any device in your network using the same standard API, life gets a lot simpler. Any application or system dealing with those devices (OSS, NMS, telemetry) can do things in the same way, without custom coding or jumping through vendor hoops. That simplicity is immediate—even before you start swapping out vendors. But you can’t get there using half-measures that let vendors keep device APIs locked down.

So, what can you do to try to get to the open future more quickly?

  • Keep your options open: Go ahead and use a solution with proprietary feature you like, as long as the vendor still allows for open interfaces, so you can bring open source tools into the mix. Expand your use of open standards and your involvement in open source communities, even if you’re still working under a proprietary strategy today.
  • Use an open source abstraction layer: In the future, you’ll be able to use open standards to control any device in your network. But in the meantime, you can use an open source controller like the Lumina SDN Controller to translate between proprietary vendor devices and the open source/open standards world. Yes, it’s still a mediation layer, but it’s an open one that you fully control. Here, the open source controller handles all the complexity associated with proprietary vendor models, so all your applications on top of it don’t have to worry about it.
  • Experiment with openness: Some operators (like Telstra) have been experimenting with open networks in parallel to more proprietary production systems. They’re building their open source muscles without introducing risk to critical revenues and services. Once they demonstrate that an open, standards-based solution works and delivers real value, switching over is far less intimidating. 

Ultimately, the most important thing you can do to break vendor lock-in—and keep doing, over and over again—is keep up the pressure. The open future is coming. But the more Service Providers demand real support for real standards, the more quickly vendors will fall in line.

Contact us today for a free consultation to support your digital transformation.


Related resources: