Open source projects can make money. There are a wide variety of ways, methods and models to generate revenue from open source projects. Learn how successful open source developers earn money, what is working and what is not.
The purpose of this report is to explain how open source projects make money and to evaluate whether projects are really profitable. The report was written from a pragmatic point of view and the focus is on tangible issues with existing open source businesses.
While not typically used by large for-profit companies, some individual developers make pretty good money by taking donations for their open source work. Patreon, GitHub, and Buy Me A Coffee are all popular platforms that allow individuals and businesses to help support open source projects that they use or want to see maintained.
The downside to this model is that it’s really hard to build predictable, sustainable income from it. Some people will heavily use and benefit from updates while never paying the creators, and this frustrates those who do support the project. If you’ve ever asked your boss if you can start paying for some of the free, open source software you use at work, you know how tough this can be to sell.
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.
Paid Support or Courses
Red Hat’s model of open source software financed by paid support contracts and on-premise configuration takes more human hours, but it allows them to improve the user experience dramatically. When companies look at the cost to troubleshoot open source software, it’s usually a better deal to sign up with the people who made the software rather than learn it themselves.
If you want to make your software more accessible, you can sell training at a lower cost than hands-on management and support. For example, The Linux Foundation helps maintain hundreds of open source projects and makes money through its training courses.
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).
Selling Other Products
As in Automattic’s case, they offer a free, open source product (WordPress.org) and a suite of related and unrelated proprietary products to generate revenue from. This model is easiest to manage if your other products support the open source one, but some companies raise money from venture capitalists to fund the open source tool’s growth while they figure out other products to build.
The downside to this model is that building and maintaining multiple products is a lot of work. Small teams will find this distracting and it might mean the open source product suffers.
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.
Contributing to open source projects can be very gratifying, but does contributing actually pay the bills? Can an open source developer make money from doing what they love? That’s the question we’ll answer in this series.