How to monetize your open source project (and pay your developers)

Hana Khelifa
7 min read

Open source started in the mid-70s with academics and passionate engineers giving away software for free. There was no concept of a business model, and the money to support these “free software” projects (of which there was very little) came mainly from research grants. Two decades later, Linux democratized the use of open source software for business use cases. Experimentation around commercialization started, consisting of paid support and services on top of free software.

Yet, not all open source software found a way to sustain itself.

For instance, cURL has been installed more than 10 billion times worldwide, but only has eight maintainers. And let’s not forget about Heartbleed. In 2012, the PR that was proposed to OpenSSL –the backbone of our digital world, maintained by only two people– contained a mistake that generated massive consequences. Yahoo, Netflix, and even the federal government of Canada had to shut down websites.

Later, OpenSSL Software Foundation’s CEO wrote about the incident in a piece called Money, Responsibility, and Pride and explained how poorly funded and over-worked they were.

That article sparked a debate on how corporations and society rely heavily on open source–while never funding or contributing to it.

Open source’s new era

When cloud computing started to rise in the early 2000s, it allowed companies to run open source applications as Software-as-a-Service. Once the open source service was hosted on the cloud, the user did not know–or did not care to know–if it was an open source or proprietary software. Hosting open source in the cloud thus rendered it invisible, with users perceiving no difference between open source applications and proprietary services. Usage of open source services continued to skyrocket, despite the lack of awareness regarding their very existence and use. This evolution, and the continued adoption of open source services, proved that open source has concrete business potential.

Since then, we have seen a new wave of open source startups rise, taking both the software development and startup world by storm. Venture capitalists took notice, and some open source startups raised hundreds of millions of dollars and became unicorns. For example, Grafana Labs raised $220 million in a series C round in 2021, and Redis raised $356 million over ten years.

This new generation of open source organizations knows how to play the money game. Though they are built on the principles and processes of open source, they take the best of what the startup world has to offer.

Nowadays, the next big open source project could come from a tech company, a university, someone’s basement, or an incubator. But one thing is certain: It is now possible to generate revenues from open source, creating the possibility to build a whole business or simply pay those hard-working maintainers.

Open source monetization models

There are multiple ways an open source project could be monetized. Here are a few models:

OpenSaaS model

If your project has generated lots of user demands, offer a Software-as-a-Service alternative. You’ll need to find the right pricing so users aren’t incentivized to self-host and self-maintain, but you can justify the cost with perks. Bundling the hosting with other services such as support, training, or paid features requests will allow you more flexibility on the margins.
This option might not work for every open source project, but it is a popular option that draws a clear line between free and paid versions.

This model also provides companies and developers the choice of self-hosting, i.e., dealing with the security and the maintenance themselves or getting a complete package for a fee. It also opens the door to new types of project users who have less technical knowledge.

Custom feature requests

Providing extra services is a good way to generate income from open source projects. You distribute the software for free, but additional features come at a cost. This is a straightforward model to make money from open source software, as it is more cost-effective for companies to hire you to develop custom functionalities directly.

Support plans

Providing support to users, especially enterprise users, is one of the most mainstream ways of earning money with open source software for a developer. When they need to troubleshoot your software, chances are they’ll be willing to pay for your support.


Distribute your software under two or more sets of terms and conditions. A good scenario for open source software would be to have one proprietary software license, create proprietary applications derived from it, and offer one free software. Therefore, you require any derived work to be released under the same license.

The copyright holder of the software then typically provides the free version of the software at little or no cost, and profits by selling proprietary licenses to commercial operations looking to incorporate the software into their own business.

For instance, MySQL has a dual-licensing business model in which its users can choose to use MySQL products either under the open source GPL or under a commercial license. Those developing and distributing open source applications under the GPL license can do so. And for those who want to develop and distribute their applications, but don’t want to release the source code, MySQL provides a commercial license.


To rely on your community of users, Open Collective is a great platform to get financial support -without fees- for your open source project. Github Sponsors is also a great tool to gain visibility and find donors for your project.

If you are considering this option, here is a guide full of best practices written by Github’s Developer Engineers. Among other things, the guide will help you make the most out of your Github Sponsors Profile page by making it appealing.

Note that this is an unpredictable business, which could make it tricky to predict and recruit accordingly if you rely solely on donated income.
For instance, cURL display their sponsor list in full transparency on their website. We can also see on their GitHub sponsors page that the silver sponsor is $100/month and the gold sponsor is $500/month. There are 1 gold sponsor and 20 silver sponsors, which makes it $2500/month - not counting the one-shot donations (which, let's be honest, isn't much for them)


Creating a sponsor framework is a standard option because it allows people or organizations to have clear levels of sponsorship. You can set up different tiers depending on the amount donated, with each tier offering different types of (non-costly) perks, like a mention on your README.

Some corporations are looking into giving back to open source projects through donations. Spotify, for example, recently launched its Spotify FOOS Fund. Why not set up a clear process for those who want to contribute through a sponsorship program?

Open Core model

Open source the majority of your code, but keep a small fraction of it licensed as proprietary. This gives the end-user the ability to use the feature-limited version as they please, while offering add-ons as proprietary software.
GitLab is a good example: Giltab CE (Community Edition) is under an MIT license, while GitLab EE (Enterprise Edition) is under a commercial license.


If you want to grow your open source software and make it more accessible to enterprises, you can sell pedagogical content like trainings and workshops, like the Linux Foundation.

How to pick the right monetization model?

One of the most popular patterns for flourishing open source companies is to have a mix of models. You can have an open core model combined with a hosted version as a second revenue stream, with services and features as a tier one.

This combination is quite successful but requires a lot of planning ahead. You’ll need to build a clear separation between your open source and commercial propositions, and take into account what your community will accept.

Your product and its community is always at the center of your project, so building a model that makes sense for the nature of the product is crucial. Whichever solution you end up choosing, don’t be afraid to explore new paths and alternatives while using the above monetizing options. With a little experimentation, you’ll be able to evaluate if your model can scale.

Share on
Other articles about:

Recommended articles