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).
The largest challenge is also the same as open-core: balancing the quantity and value of open-source vs. proprietary features.
There is no one true way to monetize open source software. You can use any number of these different methods, or a combination of them, to share your work and give back in an artistic and financial sense. There are various ways that you as a developer or designer can share your knowledge with the world while still making money. In the long run, you will make more money in financial return than if you went with only one specific route (like creating a standalone application or website). In addition, it’s much more fun and artistically fulfilling to see people repurposing your code than it is to just sell a completed program to someone.