Part 2: Deciding on the Right Open Source Business Model

Welcome to Part 2 of our series on Making Money from Open Source. This post focuses on open source business models, and how project creators might think about the revenue and company potential for their projects.

For Part 1 on going from Project-Market Fit to Product-Market Fit, click here.

A Brief History of Open Source Business Models

To understand the evolution of open source business models, one should start with Red Hat. Red Hat was founded in 1993 (pre-cloud) and sold open source operating system, Linux, as packaged software. Red Hat’s founders weren’t involved in the creation of Linux, but they saw demand for the project and the potential to package and sell it.

What “Red Hat Linux” offered was much more limited compared to what open source companies offer today — and a good deal of their early success can be tied to market timing. When Red Hat launched, internet speeds were not what they are today, so downloading Linux from the internet, even though it was free, seemed like a worse option versus getting a packaged version that also came with instructions and customer support. They also used their brand, toting trust and reliability, to convince users to buy Red Hat over free Linux. In fact, Red Hat modeled the company after commodity products that used their brand to sell an otherwise free product.

From Red Hat founder Bob Young, “All leading companies selling commodity products, including bottled water (Perrier or Evian), the soap business (Tide), or the tomato paste business (Heinz), base their marketing strategies on building strong brands. These brands must stand for quality, consistency, and reliability. We saw something in the brand management of these commodity products that we thought we could emulate.”

While Red Hat benefited from Linux’s community-based development, it had none of the distribution benefits that open source companies do today. What they sold was packaged Linux software in retail stores with new releases coming every 6 months. Despite Red Hat becoming a wildly successful company generating over $1B in annual revenue by 2012, its success is in large part due to business model savvy, luck, and timing, and is unlikely to be repeated by open source companies today. In a cloud-first world where new software is shipped at a rapid pace, packaging and selling someone else’s project is not a recipe for sustained financial success.

Today, successful open source companies take different approaches to generating revenue. The two models most commonly used are Open Core and Cloud Hosting.

Choosing Open Core, Cloud Hosting, or Both

Open Core means having an open source “main” application with additional paid “side” features. Open Core is a popular model for open source companies to start with since it offers product defensibility and many possible monetization paths. For example, GitLab provides premium features for its paid plans including security testing, incident management, and team features such as approvals.

Cloud Hosting means offering a paid, fully managed cloud-based experience for the open source project. Compared with Open Core, Cloud Hosting has less defensibility since there is no proprietary product, but it can still be a good business model. For example, open source infrastructure workflow company Temporal generates revenue through Temporal Cloud, which provides a fully managed experience for applications built with open source Temporal (hear more from CEO Maxim Fateev on this on the Open Source Startup Podcast).

As companies scale, they often use both Open Core and Cloud Hosting models to extend their monetization potential. For example, HashiCorp generates revenue from Terraform through an Open Core model by charging for features such as team management, SSO, drift detection, and audit logs. They also monetize through their Terraform Cloud hosting service.

So, how do you decide which business model(s) to use? An important step is understanding who is in your community. For instance, if your community is mostly larger enterprises, you may consider taking an Open Core approach that generates revenue from features such as scale and security. If your community is further down market, you may also use an Open Core approach but add paid features with broader appeal such as team management and integrations. You may also offer a Cloud Hosted version to down-market users as they have fewer resources to manage the project themselves.

Some ways to understand the user profiles in your community include having an “introductions” channel in your project’s Slack or Discord, encouraging users to sign up with a work email, or using a tool like Scarf which provides analytics into your open source user base.

Developer advocates can also be helpful in understanding who’s in your community, and their needs. A good developer advocate is technical enough to relate to users and has a ton of empathy and great communication skills. They act as a liaison between the community and the company, helping founders and leadership navigate decisions and communication around monetization.

Getting Business Models Right

The most important part of creating a revenue strategy is to set expectations with the community. As a project owner, maintaining trust is incredibly important, and can break if users don’t understand upfront what functionality will eventually require payment.

Having misalignment with the open source community on what will eventually be paid functionality can create big problems for companies. For example, at time series data company InfluxData, they open sourced features that they later charged for, and it upset the community. On the Open Source Startup Podcast, Influx Co-Founder Todd Persen said, “we ended up pulling out clustering (and) pulling out HA (high availability) to make the Influx enterprise product…through that, we had a lot of damage done in the open source developer community.”

Open sourcing features should be treated as a one-way door. Once the expectation is set with the community that certain functionality is free, making it paid later will break trust. Once community trust is broken, it can be hard — sometimes impossible — to rebuild. Thinking through business models upfront, and being clear with the community what will and will not be charged for, can help open source companies avoid potentially fatal errors.

At Cowboy, we spend a lot of time with our portfolio companies helping with their early GTM strategies. For open source companies, determining the right business model is a big decision that we spend a lot of time thinking through.