One Open Source Proxy’s License Cost Its Creator a Full-Time Job

In early 2024, a single maintainer of a widely-used open source proxy library made a decision that would cost him his livelihood. After years of building and maintaining the software that thousands of companies depended on, he switched its license from Apache 2.0 to the Business Source License. Within months, enterprise contributions dried up, revenue dropped to near zero, and his consulting contracts evaporated. By the end of the year, he was publicly announcing his job search on his personal blog.

The License That Changed Everything

The library in question is a high-performance proxy used primarily in microservice architectures for traffic routing, load balancing, and observability. Its creator, a solo developer based in Europe, had spent over five years refining the codebase. Under the Apache 2.0 license, the project had gained a large following, with thousands of stars on GitHub and deployments at several Fortune 500 companies.

The switch to the Business Source License (BSL) was intended to generate revenue from the largest users. The BSL allows free use up to a certain scale—typically measured by number of instances or revenue—after which a paid license is required. The creator hoped this would capture value from the cloud providers and enterprises that had been using the software without contributing financially.

But the response was swift and brutal. Enterprise users, many of whom had internal legal teams that flagged the new license as incompatible with their procurement policies, stopped contributing code and documentation. One major bank that had been a regular contributor pulled all its engineers from the project. The creator's consulting contracts, which had been tied to his expertise with the proxy, were not renewed because the companies could no longer use the latest version without a paid license.

By mid-2024, the project's revenue—which had come from a combination of donations, corporate sponsorships, and consulting—had dropped to near zero. The creator, who had relied on this income to support himself and his family, was forced to look for a full-time job. He later wrote that the license change had been a last resort, but it backfired in ways he hadn't anticipated.

Why Proxy Libraries Are a Funding Trap

Proxy libraries occupy a peculiar position in the software ecosystem. They are invisible infrastructure—code that runs between services, handling requests, retries, and observability. Users rarely see them directly, but every request passes through them. This invisibility makes it hard to justify paying for them, even when they are critical.

Unlike databases or web frameworks, which have clear value propositions and established monetization paths, proxy libraries are middleware. They don't store data or render pages; they just move bytes. As a result, users expect them to be free, stable, and well-documented. The idea of paying for a proxy feels wrong to many developers, even when they depend on it for production traffic.

There is no direct monetization path for middleware like proxies. You can't sell a hosted version easily because the proxy is typically deployed as part of the user's own infrastructure. You can't sell support easily because the code is simple enough that most teams can debug it themselves, at least initially. The only real avenue is consulting, which scales linearly with the maintainer's time.

The bus factor is also dangerously high. A single maintainer carries ten thousand deployments. If they get sick, burned out, or hit by a bus, there is no one to take over. This is exactly what happened with this proxy: the creator was the sole committer for years. When he changed the license, there was no community governance structure to debate or overrule the decision. It was his call alone, and the consequences were his alone to bear.

The Business Source License Math

The BSL is designed as a compromise: it allows free use for a limited time (typically four years), after which the code converts to a true open source license. In the meantime, production use beyond a certain scale requires a paid license. The creator set the scale limit at five instances or $2 million in annual revenue, whichever came first.

On paper, this seemed reasonable. Large firms that had been paying nothing before would now need to pay. The creator estimated that even a handful of enterprise deals would sustain the project. But the reality was different. Legal departments at large companies balked at the BSL because it wasn't on their approved list of licenses. Procurement processes that could approve an Apache 2.0 license in minutes now required weeks of review.

As a result, adoption of new versions collapsed. Companies that had been using the Apache 2.0 version simply stayed on that version, freezing their dependency. They had no incentive to upgrade, and the new features in the BSL-licensed versions were not compelling enough to justify the legal overhead. The revenue per user fell below the server cost of hosting the package repository.

The math simply didn't work. The creator needed roughly $100,000 per year to sustain the project. At the prices he set for the paid license—$5,000 per year for a single instance—he would have needed twenty paying customers. Instead, he got two, both small startups that quickly outgrew the free tier and then left for alternatives.

