There’s something quietly radical about releasing code into the world with no strings attached. No invoice. No NDA. No “contact us for pricing.” Just here it is, take it, build with it.
I’ve been thinking about this a lot lately. Not from a neutral vantage point but because the tools we build sit squarely in this world. We build on open stacks, we contribute back where we can, and we’ve watched projects we depend on wrestle with the question every OSS maintainer eventually faces: how do you keep going?
Open source has a sustainability problem that doesn’t get talked about honestly enough. The people building the tools the world runs on, often doing it in their spare time across time zones, without job titles are burning out. And the projects that do find a way to pay the bills are navigating real tension between staying open and staying solvent.
Now, with AI coding tools making it easier than ever to ship, there’s a new wave of builders entering open source, people who might not have had the years of experience to contribute before, but who can now make something real and share it. That’s genuinely exciting. And it raises the question again: once you’ve built the thing, how does it keep going?
This post is my attempt to map that landscape honestly.
Open source doesn't mean no one owns it
Before getting into how open source projects make money, it’s worth clearing up the most common misconception: open source code is not public domain. Someone owns it, usually the person or organization that wrote it and the license is how they choose to share it.
A software license is a legal permission slip. When a project is released under an open source license, the copyright holder is saying: here are the terms under which you can use, modify, and distribute this. They’re not giving up ownership, they’re defining access.
The main thing most people need to know is that licenses sit on a spectrum:
Permissive licenses (MIT, Apache 2.0, BSD): you can take the code, modify it, and use it in your own product, including commercial and closed-source ones. Minimal restrictions. This is why most startups prefer their dependencies to use MIT or Apache.
Copyleft licenses (GPL, AGPL, MPL) : you can use and modify the code, but if you distribute a product that includes it, your product must also be open source under the same terms. AGPL goes further: it applies even if you’re just running the software as a service, which is why big companies have policies against using AGPL dependencies internally.
Source-available / non-OSI licenses (BSL, SSPL, Elastic License) : the code is readable and sometimes modifiable, but with specific commercial restrictions. These are technically not open source by the Open Source Initiative’s definition, even though the code is public. This is the category HashiCorp, Elastic, and Redis moved into and why their relicensing announcements caused such friction.
For anyone building on top of open source or building open source for others, the license is the thing that determines what’s actually allowed. Reading it once is worth more than assuming.
Open source business models
When people say “open source can’t be a business,” they usually haven’t looked hard enough. The money is real; it’s just structured differently.
Here’s what we found across 20+ established projects:
Cloud hosting: you release the code for free and charge for the managed version. Supabase, Discourse, Plausible, n8n. You handle the ops complexity so users don’t have to. The OSS version stays fully functional; there’s no artificial friction. Revenue scales with usage.
Open core/enterprise: the core is open, and advanced features (single sign-on, audit logs, compliance controls, team admin) are paid. GitLab, Grafana, MongoDB, Strapi, Mattermost. The tricky part is drawing the line well. If the paid layer feels like it’s withholding something essential, trust erodes fast.
Support & services: you charge for expertise, not software. Canonical, the company behind Ubuntu, built a $292M (2024) revenue business this way. Ubuntu itself stays free forever, but enterprises pay for Ubuntu Pro (security patching, long-term support) and migration help. The software is free to run; what costs money is the guarantee that someone will fix it when it breaks. Works best for infrastructure-grade tools where downtime has real consequences.
Foundation/sponsorship: companies fund projects they strategically depend on. Kubernetes, Blender, Let’s Encrypt. No direct revenue to the project itself; the money flows through a foundation, and contributors are often employed by the companies benefiting from the ecosystem. Sustainable at scale, fragile at the early stage.
Self-host tooling + premium assets: the framework is free, and you sell what surrounds it. Tailwind UI is the cleanest example: an open CSS framework, a paid component library. n8n is similar, fair-code licensed, and sells cloud and enterprise on top. Directus lives here too.
Every model involves a tradeoff between revenue predictability, community trust, and the speed at which you can build a real team around the project. There’s no universally right answer, just better and worse fits for the type of software you’re building and who you’re building it for.
The maintainer problem
The part of this that doesn’t show up in the business model charts is the human cost.
Maintaining an open-source project at scale means: triaging issues you didn’t create, answering questions that are already in the docs, managing contributions from well-meaning developers whose code isn’t ready to merge, handling security disclosures, cutting releases, and increasingly fielding frustration from users who treat a free tool like a paid product with a guaranteed response time.
Burnout in OSS is structural,not personal. It’s the predictable outcome when a project’s user base grows faster than its funding.
Tidelift, a Boston-based company that connects enterprise teams with OSS maintainers and pays them for upkeep work, surveys hundreds of maintainers about their working conditions. The 2024 report (400+ respondents) found that 60% are unpaid volunteers and that paid maintainers are 55% more likely to follow security best practices than unpaid ones. About half said they feel underappreciated; many have considered walking away entirely.
Some data points worth sitting with:
- Most open-source projects are maintained by 1–3 people
- Security patching is the most cited “underfunded” responsibility
- The projects that get corporate sponsorship are often the ones that already don’t need it
- AI-generated issues and low-quality PRs are a newly rising source of maintainer load
This isn’t a reason to avoid open source. It’s a reason to think about the model before the burnout arrives.
Where trust breaks
The most painful moments in OSS aren’t the slow quiet deaths. They’re the relicensing announcements.
Three examples that made headlines:
HashiCorp / Terraform (2023): After nearly a decade as a popular open-source infrastructure tool, HashiCorp switched Terraform’s license from the Mozilla Public License to the Business Source License, which restricts commercial use by competitors. The community was caught off guard. Within weeks, a fork called OpenTofu launched under the Linux Foundation and quickly gained traction. Source: HashiCorp blog, Aug 2023
Elasticsearch / Elastic (2021): Elastic moved Elasticsearch and Kibana from the Apache 2.0 license to a dual-license model, widely seen as targeting Amazon, which had been offering a hosted Elasticsearch service without contributing back. Amazon responded by forking the project as OpenSearch, which remains fully open source today. Source: Elastic blog, Jan 2021
Redis (2024): Redis switched from BSD to a dual-license model, making it no longer open source by OSI definition. The community forked it as Valkey within days, backed by the Linux Foundation and quickly adopted by major cloud providers. Source: Redis blog, Mar 2024
Each case shares a pattern: a commercial entity decides the open source license is too permissive once cloud providers start profiting from their work. The community feels the terms shifted after they’d already invested.
The trust problem in open source is specific: you can’t take back a promise that was never written down. From the forum threads and community discussions we pulled for this research, a few patterns repeat:
- Users are generally fine with OSS projects charging for cloud convenience or enterprise features, as long as the self-hosted version stays fully functional
- What breaks trust is artificial friction: features delayed in the OSS release, bugs fixed for paid users first, or a vague “we’ll open-source this later” that never materializes
- Contributors feel the betrayal more acutely than users; they put time in under a set of assumptions, and the ground shifted
The projects that navigate this well tend to be explicit early: here’s what’s always going to be free, here’s what we’ll charge for, here’s why. Not as fine print, as a genuine commitment communicated to the community.
The AI shift
Something has changed in the past two years that I find genuinely interesting.
Building used to require years of accumulated skill before you could make something real enough to share. Open source contribution was, for most people, a long apprenticeship. You read the codebase for months before touching it.
Now people are shipping tools, submitting PRs, and starting projects with a fraction of that runway. AI coding tools have lowered the bar for participation.
On one hand, this is expanding who gets to build which is good. More perspectives, more problems getting addressed, more experiments. On the other hand, it’s surfacing a new kind of tension. Some maintainers are already reporting an increase in low-quality issues and PRs not from malicious actors, but from people who generated code they don’t fully understand and submitted it anyway. The contribution appears, but understanding doesn’t always follow.
I don’t think this is a reason to be pessimistic. I think it means the bar for community design, how you explain contribution norms, how you structure onboarding, how you make clear what thoughtful participation looks like just got higher.
Open source has always been about sharing knowledge, not just code. That part doesn’t change.
Why we care
We’re not neutral observers of this space. When infrastructure millions of people depend on disappears because a company changes strategy, gets acquired, or the math stops working, real people lose things they’d built their lives around. Google Reader’s 2013 shutdown is the textbook case: nobody did anything wrong, a company just decided the math no longer worked. That risk only grows as more of daily life runs through proprietary layers people can’t see inside or run without permission.
Being open source isn’t just a license choice for us. It’s closer to a value, about who gets to look inside the thing you’ve built, who gets to run it without asking permission, and who gets to continue it after you move on.
Reef.Regen is a good example of what this looks like in practice: a coral restoration impact-monitoring tool built for field teams, open-source, with the goal never being revenue; it was about making sure the data exists, is accessible, and doesn’t disappear if the project goes quiet.
That’s the kind of software we find worth building. And if you’re building something like it, we’d like to know about it.
Closing thought
Open source is one of the stranger things humans have built together: a global commons of software, maintained mostly by people who owe no one anything, kept alive by a mix of mission, craft, habit, and, occasionally, funding.
The sustainability question will keep evolving. AI is changing who can build. Licensing debates aren’t going away. Maintainer burnout is a structural problem with no clean solution.
But the underlying impulse: make something good, share it, let others run with it, that part I find genuinely worth protecting.
If you’re building something in this space, or thinking about it: the community is more welcoming than it looks from the outside. Show up, be useful, and write things down.
