For decades, the open source movement ran on a simple social contract: developers write code, share it freely, and the community benefits. That contract is fraying. A growing number of independent developers and small teams are experimenting with models that would have been heretical a decade ago — charging money for open source software, directly, without apology.
The shift isn’t sudden. But it’s accelerating.
A wide-ranging discussion on Hacker News this week surfaced dozens of developers who are successfully selling software they’ve built — tools, utilities, SaaS products, desktop applications — many of them solo operators pulling in anywhere from modest side income to six- and seven-figure annual revenues. The thread, which drew hundreds of responses, reads less like a bragging contest and more like a field report from a generation of builders who’ve figured out that giving everything away doesn’t pay the mortgage.
The products span an enormous range. Calendar apps. PDF tools. Browser extensions. API monitoring services. Invoicing software. Privacy-focused email clients. Niche analytics platforms for specific industries. What they share is a common DNA: small teams, often one or two people, building focused tools that solve specific problems and charging users directly for the value delivered.
One recurring theme stands out. Many of these developers explicitly rejected the venture-backed startup path. They didn’t want to raise money, hire fast, and chase hockey-stick growth. They wanted to build something useful, charge a fair price, and maintain control over their time. The term “indie hacker” gets thrown around, but what’s happening here is more substantive than a lifestyle brand. It’s a structural shift in how software gets funded and distributed.
Consider the economics. A solo developer building a focused tool has near-zero marginal costs once the product is built. No sales team. No office. Marketing often consists of a personal blog, a presence on X, and word of mouth in developer communities. If the product solves a real pain point, customers find it. If it doesn’t, no amount of marketing will save it. The feedback loop is brutally direct.
This model has always existed in some form. Shareware in the 1990s. WordPress plugins in the 2000s. But what’s different now is the infrastructure available to independent developers. Payment processing through Stripe takes minutes to set up. Distribution happens through app stores, package managers, or direct downloads. Customer support can be handled through email or a simple help desk tool. The barriers that once required a company — payroll, legal, distribution, billing — have been reduced to configuration files and API calls.
And the market is receptive. After years of free products that monetize through advertising, data harvesting, or eventual enshittification, a meaningful segment of users — particularly technical users and small business owners — actively prefer to pay for software. They understand the transaction. Money for product. No hidden incentives. No pivot to ads. No acquisition that kills the tool they depend on.
Several developers in the Hacker News discussion reported that their paying customers are more loyal, provide better feedback, and churn less than users of free products. That’s not surprising. When someone pays for a tool, they’ve made a commitment. They want it to work. They’ll tell you when it doesn’t. Free users, by contrast, often disappear without a word.
But the model has limits. Discovery remains the hardest problem. The App Store and Google Play are flooded with competitors. Standing out requires either a genuinely superior product, a strong personal brand, or both. Several developers noted that their most effective marketing channel was writing detailed technical content — blog posts, tutorials, documentation — that attracted exactly the kind of users who would value their product. Content as a sales funnel, but without the cynicism that phrase usually implies.
Pricing is another minefield. Charge too little and you signal low quality while leaving money on the table. Charge too much and you limit your addressable market. Multiple developers reported experimenting extensively with pricing — raising prices, adding tiers, switching from one-time purchases to subscriptions and back again. The consensus, to the extent one exists, is that most indie developers undercharge. Dramatically.
One developer described raising prices by 3x and seeing no meaningful drop in conversions. Another reported that switching from a $9/month subscription to a $199/year plan actually increased revenue because it attracted more serious customers who were less likely to cancel. The psychology of pricing, it turns out, matters as much as the absolute number.
The subscription versus one-time purchase debate generates strong opinions. Subscriptions provide predictable recurring revenue, which makes planning easier and valuations higher if you ever want to sell. But many users — especially developers — loathe subscriptions. They’ve been burned too many times by products that go subscription-only after years of one-time purchases. Some indie developers have found a middle path: a one-time purchase with optional paid upgrades for major new versions. It’s the model that sustained commercial software for decades before SaaS became the default.
There’s a philosophical dimension here too. The open source community has long struggled with sustainability. Maintainers of critical infrastructure — libraries used by millions of applications, by Fortune 500 companies, by governments — often work for free or for donations that amount to pennies per hour of effort. The Hacker News thread surfaced frustration with this dynamic. Why should a developer who builds something useful give it away when the companies profiting from it won’t contribute back?
Some developers have adopted dual licensing as a compromise. The code is open source under a copyleft license like AGPL, which requires anyone who modifies and deploys it to also open-source their changes. Companies that don’t want to comply with those terms can buy a commercial license. It’s a model that respects the principles of open source while creating a revenue stream from companies that derive commercial value from the software.
Others have gone further, adopting source-available licenses that allow users to view and modify the code but restrict commercial use without a paid license. This approach has drawn criticism from open source purists who argue it violates the definition of open source. The developers doing it generally don’t care about the semantic debate. They care about getting paid.
The broader industry context matters. Large technology companies have spent the last two decades building business models that depend on open source software — running it on their cloud platforms, embedding it in their products, training AI models on it. The value extracted from open source by these companies is measured in hundreds of billions of dollars. The value returned to the developers who created it is… less.
This asymmetry has driven a wave of license changes among venture-backed open source companies. HashiCorp switched from the Mozilla Public License to the Business Source License. Redis moved away from the BSD license. Elastic abandoned the Apache License. Each move triggered the same cycle: outrage from the community, forks of the project, and ultimately an acknowledgment that the old model wasn’t working for the people building the software.
Indie developers are arriving at the same conclusion through different channels. They don’t have boards or investors pushing them toward monetization. They simply look at their bank accounts and their time sheets and make a rational calculation. If the choice is between giving software away for free and burning out, or charging for it and sustaining the project for years, charging wins.
So where does this go?
The most likely outcome is a continued fragmentation of the software market into tiers. At the top, massive open source projects backed by foundations or corporate sponsors — Linux, Kubernetes, PostgreSQL — will continue to be free. At the bottom, hobby projects and learning exercises will remain free because their creators aren’t trying to make money. But in the middle, where focused tools solve specific problems for identifiable users, paid software will become increasingly common. And increasingly accepted.
The tools for building and selling software independently are only getting better. AI coding assistants are making solo developers more productive. No-code and low-code platforms are expanding the range of what a single person can build. Payment infrastructure is simpler than ever. Distribution channels, while noisy, are accessible to anyone.
What’s needed most isn’t better technology. It’s a cultural shift — one that’s already underway — in which paying for software you use is seen not as a burden but as an investment in the continued existence of that software. Every time a developer charges for their work and a user pays willingly, it reinforces a model that’s more sustainable than the alternative. More honest, too.
The era of “everything should be free” was never really free. Someone always paid, whether through ads, data, or the unpaid labor of maintainers who eventually burned out. The developers putting price tags on their code aren’t breaking the social contract of open source. They’re writing a new one. And based on the evidence accumulating in forums, on X, and in the revenue numbers these builders are sharing, the market is signing on.
WebProNews is an iEntry Publication