Open source is free to use. It has never been free to make.
Open source sits underneath almost every piece of software shipped today. Frameworks, databases, build tools and the libraries inside them are, in large part, written and maintained by people who were never paid to do so.
The conversation around open source tends to focus on its benefits: faster innovation, shared infrastructure and transparency. Far less attention is paid to what publishing costs the people who do it. That cost is rarely financial, and few maintainers expect it to be. It is measured instead in control, in attribution, and in the time and energy required to sustain something that others depend on.
This article examines those costs, why developers continue to accept them, and what can be done to make them more manageable.
What does a developer give up when they give their work away?
Part One: Loss of Control Over Use
Software is written with an intended purpose. A license, however, governs permission, not purpose. Once code is published, its author has no say in how it is applied.
A scraping library built for price comparison can power ticket-scalping bots. An automation tool designed for customer support can be repurposed to send spam. A speech-synthesis feature intended to let people reply in their own voice can be used to imitate someone else's.
For many maintainers, this is the most personal cost of publishing: becoming an unwilling participant in uses they would have declined. There is no approval step and rarely any notification. Discovery tends to be accidental.
The tension occasionally surfaces in public. In January 2022, the author of the widely used JavaScript packages colors and faker deliberately published broken releases, citing frustration that large companies relied on his unpaid work. The response was widely criticised and disrupted a large number of downstream projects. The grievance behind it, however, was one many maintainers recognised.
Part Two: The Erosion of Attribution
For most contributors, attribution is the primary return on their work. It underpins professional reputation, demonstrates competence to employers and clients, and is often the only recognition for work done unpaid. Its loss is therefore felt disproportionately.
Permissive licenses such as MIT ask for very little: chiefly, that the copyright and license notice be preserved. Even so, several patterns are common:
- Rebranded forks. The same code under a new name and logo, with the original commit history collapsed into a single "initial commit".
- Repackaged "premium" products. Open source dashboards and starter kits, lightly restyled and sold on template marketplaces without reference to their origin.
- Installation and support services. Third parties charging businesses to deploy a free project, presenting it as a proprietary platform, while support requests flow back to the original maintainer.
- Absorption into AI models. Public repositories have been used to train code-generation models that can reproduce familiar patterns without the accompanying license or author. The legal position remains under dispute. The attribution gap does not.
None of these practices affect whether the code works. They do, however, sever the connection between the work and the person responsible for maintaining it, who is usually the party the project most depends on.
Part Three: Premium Functionality Without a Price
The costs above are most acute for one category of project: the one that offers, for free, capabilities that are elsewhere sold as commercial products.
Agent orchestration, workflow automation, observability, voice synthesis and evaluation tooling all have established paid markets. When an independent developer publishes a working alternative, three effects tend to follow.
Credibility suffers. Free software is often assumed to be a prototype or an abandoned experiment. The same software can appear more credible once someone else attaches a price to it.
Others monetise it. Consultants and resellers package, install and bill for it. Most licenses permit this. For the author, it can mean watching their unpaid work become someone else's recurring revenue.
Large providers adopt it at scale. This dynamic has shaped much of the last five years of open source licensing:
| Project | What happened |
|---|---|
| Elasticsearch | Moved away from Apache 2.0 in 2021, citing cloud providers offering it as a managed service. Later added the AGPL back as an option. |
| Redis | Switched from BSD to the source-available RSAL and SSPL in 2024. The Linux Foundation backed a community fork, Valkey. Redis 8 returned with an AGPL option in 2025. |
| Terraform | HashiCorp moved to the Business Source License in 2023. The community forked it as OpenTofu. |
Each decision addressed the same problem: how to prevent others from profiting from a project without contributing back. Each also carried its own cost, in forks, lost trust and divided communities.
If organisations with legal teams and boards have struggled to resolve this, individual maintainers are considerably less well placed to do so.
Part Four: Expectation, Noise and Maintainer Fatigue
Unpaid support obligations
A useful project attracts issues. Many are constructive. A significant share are not: terse reports, requests for timelines, and questions about whether the project has been abandoned. Some come from users who paid a third party for an installation and now expect the original author to support it.
No contract exists in any of these cases. The expectation forms regardless.
Automated noise
A newer cost is the volume of AI-generated bug reports: submissions that appear credible, reference functions that do not exist, and consume hours of review before they can be dismissed.
The curl project illustrates the scale of the problem. It ended its bug bounty in January 2026, after more than six years, because fabricated reports had begun to outnumber genuine ones. From 1 July to 3 August 2026, its security team paused vulnerability intake altogether. One of the most widely deployed libraries in the world, maintained by a small volunteer team, had to close its inbox to remain sustainable.
Usage without support
In February 2023, the maintainer of core-js, a library downloaded tens of millions of times a week and present on a large share of the most visited websites, published an account of his financial difficulties. Early donations had amounted to roughly $57 a month, and adding a funding link had, by his account, drawn hostile responses.
The pattern is consistent: the more widely a project is used, the more its maintainer is relied upon, and the less visible that maintainer becomes.
Fatigue as a security risk
In 2024, a backdoor was discovered in xz, a compression library present in a large number of Linux distributions. It was not the result of a technical breach. The attacker spent years building trust with an overextended maintainer until they were granted commit access.
Maintainer fatigue is therefore not only a personal cost. When the people sustaining critical software run out of capacity, everyone who depends on it inherits the risk.
Part Five: Why Developers Continue to Publish
Given these costs, it is reasonable to ask why so many developers continue to release valuable work for free. The answer is that the other side of the ledger is equally real.
| Cost | Return |
|---|---|
| Loss of control over how code is used | Reach far beyond what one developer could achieve alone |
| Attribution that is removed or overlooked | A public body of work that demonstrates capability directly |
| Premium features monetised by others | Clear evidence that the work has commercial value |
| Unpaid support and automated noise | Bug reports, fixes and ideas from a wider community |
| Mistakes visible to everyone | Security that can be audited rather than assumed |
| Time and energy | Freedom to build without commercial constraints |
Open source also offers something few commercial products can: freedom from lock-in. A subscription business benefits when leaving is difficult. An open project has no such incentive. Users can run it on their own infrastructure, keep their data in-house, inspect every line and migrate whenever they choose.
Finally, there is reciprocity. Every developer builds on open source written by others. Publishing is, for many, a way of contributing back to the foundation they rely on.
Part Six: Managing the Costs
These costs cannot be eliminated, but they can be chosen deliberately rather than discovered later.
Select a license intentionally
MIT is often chosen by default. That is a reasonable choice, provided its implications are understood.
| License | What others may do | What it protects |
|---|---|---|
| MIT / Apache 2.0 | Almost anything, including closed commercial products built on the code | The copyright notice |
| GPL-3.0 | Use and sell it; distributed modifications must remain open | Improvements to distributed software |
| AGPL-3.0 | As GPL, with network use of a modified version also counting as distribution | Modifications offered as a hosted service |
None of these prevent others from charging for installation or support. Each defines clearly what must be returned.
Make attribution durable
Include the author's name in the LICENSE and a NOTICE file, in the application's About screen and in API metadata. Attribution recorded in several places is considerably harder to remove than attribution recorded in one.
Protect the name
The code may be open while the project's name and logo are not. Trademarks are how many established projects prevent forks from presenting themselves as the official distribution.
Document expectations
A CONTRIBUTING guide, a SECURITY policy and a short support statement convert implicit expectations into explicit ones. A single line, such as "issues are reviewed weekly and paid support is not offered", can prevent a great deal of friction.
Provide a route for support
Sponsorship links rarely produce significant income. They do give users who value the work a practical way to contribute to its upkeep.
Set limits
Declining features, deadlines and demands is part of sustainable maintenance. curl's five-week intake pause demonstrates that even critical projects can, and sometimes must, step back.
A Case in Point: Obsidian AI
A brief disclosure: this subject is not abstract for me.
For the past seven months I have been developing Obsidian AI, an open source, self-hosted platform for building and orchestrating AI agents. It falls squarely into the category described in Part Three, offering capabilities that are typically sold as commercial products.
| Capability | Typical commercial equivalent |
|---|---|
| Agents across OpenAI, Anthropic, Gemini, Ollama and OpenRouter | Separate per-provider integrations |
| Multi-agent teams with delegation between agents | Enterprise agent platforms |
| Visual workflows with conditions, approvals and loops, including n8n import | Workflow automation subscriptions |
| Evaluation suites, prompt optimisation, tracing and per-agent cost reporting | Observability and evaluation licences |
| Long-term memory, retrieval-augmented generation and Markdown knowledge vaults | Knowledge management add-ons |
| WhatsApp agents with local transcription, voice replies and voice cloning | Metered messaging and voice APIs |
| A Docker sandbox and isolated execution for user-defined tools | Hosted code execution services |
The project now comprises roughly 62,000 lines of code and 173 API endpoints, and runs entirely on the user's own infrastructure. It has also appeared on third-party sites as a paid installation service.
Several of the costs discussed above apply directly. The voice cloning feature was designed so that users could respond in their own voice, but its use cannot be controlled once published. The WhatsApp integration avoids the need for a business account by relying on an unofficial library, a trade-off that every deployment inherits. Documentation has not kept pace with development. And when a weakness was identified in how user-defined tools were executed, it was resolved in public, where its prior existence was equally visible.
These considerations informed the choice of license. Obsidian AI is released under the AGPL-3.0. Anyone may install, host, customise and charge for services around it. Modified versions, including those offered as hosted services, must remain open, and their users are entitled to the source.
For those offering it commercially to clients, the request is a simple one: be transparent that the underlying software is open source, retain the attribution, and contribute improvements back upstream.
Conclusion
Open source remains one of the most significant achievements of the software industry. It is not, however, without cost. That cost is borne in control, attribution and energy, largely by individuals, and is seldom discussed.
Developers considering publishing valuable work should do so, but with a clear understanding of what they are accepting, and with deliberate choices about which costs they are prepared to carry.
Open source has never been free. Someone always pays. The question is whether they chose to.
Links:
- Obsidian AI: github.com/sup3rus3r/obsidian-ai
- Previous article: What If Full-Stack Features Were Installable?
- Sponsor the project: GitHub Sponsors
Sources: curl's 2026 reporting pause, the core-js funding post, Redis returning to the AGPL.
Top comments (0)