FFmpeg thanks Google for the bug reporting, now asks where the funding is

Skye Jacobs

Posts: 1,914   +58
Staff
Sounding off: As AI-driven security diagnostics become more sophisticated and widespread, the open-source projects forming the backbone of digital infrastructure will face increasing pressure to scale their responses and resources in step with the accelerating pace of automated discovery. Until technology leaders acknowledge the need for direct investment in sustaining these critical tools, the risks of unfunded maintenance and unresolved vulnerabilities will continue to compound.

FFmpeg's volunteer maintainers are facing renewed security pressure after a Google AI tool flagged a minor flaw buried deep in the project's decades-old codebase. The incident has reignited debate over who bears responsibility for safeguarding the open-source infrastructure underpinning modern media technology, exposing broader tensions between automation, corporate dependence, and unpaid maintenance.

The latest flashpoint arose when Google's automated scanner detected a "medium-impact" bug in FFmpeg's handling of the LucasArts Smush codec, an issue affecting only early versions of the 1990s game Rebel Assault II and limited to the initial frames during decoding. While developers quickly issued a patch, the episode sparked renewed concern over how security vulnerabilities are disclosed, especially as AI-driven tools generate growing volumes of largely low-priority reports.

FFmpeg's team reiterated that the project is sustained almost entirely by volunteers. To them, the imbalance between the demands of global corporations and the capacity of a small community maintaining complex multimedia code – much of it written in assembly language – has never been clearer.

That disconnect became even more apparent after open-source policy expert Mark Atwood urged AWS and other major users to stop treating FFmpeg like a conventional vendor. Despite relying on the software for critical operations, many of these companies have resisted offering financial support, even as their infrastructures depend on it.

The incident underscores growing frustration within the open-source community. Corporate users continue to reap the benefits of FFmpeg's stability and performance, yet the responsibility for fixing vulnerabilities falls on volunteers whose workloads expand with each new automated bug report, no matter how minor.

The situation also coincides with Google Project Zero's trial of a new "Reporting Transparency" policy, which requires researchers to publicly disclose vulnerabilities within one week of discovery and begin a 90-day countdown, regardless of whether a patch is ready. Google's security team argues that this accelerates fixes and strengthens accountability, but many open-source developers say it only increases pressure on volunteer maintainers who lack the resources to meet such deadlines.

Some defenders, including Chainguard's Dan Lorenc, argue that publishing vulnerability information serves the public good and that withholding it would undermine transparency – even if it temporarily increases the burden on maintainers.

But FFmpeg's developers describe the outcome as "CVE slop," a constant swell of automated reports, each treated with the same urgency as critical flaws, often forcing maintainers to spend more time on administrative triage than on actual engineering.

This isn't an isolated issue. Open-source maintainers across key projects are stepping back, citing burnout from the relentless pace of vulnerability management. Nick Wellnhofer's recent decision to step away from maintaining libxml2 – a core library embedded in nearly every operating system and browser – stands as a telling example. He cited the overwhelming volume of minor security reports and the absence of compensation as decisive factors in his resignation.

It all underscores a deeper imbalance: critical, volunteer-driven codebases are held to corporate standards for security and responsiveness, yet lack the funding or institutional support those standards demand. Corporate reliance on open source has become routine, but accountability and investment continue to lag far behind. As many maintainers now note, the issue isn't how many vulnerabilities AI can uncover, it's whether anyone is actually empowered to fix them.

Permalink to story:

 
If the AI can generate the bug report, can't it also include the PR to fix it? Or is it already doing that and the issue is even with the fix in hand it's just too much work for the project to review them all?
 
If the AI can generate the bug report, can't it also include the PR to fix it? Or is it already doing that and the issue is even with the fix in hand it's just too much work for the project to review them all?
You will spend just as much time reviewing PRs as you would creating them yourself.

The core issue is that there is not enough labor being put into the system to fix issues, and without funding that will only get worse.
 
If the AI can generate the bug report, can't it also include the PR to fix it? Or is it already doing that and the issue is even with the fix in hand it's just too much work for the project to review them all?
Not yet, it would create more issues than it pretend to fix. AI is not there yet, it is not deterministic, and falls under hallucinations. Not all of those bug reports are real, either. I think AI bubble will burst within next 5 years, and when there will be much less money to do on hype we will see real engineers fixing it and then it should be usable to actual work, not only as a guessing statistic machines.
 
Just make it easier on the maintainers - you file a bug report, you send them $xxx depending on the criticality of the bug. The amounts could be anything, but it sounds like open source maintainers need to put together a working group to set some standards and expectations for how much and how to handle these issues. This would a) fund the fixes corporations want fixed and b) maybe slow down the ai slop if companies are just churning out bugs reports without some kind of review process.
 
Just make it easier on the maintainers - you file a bug report, you send them $xxx depending on the criticality of the bug. The amounts could be anything, but it sounds like open source maintainers need to put together a working group to set some standards and expectations for how much and how to handle these issues. This would a) fund the fixes corporations want fixed and b) maybe slow down the ai slop if companies are just churning out bugs reports without some kind of review process.
A Fee. We call that a fee. A license fee. And there existed licensing structure for OSS that requires corporate payment but allows free personal use.

The FOSS community has a serious "have your cake and eat it too" problem, where they want this beautiful world where all software is free and everyone donates to keep projects going, but that is not reality. What happens is these products are released, and some companies use them without paying. That is just going to happen when you make it free. You could use the appropriate licensing structure, but then it isnt free, and rather than compromise on their worldview, the FOSS community would rather throw a fit that corporations are using the software as licensed.

If you want to be paid for your software, license it as such. If you want it to be open for personal use, then license it as OSS with corporate payment requirements. If you want it to be FOSS, then license it as FOSS, and accept that there will be times where megacorps are gonna use your tech for free. And if they submit bug reports? Dont worry about them. IF the bug goes public, and bugs enough people, then eventually someone will get enough of a bug up their butt that they will fix it and submit the patch to you.
 
I've always wondered why open-source software doesn't have a clause in its licenses that says something like, "If it's being used commercially, it gets a flat fee every year for use." I know it's hard to enforce, which is one reason why I say flat fee. If a large company depends on it, it should be pretty clear they should pay the fee. The fee doesn't have to be huge, just enough to support the project. Then at least you've put a suggested amount on the table. If you leave it up to them to pay what they think they owe, it will be nothing in most scenarios, because public companies have a fiduciary duty but not an ethical one... thank you, US Supreme Court.
 
Back