The Telecom Industry Has Moved to Open Source. But What is Open Source?

In a blog titled "The Telecom Industry Has Moved to Open Source", Arpit Joshipura, GM Networking & Orchestration + Edge/IOT at Linux Foundation, is quoted as saying, "We have seen a 140-year-old telecom industry move from proprietary and legacy technologies to open source technologies with LF Networking.” I couldn't agree more. As with enterprises, open source adoption will increase within Communication Service Providers (CSPs). And it will increase significantly.

At the same time, there is massive confusion amongst CSPs in terms of what open source is, and how they should consume it. I've heard statements such as, "I'm going to wait until project XYZ is a stable product" or "why should I pay for open source software support, the community will provide support." The implication here is that the community is working on full productization and/or providing L1-3 support. Here are some of my thoughts on open source:

What is Open Source?

Isn't open source code developed in an open repo using an open source license? Yes, but this is a very limited understanding. Just having open access to the code does not make it usable. True open source means that all aspects code development needs to be open:

Code development
Test suites
Continuous Integration (CI) pipeline
Code review process/disposition of reviews
Integration labs
Backlog list (roadmap features/bugs) and process of deciding which items make it in a particular release
Meetings
Wiki pages/documentation
Interop testing
Use case discussions/demos

Linux Foundation projects have governance in place to make all these aspects open.

What Open Source is Not?

There are two major misconceptions — community (as opposed to a commercial distro) open source is a product and open source is free. These two points are obviously inter-related. An open source community's charter is to develop code. It's not to develop and support a fully finished product. For this reason, the open source community typically works on interesting technical problems. It doesn't do the laborious work of building a product. Unfortunately, a lot of productization in terms of stability, scalability, security, performance, documentation, manageability, installation, lifecycle management and monitoring is not the most exciting work. This same point also explains why open source is not free. Either the end user or a commercial distribution vendor has to do the work of creating a finished product from the open source code.

The above picture is analogous to the gap between open source and a commercial product.

Why Open Source?

If open source is not free and it is not a finished product, then why bother using it? Should't one keep using proprietary products? Not really. There are numerous very good reasons to embrace open source. Open source:

Supplements/replaces standards: Standards often move very slowly. Or they are not grounded in reality. Or they leave things open to interpretation. Open source projects can supplement standards with a reference implementation and in some cases replace them entirely.
Results in faster innovation: Since programmers from a diverse backgrounds work on open source projects, they can typically innovate faster. In a project such as the Linux Foundation ONAP project, you have a diversity of programmers from classic telco to cloud technologies to hardware to security to OSS/BSS backgrounds. This means ONAP can innovate faster than any proprietary product.
Roadmap influence: Traditionally an end user has to talk to a sales person who talks to a product manager who talks to an architect who talks to the engineers. Anybody remember the game of telephone? By the time the engineer gets the requirement, it's hardly recognizable. In open source, end users can influence the project directly.
Reduced lock-in: A healthy open source project (see next section) typically has multiple commercial vendors. This reduces, if not eliminates, vendor lock-in. So even though open source is not free, this particular point might result in open source being less expensive than proprietary.
Transparency: If an open source project is truly open as per the section above, there is full transparency in terms of what the community is doing, and more importantly how decisions are being made.

What is a Healthy Open Source Project?

A healthy open source, in my view, has five attributes:

Truly open: A healthy open source project, see above, is truly open in all aspects.
Multiple contributors: An indication of a healthy project is that no one company dominates contributions. The more uniform the distribution of contributions, the better off is the community.
Active end-user participation: This is a critical point. Ideally end-users should be contributing code. But this need not always be the case; end-users can contribute in other ways, e.g. by defining requirements, participating in use cases, providing customer case studies etc.
Commercial activity: A project may do well for a while without commercial activity (commercial activity may be defined as both vendors generating revenue and end-users putting the project in production to generate value), especially if it is early in the project's life. However, commercial activity is the oxygen that sustains a project. Without commercial activity, it is very difficult to see how a project can survive long term.
Ecosystem: Related to the previous point, a healthy open source project has an ecosystem of interoperating products (proprietary or open source). Again, early in a project's life, the ecosystem may be small.

Let's take ONAP as a case study. By being a part of Linux Foundation, ONAP is automatically truly open.

Second, the distribution of contributions is quite uniform (contributions from Dec-26 2018 to Mar-26 2019).

Third, ONAP boasts end user participation from AT&T, China Mobile, Orange, Bell Canada, Vodafone, Verizon, Turk Telecom, Reliance, China Telecom and others. Some contribute code. Others participate in use case/blueprint development. And yet others contribute by providing requirements. Finally, end user customer success stories are just starting to emerge.

Fourth, the ONAP commercial activity is early. We (Aarna) provide a development distribution (as of March 2019; if you are reading this in the future, we should have production distribution), training and some point professional services. SIs such as Tech Mahindra, Accenture and others provide a much broader set of ONAP professional services. Orange has put parts of ONAP in production and is mandating ONAP compliance in their RFPs.

For the last point, ONAP is still early in terms of an ecosystem. The upcoming OVP VNF Validation program should expand the ecosystem significantly. The ecosystem of interoperating cloud, SDN controller and OSS/BSS systems is also early and growing.

While the last 2 points are a bit weak, it is still early in the life of ONAP, so we can hazard a guess that ONAP is going to be a healthy project. You can use the same evaluation technique on other projects too.

Open Source Consumption Models

Given the above background, there are three ways to consume open source projects. Two lead to success and one leads to failure.

Successful Model#1 Do-it-yourself (DIY): The DIY model requires that an end user support themselves with the open source technology. This requires architecture, engineering, testing and support teams. A meaningful open source project can easily require 20-30 full time people. This can be very expensive. Also, the end user has to have the ability to retain these individuals. There are many stories where end users spun up an internal OpenStack team, only to lose the staff once the team members had completed their actual goal — which was learning OpenStack and improving their resume appeal. Given the hassle and cost, an end user needs to determine whether a DIY model is a core differentiator for them. End users successful with a DIY technique are Google for Kubernetes and Amazon for Hadoop.

Successful Model#2 (Commercial distribution): This model requires that an end user work with a commercial distribution vendor for an open source project. The commercial vendor provides a finished product and L1-3 support. This is normally a safe default path for most end users.

Failed Model#1 (DIY without a long-term internal team): I can't tell you how many end users mistakenly believe that an open source project is a free finished product (reminds me of the saying — if something is too good to be true, it probably is). Even if the customer can do a successful PoCs using this technique, it is a doomed model once you go into production. There are numerous anecdotes of how a bunch of smart architects and engineers got OpenStack to run in a lab and then put it into production. 6 months later, either the engineers were gone. Or they were around but didn't know how to upgrade. Or the configuration changes got so complex that nobody could support the deployment after a year. This is a horrible lose-lose model. The end user directly experiences a negative business impact with very unhappy customers. And the open source project unfairly gets a bad name.

In short, open source is on a meteoric rise amongst CSPs. And I hope CSPs can embrace open source with their eyes wide open.

Needless to say, if you are looking for a commercial ONAP vendor, please contact us.