If you are curious about the business of open source software, I would highly recommend Peter Levine and Jennifer Li's blog titled, "Open Source: From Community to Commercialization." This exceptional blog, that uses the "As Software Eats the World, Open Source Eats Software" line, covers a number of topics ranging from growth of open source software in both revenue and across verticals, the virtuous cycle of open source, business success KPIs, business models, and finally open source go-to-market.

I am going to attempt to evaluate the ONAP project across the above metrics. ONAP, for those new to it, is a Linux Foundation Networking open source project that provides fully automated orchestration, monitoring, and lifecycle management of NFV, SDN, and edge computing services.

At least a quick scan of Levine's and Li's blog will be useful to get some context around the rest of my blog.

Open Source Renaissance

This one should apply to ONAP with ease. There is every reason to believe that open source will impact 5G and edge computing in the same way it has impacted other industries. With analysts such as Chetan Sharma predicting that over the first 10 years in their lifecycle, the edge computing economy will be more than 4x bigger than the cloud economy, the prospects for open source software in this segment are promising.

The Virtuous Cycle of Open Source

As 5G and edge computing disaggregate what has traditionally been a vertically integrated hardware and software solution, traditional benefits of open source such as no-vendor lock-in, the ability to influence the roadmap, rapid innovation, transparency, improved security etc.  come into play. ONAP brings with it a couple more advantages in the areas of collaboration with 3rd party standards bodies/open source projects and streamlining interop testing. On the first point, organizations such as ETSI, TM Forum, MEF, 3GPP, CNCF are using ONAP as a de-facto project to prove out their standards or open source efforts. On the second point, the industry simply does not have the resources to do N orchestration vendors x M Workload vendor interop testing. ONAP with its community driven compliance and validation testing of VNFs, will become the gold standard in interop test verification. In short, the combination of traditional open source benefits and a couple of unique ONAP-specific ones, should unlock the virtuous cycle of open source for ONAP.

Business Success

Levine and Li talk about three stages of business success: project-community fit, product-market fit, and value-market fit. Let me first provide my assessment of ONAP across these three stages and then my reasons for the assessment:

  • Project-community fit: Proven
  • Product-market fit: In-process
  • Value-market fit: Not proven but promising

Project-Community Fit

If we look at project-community fit for ONAP, over the last 90 days, we see:

  • 26 contributing organizations
  • 30 sub-projects

The contributor growth since the inception of the project is as per the below chart. The month-to-month varies a lot, so I think the 6 month or 180 day moving average is better (source onap.biterg.io), and overall in the right direction.

Product-Market Fit

The fact that users such as AT&T and China Mobile were founders of the project shows that ONAP solves a real problem. With the latest ONAP Dublin release, the user activity looks like follows:

This is all promising, but I don't think we have yet seen the one solid use case where users are tripping over each other to get to ONAP. Perhaps 5G and edge computing might be it? For this reason, I'm leaning towards saying product-market fit is in-process.

Value-Market Fit

There are two questions that come to mind: 1) Is the project inherently amenable to a value-market fit? And 2) Has that value-market fit been demonstrated as of now?

The first question is interesting. As Levine and Li point out, if the project is too awesome, there isn't an opportunity to create much value-market fit. Docker comes to mind. So the project should inherently have some rough edges that require vendors. ONAP fits in this category. In fact, if anything vendors will have to do some serious heavy lifting in terms of ONAP lifecycle management and hardening.

Having established this point, the second question is whether there is value-market fit today. Based on the ONAP product revenue, I would say not yet. Other than us (Aarna.ml), I am not aware of a 100% open source pure-play distribution. However, as per the Dublin announcement, there is some level of commercial activity around ONAP at Accenture, Amdocs, Boco, CommScope, ENEA, Ericsson, Fujitsu, Huawei, IBM, Netsia, Nokia, Tech Mahindra, Samsung, Wipro, and ZTE. Many of the bigger companies are obviously dabbling; looking to see which way the wind blows. The only burn-your-ships-a-la-vikings company is Aarna.ml, where we will live and die solely based on the success or failure of ONAP.

Business Models

I expect 5 business models for ONAP:

  1. SaaS: ONAP could be installed in a public cloud to manage 5G/edge and other workloads. This could be attractive for smaller customers.
  2. Managed ONAP: This is between a software sale and SaaS, where ONAP could be installed on-prem, but managed by a vendor.
  3. Open-core: This is a perhaps going to be the most popular ONAP business model. In fact, we at Aarna are pursuing this model at this time. We will provide support for the ONAP platform itself and provide proprietary apps, artifacts, and dashboards on top specific to a use-case. Our proprietary add-on is called AarnaStream™.
  4. Services: ONAP will need a ton of professional services. We expect large SIs to provide these services.
  5. Training: This is another standard business model. In fact, Aarna is the #1 ONAP training provider.

Open Source Types by Buyer

If there was one embellishment I might make to an otherwise amazing blog by Levine and Li, that is to categorize open source projects by the buyer persona, more specifically the champion.

I think the champion can be classified into three categories:

  1. Individual champion: Take Postman for example. It is typically brought into the organization by individuals.
  2. Team leader champion:  Jenkins for example. It is difficult to try this out individually, but a team can definitely evaluate Jenkins and bring it in.
  3. Organization leader champion: For good or bad, ONAP fits here. Even the evaluation of ONAP has to be driven at high level by someone who has authority across multiple teams.

How an open source project is championed in an organization, in my view, affects the way the business success evolves:

What do you think? I'd love to hear your feedback.