Open source and the next wave of telecom innovation
A conversation with Arpit Joshipura,
General Manager for Networking, Edge & IoT at the Linux Foundation
As part of our interview series exploring the four dimensions of openness driving telecom innovation, Nokia’s Solutions Lead for Cross-Portfolio Marketing, Stefan Kindt, spoke to Arpit Joshipura, General Manager, Networking, Edge and IoT Software at the Linux Foundation, and Jonne Soininen, Head of Open Source Initiatives at Nokia.
They reveal how open source software is changing the landscape for innovation in the telecom industry, and how vendors, integrators and CSPs can all harness it to their advantage.
General Manager, Networking + Edge/IoT, Linux Foundation
Head of Open Source Initiatives, Nokia
Solutions Lead, Cross Portfolio Marketing, Nokia
STEFAN KINDT: Arpit, could you give us a brief introduction to the Linux Foundation?
ARPIT JOSHIPURA: We’re the largest non-profit foundation that enables distributed innovation, by allowing the creation of open source software, open collaboration and open communities across major industries globally.
SK: There are lots of different opinions and frameworks out there around the concept of openness. What does it mean for you – both in a broader sense and in terms of activities in the telecom space?
AJ: The Linux Foundation is built on the word ‘open’ – starting from open collaboration and neutral governance, through to open source software, open interoperability and open testing. We host software projects through their entire lifecycle, from incubation all the way through our ecosystem partners providing market differentiation, innovation and support to end users.
SK: Can you give us an example where openness has driven innovation in the telecom space – maybe beyond what any single vendor could do?
AJ: A perfect example is ONAP, which started in 2017. It came together from a project in Asia led by China Mobile, and a project in the US and Europe led by AT&T, and it’s now the largest network automation platform that enables 5G for operators.
ONAP is about 10-15 million lines of code. Imagine a single vendor, or three or four, trying to complete the stack. It would have taken years. And it’s not differentiating for these vendors or integrators. It’s the plumbing layer - it’s lifecycle management, lifecycle modelling, start/stop/pause.
This innovation gets you three dimensions. One is speed. In less than three years we’re on the seventh release of ONAP, moving to cloud-native very quickly. Another is cost. R&D is shared by over 1,000 developers globally, so individual vendors only have to pay for the few engineers that work on it. And the third is faster time to revenue for operators, vendors and system integrators.
SK: What do you see as the main barriers to open-source collaboration – and how can they be overcome?
AJ: The biggest barrier in my mind is people. Organizational structures either help or hinder open collaboration. If you start with CSPs, there are usually three groups. There’s the CTO group, the network operations group and the R&D or future planning group. Unless they coordinate, there can be tension between the network operations group and the CTO team or future planning group.
We’ve seen that operators who bring those groups together, like AT&T, Orange and Deutsche Telekom, have been successful at taking advantage of open source. And CSPs that have not made the change have fallen significantly behind in grabbing market share. We have a stat: operators participating in Linux Foundation Networking and open source collaboration gain subscribers six times more than their competitors locally within the region.
JS: There also has to be a willingness to work together. We can all agree there’s a problem in the industry, but we also have to be willing to invest in solving it. It means lending out good developers to work on a community project, which is a big investment. If the timing isn’t right for everyone, or if they can more cost effectively buy the software, they’re less likely to work together.
SK: Looking at open source and open standards, how do they complement each other, in your view?
AJ: The telecommunications industry is built on standards. We’re probably the most standardized industry in the world. But prior to the last five years, it was always open source versus open standards. When we launched Linux Foundation Networking, we called on industry colleagues and standards bodies to embrace harmonization between open source and open standards.
The principle behind that is very simple. If a standard exists, code it. If it doesn’t exist, code it and upstream it to the standards. This way, when you deploy software from Linux Foundation ecosystems, you can always guarantee that it’s standards-based and standards-compliant.
The principle is simple, but we encountered a lot of challenges in terms of licensing, in terms of community contributions back into the code, and signing agreements with the top standards bodies. But we’ve done it. If you look at ETSI, 3GPP, GSMA, Open RAN, TMS, TM Forum, we are actively collaborating. There’s no boundary in our communities of implementing standards-based interfaces. In fact, the latest release of ONAP, or OpenDaylight, or OPNFV, all of the discussions start from the standards and end in deployment and implementation. That would have been a big issue five years ago, but today, that’s the way business is being done.
JS: Standards do have a very special meaning in this industry, and they’re why we have a long history of working together. From that point of view, open source is just another collaboration tool.
I can imagine that in other industries it’s much harder for customers and vendors – especially competing vendors – to work together. So open source has been relatively easy for us to learn because it’s an extension of how we’ve worked previously.
SK: In terms of community contributions – would you say upstream should come first, or does it depend on the product or the solution area?
AJ: The principle of open source, which I think everybody in the community has understood, is not to fork any open source software. This is a key problem that other communities have faced. Once you fork, you have to maintain the patches. It becomes a separate initiative, and it’s no longer relevant.
In the early days of OpenStack and others, this caused some major issues. But now, if you look at the Linux kernel, or Kubernetes, or ONAP, these major frameworks have a no-fork policy. Upstream first, pull it down, make changes in an interdependency manner. That’s absolutely the right model.
SK: Let’s look at open interfaces. Why are they important for innovation?
JS: APIs are critical for allowing third party innovation on top of your product that you couldn’t, as a vendor, necessarily invent yourself. With the right API architecture, third parties can build new functionality that creates a lot of value, and that’s very powerful.
AJ: Open interfaces can be viewed at multiple layers. If you take the standard telecom architecture, you have access, you have edge and you have the core. We believe each of these areas should have a set of open source projects that enable interfaces to work together across access, edge and core.
For example, on the access side we host projects for software for Open RAN, where a set of interfaces are defined. They’re defined as specifications by the O-RAN Alliance. They’re implemented in the software through the Linux Foundation. And the interfaces are tested and integrated both in the edge, through a project we host called Akraino, and in the core, through ONAP.
So interfaces are critical for an end-to-end ecosystem, whether it’s 5G deployments, or 5G network slicing, all the way from core to edge to access. And within those, there are subsystems that also need open interfaces, especially with disaggregation and SDN. In short, open interfaces are a must to move all dimensions of open source forward.
SK: Let’s look at another dimension of openness – open culture. What are the critical factors for creating an open culture and mindset in an organization?
AJ: The most important factor is the individual who is participating in the innovation. That person has a responsibility to be collaborative, to use vocabulary that fosters collaboration, to listen more than speak, to follow a neutral governance – so that when they’re working with their peers they aren’t working for their employer but for the shared community.
That mindset is the most important cultural factor for creating this ecosystem. It also makes them very marketable, because that skill can be easily transferred into any of their peers or end users.
SK: Do any of the four dimensions stand out for you, from the point of view of driving innovation?
AJ: I think all four dimensions need to be driven equally. However, there might be a phase of a project or a phase of a technology or a phase of an industry where one might be more important.
For example, in the early stages of project formation, people collaboration is extremely important. In the late stages of the deployment, interoperability and standardization and the kind of communities would be more important. In the middle stages, definition of interfaces may be more important.
But at the end of the day they are four sides of the same coin – if we can say a coin has four sides!
SK: Lastly, on a scale from 1-10, how relevant would you rate openness for driving innovation, especially as we move further into 5G and IoT over the next five years?
AJ: I would say 8. The reason it’s not 10 is that there are still pieces of the puzzle, specifically in the RAN, that are still working towards becoming open. On the IoT side too there are pieces that are not yet done in terms of messaging interfaces and physical interfaces.
But it’s moving towards 10 very quickly, and if you look at things like Linux and ONAP, they’ve already made a massive difference in terms of relevance. So we believe that we will have a huge community and move innovation forward faster if we all collaborate in an open way.
SK: Thank you Arpit and Jonne for your time and your insights.