Companies make money from open source in a variety of way, depending on their size, business model and other variables. Many companies who use open source make it available for download from their websites and others sell merchandise such as clothing and other wearables with the open source logo.
Since the advent of open source, many companies have developed various ways to make money from open source projects. Some of these companies develop as products for open source projects and make money by charging for support, some offer services around a project, and some companies even sell the project itself.
Offering paid support is one of the most straightforward revenue streams for all kinds of open source projects. As a project maintainer, you have a lot of knowledge about the codebase. This puts you in the position to offer consultancy or support services to companies that want to use your code.
On the other hand, offering paid support doesn’t provide a scalable business model for open source projects. Because most projects are maintained by a few developers, there’s limited time for them to offer support to companies. Bear in mind the time required to improve the functionality and maintain the codebase.
In conclusion, it’s an effective way to earn some money as an open source maintainer and keep the project going.
The first prerequisite is broad adoption: the open-source project needs to have a large user base and community.
Broad adoption is necessary because an open-source company can capture only a small amount of the value it creates. To be clear: an open-source company gives most, if not all, of its developed software away for free, and most of its users will never pay for that software.
In fact, most open-source monetization rates (the conversion rate from users to paying customers) are fairly small: often in the low single-digit percentages (if not lower). But given a large enough community, that conversion rate can be enough. This dynamic is one of the drivers behind the economies of scale in the open-source model. In other words, the need to have broad adoption is one of the reasons why there are often category “winners” in open-source.
This need for a large up-front investment in adoption is also why most successful open-source companies today start off as projects in a large company (e.g., Hadoop/HDFS at Yahoo!, Kafka at LinkedIn, Kubernetes at Google), as research areas in academia (e.g., Spark at Berkeley), or as VC-backed startups.
Software as a Service
An open source project that has generated plenty of demand can choose to offer a Software as a Service (SaaS) business model. This model is most viable for projects that offer a complete application, such as a publishing platform, monitoring tool, or marketing automation tool.
Developers can choose to host the software themselves. However, this means that they have to take care of security, security, and maintenance.
It’s often much easier and cheaper to pay for a managed offering under a SaaS model. Developers pay a monthly fee to use the hosted solution. Therefore, they can focus on the tool itself instead of all maintenance-related tasks. Moreover, a marketing or content team often doesn’t have the required technical knowledge to host a solution themselves. For that reason, a SaaS solution is a great alternative to make money from open source software.
The second prerequisite is primary credibility within the community. This is important because it enables the open-source company to build an efficient sales and marketing process, which is especially important given the low monetization rates.
Having “primary credibility” means that anyone who needs help with the software reaches out to the open-source company and not someone else for assistance. Not having this credibility means having to slog it out with others in the market for that attention, leading to a far less efficient business model and lower margins.
The value of primary credibility, which today is often achieved by being the main contributors to the project, can be seen by comparing the market caps, annualized revenue, and multiples of Elastic ($4.59 billion market cap, $160 million revenue, 29x) and MongoDB ($3.97 billion market cap, $155 million revenue, 26x) vs. (pre-merger) Hortonworks ($1.23 billion market cap, $262 million revenue, 5x) and Cloudera ($1.73 billion market cap, $367 million revenue, 5x). (Market caps as of November 27, 2018; revenue numbers are from latest reported fiscal year.)
Because Elastic and MongoDB had primary credibility in their respective communities, they were able to build a much more efficient business model, and capture far more value with less revenue than either Hortonworks or Cloudera, who had to raise more money and fight fiercely over the Hadoop market. (One could even speculate that the need to possess primary credibility was one of the reasons behind the recent Hortonworks/Cloudera merger.)
Once an open-source company has broad adoption and primary credibility, it can build a pipeline of companies who need assistance, and start layering in a variety of business models to build a sustainable business.
Paid Feature Requests
It’s not easy for smaller projects to earn revenue. Often, these developers have a daytime job besides maintaining an open source project. Therefore, they are limited in time to maintain their project.
Yet, if you happen to find a couple of companies using your project, you can offer paid feature requests. In other words, you develop new features based on a company’s request. In return, they pay you for developing the features they want.
It’s one of the most straightforward models to make money from open source software. Even a small project can find a few companies that are interested in using their open source software. Often, it’s cheaper for them to hire you as a freelancer to develop the new functionality they need than having their developers spend time figuring out the codebase and adding new functionality.
Suppose a company forks an open source project to add new functionality themselves. In that case, this means they’ll have to maintain their fork and merge new updates from the original codebase to their codebase. This can sometimes become messy and increase maintenance complexity.
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.
Since May 23, 2019, GitHub introduced GitHub Sponsors.
“The world runs on open source. None of it would be possible without the global team of maintainers, designers, programmers, researchers, teachers, writers, leaders—and more—who devote themselves to pushing technology forward. These extraordinary developers can now receive funding from the community that depends on their work, seamlessly through their GitHub profiles.”
The primary benefit of using GitHub Sponsors is that they charge zero fees. 100% of sponsorships go to the developers. The feature aims to reward developers for maintaining free software. Yet, alternatives exist to receive sponsorships, such as Open Collective or Patreon.
(Source: Babel sponsors on GitHub)
Sponsorships are a great revenue stream for well-established open source projects that require more funds to stay afloat.
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 source software is mostly provided for free with support coming from the community. Thanks to this, open source software becomes widely used. Without a business model, there are no profits. But companies do not hesitate to use open source software and they do make money by selling services such as training and support or by creating add-ons of some kind that complement the open source product.