It’s no secret that open-source technology — once the province of radicals, hippies and granola eaters — has gone mainstream. According to industry estimates, more than 180 young companies that give away their software raised roughly $3.2 billion in financing from 2011 to 2014.
Even major enterprise-IT vendors are relying on open-source for critical business functions today. It’s a big turnaround from the days when former Microsoft CEO Steve Ballmer famously called the open-source Linux operating system “a cancer” (and obviously a threat to Windows).
Despite the growing popularity of open-source software, though, many open-source companies are not financially healthy. Just like eyeballs didn’t translate into actual online purchases during the first dot-com era in the late 1990s, millions of free-software downloads do not always lead to sustainable revenue streams.
Make no mistake, open-source software is a brilliant delivery model to drive user adoption, and it’s poised to drive increasing market value in the coming years.
Most people, when they think of open source software, imagine enthusiastic and generous developers who spend their days and nights creating software for free. Indeed, for a few decades “open source software” was synonymous with “free software.” Developing software with open code through group effort excluded the opportunity for profit. But today there are ways to profit from building open source software (OSS).
Lately, developers have started thinking about how to monetize their OSS. We’re going to highlight a few common ways to make profits from open source software.
The support model, also known as the “RedHat” model, goes like this: sell deployment and integration services, production-oriented “insurance policies”, certified binaries, trainings, bug fixes, etc., to businesses deploying the project in production.
This model becomes limiting over the long-term for a few reasons: (1) support often requires a lot of manual work, and so reduces business margins; (2) scaling is hard because support work is often not easily repeatable; (3) it creates perverse incentives on the part of the open-source company, where making the product easier to use cannibalizes support revenue. In fact, this model works very well when the project requires complex deployments with sprawling ecosystems, which often goes against building the best user experience.
This model is also notoriously inefficient, typically converting less than 1% of all users into paying customers. This inefficiency should come as no surprise. Open-source software itself is free. In order to feel the need to pay for support, a company needs to rely on the project for mission critical systems. Yet over time, companies that do rely heavily on the project will naturally invest their own engineering efforts to understand the project, reducing the need for external support. So there’s only a small usage window where this model works.
The support model is still where every open-source company starts today. Yet, with all these challenges, and the fact that RedHat is still the only company to build a multi-billion dollar revenue business in open-source in the past 25 years, it’s become clear that open-source companies need better business models than just support.
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 can spin up a remote server with the software in just a few clicks, and not have to worry about operating it in steady state (i.e., not worry about backups, downtime, upgrades, etc.).
Given the popularity of the cloud and managed services in general, it should come as no surprise that this has also become a popular model for open-source. In particular, this has become a common way for the public cloud providers (and in particular, AWS) to monetize open-source projects without giving back to the community, which has led to some complaints and tensions (and the emergence of other models, which we’ll soon discuss).
The hosting-only model can work well. Some companies (e.g. Databricks, Acquia) have been quite successful with it. Yet typically hosting is layered in with a few of the following other models.
3. Restrictive licensing
The restrictive licensing model creates a legal reason for users of open-source software to pay. It does this by providing an open-source license with slightly onerous terms, such that anyone using the software in production is highly incentivized to strike a commercial deal with the vendor. The GPL and AGPL licenses, as well as the newly created Commons Clause (adopted by certain Redis modules), are examples of this model. In particular, AGPL and Commons Clause (as well as the new SSPL launched by MongoDB) are licenses also designed to defend against the public cloud providers.
But this approach has limitations: the GPL-based license restrictions do not restrict unmodified usage, and only apply if one makes modifications and does not want to open-source them; the Common Clause has some ambiguity in its language, and it remains to be seen how this will play out in the courts. Still, the largest drawback of this approach is that these licenses hurt adoption, often turning off potential users. In particular, there are quite a few large companies who have explicit policies against using restrictive licenses. Because of the inherent friction of this approach, many rule it out, relying on other business models.
Open-core has quickly emerged as the most popular way for open-source companies to make money. The idea behind open-core is that the majority of the code base is open-source, while a smaller percentage (targeted at production or enterprise users) is proprietary. The proprietary portion may be packaged into separate modules or services that interface with the open-source base, or could be distributed in a forked version of the open-source base.
Typically the proprietary features are ones needed for production deployments and/or at scale. (As an example, for an open-source database, features like monitoring, administration, backup/restore, and clustering are often proprietary.) One benefit here is that it allows the open-source company to license the core with a very permissive license (e.g., Apache 2), while retaining the ability to charge for proprietary features. It also allows open-source companies to defend against free-loading participants (e.g., such as the public cloud providers) by keeping certain features in the proprietary code base.
The challenge with this model is in balancing the open-source value versus the proprietary: 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 open-source project effectively becomes “lame-ware” (and the project will likely fail to get broad adoption).
Another challenge is that cleanly separating the open-source from proprietary features in code is sometimes difficult. Even if separating them is easy, maintaining two different code bases can also be challenging from an engineering process perspective: e.g., managing independently versioned releases that might need to interoperate and/or porting code back-and-forth to prevent code divergence over time. And often engineers would rather work in the open-source repo than the “business” repo. But despite all these reasons, this model is quite powerful.
5. Hybrid licensing
The hybrid licensing model is the newest one on this list. Initially popularized by CockroachDB (Jan 2017), and later adopted by Elastic (Feb 2018), hybrid licensing takes the open-core approach but improves on it in a few key ways.
What hybrid licensing does is intermingle open-source and proprietary software in the same repository, and then make the code for the entire repo available. That is, the entire repository is “open code” (or “source available”), just not all licensed under an OSI-approved open-source license. Users can choose to use a binary with just the open-source bits (available under an open-source license), or use a binary with both the open-source and proprietary bits (available under the proprietary license). The proprietary licensed binary often will have paid functionality that is off by default, but can be unlocked by purchasing a license key.
The advantages of this approach for an open-source company include all of the ones listed under open-core, plus a few more: (1) having everything in the same code base makes it easier to manage engineering process and development; (2) it enables the entire team to work on the core project; (3) it allows users to upgrade from free to paid in-place, often without downtime (and without needing to interact with a salesperson); (4) it allows external community members to comment on, file issues on, and (if they so choose) contribute to proprietary features using the same workflow they’d normally use for open-source features (e.g., via GitHub).
Open source software is highly regarded thanks to its security, reliability, and vibrant communities that support it. Moreover, OSS helps companies avoid reinventing the wheel, and can even be used within proprietary software. Altogether, these factors have made OSS quite popular. Today, people are willing to pay for open source software to ensure legal protection, technical support, and professional services. With paid open source technologies, companies can offer the best of both worlds: transparent technology with the support and features of commercial software.