In our eBook on “overlooked factors in 5G rollouts”, one major item we cited was the importance of open source software. We offered a high-level overview: why service providers (SPs) are turning to open source projects, wherein the network stack those projects can play a role, what they mean for RFPs. We didn’t spend as much time, however, on the broader context for open source software: the industry-wide push for open standards.
In recent years, SPs have been pushing their traditional vendors to support industry-wide standards for open protocols and interoperable networks, and vendors like to claim they’re working to deliver them. It’s within the various open source projects, however (especially the big ones like OpenDaylight, or ODL), where the rubber meets the road. These projects function as the mechanism by which SPs can keep their vendors honest. And, if you want your future 5G network to be open and flexible, instead of locked into a vendor’s proprietary mechanisms, innovation, and pricing, you should be joining the open source club.
The Open Source-to-Open-Standards Continuum
Let’s start with the basics: most SPs don’t get into open source software because they think it will save them tons of money. Converting to open source projects never saved anyone tons of money right away. Open standards, however, absolutely have saved SPs money by inviting competition among equipment vendors, and reduced IT/OSS/BSS/SA teams’ needs to connect to every proprietary interface. When your network is built with open standards and protocols, and you can basically mix and match devices from any vendor, your costs will drop. And if there’s one thing SPs need as they contemplate the price tag for 5G overhauls, it’s to insert some good old-fashioned competition into the mix.
So, how do you get to open standards? SPs have to hold vendors’ “feet to the fire” and force them to support these standard protocols via standard interfaces. The best way to do that is through open source software developed in open communities. Historically, community-based open software projects, open platforms, and open protocols are the only thing that’s gotten vendors to reluctantly embrace standards. It’s how we dragged the major network vendors (albeit kicking and screaming) to things like NETCONF and YANG – actual feature-complete and syntax-validated, production-deployable versions of it. If vendors didn’t have to deal with open source communities testing their implementations, validating that they work the way they’re supposed to, we wouldn’t have anything close to the widespread vendor support that exists today for NETCONF and YANG.
Standards and Quasi-Standards
What would we have instead? Lots of quasi-agreements that vendors like to call industry standards. Two or three leading vendors will, for example, draft a specification developed under a joint master agreement (and they’ll be sure to tell you how much they’re spending on it). They’ll claim multivendor commonality, so it’s a de facto “industry standard”—except that no outside community is actually auditing it or holding vendors to it. Somehow, the “standard” still manages to preserve those vendors’ proprietary mechanisms and margins. And of course, no standards body participated, no one can actually enforce common structures across vendors, no one can prevent the vendors from making changes, and no one will be able to support the “standard” if they decide to defund it.
Take Openconfig, which is a pretty comprehensive set of open standards for Layer-2/Layer-3 networking—and is rapidly gaining in practical, deployable vendor support. Contrast that with quasi-standards like OpenROADM, GFAST, TR-303 and TR-69, which only partially cover a deployable solution. Or, return to NETCONF and YANG. Some of the largest IP network equipment vendors (whom we won’t name here) claimed to support them since inception, but in the last three years, these vendors completely refactored their YANG model structures. Why? Because the major SPs demanded that their implementations fully comply, that 100% of their configurations work via NETCONF (instead of just a subset), and that everything be auditable by the ODL community. Today, lo and behold, these same vendors have NETCONF/YANG implementations that actually work in real-world production multi-vendor networks. That’s not an accident. That’s “open standards implemented via open source software.”
The largest SPs are now making the same kinds of demands to vendors for all their use cases across the 5G stack, including the 5G RAN edge. They’re demanding actual industry standards, not “agreements.” And they’re telling vendors that, if they want to do one of these agreements, then they need to take the next step and submit it as a draft to one of the standards bodies. It’s that insistence and only that insistence—enforced via open source software and communities—that compels vendors to implement non-proprietary functions that actually work. As an example, the early-adopter SPs of NETCONF and YANG have also realized even more cost-savings by pushing new vendors in new edge environments to simply reuse these standards, which in turn makes the SP able to immediately onboard these new standards-compliant vendors.
It’s Time to Get Involved
So, how should you be participating in open standards and the open source world? It’s different for every project, though as a rule, it’s easier to get involved in open source communities than standards bodywork. Working with projects under the Linux Foundation, for example, is relatively simple and inexpensive. You just need some in-house expertise—developers who have a basic sense of how to code in the codebase of those projects and how to use those use cases. After that, it’s just a matter of having the developers start attending project meetings, and asking how they can contribute. Most project teams have onboarding “HOWTO” docs to make this process nearly instantaneous.
For larger SPs, it’s a good investment to bring in full-time staff to work with open source software and communities. But even smaller service providers can get in the game. You can still benefit from consuming open source code; you don’t have to be constantly contributing to those communities (although the benefits are obviously higher if you do). You can also contribute your own subject matter expertise in operations, even if those experts aren’t software developers. And, when it comes to actual open source development—and the nuts-and-bolts work of checking your vendors’ implementations and holding their feet to the fire—you can outsource that effort to a partner who is an expert in those areas—a partner like Lumina.
When you get involved in open software and communities, you’re taking concrete steps to move the industry towards true openness and interoperability. You’re ensuring that your vendors will actually comply with standards and implement them in a way that everyone can see and debate and audit, rather than the vendors slapping more letters on their slides and claiming support. Indeed, if the history of this industry teaches us anything, it’s that efforts like these are the only way to make proprietary vendors implement standards that are actually open, and that actually work.