The Irony of Our Own Success
We built the internet on open source. Linux, Apache, MySQL, PHP—the entire LAMP stack that powered the early web. We shared code freely, collaborated across continents, and believed that better software emerged when everyone could see how it worked. The cathedral gave way to the bazaar, and for a while, it felt like we were winning.
Fast forward to 2026, and that same culture is being used against us. The tools we built to empower everyone are being locked behind paywalls. The APIs we documented meticulously are being turned into revenue streams by companies that contributed nothing to their creation. And the worst part? We helped build the infrastructure that makes this possible.
I've been in this industry for twenty years. I remember when "open source" meant freedom, not freemium. When sharing code was about making things better, not building a user base to monetize later. Something fundamental has shifted, and it's time we talked about it.
The Bait and Switch: From Open Source to Open Core
Remember when Redis was just Redis? When MongoDB was just MongoDB? These projects followed a familiar pattern: build something amazing, get massive adoption, then introduce commercial licensing for the "enterprise features." What starts as truly open source gradually becomes what we now call "open core"—where the basic version remains free, but everything you actually need costs money.
The discussion on Reddit highlighted this perfectly. One developer shared their experience with a popular database tool: "We built our entire infrastructure around it, only to find out the clustering features we needed were suddenly part of a $50,000/year enterprise license. It felt like a betrayal."
And here's the kicker—these companies often rely on community contributions to improve their core product. Volunteers fix bugs, add features, and improve documentation, while the company builds proprietary extensions on top. It's extractive capitalism dressed up as open collaboration.
The API Monetization Trap
This is where it gets particularly painful for those of us working with APIs and integrations. We've spent years building robust, well-documented APIs for our open source projects. We wanted to make integration easy. We wanted to encourage adoption.
Now, companies are taking those same APIs and putting them behind usage-based pricing. What was once a simple HTTP endpoint becomes a metered service. Need more than 1,000 requests per day? That'll be $99/month. Want webhook support? That's in the $299 tier.
I recently worked with a project that had this exact problem. Their open source library had been forked, wrapped in a SaaS offering, and was now being sold back to their own community. The original maintainers couldn't compete—they were volunteers, while the company had venture funding.
The Infrastructure Tax
Here's something that doesn't get talked about enough: the hidden cost of cloud dependency. When everything moves to the cloud, your open source project becomes someone else's revenue stream.
Take container orchestration. We built Kubernetes as an open source project. Now, every major cloud provider offers it as a managed service—and they're making billions. The companies providing the actual infrastructure capture most of the value, while the developers who built the software get... well, they get to list it on their resume.
Or consider serverless functions. The code might be open source, but you can't run it without the platform. And once you're locked into that platform, the pricing models get creative. Suddenly, you're paying for execution time, memory allocation, cold starts—all the things we used to handle ourselves with a simple VPS.
The Burnout Economy
Let's talk about the human cost. The Reddit discussion was filled with stories of maintainer burnout. Developers who started projects for fun, watched them grow to millions of users, and now spend their nights dealing with support requests, security vulnerabilities, and entitlement.
"I get emails at 3 AM demanding fixes for edge cases in my free library," one maintainer wrote. "Meanwhile, companies are building million-dollar businesses on top of it without so much as a thank you."
We've created a system where individual developers bear the emotional and technical burden, while corporations capture the financial value. And when maintainers try to monetize their work? They're accused of "selling out" or "betraying the open source ethos." It's a no-win situation.
The Corporate Capture of Standards
This might be the most insidious development. Remember when web standards were developed through consensus? When WHATWG and W3C worked (mostly) in the public interest?
Now, look at what's happening with AI APIs. Major companies are creating de facto standards through their proprietary APIs, then charging for access. Want to use the "industry standard" vision model? You'll need to go through their API—and pay per request.
Even when these companies open source some components, they keep the training data, the weights, or the infrastructure proprietary. It's open source theater—enough to claim the mantle of openness, but not enough to actually enable competition.
What Can We Actually Do About It?
I'm not here to just complain. After talking with dozens of developers and studying successful projects, here's what I think we can do:
Choose Licenses Strategically
The AGPL license gets a bad rap, but it's one of the few that prevents SaaSification of your work. If someone wants to offer your software as a service, they need to open source their modifications. It's not perfect, but it's better than MIT or Apache for preventing extraction.
Some projects are experimenting with new approaches like the Business Source License (BSL), which allows free use for most purposes but requires a license for commercial SaaS offerings. It's controversial, but it might be necessary.
Build Sustainable Funding Models
GitHub Sponsors, Open Collective, and similar platforms aren't perfect, but they're better than nothing. The key is to start early—don't wait until you're burned out to ask for support.
Consider offering commercial licenses from day one. Have a clear, transparent pricing page. Make it easy for companies that are making money from your work to pay their fair share.
Document Everything
This might sound basic, but it's crucial. When you're dealing with APIs and integrations, clear documentation is your best defense against being replaced by a proprietary wrapper.
I've seen projects where the official documentation was so good that there was no market for "premium" documentation or training. Make your project easy to use without middlemen.
Use Automation to Level the Playing Field
Here's a practical tip: automate your infrastructure. If you're offering a service, use tools that handle scaling, monitoring, and deployment automatically. This reduces the advantage that well-funded companies have.
For example, if you're dealing with web scraping or data extraction as part of your API service, consider using a platform like Apify to handle the infrastructure. It lets you focus on your core logic rather than building scraping systems from scratch. The point is to reduce the operational overhead that gives big companies an advantage.
Common Mistakes (And How to Avoid Them)
I've made most of these mistakes myself, so learn from my experience:
Mistake #1: Assuming good intentions. Not every company using your open source project is acting in good faith. Some are explicitly looking to extract value. Protect yourself with clear licensing and boundaries.
Mistake #2: Underestimating operational costs. That "simple" API you built might need monitoring, rate limiting, security updates, and support. Plan for these costs from the beginning.
Mistake #3: Trying to do everything yourself. If you need specialized skills—like UI design for your admin panel or DevOps expertise—consider hiring a freelancer. Your time is better spent on core development.
Mistake #4: Ignoring the business side. You're building software that has value. It's okay to think about how to capture some of that value. Read Working in Public: The Making and Maintenance of Open Source Software to understand the dynamics better.
A Path Forward (That Doesn't Require Selling Out)
Look, I'm not saying we should abandon open source. The culture of collaboration we built is still valuable. The transparency still leads to better software. The accessibility still empowers people who couldn't afford proprietary solutions.
But we need to be smarter about how we operate in 2026. We need to recognize that our generosity is being exploited. We need to build systems that are sustainable for maintainers, not just convenient for corporations.
Maybe that means more copyleft licenses. Maybe it means more cooperative ownership structures. Maybe it means being more selective about who we collaborate with.
What I know for sure is this: we built the modern digital world through open collaboration. We can build a sustainable future for that collaboration too. But first, we need to stop letting other people profit from our work without giving back.
The next time you're about to open source something, ask yourself: who benefits most from this? If the answer is "everyone but me," maybe reconsider your approach. Your code has value. Your time has value. Don't let anyone convince you otherwise.
