Inside Open Source #5
All things Open Source: Interesting reads, startup news, trivia and views from Europe and beyond
Welcome to issue #5 of the Inside Open Source Newsletter
Every month I write about interesting developments in the European Open Source ecosystem and related topics that I come across. Check out the June issue below and subscribe if you like what you read :)
This month’s topics:
🏢Open Source Program Offices
🎯Overview of Open Source business models
💭Thoughts from the Inside
“Empowerment of individuals is a key part of what makes open source work, since in the end, innovations tend to come from small groups, not from large, structured efforts.”
Tim O’Reilly - founder of O’Reilly Media and popularised the terms “open source” (vs “free software”) and “Web 2.0”
🏢What is an Open Source Program Office (OSPO)?
Nowadays, Open Source is a critical component of just about every modern software stack — from databases to cloud security — and a recent report from Synopsys concluded that 98% of codebases contain at least some Open Source code.
To manage all this complexity from an organizational perspective, OSPOs have become an integral part of businesses ranging from tech titans like Google to venture capital-backed startups.
The Linux Foundation defines an OSPO as “a central Open Source program office is a designated place where open source is supported, nurtured, shared, explained, and grown inside a company. With such an office in place, businesses can establish and execute on their Open Source strategies in clear terms, giving their leaders, developers, marketers, and other staff the tools they need to make open source a success within their operations.”
The responsibilities of a program office include:
Clearly communicating the Open Source strategy within and outside the company
Owning and overseeing the execution of the strategy
Facilitating the effective use of Open Source in commercial products and services
Ensuring high-quality and frequent releases of code to Open Source communities
Engaging with developer communities and seeing that the company contributes back to other projects effectively
Fostering an Open Source culture within an organization
Maintaining Open Source license compliance reviews and oversight
But OSPOs are not just interesting for large tech enterprise, as Oskari Saarenmaa, CEO at Aiven points out in a recent interview: “Open source is at the heart of what Aiven offers, and it is in our collective interest to develop Open Source technologies and ensure that open source remains truly open. As the company grows, staying connected to open source communities is more and more important, and we want to make sure there’s a team and function at the company that coordinates our efforts, moving our contributions from occasional to continuous and predictable. This is why we’re now launching the Open Source program office.”
📖You can find more resources on the topic here, here, and here 🤓
🎯Overview of Open Source business models
When you take a look at the most successful commercial Open Source companies (check out the COSS index for a nice overview), one can observe several dominant business models.
Professional Services (“Proserv”)
Most people in the industry would call the service & support business model for Open Source companies a little outdated or antiquated. In the 90s and early 2000s, RedHat successfully deployed this business model and built a multi-billion dollar revenue company on top of it (although compared to its closed core counterparts the captured value and market cap was rather small - RedHat vs Microsoft, MySQL vs Oracle, XenSource vs VMWare).
Broken down the Professional Services model works like this: “sell deployment and integration services, production-oriented “insurance policies”, certified binaries, trainings & workshops, bug fixes, etc., to businesses deploying the project in production.”
But there are a number of challenges with this business model:
revenue is highly unpredictable, entails a lot of manual work, and generates very thin margins
due to a lack of repeatability of most support activities, it is really hard to scale a professional services business and it requires a significant underlying headcount growth
misaligned incentives with customers - enhancing the user experience of a product cannibalizes support revenue
Historically, this model is also notoriously inefficient, typically converting less than 1% of all users into paying customers. The public market has similarly viewed services-based companies rather pessimistically. Services companies typically trade at 1x-3x their revenue vs product-based companies which frequently trade at 10x+.
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.
With all these challenges it’s become clear that Open Source companies need better business models than just support.
📖Read more about “Why there will never be another RedHat” in this article by a16z.
Hosting
Hosting means offering a fully-managed version of your project so that when users want to try out the project, or even deploy it in production, they do not have to worry about operating it (i.e., not worry about backups, downtime, upgrades, etc.). At the core of this model lies the philosophy to enable 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.
As a reference for the margins of the hosting business model, it is interesting to see MongoDB’s cloud business operating at ~65% and Elastic’s at ~40% gross margin. MongoDB trades at a ~35x revenue multiple and Elastic at ~22x.
With the rising popularity of cloud and managed services in general, the hosting model has also become popular for Open Source companies, especially in the data space (e.g. Databricks).
Hosting is typically layered in with a few of the following other models, and most often a secondary revenue channel. For companies with hosting as their primary revenue channel, it’s normally combined with significant SaaS offerings (e.g. GitHub and WPEngine).
In recent years cloud hosting providers, most notably AWS, have started to offer managed hosting solutions for popular Open Source packages. This resulted in a number of Open Source products such as Redis and MongoDB changing their licenses to prevent such competition from cloud vendors. Other companies decided to exclusively offer features in their hosted services that aren’t available in the open-core, creating a blended hosting/open-core model (e.g. Confluent and Elastic).
Open-core
Nowadays, open-core is the most popular model for Open Source companies to capture value. The basic idea is to open-source a majority of the code base but leave a small but significant fraction of the code proprietary.
Typically the proprietary features are ones needed for production deployments and/or at scale for enterprise users. (e.g. for an open-source database, features like monitoring, administration, backup/restore, and clustering)
In general, it’s critical for open-core companies to nail the selection/balancing of components that are left proprietary and are being used to monetize the overall product with certain target users (usually enterprise). If an Open Source company gives away too much, then it gives up the opportunity to make money; but if it gives away too little, then the project will likely fail to get broad adoption —> tough choices!
Separating the Open Source code from the proprietary features can also be tricky from an engineering perspective as the maintenance of two different code bases that potentially interoperate can pose a lot of difficulties.
But despite these challenges the open-core model is pretty dominant these days and even though for most successful open-core companies their customers represent only a small percentage of their overall users, the companies are able to generate SaaS-like margins of >80% (e.g. Confluent and Github).
Hybrid licensing
Hybrid licensing means that companies mix Open Souce code with proprietary code in the same repository. The trick is, that not all the code is licensed the same way. So you have the entire repo available but users can choose between a binary with just the Open Source bits and a binary with both the Open Source and proprietary pieces, the latter under a proprietary license. The proprietary licensed binary often has paid functionality that is off by default, but can be unlocked by purchasing a license key.
The advantages of this model include all of the advantages of the open-core model explained above but also additional factors:
easier engineering processes because you have everything in the same code base
easier upgrade from free to paid for users
external community members can also contribute to the proprietary features
CockroachDB and Elastic implemented this rather new this business model strategy in the last years and popularized it.
Restrictive licensing
The basic idea behind the approach is to create legal pressure for users to pay for the Open Souce software. This works by using an Open Souce license with somewhat constraining terms that incentivize the user to get a commercial deal with the software vendor for ease of mind. The GPL, AGPL licenses and the new Commons Clause (adopted by certain Redis modules) are examples of this model. These models are also frequently used by Open Source companies to defend themselves against the big public cloud providers (see MongoDB example).
However, these models are very critically viewed at in the Open Source community, resulting in a barrier for large-scale adoption.
So whats the right business model strategy?
Most Open Source companies make money using a combination of the outlined 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.
This model requires a lot of thought around how to make a clear separation between the commercial and Open Source offering and the selection of the different components for each category.
I hope some of the points mentioned above might be suitable for guiding a thought process for some founders out there - let me know what you think about that part😉
I hope you enjoyed this month’s issue - for me it was super interesting to deep dive a little on the covered topics, so the high-level summary in this blog might do the same for you 🤓
If you like what you read pls share with your common-minded friends and colleagues!
Sources
https://blog.timescale.com/blog/how-open-source-software-makes-money-time-series-database-f3e4be409467/
https://medium.com/blossom-capital/successful-open-source-business-models-2709e831e38a
https://a16z.com/2019/10/04/commercializing-open-source/
https://a16z.com/2014/02/14/why-there-will-never-be-another-redhat-the-economics-of-open-source/
https://redmonk.com/sogrady/2017/06/01/hybrid-licenses/
https://www.forbes.com/sites/glennsolomon/2020/09/15/monetizing-open-source-business-models-that-generate-billions/?sh=1b71911334fd
https://www.cockroachlabs.com/blog/how-were-building-a-business-to-last/