Open Source, Unpaid Expectations | Blog of Anant Shrivastava

Most widely used open source licenses start with the same idea: “no warranty, no liability.” It is as explicit as legal text can be. Use it if you want, at your own risk. And yet, every time something breaks, the world turns around and blames the developer.

Somehow, that simple clause of “no obligation” became invisible in practice. We built a culture that holds unpaid volunteers to the same standards as billion dollar corporations. If a small library misbehaves, the question is rarely “why didn’t the company test this?” It becomes “why didn’t the maintainer fix it yet?”

Every vulnerability becomes a headline, every maintainer becomes a villain, and every apology is demanded in triplicate.

The Misuse of Accountability

Even when multi billion dollar corporations rely on volunteer built tools, they often behave as if maintainers owe them service level agreements. When a flaw shows up, too many organizations treat disclosure like a hot potato. They drop it back with a deadline and call it responsibility.

Disclosure norms were built to pressure corporations that had budgets, release teams, and legal cover. In many cases, they did work. But the same process, applied to individuals, creates a strange distortion. Volunteers do not have a QA department. They do not have a security team. They do not have a manager who can reshuffle priorities because a PR crisis is brewing.

Finding a bug and forcing a deadline without offering help is not responsibility. It is arrogance dressed up as process.

If you benefit, contribute. Money helps, but so do patches, testing, triage, and plain empathy.

This is also why I like Dan Lorenc’s thread. It adds nuance. It is not always a pure “funding problem.” Sometimes money exists, but it does not flow to the right place, or it arrives with strings attached.

The Myth of Free Labor

We repeat “open source is free” so often that we forget what “free” actually means. Free to use is not the same as free of responsibility for how you use it. No one forces you to adopt someone’s code. There is no sales pitch, no NDA, no onboarding call where you get a false sense of safety.

You chose it.

If it breaks, you are still responsible for your own house.

And because humans love easy targets, we aim at the maintainer. It is simpler than admitting that an entire corporate ecosystem depends on unvetted, unpaid work.

Somehow, “thank you for sharing” quietly became “you owe us uptime.”

A great example of this tension shows up in Salvatore Sanfilippo’s reflection, the creator of Redis. He stepped away from his company when his role became more about business than technology. His story captures an essential truth: not every developer wants to scale, monetize, or manage teams. Some want to build, learn, and share. That motivation gets flattened when we treat every open source repo as a pipeline to profit.

The Many Faces of Open Source

Open source is not a single identity. It is a crowded room of very different people wearing the same label.

1. The Job Seeker: writes to demonstrate competence and land opportunities.
2. The Builder: shares for joy, curiosity, and the urge to tinker.
3. The Business: balances openness with sustainability and a clear support model.
4. The Idealist: believes software should belong to everyone.
5. The “I do not care” Hacker: publishes code because sharing is easier than maintaining it privately.

And yet, the world lumps them together. When something breaks, nobody pauses to ask which one wrote the code. The job seeker did not sign up for audits. The hobbyist did not promise support. The idealist did not agree to SLAs. The hacker did not intend to scale.

But liability finds everyone equally.

The Cost of Uniform Expectations

This flattening is why many developers quietly stop sharing.

The corporate user wants stability.
The individual creator wants freedom.
The regulator wants control.
The community wants trust.

Trying to satisfy them all with one set of expectations guarantees that no one wins.

Look at the Google Play ecosystem.

In its early days, it was a wild bazaar where anyone could upload an app. It was chaotic, but it was also full of creativity.

Now, in the name of safety, even developers who do not distribute through the Play Store can be pushed into verification requirements just to exist in the same ecosystem. The same company that once welcomed every developer is now too busy managing its own scale.

I am not arguing against safety. I am arguing that control grows faster than empathy. Once systems scale, they tend to protect themselves first.

The Corporate Blind Spot

Take FFmpeg, the backbone of modern multimedia.

When vulnerabilities appear, organizations that depend on it often expect volunteers to fix them, on a schedule the volunteers did not agree to. The organization did not write the code. They discovered a flaw. But instead of contributing patches or funding maintenance in a direct and sustained way, they set timelines and demand compliance.

