Open Source has a "free rider" problem
It might be called "free software" but we still don't want "free riders"
The recent kerfuffle between Google and FFmpeg, where Google used AI to identify relatively meaningless security vulnerabilities and changed its policy to put time pressure on maintainers to fix them, is the latest in a long history of issues around ownership and compensation for open source projects. It also resurfaces some important questions:
Who should be responsible for fixing security vulnerabilities?
How do we want to use AI tools to identify security issues in open-source software?
Why should we expect a bunch of unpaid volunteer software maintainers to fix software for free on behalf of companies that have made trillions of dollars?
The dispute has grown heated, with FFmpeg developers publicly urging Google to either help fund maintenance or stop sending them so many issues to repair. They argue that a giant corporation with so many AI resources shouldn’t dump unpaid work on a volunteer community.
Issues around large tech companies and Open Source software aren’t new. For example, in 2015 Amazon started selling Elasticsearch as a service without asking Elastic (the company behind it). Elastic claimed that Amazon was confusing customers and stealing their code. Ultimately Elastic changed the software license to stop cloud companies from reselling it, which led to a whole debate around what counts as “open source” vs not.
Both of these are examples of the problems that arise when a company starts making money from software developed by others, but they’re far from the only examples.
Companies, particularly large corporations like Google or Amazon, profit enormously from many open-source projects while contributing little towards their maintenance. This creates a classic collective action problem where everyone benefits from volunteer work, but no one has individual incentive to pay for it.
The conflict fundamentally comes down to a question of money, specifically: who should pay for the work of identifying (and fixing) the issues (including security vulnerabilities) that exist in open software?
Framed this way, the answer feels pretty obvious to me: if companies are making a lot of money from open source software, they should contribute some of those gains to actually fixing the software they rely on.
It’s not the code. it’s the culture
The core problem here is sociological rather than technical.
Open source culture was built on individual passion projects with manageable contribution levels, but this model breaks down when corporations scale up demands without proportional support. If companies increasingly use AI tools to generate massive amounts of bug reports and security findings, maintainers simply won’t have the bandwidth to keep up.
Expecting volunteer maintainers to address an avalanche of AI-generated issues or pull requests on behalf of Google and similar tech giants is clearly unreasonable. Maintainers shouldn’t bear sole responsibility for resolving problems surfaced primarily through corporate AI systems rather than genuine community needs.
But this is about more than just security issues and bug fixes. There are bigger questions in play, including:
Who should pay to keep the software up-to-date as the broader software ecosystem evolves?
Who should pay for the direct (and indirect) costs of adding new features?
Who should be responsible for helping users, updating documentation, and the hundred other things that go into creating a healthy, thriving open source project?
The obvious answer to “who should pay for these costs” is “whoever is incurring the costs” and “whoever is making money from the software”. That is, the companies that are building on top of any given open software project.
The licenses are actually quite clear about whose responsibility it is to fix bugs--it’s literally the first sentence in all caps in the MIT License:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
It’s hard for me to read that as saying “Oh but don’t worry we’ll totally fix all the bugs for you”. Rather, what it says very clearly, is that you, the user, are responsible for making this software usable for yourself. For Google to effectively bully open source projects by threatening to publicly release zero-day exploits, rather than going through the project’s proper security channels and processes, is obviously hostile.
To its credit, Google does have its Bug Hunters bug bounty program. The company is also generally one of the better actors in the space, sponsoring a wide variety of open source software and programs (like Google’s Summer of Code). In 2024, the company’s Open Source Programs Office provided $2 million in sponsorships and membership fees to more than 40 open source projects and organizations. But the fact that we’re talking about Google being a “good actor” when they’re making direct contributions of 0.0006% of their revenue towards open source is at least a little bit silly1.
Where do we go from here?
Work is clearly still needed to improve these systems. Many of the bugs in the ffmpeg controversy didn’t even qualify for the Bug Hunters program, and there are plenty of other libraries Google uses without any compensation at all.
We need more exploration and participation in this space. There are bug bounties, but very little money is transferred to the people who solve them. There are mechanisms for donating to open-source projects, but almost no companies make any contributions. There is a pledge for supporting Open Source software, but very few companies have signed on. There are some companies that allow some employees to work on open-source software, but the vast majority of software engineers are not paid to contribute to open-source projects.
This is a classic “free rider” or “collective action” problem. Companies benefit massively from the volunteers who create and maintain open-source software, yet have little incentive to contribute. As open-source adoption increases, so does the maintenance burden on volunteer maintainers. When overworked maintainers burn out and abandon projects, the entire ecosystem suffers.
Solving this collective action problem starts with acknowledging an uncomfortable truth: companies extracting value from open source have a responsibility to sustain it. Open-source software has become too vital to our infrastructure to rely on goodwill alone.
As software creation costs continue to collapse, millions of people are about to start creating software. We need infrastructure that makes the implicit norms explicit and enforceable, where commercial use requires negotiation, not just goodwill.
If you’d like to see something happen about this, maybe it’s time we started talking about it. Share this article, leave a comment, or send me a note!
Yes, Google also has employees that work on Open Source projects, but it's complicated by the fact that there are business strategy reasons to release software as open source, and thus many of the "open source contributions" to their own projects are more "code that Google was going to write anyway and which happens to be open" rather than an attempt to foster a healthy open source ecosystem