Open source in telecom doesn’t have to be cool kids vs. suits
Veteran telecom journalist Carol Wilson explains why the best way forward for open source and software-development organizations is to work together and let each group do what it does best, while enabling timely sharing of information among all.
20 Sep 2018
Open source in telecom doesn’t have to be cool kids vs. suits
When open source first emerged as a significant part of the telecom industry's future – around the time that software-defined networking was emerging – there was a tendency to see open source communities as competitive threats to existing telecom software-development organizations (SDOs). The open source crowd were the cool kids, the coders in sandals and wrinkled shirts who held hackathons, ate pizza, and pushed Agile development and DevOps. The SDOs, meanwhile, wore suits and ties, sipped wine, met in conference rooms and sat around talking for years to get competing groups to reach consensus on paper.
Or so the perception went. Neither stereotype was ever entirely true. Many of the same companies that participated actively in SDOs also were engaged in open source, particularly as virtualization took hold. But as software began to consume the telecom world, more communications service providers (CSPs) began to see the open source as valuable for the speed it brought to their efforts to push technology forward without becoming vendor dependent.
With that shift, it became clear to the leadership of many SDOs that open source was not just here to stay but likely to play an increasingly significant role, because, as TM Forum's Ken Dilbeck notes, open source is “uniquely set up to facilitate this lightweight, attack-in-parallel, softwareization” of the telecom industry and its ecosystems. As telecom network operators try to solve difficult challenges such as orchestration of virtualized networks, open source processes represent a logical path to moving the industry forward together faster.
It's not surprising then, that in the last 18 months we've seen major initiatives on the part of SDOs to engage with open source efforts and acknowledgement by open source organizations such as the Linux Foundation that SDOs have a significant role to play as well. Notably, the TM Forum and MEF have collaborated on the Open Network Automation Project (ONAP), a Linux Foundation project. Other open source groups that have drawn on traditional SDO work include OpenDaylight, OPNFV and the Open Networking Foundation.
We've also seen the emergence of initiatives that are neither SDOs nor true open source efforts, including such industry trade groups as the Open Compute Project and the Telecom Infra Project. They represent another means of cross-industry information sharing and, in many cases, their work can be funneled into either SDOs or open source groups.
Working together and letting each group do what it does best, while enabling timely sharing of information among all groups, seems the logical path forward. Open source efforts are usually launched around specific problems or initiatives and launch with contributed seed code from a major advocate – think AT&T and ONAP or Akraino – but they can make use of SDO work such as common data models or open application program interfaces (APIs).
Conversely, SDOs can incorporate open source solutions as they address industry challenges that require interoperability and end-to-end service offerings that must traverse today's complex interwoven network infrastructures.
Going forward, any organization's success will be based on how relevant it remains to its membership, since it is the members who pay the freight for such entities to exist. And CSPs are tightly focused on solving problems, less so on who gets credit. That reality is one reason why I would expect to see greater cooperation between SDOs and open source groups on the real-world issues that continue to pose challenges to bringing new services and capabilities to market faster and more efficiently.
Ultimately the debate isn't about open source-versus SDO, it's about getting the fastest solutions to market faster in easily consumable fashion.
Or so the perception went. Neither stereotype was ever entirely true. Many of the same companies that participated actively in SDOs also were engaged in open source, particularly as virtualization took hold. But as software began to consume the telecom world, more communications service providers (CSPs) began to see the open source as valuable for the speed it brought to their efforts to push technology forward without becoming vendor dependent.
With that shift, it became clear to the leadership of many SDOs that open source was not just here to stay but likely to play an increasingly significant role, because, as TM Forum's Ken Dilbeck notes, open source is “uniquely set up to facilitate this lightweight, attack-in-parallel, softwareization” of the telecom industry and its ecosystems. As telecom network operators try to solve difficult challenges such as orchestration of virtualized networks, open source processes represent a logical path to moving the industry forward together faster.
It's not surprising then, that in the last 18 months we've seen major initiatives on the part of SDOs to engage with open source efforts and acknowledgement by open source organizations such as the Linux Foundation that SDOs have a significant role to play as well. Notably, the TM Forum and MEF have collaborated on the Open Network Automation Project (ONAP), a Linux Foundation project. Other open source groups that have drawn on traditional SDO work include OpenDaylight, OPNFV and the Open Networking Foundation.
We've also seen the emergence of initiatives that are neither SDOs nor true open source efforts, including such industry trade groups as the Open Compute Project and the Telecom Infra Project. They represent another means of cross-industry information sharing and, in many cases, their work can be funneled into either SDOs or open source groups.
Sharing is key
Working together and letting each group do what it does best, while enabling timely sharing of information among all groups, seems the logical path forward. Open source efforts are usually launched around specific problems or initiatives and launch with contributed seed code from a major advocate – think AT&T and ONAP or Akraino – but they can make use of SDO work such as common data models or open application program interfaces (APIs).
Conversely, SDOs can incorporate open source solutions as they address industry challenges that require interoperability and end-to-end service offerings that must traverse today's complex interwoven network infrastructures.
Going forward, any organization's success will be based on how relevant it remains to its membership, since it is the members who pay the freight for such entities to exist. And CSPs are tightly focused on solving problems, less so on who gets credit. That reality is one reason why I would expect to see greater cooperation between SDOs and open source groups on the real-world issues that continue to pose challenges to bringing new services and capabilities to market faster and more efficiently.
Ultimately the debate isn't about open source-versus SDO, it's about getting the fastest solutions to market faster in easily consumable fashion.