libjpeg-turbo 3.0.0 has been released, and why there may never be a libjpeg-turbo 3.1

[DRC]

Binaries and source tarball are here:
https://sourceforge.net/projects/libjpeg-turbo/files/3.0.0/

Change log is here:
https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/3.0.0

Sorry for the delay, the reasons for which were expressed in previous
emails
(https://groups.google.com/g/libjpeg-turbo-announce/c/zXCK0qw1pIE/m/yMLo__OuAAAJ).
SignPath is still having issues with their upstream CA, so the Windows
installers for libjpeg-turbo 3.0.0 are temporarily unsigned until those
issues can be resolved. Ultimately, however, the delay produced a more
stable 3.0.0 release, since most of the bug reports against 3.0 beta
were filed after the beta cycle was supposed to have ended.

On that subject, I want to remind everyone that, while I do my best to
maintain this project with the highest possible quality standards and
using industry best practices, I cannot test for every possible usage
scenario. The three-month beta testing phase is intended to allow the
community ample time to thoroughly test a new release series. *Please*
use that time to test the new release series rather than waiting until
after the .0 release!

Why there may never be a libjpeg-turbo 3.1
------------------------------------------

I will continue to fix bugs in libjpeg-turbo and issue bug-fix releases
in the 3.0.x release series, but there will not be a libjpeg-turbo 3.1
release series *unless* this project can secure more general funding.
As it stands, libjpeg-turbo only has general funding for about 8-10
hours of labor per month. Finishing the 3.0 beta release required
borrowing against all expected general funding for 2023, and fixing all
of the 3.0 post-beta bugs required borrowing against all expected
general funding through September of 2024. If things continue apace,
then libjpeg-turbo is effectively in "maintenance mode". That means
that no new features (even minor ones) can be considered, and tech
support will be limited, for at least the next 15 months.

I maintain three open source projects for a living. Those projects have
saved companies many millions of dollars in labor and IT costs, but I
take home less pay than that of a typical starting teacher. (For those
outside of the U.S., a starting teacher's salary is a rhetorical
benchmark for very low pay. We criminally underfund education here just
like we criminally underfund open source development.) What I earn
through independent open source development is about 20-25% of what my
skills would be worth to a corporate employer, and I have turned down
numerous offers from such employers over the years in order to continue
working on these OSS projects full-time. I don't expect to get rich
from open source development, but it is also unfair for organizations to
profit handsomely from my work while I am expected to do that work for free.

Because the majority of my income is from VirtualGL and TurboVNC,
uncompensated labor on libjpeg-turbo forces me to steal time away from
those more lucrative projects. Thus, I simply can't eat labor cost on
libjpeg-turbo anymore. (I ate hundreds of thousands of dollars' worth
of it from 2010-2018, but when the libjpeg-turbo 2.0 release caused me
to go into debt in 2018, I had to stop.) However, major releases still
require a lot of general labor. Because the project is so high-profile
(used by literally billions of people every day through major web
browsers, operating systems, and image viewers/editors) and is an
ISO/ITU-T reference implementation, it undergoes intense scrutiny.
Unfortunately, that scrutiny typically lags the development of new
features by enough time that specific funding is no longer available to
fix unanticipated bugs in the new features. Thus, it has become
increasingly difficult to estimate the labor costs of new features
upfront. In order to adequately cushion against unforeseen bugs, I
would have to grossly overestimate every new feature to the point that
no one would be willing to fund the feature. Instead, I have had to
accept the risk of unforeseen bugs in order to keep libjpeg-turbo moving
forward, and that has forced me to perform many hours of general labor
on the run-up to every new release series. The companies that have
partially (but unfortunately not fully) funded each new release series
have pressured me to put out the .0 releases in a timely manner, so that
has left me with no choice but to borrow against expected future
funding. Specific to 3.0, I had to spend more than 70 uncompensated
hours fixing bugs discovered in the beta release. Most of those hours
were spent fixing bugs in the lossless JPEG feature, but I also spent a
significant amount of time fixing bugs in the partial image
decompression and RGB565 features (both of which were integrated to
support Android and both of which have required me to eat the cost of
bug fixes or beg for money a handful of times since they were integrated.)

This project has only been kept alive because of the libjpeg-turbo
General Fund, which is funded by Cendio AB and Crimson Vista and your ad
hoc donations, as well as a few large ad hoc donations from Google.
However, the current General Fund is only enough to pay for general
project maintenance and support. To keep libjpeg-turbo moving forward
in any meaningful way, including providing community support,
integrating or implementing minor features, supporting popular new
platforms, etc. requires more general funding. To keep libjpeg-turbo
moving forward in a more proactive/progressive way, including expanding
the coverage of the JPEG spec (3.0 essentially expands our coverage of
the JPEG spec by a factor of five), expanding SIMD coverage to new
algorithms or instruction sets or CPU architectures, supporting less
popular new platforms, improving the APIs, hardening security, improving
fuzzer coverage, enhancing the build system, improving automation, etc.
requires even more general funding. Essentially I have been expected to
keep libjpeg-turbo moving forward in a proactive/progressive way, but
the amount of general funding only allows for maintenance mode. In the
best case, that puts me in the position of begging for funding on a
regular basis, which distracts from meaningful open source development.
In the worst case (where we are now), that puts me in the position of
stalling the project for potentially more than a year until funding can
catch up to the labor I've already contributed. It just isn't working,
and I don't know how to fix it. It's ironic that the most
popular/ubiquitous open source project I maintain (by at least four or
five orders of magnitude) is much more difficult to fund than the
others. Maybe a JPEG codec isn't "sexy" enough? Maybe people take it
for granted because the complexity of it is hidden behind higher-level
interfaces and applications? Still, though, the organizations that
develop those higher-level interfaces and applications should not be
taking libjpeg-turbo for granted, particularly when most of the recent
issues I was expected to fix for free were security-related.

I have expressed in the past that the business model necessitated by
independent open source development may not be the best fit for a
critical infrastructure project such as libjpeg-turbo. Thus, I am open
to acquisition by a larger organization, if that organization is both
O/S-agnostic and CPU-agnostic and has a vested interest in both the
survival and the openness of libjpeg-turbo. However, I also don't
expect such an offer to ever materialize. I have built significant
value in libjpeg-turbo-- including its reputation, its ubiquity, and its
user community-- over the past 13 years, but it is obviously not a cash
cow. Still, though, unless I can secure enough general funding to move
the project forward in a meaningful way, the only other options are
acquisition (however unlikely) or putting the project into maintenance
mode for the foreseeable future. The latter is where we are now.

How can you help? If every individual developer who used libjpeg-turbo
on a regular basis donated just $5-10/month to the project through
GitHub Sponsors (https://github.com/sponsors/libjpeg-turbo), we'd have a
healthy amount of general funding. But that requires everyone to take
responsibility for the health of this project, not to rely on the few
corporate benefactors that have kept libjpeg-turbo on life support for
the past five years.

DRC

[DRC]

A wholehearted thanks to everyone who has donated to libjpeg-turbo in
the past few days.  Because of your generous monthly and yearly
sponsorships through GitHub, we will have a 30% higher monthly budget
going forward.  Because of your generous one-time donations through
GitHub and PayPal, in addition to the new monthly and yearly
sponsorships, the General Fund for 2023 is now over 60% larger. 
Combined with an expected payment from another source, we will now catch
up to the deficit in about four months instead of 15!

Thank you thank you thank you!!!

You can see the current list of public GitHub Sponsors (those who chose
not to be anonymous) at the bottom of this page:
https://github.com/sponsors/libjpeg-turbo
All public sponsors also have a libjpeg-turbo sponsor badge on their
GitHub profiles.

DRC

[DRC]

Thanks to some supplemental contributions from MathWorks and the Open
Source Technology Improvement Fund, our deficit has been completely
cleared, and The libjpeg-turbo Project is now back to normal operation.

Once again, your new monthly and yearly sponsorships mean that our
project's monthly budget is now about 1/3 higher than it was in June. 
That will make it easier to provide support to the community, integrate
non-disruptive features, be more proactive about bug fixes, etc.

DRC