To make matters worse, the administrative overhead of managing license keys and compliance checks consumed time that could have been spent on development. The creator had to build a simple licensing server to issue and validate keys, which added complexity and maintenance burden. For a solo maintainer, every hour spent on licensing infrastructure is an hour not spent on improving the code. This opportunity cost is rarely discussed in license change analyses, but it can be significant.

Another factor was the asymmetry in negotiating power. Large enterprises could demand custom terms or discounts, while the creator had no leverage. One Fortune 500 company asked for a flat fee of $10,000 for unlimited use across their entire organization—a fraction of what the per-instance pricing would have been. The creator declined, and the company simply forked the last Apache 2.0 version instead. That single lost deal represented more potential revenue than all the paid licenses he eventually sold.

How the Market Reacted: Forks and Silence

Within weeks of the license change, a key competitor forked the last Apache 2.0 version of the proxy. That fork quickly gained traction, with contributions from developers who had previously contributed to the original project. The fork adopted a permissive license and added features that the original had been slow to implement.

Corporate users migrated en masse. One Fortune 500 company that had been a reference customer for the original proxy publicly announced its migration to the fork, citing license concerns. Over the next six months, the original repository's star count dropped by roughly 40%. Issues and pull requests slowed to a trickle. The community that had once been vibrant was now silent.

No major sponsor stepped in to support the original project. The creator had approached several cloud providers and venture capital firms, but none were interested. The proxy was too small and too specialized to warrant investment, even though it was used by many of those same companies. The silence was deafening.

In a blog post titled "Why I'm Looking for a Job," the creator detailed the timeline: the license change, the drop in contributions, the loss of consulting income, and the eventual realization that the project could no longer support him. He wrote that he had no regrets about the license change—it was a necessary experiment—but he wished he had done it earlier, before the project had reached critical mass.

An interesting counterpoint is that some projects have successfully used the BSL. For example, MariaDB and CockroachDB employ the BSL and have built sustainable businesses around it. However, those projects are databases, not middleware. Databases have a clearer value proposition and are often sold as managed services or with enterprise features. The proxy library lacked those advantages: it was too low-level to sell as a service, and its feature set was already complete for most users. The BSL works best when there is a clear upgrade path to a paid product, not when the free version is already sufficient.

Another lesson from the fork is that the community's loyalty was to the code, not the maintainer. Once a viable alternative existed under a permissive license, users switched without hesitation. The creator had invested years of effort, but that goodwill evaporated in weeks. This highlights the importance of building a community that is invested in the project's governance, not just its output.

The Real Cost of Open Source Middleware

The story of this proxy is not unique. Cloud providers like AWS, Google, and Azure routinely package open source middleware as managed services, generating millions in revenue while the maintainers earn zero. The proxy in question was already available as a managed service on at least two clouds, but the creator saw none of that money.

There is no equivalent of npm fund or GitHub Sponsors for infrastructure code. Donations to the project were sporadic and never exceeded a few hundred dollars per month. The creator had tried Patreon and Open Collective, but the conversion rate was low. Developers who use the software every day rarely think about sending money upstream.

Maintainer burnout is a systemic market failure. The incentives are misaligned: users benefit from free software, but they have no obligation to support its creators. The license change is a symptom, not the disease. The disease is that the market for open source infrastructure is broken. It rewards consumption, not production.

Some argue that maintainers should treat their projects as marketing for consulting services, as the creator had done for years. But consulting doesn't scale. When the maintainer's time is the product, there is a hard limit on income. The only way to make open source sustainable at scale is to find a business model that decouples income from hours worked.

Consider the economics of a typical proxy deployment. A mid-sized company might run a few dozen instances of the proxy, each handling millions of requests per day. The value generated by the proxy—in terms of reduced latency, improved reliability, and developer productivity—can easily exceed tens of thousands of dollars per year. Yet the maintainer sees none of that value. This is the fundamental disconnect: the users capture the value, but the creator bears the cost.

