So You Want to Make Money from Open Source?

Four monetization models to help open source maintainers get paid

Supporting open source maintainers is a hotly discussed topic. We’ve all seen that xkcd comic about how modern digital infrastructure is a giant Jenga puzzle relying on a project maintained by one person in Nebraska. It’s not wrong. That comic was created in response to the HeartBleed bug that affected OpenSSL back in 2014. OpenSSL is the most widely used TLS/SSL crypto library found in web servers, operating systems, cloud services, IoT devices, etc - it’s pretty much everywhere. There were plenty of articles like “The Internet Is Being Protected By Two Guys Named Steve” highlighting the fact that critical internet infrastructure, like OpenSSL, relies on underfunded developer teams and volunteers. However, OpenSSL was funded through commercial support contracts, but the funding was inadequate given its importance. At the time of the HeartBleed bug, only one of the OpenSSL developers was working on OpenSSL full-time. According to Steve Marquess, “There should be at least a half dozen full time OpenSSL team members, not just one, able to concentrate on the care and feeding of OpenSSL without having to hustle commercial work”. This raises the question, would OpenSSL have received the resources they needed if they adopted a different business model?

xkcd: Dependency

The purpose of this post isn’t to shame companies for not funding open source software, but rather to explore ways for individuals to monetize their open source project so they don’t find themselves in a position like the Steves with OpenSSL.

This post covers four monetization models geared toward individual maintainers.

1. Commercial Support

2. Dual Licensing

3. Open Core

4. Sponsorships & Donations

In another post we will cover some of the non-open source licenses that have popped up recently (Fair license).

Commercial Support

Commercial support is straightforward. You find people willing to give you money for your time and expertise like the Steves with OpenSSL. If your open source project has decent adoption then you already have some leads. On GitHub, the Insights tab provides useful information, such as which organizations depend on your project.

If organizations are using your project, that means they are already invested in it. Define what types of support you provide (e.g., email support, phone consultations, or even on-site assistance), and set clear boundaries and service level agreements (SLAs) for response times and issue resolution. This ensures that both you and your clients know what to expect.

Examples of commercial support models include Curl, Caddy, and SyncThing.

Dual Licensing

Dual licensing, sometimes referred to as parallel licensing or multiple licensing, is the practice of distributing software under two or more licenses. It’s common for one license to be a strong copyleft license, such as those in the GPL family, while the other is a commercial license. The purpose of releasing software under a free and open source license is to gain users, build a community, and respond to feedback. But then you may be asking why would anyone buy a commercial license if the code is “freely” available on GitHub or GitLab? Can’t I just rip it and use it in my awesome B2B SaaS?

Image by David Wheeler

Nope. That’s potentially illegal. Software released under copyleft licenses mandates that any software incorporating the copyleft-protected code must also be distributed under the same license.

Imagine you’re the CTO of a new B2B SaaS company, AreMyEmployeesWorking.com. AreMyEmployeesWorking.com depends on a keylogging library, CoolKeyLogger, and CoolKeyLogger is distributed under AGPLv3. Because CoolKeyLogger is distributed under AGPLv3, you must make the source code available for AreMyEmployeesWorking.com under the same AGPLv3 license. Not great if you’re trying to keep your B2B spyware proprietary.

However, the maintainer of CoolKeyLogger offers a commercial license.

AreMyEmployeesWorking.com just closed a $100M Series A round from the renowned VC FundersFound, which means you have dollars to spend. You contact the maintainer of CoolKeyLogger and acquire a commercial license which grants exceptions to the copyleft restrictions found in AGPLv3. Hooray.

Now let’s look at dual licensing from the maintainer’s perspective. Offering a commercial license for purchase is sometimes referred to as “selling exceptions”, or, as Saint IGNUcius puts it, “Selling exceptions means that the copyright holder of the code releases it to the public under a free software license, then lets customers pay for permission to use the same code under different terms, for instance allowing its inclusion in proprietary applications.” Fun side note, I saw Richard Stallman give a talk at UIUC. He stopped halfway through his talk to open a bottle of Pepsi then proceeded to take off his shoes and socks.

St. IGNUcius

Which license should you choose for your project? Consider your priorities. If you want robust protection against commercial redistribution of your code, a strong copyleft license might be the way to go. However, be aware that some organizations have policies against using strong copyleft software, which could limit your project’s adoption. Conversely, more permissive licenses tend to foster faster adoption because developers can integrate the software without needing to navigate internal policies or consult legal teams. The latter is less viable if you are trying to dual license.

Here is a table of dual licensed repos on GitHub. It might not be complete and there may be some entries that shouldn’t be in there. I’ll upload the code that generates this table soon, probably.

Oh, and try not to rug pull your project like these guys.

Open Core

Open core is a business model where you sell a proprietary product built on top of an open source core. The core is given away for free.

Since the mid-2010s, several open core companies, including GitLab, HashiCorp, MongoDB, and Confluent, have gone public. Many venture-backed startups also follow the open core model. But open core isn’t just for venture-backed startups and companies looking to IPO. An open core business model can work for individual maintainers. In fact, there are individual maintainers pulling down 7 to 8 figures by running an open core model.

An exemplary open core business operated by a single individual is SideKiq. SideKiq is a popular background job processing framework used in Rails projects. SideKiq is released under LGPLv3 while SideKiq Pro and SideKiq Enterprise are source-available under a commercial license. The maintainer of SideKiq, Mike Perham, is pretty candid about his success, he generates “close to 10M in annual revenue”. I recommend taking a look at some of his interviews and podcast appearances. You can even ask him questions about SideKiq during his weekly office hours.

Carlos Becker is another example of a maintainer successfully running a one-person shop. He maintains GoReleaser, a tool that simplifies software releases in Go, Rust, and Zig. The core project is open-source under the MIT license, while GoReleaser Pro, a proprietary version, offers additional features and enhancements. I use it for nearly all my Go projects, and it has saved me countless hours and headaches.

The open core model provides a flexible way to monetize open-source software without requiring a strong copyleft license (although you totally could use a copyleft license). Maintainers can keep the core project freely available while selling proprietary add-ons and premium features. This allows for a sustainable revenue stream without restricting adoption. Another great feature of open core is that businesses don’t have to host customer data if they prefer not to, as seen in SideKiq’s case, where Mike Perham sells commercial licenses without running infrastructure for customers. This makes open core an attractive and scalable approach for independent developers.

Donations and Sponsorships

Donations and sponsorships have become more common thanks to platforms like GitHub Sponsors, OpenCollective, and Patreon. While this model isn't the most sustainable way to monetize an open-source project, it can provide some income and it’s easy to set up. If your project has a large user base or is widely adopted in the industry then you might be able to get actual companies to sponsor you, but don’t count on it. Companies like paying for things, not giving away donations.

One of the biggest challenges with donations is their unpredictability. Unlike commercial support or open core models, sponsorship income can fluctuate month to month, making it difficult to rely on for long-term stability. However, some maintainers have successfully built a sustainable income through sponsorships by consistently engaging with their communities, offering perks like early access to features, and offering sponsor logo placement on READMEs.

---

So we got commercial support, dual license, open core, and donations and sponsors. Which one you gonna choose?