Open Source Business Model Definition

The Secrets of Successful Open Source Business Models

Finding the right model for your open-source startup

I've been spending a good part of last year meeting the founders of open source projects, ranging from network infrastructure and databases to desktop applications and browser extensions. Yet across this huge variety of projects I discovered founders asking the same fundamental question:

How do I build a business around my open-source project?

I'm lucky to be able to come at this question having seen many sides of the open source world. Not only from my time in venture capital at Blossom Capital and Index Ventures (both active investors in open source startups), but also as an open source contributor, both to small independent projects and larger ones under the auspices of organisations like the FSF and the Apache Foundation. I was also fortunate to have co-chaired the first board of trustee elections for the Wikimedia foundation.

Picking the right model is critical not only for the commercial viability of a project but also to ensure the support of the community. In the worst-cases communities and projects have forked as a result of commercial decisions and the resulting governance debates.

While there are many models that work to support small teams, the driver for founders is often to build substantial companies that can help their open source projects continue to grow and establish themselves as the long-term leaders in their space. So I've focused here on models that can enable companies to reach significant scale ($100m+ in annual revenue) and put them on the route to become stand-alone public companies.

Over the last few decades we've seen the open source world converge to four fundamental open source business models that can achieve this: open-core, professional services, hosting, and marketplace.

Open-Core

In the late 90s and early 2000s, the open-core model was viewed with suspicion, coming in the Microsoft era of "embrace extend extinguish", where developers worried that companies building commercial products on-top of open source cores would seek to weaken the open source product to make the commercial offering more attractive.

However, over the last decade this has changed significantly, as we've seen countless commercial open-source companies prove to be good stewards of their open-source projects, choosing to build products that extend their open-core without directly conflicting with them, in some case placing the open-source project governance under the auspices of non-profit foundations such as the Apache Foundation.

We're starting to see design patterns emerge for open-core companies, where their commercial offering complement rather than conflict with the open-core. These include:

- Ease-of-use pattern: SaaS, UX, Collaboration tools
- Enterprise pattern: Scalability, Security, Management and Integrations
- Solutions pattern: Use-case specific functionality

What seems to drive these choices are two factors (1) functionality that is valuable to enterprise users and (2) that is unlikely to be contributed by the community and be on the roadmap for the open-core.

It is important for the community to not feel that essential functionality is being held back from the core product. For most successful open-core companies their customers represent only a small percentage of their overall users. Ensuring the success of the open source product is key to the success of the commercial offering.

Open-core is now the dominant model for recent open source success stories, including the likes of Confluent, Elastic, and Github.

Professional Services (Proserv)

Early open-source models often built on professional services, with companies paying for support and consultancy. While a number of companies have got to scale with this model, it has not been without significant challenges.

Services revenue is often highly-unpredictable and requires significant scaling of head-count which can leaves companies exposed when revenues shift. The margins with professional services are also much thinner than those for product-based companies.

Red Hat's margin on services last year was 31% compared to 93% on their subscriptions. This means to hire an additional core developer, Red Hat has to make 3x the revenue from consulting as they do from subscriptions. This huge difference in margins has meant that consulting based open-source businesses have typically been consultant-heavy with limited resources to spend on developing their core open source product.

It's worth noting that Red Hat's subscription business started as primarily a "support subscription" but evolved into a product offering over time as companies like IBM started to undercut Red Hat for support services (IBM has since acquired Red Hat).

While there are a few companies like Hortonworks (pre-Cloudera acquisition) that still have significant revenue via the pure-support subscription model, support is now something that's typically bundled with additional product offerings due to the lack of defensibility.

The public market has similarly viewed services based companies negatively. Services companies typically trade at 1x-3x their revenue vs product-based companies which frequently trade at 10x+.

Hosting

In the last decade hosting has become a common offering from open source companies, especially in the data space, enabling end-users to use infrastructure components in a similar way to SaaS offerings without having to be concerned with the operational overhead of managing the infrastructure.

While public open-source companies have generally avoided disclosing margins explicitly for their hosted services, a back-of-the-envelope calculation suggests MongoDB's cloud business operates at ~65% and Elastic's at ~40%. This places it above services margin but lower than the typical product margin.

The economics of hosting are driven on the upside by willingness to pay, if the price is significantly higher than the cost of the underlying infrastructure then companies will choose to host for themselves, this is especially true for larger customers who already have sophisticated in-house devops teams.

In recent years cloud hosting providers, most notably AWS have started to offer managed hosting solutions for common open source packages, further squeezing the margins for open source companies. This resulted in a number of open-source products such as Redis and MongoDB changing their licences to prevent such competition from cloud vendors.

The other strategy, chosen by companies such Confluent and Elastic, has been to exclusively offer features in their hosted services that aren't available in the open-core, creating a blended hosting/open-core model.

While we're still early in seeing how this plays out, the later strategy is likely a natural extension for companies already building on open-core, especially where licence changes may be controversial among users.

It's also worth noting that while hosting is often a significant ($100m+) revenue stream for these businesses, it's often the secondary revenue generator rather than the primary.

For those open-source businesses where hosting is the primary offering, it's normally combined with significant SaaS or infrastructure offerings that go significantly beyond the open-source core, with good examples being GitHub and WPEngine.

Marketplaces

While often overlooked, the largest commercial success story in open source is Android. While Google doesn't breakout revenue and margin from the Play store in their annual financial reports, they're likely to be higher than those of Red Hat which previously held the title.

Mozilla similarly generates the bulk of their $500m annual revenue by providing lead generation to search engines.

While it's still a relatively rare model, being an intermediary between different parties that interact with your product is a model that open source startups are increasingly exploring, and we're likely to see a number of additional open source companies built on this model over the next decade.

How to pick the right model?

In practice companies often end up blending a combination of the models.

The most common pattern for successful open source companies today is to have an open-core product combined with hosting and services as secondary and tertiary revenue streams. If this combination works for your product then it could well be a good choice, but it requires a lot of thought around how you make a clear separation between the commercial and open-source offering.

In some cases none of these models might be suitable, and you might need to innovate a unique commercial model for what you're building. You shouldn't be afraid the explore alternatives, and use the above as a framework for evaluating how well a model may scale.

Beyond being a model that can enable a company to reach scale, it's key that the model chosen is one that is right for the nature of the product, and equally importantly the goals and desires of the founders and the community more generally.

If you're thinking about commercialising your open source project I'd be more than happy to chat and share my thoughts on what might work effectively for you. You can reach me at imran@blossomcap.com or on twitter @imranghory .

Open Source Business Model Definition

Source: https://medium.com/blossom-capital/successful-open-source-business-models-2709e831e38a

Share this post