In November 2025, a handful of software maintainers had a public argument with one of the largest companies on earth about who should be doing unpaid work. The maintainers were FFmpeg’s. The disputed work was triaging a bug found by an automated system at a company FFmpeg’s own account described as a “trillion-dollar corporation.” The bug lived in a decoder for a video format used by a 1995 LucasArts game.
Described that way, it sounds petty. It isn’t. The phrase FFmpeg volunteer project simultaneously understates how much of the world’s video passes through this code and overstates how many people are paid to keep it working — and the gap between those two facts is one of the most consequential unsolved problems in modern software. It is the same gap that produced Heartbleed, Log4Shell, and the xz-utils backdoor, each of which arrived as a surprise only to people who had never looked at who was maintaining the affected code.
This is not a morality play. Nobody in the November 2025 story behaved badly. That is precisely what makes it worth understanding: it is a structural problem wearing the costume of a personal one.
The November 2025 Argument, Reported Straight
What happened
Google’s Big Sleep — an AI-driven vulnerability-discovery system developed out of Google Project Zero and Google DeepMind — analysed FFmpeg’s source and flagged a memory-safety bug in the decoder for LucasArts Smush, a video format from the mid-1990s. The reachable content was reported as the first ten to twenty frames of a full-motion-video sequence in Star Wars: Rebel Assault II, a game released in 1995.
FFmpeg fixed the bug. Then FFmpeg’s project account posted a public objection, reported by It’s FOSS on November 14, 2025 and by Slashdot on November 11, 2025, calling the report “CVE slop” and arguing:
“We take security very seriously but at the same time is it really fair that trillion-dollar corporations run AI to find security issues in people’s hobby code? Then expect volunteers to fix.”
The argument attached to that quote was about arithmetic, not principle. An automated discovery pipeline can generate reports far faster than a volunteer triage queue can absorb them, and each report arrives with a disclosure clock attached. Per It’s FOSS’s account of the incident, Google’s practice is to announce discovered vulnerabilities publicly within about a week of reporting, with a 90-day clock running regardless of whether a patch has landed. That schedule is designed to protect users from vendors who sit on bugs. Applied to a project with no vendor — no on-call rotation, no security team, no one whose job this is — it functions as an unfunded mandate.
What the other side of it looks like
Being fair here matters more than being sympathetic.
The bug was real. Memory-safety defects in media decoders are not theoretical; a decoder is a large, fast, memory-unsafe parser that runs automatically on data supplied by strangers, which is why this class of software attracts fuzzing in the first place. “Nobody will ever open a 1995 LucasArts video” is an assumption about attacker behaviour, and assumptions about attacker behaviour are exactly what security research exists to falsify. Google did not fabricate a problem.
Nor is this the whole of the Google–FFmpeg relationship. On January 10, 2014, Google engineers publicly announced that a cooperative fuzzing effort had found and helped fix more than a thousand bugs in FFmpeg over the preceding two years — free labour, at scale, in the same codebase. The 2014 and 2025 episodes are not two different relationships. They are one relationship at two points in time, and any account that shows you only one of them is selling something.
The honest counter-arguments to FFmpeg’s position are worth stating plainly: large users contribute in forms that never appear as a cash line item — fuzzing infrastructure, hardware, engineering time upstream, security research. And maintainers, not their users, set a project’s triage scope; nothing compels a volunteer project to work a report on a 1995 game decoder at all. It could deprecate the decoder, or mark the report wontfix, and the disclosure clock would run out on a bug in code nobody ships in a threatened configuration.
What that response costs, though, is reputation — and reputation is one of the few assets an unfunded project actually has.
| January 2014 | November 2025 | |
|---|---|---|
| What Google’s tooling did | Cooperative fuzzing campaign | Automated AI discovery pipeline (Big Sleep) |
| Reported outcome | 1,000+ bugs found and fixed over two years | One memory-safety bug in a 1995-era decoder |
| Who absorbed the triage cost | Shared — Google engineers worked fixes upstream | FFmpeg volunteers |
| How it was received | As a contribution | As “CVE slop” |
| What changed in between | Discovery got cheap and fast; triage did not |
The variable that moved is discovery cost. When finding bugs required a skilled human, the number of reports a volunteer project received was naturally rate-limited by the scarcity of people willing to do it. Automated discovery removes that limit on one side of the exchange and leaves it in place on the other. This is the same asymmetry now appearing across security research generally — as AI systems that can find vulnerabilities faster than humans can triage them move from research demos into routine tooling, every under-resourced dependency in the world inherits the queue.
How Much of the World Actually Runs This Code
The headline says phone, browser, and car. The honest version of that sentence is more interesting than the confident version.
Here is what is documented. Chromium — and therefore Chrome, Edge, and the long tail of Chromium-derived browsers and embedded shells — ships FFmpeg code directly. Chromium’s own README.chromium for third_party/ffmpeg describes its copy as “a fork of the upstream git repository,” manually merged, deliberately carrying no GPL-licensed components. Firefox uses FFmpeg for native playback on Linux. VLC, Kodi, Plex, HandBrake, Shotcut, OBS, and Blender all build on the libraries. YouTube’s pipeline uses it. So, at the far end of the range, does NASA’s Perseverance rover, which compresses imagery with FFmpeg before transmitting it to Earth. (If you want the architectural reason so many different products link the same code rather than shelling out to a command-line tool, that distinction is worth understanding on its own terms — and it is why “X is a GUI for FFmpeg” is almost always wrong.)
What about the car? Automotive infotainment overwhelmingly runs Linux-based stacks and Chromium-derived browsers, which makes FFmpeg code overwhelmingly likely to be present. But “overwhelmingly likely” is the strongest honest claim available, and the reason for that is the most important fact in the whole story:
Nobody can produce a complete list of the devices running FFmpeg — including FFmpeg.
That is not carelessness. It is what the licence means. FFmpeg is LGPL-2.1-or-later by default. Under the LGPL you may dynamically link the libraries into a proprietary product and ship it worldwide, provided you publish the corresponding FFmpeg source and your build configuration alongside the binary. You do not register. You do not notify anyone. You do not sign anything. A company can ship FFmpeg in fifty million units and never once appear in the project’s inbox — and be fully compliant while doing it.
So the deployment footprint is uncountable by design, and the maintainer count is small by circumstance, and no mechanism connects the two numbers. That disconnection is the whole story. Everything else is detail.
The Funding Patchwork
FFmpeg is not unfunded. It is funded in a way that reliably produces servers and conference travel and almost never produces salaries.
Donations flow through Software in the Public Interest (SPI), the nonprofit that acts as FFmpeg’s fiscal sponsor. (This detail is widely misreported — FFmpeg is not a Software Freedom Conservancy member project, whatever you may have read.) FFmpeg’s donations page is specific about what the money is for: “expenses related to development (e.g. to cover equipment and server maintenance costs), to sponsor bug fixing, feature development, the participation or organization of meetings and events in the project interest area, and to support internal development or educational projects.” Individual developers also accept direct donations — including cryptocurrency — and the page is explicit that those are personal gifts, independent of project funds, spent “entirely at the developer’s own discretion.”
Institutional money exists, and it is dateable. FFmpeg’s own news archive records Samsung’s Open Source Group contributing 6,000 USD on October 8, 2014, earmarked for Outreach Program for Women internships; Telepoint and MediaHub each donating a dedicated server with free connectivity on October 13, 2015; and Ampere Computing donating a 192-core AmpereOne server on June 24, 2026. The project has also run Google Summer of Code cycles. And on May 13, 2024, Germany’s Sovereign Tech Fund became FFmpeg’s first governmental sponsor, explicitly to help sustain maintenance of what it classified as a critical open-source multimedia component.
That last one matters more than its size, because it is the only item on the list that treats maintenance itself as the deliverable.
| Funding mechanism | What it reliably pays for | What it does not pay for |
|---|---|---|
| Individual donations via SPI | Servers, equipment, event travel, occasional bug bounties | Anyone’s rent, continuously |
| Direct developer tips (incl. crypto) | Whatever that developer chooses | Coordinated project priorities |
| GitHub Sponsors | Same as above, with better discovery | Predictable multi-year headcount |
| One-off corporate gifts (Samsung 2014, Telepoint/MediaHub 2015, Ampere 2026) | Specific, bounded needs — hardware, an internship programme | Ongoing maintenance |
| Google Summer of Code | Student contributions over one summer | Retention after the summer |
| Sovereign Tech Fund (May 13, 2024) | Maintenance work, named as such | Permanence — grants have terms |
| Downstream commercial use (LGPL) | Nothing. This is the point. | Everything |
Read the bottom row again. The largest category of use contributes the least reliable revenue, and that is not an abuse of the licence — it is the licence operating exactly as written. FFmpeg chose the LGPL precisely so that its code could go everywhere without negotiation. It went everywhere. The bill for that decision arrives as maintainer hours, decades later.
The bus factor was documented years before the argument
None of this is a new discovery, and the most credible account of it came from a distribution, not from the project.
When Debian’s multimedia team resolved on July 8, 2015 to switch its default back from Libav to FFmpeg — after the 2011 fork that had split the community for four years — LWN’s coverage of that debate recorded the reasoning on both sides. Debian’s stated grounds were operational: FFmpeg’s security-response latency and format coverage were measurably better. But the same debate raised a legitimate concern about FFmpeg itself, and it was arithmetic: one developer, Michael Niedermayer, accounted for 1,831 commits in the period under discussion, against roughly 100–300 for other contributors. Niedermayer had led the project since 2004 and stepped down as leader on July 31, 2015.
A ten-to-one commit ratio is not a scandal — highly skewed contribution curves are normal in open source, and often reflect one person’s extraordinary productivity rather than everyone else’s absence. But it is a measurement, and it was on the record a decade before the November 2025 argument. The people who were surprised in 2025 had simply not been reading.
xkcd 2347, and Why This Keeps Happening
In 2020, Randall Munroe published xkcd #2347, “Dependency”: a towering, precarious assembly of blocks labelled all modern digital infrastructure, with the entire structure resting on a single thin piece annotated as “a project some random person in Nebraska has been thanklessly maintaining since 2003.” The comic’s hover text extends the joke to ImageMagick and the scramble to “reassemble civilization from the rubble.”
It became the canonical illustration of this problem because it is not really a joke. The pattern it describes has a documented incident history, each case following the same three-act shape: a critical, ubiquitous, under-maintained component; a failure; a wave of attention and money arriving after the failure.
| Project | Year | What broke | What changed after |
|---|---|---|---|
| OpenSSL | 2014 | Heartbleed (CVE-2014-0160) — a TLS heartbeat bug let attackers read server memory, exposing keys and credentials. Introduced December 2011, shipped March 2012, unpatched until April 7, 2014, when Apache and nginx together held over 66% of the web-server market. | The Linux Foundation’s Core Infrastructure Initiative formed to fund under-resourced projects; OpenSSL gained sustained funding and a much larger team; the code was audited and forked (LibreSSL, BoringSSL). |
| Apache Log4j | 2021 | Log4Shell (CVE-2021-44228) — CVSS 10.0. Anyone able to control a logged string could execute code loaded from a remote LDAP server, via an unprotected JNDI lookup. Present since 2.0-beta9; fixed in 2.15.0, backported to 2.12.2 and 2.3.1. | A US White House open-source security summit in January 2022; the founding of the OpenSSF’s Alpha-Omega initiative; sustained corporate funding for critical projects. A handful of volunteers before; enterprise attention afterwards. |
| XZ Utils | 2024 | The xz backdoor (CVE-2024-3094) — not a bug but a deliberate multi-year operation: an attacker earned co-maintainer trust on an exhausted single-maintainer project and planted an SSH-compromising backdoor in the release tarballs. Disclosed by Microsoft engineer Andres Freund on March 29, 2024. | Recognition that maintainer burnout is an attack surface, not merely a sustainability concern; scrutiny of build-vs-repository discrepancies; renewed funding interest in single-maintainer dependencies. |
| FFmpeg | — | Nothing, yet. The 2025 dispute was about triage capacity, not a breach. | Which is why it is worth writing about now rather than later. |
Freund’s original disclosure post is short, and worth reading as a document of how thin the margin was. He was not auditing xz. He was benchmarking something else, noticed SSH logins burning unexpected CPU, and followed the anomaly down. Security researcher Alex Stamos later called the backdoor’s near-miss potential “the most widespread and effective backdoor ever planted in any software product.” It was caught by a performance regression and one engineer’s curiosity.
The through-line across all four rows is not “open source is fragile.” Enormous amounts of open source are robust, well-funded, and boring. It is that the correlation between how load-bearing a component is and how well-resourced it is turns out to be weak, and nothing in the system corrects it until something breaks.
The Responses, Assessed Honestly
There are real efforts to fix this. They are worth taking seriously, which means describing what each actually does rather than what it hopes to do.
Germany’s Sovereign Tech Fund treats critical open source as public infrastructure and funds maintenance directly — FFmpeg’s first governmental sponsor as of May 13, 2024. This is the most structurally correct answer on the list, because it names maintenance as the deliverable rather than funding features and hoping maintenance comes along. Its limits are equally structural: one country’s programme, grants with terms and end dates, and a pool nowhere near the scale of the dependency graph it faces.
The Open Source Pledge asks companies to pay more than $2,000 per year per employed developer to maintainers and foundations, and to report it publicly; its own site reports $7,270,139 raised, with $3M+ in the past year. The design insight is good — it converts an open-ended moral question into a computable line item, which is the only form a finance department can process. The limit is voluntariness. A pledge works best on companies whose engineering culture already wanted to pay, and has no purchase at all on a manufacturer shipping FFmpeg in an appliance who has never heard of the project.
Corporate open-source security programmes are the largest pool of money in play. The Linux Foundation–hosted Open Source Security Foundation counts GitHub, Google, IBM, JPMorgan Chase, Microsoft, NCC Group, the OWASP Foundation, and Red Hat among its founding members. Its associated Alpha-Omega initiative — backed by Anthropic, AWS, Citi, GitHub, Google, Google DeepMind, Microsoft, and OpenAI — states an annual budget of over $7 million and a mission “to protect society by catalyzing sustainable security improvements across open source, from the largest global projects to the smallest but essential components maintained by individuals.” Exactly the right target; a modest sum against the scale of the problem; and scoped to security rather than maintenance generally.
GitHub Sponsors — one of the channels FFmpeg’s donations page lists — lowered the friction of paying an individual maintainer to roughly zero, which has meaningfully changed some maintainers’ lives. What it has not changed is the shape of the distribution: sponsorship follows visibility, and the projects most in need of it are by definition the ones nobody thinks about.
| Response | What it genuinely fixes | What it structurally cannot fix |
|---|---|---|
| Sovereign Tech Fund | Funds maintenance explicitly; treats infrastructure as public good | One jurisdiction; fixed grant terms; scale |
| Open Source Pledge | Makes the ask computable and comparable across companies | Purely voluntary; invisible to non-participants |
| OpenSSF / Alpha-Omega | Serious, sustained corporate money aimed at critical components | Security-scoped, not maintenance-scoped; budget vs. dependency-graph size |
| GitHub Sponsors | Near-zero friction to pay an individual | Rewards visibility, not load-bearing-ness |
| Doing nothing | Costs nothing today | Pays later, at crisis prices — see the table above |
None of these is a bad idea. Collectively they are a set of partial answers to a problem that does not have a clean one, because the underlying economics are genuinely hard.
Why This Is Structural, Not a Villain Problem
“Big company uses free software without paying” is not a scandal. It is the intended behaviour of the licence, and every user of open source — including you, right now, reading this in a browser — is doing the same thing at a smaller scale. Treating this as a morality story about corporate greed gets the diagnosis wrong and therefore gets the prescription wrong too.
Maintained open-source software is close to a textbook non-excludable good: the maintainer cannot prevent non-payers from benefiting, and one company’s use does not diminish another’s. Economics predicts underfunding for goods with that shape, reliably, regardless of anyone’s intentions. Which is precisely what we observe.
Two further mechanisms make the media stack worse than average. First, the licence deliberately removes the point of contact. LGPL compliance requires publishing source and build configuration; it does not require saying hello. A relationship that never begins cannot generate a budget line. Second, the code is vendored and forked, as Chromium’s own README documents — meaning downstream products carry their own copies on independent patch cadences, and even a company that fully intends to be a good citizen may be several merges away from upstream. “Upstream fixed it” and “you are patched” are different sentences.
There are alternative structures, and one sits right next door. VideoLAN — the French nonprofit behind VLC, x264, and dav1d — took a different bet: a legally incorporated organisation with an elected board, and a commercial-licensing business selling non-GPL rights to x264 for companies that cannot open their own products. Same copyleft code given away, plus a recurring revenue stream from the subset of users who need something the free licence does not grant. (Attribution precision, since it is routinely mangled: x264 and dav1d are VideoLAN’s; x265 is MulticoreWare’s, built on x264 code licensed from VideoLAN — even though VideoLAN’s own current site lists x265 among its projects, an imprecision worth flagging rather than repeating.)
| FFmpeg | VideoLAN | |
|---|---|---|
| Legal structure | Fiscal sponsorship via SPI | Incorporated French nonprofit, elected board, autonomous since 2009 |
| Revenue shape | Donations, grants, one-off gifts | Donations plus recurring commercial-licensing revenue (x264) |
| Overhead | Low — few formalities to maintain | Higher — a real organisation to run |
| Resilience | Fragile; depends on individuals | More durable; survives individual departures |
| Trade-off | Maximum reach, minimum obligation | Slower, more structure, more continuity |
Neither is the correct answer. They are two defensible responses to the same question, and the trade-off generalises to any team deciding how to sustain shared infrastructure over decades.
The comparison to draw here is not to a company. It is to other volunteer-held infrastructure with the same profile — projects where the funding model and the threat model are the same conversation. The Tor Project’s funding paradox is the closest analogue on this site: critical infrastructure, an awkward funding base, and a community that has had to think publicly about who pays and what that buys them. FFmpeg has not yet had that conversation with the same rigour, largely because nothing has forced it to.
What Actually Moves the Needle
The useful actions are boring and specific:
- Know what you ship. Most organisations cannot answer “which version of FFmpeg is in our product, and how far behind upstream is it?” That question sits upstream of every other one, and it is the same discipline supply-chain security for any dependency demands.
- If your company depends on it, fund it as a line item, not a gesture. A recurring budgeted contribution beats a larger one-off, because maintenance is a recurring cost.
- Contribute triage, not just reports. The scarce resource in the November 2025 story was never bug discovery — it was the human attention needed to assess, reproduce, prioritise, and fix. A report with a reproducer, a scope assessment, and a proposed patch costs a maintainer minutes; one without costs hours.
❓ Frequently Asked Questions
Is FFmpeg really maintained entirely by volunteers? Not literally — some contributors are employed by companies that use FFmpeg and contribute during work hours, and grant money like the Sovereign Tech Fund’s May 2024 sponsorship funds real maintenance work. But the project has no permanent salaried staff in the way a company or a large foundation-backed project does, and its own maintainers described the codebase in November 2025 as “people’s hobby code.” The accurate statement is that FFmpeg is predominantly volunteer-maintained relative to a deployment footprint spanning browsers, phones, televisions, streaming platforms, and a Mars rover.
Does Google contribute anything to FFmpeg? Yes, substantially, which is what makes the November 2025 story more interesting than a simple grievance. Google engineers announced in January 2014 that a cooperative fuzzing effort had found and fixed over a thousand FFmpeg bugs across two years, and Google-funded fuzzing infrastructure continues to test the codebase. Google is also a founding member of the OpenSSF and backs its Alpha-Omega initiative. The dispute was never “Google contributes nothing” — it was about who absorbs the triage cost when automated discovery outpaces volunteer capacity.
What licence is FFmpeg under, and does using it require paying? FFmpeg is LGPL-2.1-or-later by default; building with --enable-gpl (required to link encoders like x264 and x265) makes the resulting binary GPL, and --enable-nonfree produces a build that cannot be redistributed under any terms at all. No configuration requires payment to FFmpeg. Note carefully that none of this touches patent licensing — FFmpeg’s own legal page declines to answer patent questions, and a software licence never grants patent rights over the codec formats themselves. That is a separate legal system with separate bills, and this is general explanation, not legal advice.
Was the November 2025 bug real, or was Google wrong to report it? The bug was real and FFmpeg fixed it. Reasonable people disagree about whether a memory-safety defect reachable only through a 1995 game’s video format warrants the same disclosure machinery as a bug in a widely-exposed decoder. The maintainers’ position was that the fix cost was being externalised onto volunteers; the counter-position is that attacker creativity routinely defeats “nobody would ever open that file” reasoning, and that maintainers are free to decline reports they consider out of scope. Both are defensible.
Could FFmpeg just charge companies for using it? Not retroactively, and not without changing what it is. The LGPL is irrevocable for code already released, so existing users owe nothing. A project can pivot — dual-licensing, as VideoLAN does with x264, or an open-core model — but each option trades reach for revenue and requires organisational machinery FFmpeg does not currently have. Relicensing a codebase with hundreds of copyright holders and no contributor licence agreement is, in practice, close to impossible.
What happens if the maintainers walk away? Nothing dramatic on day one, and that is the danger. The code keeps working; existing products keep shipping. What stops is new format support, new hardware support, performance work, and — critically — security fixes. Every downstream vendor’s fork drifts further from an upstream that is no longer moving. The failure mode for infrastructure like this is never a sudden outage; it is a slow accumulation of unpatched surface until something finds it, which is the shape of all three incidents in the lineage table above.
📚 Further Reading
- FFmpeg’s donations page — the primary source on SPI fiscal sponsorship, donation channels, and exactly what the money is spent on.
- FFmpeg’s news archive — every dated sponsorship announcement, including the Sovereign Tech Fund (May 13, 2024), Samsung (October 8, 2014), Telepoint and MediaHub (October 13, 2015), and Ampere Computing (June 24, 2026).
- FFmpeg’s legal FAQ — the LGPL/GPL/nonfree ladder in the project’s own words, plus its refusal to answer patent questions.
- xkcd #2347, “Dependency” — the comic that gave this whole problem its shorthand.
- Heartbleed.com — the canonical write-up of CVE-2014-0160, including the timeline from introduction to disclosure.
- The Apache Log4j security page — CVE-2021-44228 in the project’s own record, with affected and fixed versions.
- Andres Freund’s oss-security disclosure of the xz backdoor — March 29, 2024. A primary document, and a short one.
- LWN’s coverage of Debian’s 2015 return to FFmpeg — the fairest close-to-primary account of the fork’s resolution, and where the bus-factor numbers come from.
- The Open Source Pledge and Alpha-Omega — the two clearest attempts to convert this problem into a budget line.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Start with the free material. The best writing on who maintains open source and who pays for it is available at no cost, and two of the three canonical texts on this exact question were published free by their authors. Read these before buying anything.
- Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure — Nadia Eghbal’s 2016 report for the Ford Foundation, and still the clearest single document on the problem this article describes. Written in the wake of Heartbleed, it names the structural asymmetry — enormous dependency, negligible support — before the xz backdoor made the argument for it. Free PDF, no purchase required.
- FFmpeg’s own donations page — worth reading rather than skimming. It states exactly who the fiscal sponsor is (Software in the Public Interest), what donated money is permitted to fund, and the distinction between project funds and personal gifts to individual developers. Most secondary reporting on FFmpeg’s funding gets at least one of those wrong.
- The Open Source Pledge — if you work somewhere that ships software, this is the page to send your engineering leadership. It converts an open-ended question into a number a budget can hold.
Working in Public: The Making and Maintenance of Open Source Software
Nadia Asparouhova · Stripe Press, 2020 · Paperback
The book to read if this article’s argument interested you, and the single best fit on the shelf. Asparouhova (who published Roads and Bridges under the name Nadia Eghbal) spent years inside maintainer communities and came back with a thesis that cuts against the received wisdom: the defining constraint on modern open source is not a shortage of contributors but an excess of consumers, and the scarce resource is maintainer attention rather than code. That reframing is precisely what the November 2025 FFmpeg dispute was about — an automated pipeline generating demands on a finite attention budget — and the book maps the funding models, project structures, and social dynamics that determine which projects survive it. It is descriptive rather than preachy, which is rare in this genre and the reason it holds up.
One honest caveat: it is a book about the sociology and economics of maintenance, not about video, codecs, or FFmpeg specifically. Buy it for the pattern, not for the case study.