To be fair, some large companies do fund open source security work. Google, for example, runs a Patch Rewards Program and an Open Source Security Rewards initiative. Those are real efforts, and they help.

But they also highlight the uncomfortable pattern. We have normalized a world where finding flaws is organized, incentivized, and celebrated, while fixing and maintaining is treated as optional charity.

If the intent is truly to strengthen open source, another approach is direct ownership of the problem. Fork critical components, patch them, maintain them, and upstream what you can. Large organizations already do this when it matters enough, like Blink (a WebKit fork) and BoringSSL (an OpenSSL fork).

Money alone is not the solution. Ownership and effort are.

I argued something adjacent to this a decade ago in The Glorification of Pentesters.

Back then, the industry celebrated the people who broke things while ignoring the ones who built them.

Today, the pendulum swings even further. We glorify the breakers, then we burden the builders with the aftermath. It feels like a loop we never escaped.

Dead on Arrival, by Design

A friend once told me:

Treat open source as dead on arrival.

Write it. Release it. Move on.

If people use it, good for them. If they do not, good for you.

The moment you start worrying about its afterlife, you lose your freedom.

That cynical wisdom makes more sense every year. We conditioned ourselves to believe open source should pay. Maybe it can, but only for those who want that path. Not everyone wants to run a company around their repo.

Some people want to share and disappear.

Choice, Not Compliance

Maybe the answer is to formalize that choice.

If you want enterprise adoption and enterprise money, then choose the enterprise path. Publish SBOMs. Ship reproducible releases. Run updates like a product. Put support behind a paid model.

If you do not want that, choose the free path. No guarantees, no obligations, just pure sharing.

Let corporations pay for the privilege of expecting things.

And let’s be honest, donations are not only money. They can be money, code, time, documentation, testing, triage, and community management. If you have contributed none of these, you do not get to demand anything.

You can use the software, sure. You just do not get to act entitled.

Even if you have contributed, your expectations should still be lower than what you would demand from a paid vendor. Open source is generosity, not service.

The irony is that by piling expectations on maintainers, we made them the weak link in the system.

Attackers do not need to go after fortified corporations anymore. They go after the unpaid volunteer whose code runs inside those corporations. By placing so much responsibility in the hands of individuals with no safety net, we turned open source developers into attack surfaces.

Not because they did something wrong, but because everyone else offloaded risk onto them and called it collaboration.

If we truly care about security, we should start by protecting the people who make the tools we depend on, not punishing them for being human.

This tension is not new. The OpenSSF statement on sustainable stewardship calls it out clearly: open infrastructure is not free, and pretending it is only worsens fragility. The Software Maxims piece, “Not a Supplier”, makes the same argument from another angle: open source authors are not vendors, and treating them as such is both wrong and short sighted.

Together, they point to one reality. The current system rewards intermediaries more reliably than it rewards creators.

The Paradox of Reach

Of course, freedom comes with a price.

Software that rejects support and commercial polish rarely gets adopted widely. Corporations avoid GPL like licenses because they demand reciprocity. Reach often comes from compromise.

You either give up some freedom for visibility, or you give up reach for peace.

Neither choice is wrong. The problem is pretending they are the same.

That famous XKCD comic #2347 about a single unpaid maintainer holding up the modern world stopped being funny years ago. It is now documentation.

Maybe This Is the Balance

So perhaps the path forward is not “fixing open source.” It is accepting its duality.

Open source is both chaos and order.
Generosity and exhaustion.
Freedom and frustration.

Maybe the only sustainable model is honesty. Developers declare what they can give, users respect those limits, and organizations stop outsourcing morality to volunteer time.

Freedom does not mean free of consequence.
It means knowing which consequences you accept.

Practical notes

If you build open source for fun: Ship what you can, say “no” early, and write your boundaries down. Your repo is not a contract.

If you build open source to make money: Treat it like a product. Offer clear paid support, clear release practices, and clear expectations, then let the free tier remain genuinely free.

If you are an organization: Assume responsibility by default. Fund the maintainers, contribute code and testing, or maintain your own fork. Do not outsource operational risk to unpaid goodwill.