A common counter-argument is that open source is a gift economy, and maintainers should not expect compensation. But this ignores the reality that many projects are maintained by individuals who need to pay rent. The gift economy works when maintainers have other income sources, but it breaks down when they don't. The proxy creator's story is a case study in why the gift economy is insufficient for critical infrastructure.

What a Sustainable Model Would Look Like

Dual licensing with clear usage tiers is one approach, but it requires legal infrastructure that most solo maintainers don't have. The BSL is a variant of dual licensing, but it failed in this case because the market rejected the terms. A more successful model might involve a foundation that holds the copyright and offers paid licenses for commercial use, with the funds distributed to maintainers.

Foundation-backed stewardship could work for critical path software like proxy libraries. If a neutral foundation owned the trademark and the copyright, the license could be set to require contributions from all users above a certain scale. The foundation would then distribute the revenue to maintainers based on their contributions. This would also address the bus factor, because the foundation would have the authority to appoint new maintainers.

Corporate consortium funding is another possibility. A group of companies that depend on the software could pool resources to fund its development. This already happens for some databases and web frameworks, but it's rare for middleware. The challenge is that no single company sees enough value to pay the full cost, but together they could.

The creator's own proposal, shared after his job search began, was a per-deployment microlicense. Each deployment of the proxy would incur a tiny fee—fractions of a cent per request—collected by a third-party service. This would spread the cost across all users, making it affordable for everyone while generating substantial revenue at scale. No one has implemented this yet, but it's an intriguing idea.

A more pragmatic alternative is the open core model, where the core library remains permissively licensed, and a proprietary tier adds value. For a proxy, that could include a management dashboard, advanced traffic shaping, or integration with enterprise monitoring systems. The creator of this proxy had considered this but never built the proprietary tier. In retrospect, he believes that would have been a better path: keep the core free, build a paid product around it, and avoid alienating the community.

Another model gaining traction is the "source available" license, such as the Elastic License or the SSPL. These are similar to the BSL but often more restrictive. MongoDB and Elastic have used these licenses to protect their projects from cloud providers. However, these licenses have also faced backlash and forks. The key lesson is that any license change will cause friction; the question is whether the trade-off is worth it.

Lessons for Every Maintainer Considering a License Switch

Community trust erodes faster than revenue arrives. The creator's license change was technically legal and ethically defensible, but it alienated the very people who had built the project's reputation. Trust, once lost, is very hard to regain. Any maintainer considering a license switch should expect a backlash and plan for it.

Legal costs of enforcing a new license can exceed the income it generates. The creator spent thousands of dollars on legal advice to draft the BSL terms, and then more on responding to inquiries from corporate legal teams. In the end, the revenue from paid licenses didn't cover those costs. Enforcement is expensive, and most maintainers don't have the resources to pursue violators.

An alternative is to change the license before reaching critical mass. If a project is still small, the backlash will be smaller. The creator of this proxy wished he had started with a non-permissive license from the beginning, or switched before the project became widely adopted. Once a project is embedded in thousands of deployments, any change is disruptive.

Another strategy is to build a paid product wrapper early. Instead of changing the license of the core library, maintainers can offer a proprietary version with additional features—management UI, advanced analytics, enterprise support. This keeps the core open source and preserves community trust while creating a revenue stream. Several successful projects, including some databases and message queues, have used this model.

The proxy creator now advises startups on licensing strategy, drawing from his own painful experience. He tells them to think about sustainability from day one, not as an afterthought. Open source is not a business model; it's a distribution model. The real work is figuring out how to get paid for the value you create, without breaking the trust of the community that made your project successful.

The story of this proxy is a cautionary tale, but it's also a call to action. The market for open source middleware is broken, but it doesn't have to be. With better licensing models, foundation support, and corporate responsibility, we can build a system where maintainers are compensated fairly for their work. Until then, more creators will face the same choice: change the license and risk everything, or keep giving away their work for free and burn out.