libjpeg-turbo sits behind nearly every JPEG image displayed on any screen. It runs in web browsers, mobile apps, and computer vision pipelines. The top Python libraries for decoding JPEG images all depend on it. The project is critical infrastructure, and its maintainer just explained why a 3% performance improvement PR was rejected: the project is drowning in unpaid security work, and the General Fund will not recover until 2028.
A 3% Win That Cannot Be Merged
The incident started with a pull request. A developer benchmarked Python JPEG decoding libraries and found that all the leading options route through libjpeg-turbo. He submitted a small optimization, a 3% improvement to Huffman decoding. The kind of change that, in a healthy project, gets merged in an afternoon.
The maintainer declined. The explanation was blunt and specific. Huffman decoding and partial image decompression have produced a disproportionate share of the security vulnerabilities found in the library over the years. Google contributed the partial image decompression feature in 2015. Eleven years later, the maintainer is still spending unpaid hours fixing bugs introduced or exposed by that feature, including 18 unpaid hours on a single issue a few weeks ago. Google, meanwhile, has not paid a security patch reward that was earned six months ago.
The General Fund is in debt. At the current rate of replenishment, it will not return to positive until 2028, and that projection assumes no new bugs require the maintainer's unpaid time. A 3% improvement to Huffman decoding is exactly the kind of change that could quietly introduce a new class of vulnerability in the most scrutinized part of the codebase. Merging it would be reckless given the project's current state.
The Economics of Invisible Infrastructure
The numbers tell a story that shows up across open source but rarely this clearly. libjpeg-turbo is not a niche tool. It is in every browser, every phone, every image processing pipeline. The maintainer estimates it runs on nearly every digital screen in use today. Computer vision workloads depend on it for preprocessing. Web traffic is full of JPEG images decoded by this library.
The maintainer earns nothing from most of this usage. The General Fund, which exists to pay for exactly this kind of maintenance work, is underwater. Google owes the maintainer money for security work and has not paid. The maintainer is spending unpaid hours on vulnerabilities that affect billions of users.
This is the core tension in open source sustainability. The projects that matter most, the ones embedded in the critical path of the internet, are often the ones with the least funding. libjpeg-turbo is not a hobby project with a few hundred users. It is load-bearing infrastructure. The gap between its importance and its funding is a security risk in itself.
What "Security Scrutiny" Actually Means
The maintainer's language is precise: the project is "heavily scrutinized." That scrutiny is a double-edged sword. Security researchers probe libjpeg-turbo constantly. Every vulnerability found gets a CVE. The maintainer has to fix them. The scrutiny does not come with corresponding funding. Google found the partial decompression feature useful enough to contribute in 2015, but has not followed through on the long-term maintenance cost.
Huffman decoding is a particularly sensitive area. It is the inner loop of JPEG decompression. A bug there can cause buffer overflows, out-of-bounds reads, or crashes. The 3% optimization PR touched exactly this code. The maintainer's rejection is not about the quality of the contribution. It is about the risk calculus of changing heavily-audited code in a project where the maintainer is already behind on unpaid security fixes.
The Broader Pattern
The situation with libjpeg-turbo is not unusual. It is the norm. Critical open source projects routinely run on volunteer labor and fragile funding. The difference here is the clarity of the explanation. The maintainer did not just say "we are underfunded." He gave specific numbers: 18 unpaid hours on one bug, a six-month-old unpaid reward from Google, a General Fund that will not recover until 2028.
The developer who submitted the PR looked for a way to donate via GitHub Sponsors and could not find one. That small detail says a lot. The people who benefit from the library want to contribute, but the project has not set up the infrastructure to accept their support. The maintainer is too busy fixing security bugs to set up a sponsorship page.
The poster's final observation lands hard: as LLMs make it trivial to rewrite other people's software, the people maintaining the original code that everything depends on are going unpaid. The code is everywhere. The funding is nowhere. That is a problem that does not fix itself.