The Quiet Economics of Open Source Maintenance

Every company runs on open source, and almost none of them pay for it directly. That arrangement worked for a long time because maintenance was a hobby subsidized by nights and weekends. It's working less well now, and the reasons are worth understanding whether you ship software or just depend on it.

The invisible supply chain

The average production application pulls in hundreds of transitive dependencies. Most are maintained by one or two people. When those people burn out, get a new job, or simply move on, the code doesn't disappear — it just stops improving. Security patches slow. Issues pile up. The dependency becomes a quiet liability.

"Free software isn't free. Someone is always paying — usually in unpaid time, sometimes in unfixed vulnerabilities."

New models, actually working

The last few years produced funding models that go beyond the tip jar:

• Corporate open-source offices that pay maintainers to keep critical libraries healthy.
• Foundations that pool money from many users of a shared dependency.
• Dual licensing and open-core, where a commercial tier funds the free one.

None is perfect. All are better than hoping goodwill scales.

What this means for you

When you choose a dependency, you're making a bet on its future maintenance. Look past the star count. Who funds it? How many maintainers have commit access? Is there a company or foundation with a reason to keep it alive? Those questions predict whether your dependency will still be safe to use in three years far better than any benchmark.