Have your cake and eat it too: the evolution of commercial open source

It's hard to imagine a world without open-source software. In the last few decades, open source has gone from fierce opposition from tech executives to being a mainstream category of software businesses. In this post, I dive into how commercial open source companies have had their cake (leveraged free software and community contributions) and eaten it too (built sustainable and viable businesses on top of free software).

Have your cake ...: the value of community

Successful commercial open-source strategies invest heavily in community. For creators and maintainers, opening up a project to community contributions means real-time feedback. You see this in the pull request and issues sections of any popular open-source repository. Maintainers know exactly what users think about the product and where they would like to see improvements. This real-time feedback is a low-cost way of discovering new user needs.

Another way to think about the value of open-source projects is as lead generation for a paid product. Every developer that uses an open-source repository is a candidate for an associated paid product. In this context, open-source maps to a freemium customer acquisition strategy.

... and eat it too: evolving monetization frameworks

Going from free and open-source to a paid product revolves around monetizing knowledge, add-ons or specific user segments. Let’s take a look at each of these in more detail.

Monetize knowledge

The prevailing pattern in the early days of open source was to give away the software for free and charge for services. Users paid for support, implementation, or training. Ultimately, users were paying not to rely on the kindness of strangers on the internet for bug fixes or answers to critical questions.

One of the best examples of the commercial support model is Red Hat. The core bet Red Hat made was that you could take a vanilla Linux-based operating system and fashion it for the enterprise. They shipped a Linux distribution that came with all the software system administrators needed. This included setup software for all kinds of corporate servers: web servers, mail servers & DNS servers. In addition, Red Hat focused on improving what was then a clunky developer experience. They shipped built-in convenience utilities and an easy-to-use package manager.

The bet paid off.  Red Hat was a convenient choice for enterprise IT managers and developers. The company's shares tripled when it opened on the stock market in 1999. In 2011 it became the first open-source company to cross over a billion in revenue.

Red Hat's success notwithstanding, this model poses several challenges.

First, it is hard to scale. In this model, your staff is the product. Scaling revenue means scaling developer or customer support resources at the same rate. You are trading staff time for money. As you bring on more customers, you have to bring on more staff. Consequently, the support model tends to have low margins.

Low margins equal low investment in R&D. This manifests in lower product velocity. When most of your staff is responding to bug requests and custom implementations, there are fewer resources available to build new features.

Monetize add-ons

With the rise of open-source infrastructure as a service companies, the prevailing monetization pattern shifted towards monetizing add-ons to an underlying open source project. Users buy addons for more features. The classic example of this model is Elastic. Elastic is known for the popular open-source ELK stack: Elasticsearch for, you guessed it, search. Logstash for data processing. Kibana for visualization. The company then adds a series of paid plug-ins such as cluster monitoring, alerting, and security.

This strategy tends to be a good fit for role agnostic infrastructure. That is, the product’s value is the same regardless of where a developer falls on the org chart. For example, both individual contributors and managers derive similar value from Elasticsearch.

This contrasts with products where the value prop changes as you go up the management chain. Here, monetizing specific user segments may be a better bet.

Monetize specific user segments

A growing approach in monetizing open source is to monetize specific user segments. This has become more common as open-source shifts to application software.  That is, software that has a user interface for an end-user. Here, it is easier to segment users into different personas. For example, individual contributors versus management (tech leads, engineering managers, CTOs). If a feature is being used by an individual contributor then it is free. If it is being used by someone in management, then it is paid.

This removes barriers to entry for individual contributors and accelerates adoption. The moment an individual contributor wants to use the project as part of a larger org, then it is monetized. A great example of this is Gitlab, whose CEO describes this model as buyer-based open core.

In Gitlab, anyone can have unlimited repositories and make pull requests against it. But, the moment a contributor wants to have a minimum number of approvers for a pull request, they must be on a paid version. The logic here is that a robust approval workflow implies governance from engineering leadership and serves as a natural transition point of value from the individual to the enterprise.

Conclusion

As open-source continues to be a popular acquisition channel for software companies, monetization strategies will evolve. In practice, there are not always clean lines between monetizing knowledge, add-ons, or specific user segments. Companies sometimes use these strategies in succession as they grow. Sometimes they use multiple at the same time to diversify revenue sources. What is most important is picking a strategy that aligns with users’ expectations of value.