The future of libjpeg-turbo
4,667 views
Skip to first unread message
DRC
Jan 5, 2021, 2:39:14 PM1/5/21
to libjpeg-t...@googlegroups.com, libjpeg-t...@googlegroups.com, libjpeg-tur...@googlegroups.com
tl;dr -- In order to move forward, libjpeg-turbo needs either an
additional 100 hours/year of general funding, or it needs to be acquired
by a larger organization. Contact me if you are interested in either.
Otherwise, the expectation should be that 2021 will see very little
development on libjpeg-turbo outside of critical break/fix work.
As some of you already know, developing open source code for a living is
a delicate balancing act. I have to keep my projects (libjpeg-turbo,
VirtualGL, and TurboVNC) moving forward so I can maintain their
relevance, foster a healthy user base, and provide a timely return on
investment for funded development sponsors. This in turn keeps money
flowing into the projects-- either directly, via corporate/NGO
sponsorship and individual donations (thank you!), or indirectly, via
funded development-- which allows me to continue developing and
maintaining the projects full-time, which keeps them moving forward.
(Rinse and repeat.) However, if there isn't enough funding for the labor
necessary to keep the projects moving forward (as is too often the case
in recent years), then I have to either eat labor cost or speculate
(borrow against expected future funding) in order to finish a
strategically-important feature or release. If I speculate and the
expected funding does not emerge, then I have to eat the labor cost,
which usually means dipping into cash reserves to pay expenses or
racking up credit card debt if I have no cash reserves. (If you think my
business model is a little nuts, you're not wrong, but I've somehow
managed to make it work for 11 years. The purpose of doing business
this way is to ensure that the projects remain community-focused and
independent of any one organization’s agenda.)
Unfortunately, in order to finish the libjpeg-turbo 2.1 beta release in
a timely manner, it was necessary to speculate against an expected
corporate sponsorship that did not emerge. As a result, our project’s
funding deficit right now (a bit more than 130 hours) is well in excess
of the funding that has been secured for 2021. That is, as you can
imagine, a bad situation for an open source project that is used, either
indirectly or directly, by millions of people worldwide, is considered
critical infrastructure, and is an official ISO reference implementation
to boot. At the moment, I can't even afford to move our pre-release
builds to another platform, which unfortunately became necessary in
November when Travis CI started demanding money from open source projects.
libjpeg-turbo started out as an in-tree JPEG codec for VirtualGL,
TurboVNC, and TigerVNC, but as more and more people discovered it, I was
strongly encouraged to make it available as a standalone project. I
never set out to create the world's most popular JPEG codec. I just
wanted to fill a need that wasn’t already being filled. I just wanted
to create an open source project that represented what I want from other
open source projects: uncompromising performance and quality,
responsiveness to community inquiries, ease of development, robust and
easily reproducible development and release processes, highly-compatible
binaries provided for the most popular platforms, and a reasonable
amount of backward compatibility. As the IJG, under new leadership,
moved in the direction of extending libjpeg and the JPEG format in
non-standard and backward-incompatible ways, O/S distributors and
application developers started adopting libjpeg-turbo instead. Thus,
over the past 10 years, libjpeg-turbo has become much more than just a
"turbo" implementation of libjpeg. I am proud of what has been
accomplished with this project, but at the end of the day, libjpeg-turbo
has been a loss leader for me. I've had to invest more into the
project, in terms of the value of my pro bono labor, than I've gotten
back in funded development/consulting revenue. Ironically, I've had a
much easier time getting paid for my work on VirtualGL and TurboVNC,
which are more niche projects, than on libjpeg-turbo. With this
project, the amount of pro bono labor required has reduced my effective
hourly income to the point that 40 hours of libjpeg-turbo development
can no longer pay my bills for the week.
Open source development is my sole source of income, and if I can no
longer pay the bills with it, I can no longer do it. It's not as if
someone else will magically step up to the plate and do the same work
for free-- certainly not without sacrificing the high quality standards
that you have come to expect from libjpeg-turbo. I'm not trying to
sound arrogant. If I were in this for my own self-gratification, I
wouldn't be in this at all. I would have spent the last 11 years making
3-5 times as much money for a corporate employer and contributing more
than $0 toward my retirement account rather than borrowing against said
retirement account in order to pay rent. I believe in what
libjpeg-turbo can accomplish, but I also believe very strongly that,
without the aforementioned high quality standards, it would be a much
less trustworthy-- and thus much less useful-- code base. However,
maintaining those quality standards takes time, and I can't afford to
spend that time unless the organizations that benefit the most from it
are willing to pay for it. My labor is relatively inexpensive. I
charge a lot less, per hour, than the going rate for a U.S. software
engineer with my background, and my “employers” don't have to pay for my
office, equipment, lunch breaks, bathroom breaks, vacation, health
insurance, retirement, meetings, or anything else that doesn't involve
directly working for them. Clients who fund $1000 or more of labor also
get free advertising on libjpeg-turbo.org. The amount of labor required
to produce a code base like libjpeg-turbo from scratch amounts to
millions of U.S. dollars, and yet our code is provided free of charge
under a non-restrictive license. Not only is the code free (both as in
beer and as in freedom), enterprise-quality binaries are also provided
free of charge. All I ask in return is enough money to pay my bills
while I am working on this code. That seems like a good deal to me.
At this point, there are only a few possible paths forward for
libjpeg-turbo:
1. Stagnation. I can’t afford to eat any more labor cost on this
project, so if I can't make up the funding deficit in a timely manner, I
will have to wait for the General Fund to catch up. At the current
funding rate of 100 hours/year, that means I won’t be able to work on
anything except high-priority bug fixes and fully-funded enhancements
(of which there are currently none on tap) for at least the next year.
2. Acquisition. I would entertain the notion of transferring The
libjpeg-turbo Project and all of its resources to the right organization
for the right price, but the "right organization" would have to be a
CPU-neutral and O/S-neutral organization that is committed to the same
high quality and performance standards that have become the hallmark of
libjpeg-turbo, as well as an organization with a proven track record
within the open source community.
3. Additional general funding. If we could get an additional 100
hour/year funding guarantee for 2021, that would shore up the deficit
within the next few months. That's a workable, albeit not ideal,
situation. If we could get the same 100 hour/year funding guarantee for
2022 and beyond, that would be ideal.
Those are listed in increasing order of preference. I feel that, with
10 years of experience developing and maintaining this project (and 20
years working with high-performance JPEG code in general), I am in the
best position to continue developing and maintaining libjpeg-turbo, but
I can't do that without more funding. Barring that funding, I have to
admit that the best way forward for libjpeg-turbo is probably for the
right organization to acquire it. Please contact me offline if you
would like to pursue either of those avenues. Otherwise, the
expectation should be that 2021 will see very little development on
libjpeg-turbo outside of critical break/fix work.
DRC
additional 100 hours/year of general funding, or it needs to be acquired
by a larger organization. Contact me if you are interested in either.
Otherwise, the expectation should be that 2021 will see very little
development on libjpeg-turbo outside of critical break/fix work.
As some of you already know, developing open source code for a living is
a delicate balancing act. I have to keep my projects (libjpeg-turbo,
VirtualGL, and TurboVNC) moving forward so I can maintain their
relevance, foster a healthy user base, and provide a timely return on
investment for funded development sponsors. This in turn keeps money
flowing into the projects-- either directly, via corporate/NGO
sponsorship and individual donations (thank you!), or indirectly, via
funded development-- which allows me to continue developing and
maintaining the projects full-time, which keeps them moving forward.
(Rinse and repeat.) However, if there isn't enough funding for the labor
necessary to keep the projects moving forward (as is too often the case
in recent years), then I have to either eat labor cost or speculate
(borrow against expected future funding) in order to finish a
strategically-important feature or release. If I speculate and the
expected funding does not emerge, then I have to eat the labor cost,
which usually means dipping into cash reserves to pay expenses or
racking up credit card debt if I have no cash reserves. (If you think my
business model is a little nuts, you're not wrong, but I've somehow
managed to make it work for 11 years. The purpose of doing business
this way is to ensure that the projects remain community-focused and
independent of any one organization’s agenda.)
Unfortunately, in order to finish the libjpeg-turbo 2.1 beta release in
a timely manner, it was necessary to speculate against an expected
corporate sponsorship that did not emerge. As a result, our project’s
funding deficit right now (a bit more than 130 hours) is well in excess
of the funding that has been secured for 2021. That is, as you can
imagine, a bad situation for an open source project that is used, either
indirectly or directly, by millions of people worldwide, is considered
critical infrastructure, and is an official ISO reference implementation
to boot. At the moment, I can't even afford to move our pre-release
builds to another platform, which unfortunately became necessary in
November when Travis CI started demanding money from open source projects.
libjpeg-turbo started out as an in-tree JPEG codec for VirtualGL,
TurboVNC, and TigerVNC, but as more and more people discovered it, I was
strongly encouraged to make it available as a standalone project. I
never set out to create the world's most popular JPEG codec. I just
wanted to fill a need that wasn’t already being filled. I just wanted
to create an open source project that represented what I want from other
open source projects: uncompromising performance and quality,
responsiveness to community inquiries, ease of development, robust and
easily reproducible development and release processes, highly-compatible
binaries provided for the most popular platforms, and a reasonable
amount of backward compatibility. As the IJG, under new leadership,
moved in the direction of extending libjpeg and the JPEG format in
non-standard and backward-incompatible ways, O/S distributors and
application developers started adopting libjpeg-turbo instead. Thus,
over the past 10 years, libjpeg-turbo has become much more than just a
"turbo" implementation of libjpeg. I am proud of what has been
accomplished with this project, but at the end of the day, libjpeg-turbo
has been a loss leader for me. I've had to invest more into the
project, in terms of the value of my pro bono labor, than I've gotten
back in funded development/consulting revenue. Ironically, I've had a
much easier time getting paid for my work on VirtualGL and TurboVNC,
which are more niche projects, than on libjpeg-turbo. With this
project, the amount of pro bono labor required has reduced my effective
hourly income to the point that 40 hours of libjpeg-turbo development
can no longer pay my bills for the week.
Open source development is my sole source of income, and if I can no
longer pay the bills with it, I can no longer do it. It's not as if
someone else will magically step up to the plate and do the same work
for free-- certainly not without sacrificing the high quality standards
that you have come to expect from libjpeg-turbo. I'm not trying to
sound arrogant. If I were in this for my own self-gratification, I
wouldn't be in this at all. I would have spent the last 11 years making
3-5 times as much money for a corporate employer and contributing more
than $0 toward my retirement account rather than borrowing against said
retirement account in order to pay rent. I believe in what
libjpeg-turbo can accomplish, but I also believe very strongly that,
without the aforementioned high quality standards, it would be a much
less trustworthy-- and thus much less useful-- code base. However,
maintaining those quality standards takes time, and I can't afford to
spend that time unless the organizations that benefit the most from it
are willing to pay for it. My labor is relatively inexpensive. I
charge a lot less, per hour, than the going rate for a U.S. software
engineer with my background, and my “employers” don't have to pay for my
office, equipment, lunch breaks, bathroom breaks, vacation, health
insurance, retirement, meetings, or anything else that doesn't involve
directly working for them. Clients who fund $1000 or more of labor also
get free advertising on libjpeg-turbo.org. The amount of labor required
to produce a code base like libjpeg-turbo from scratch amounts to
millions of U.S. dollars, and yet our code is provided free of charge
under a non-restrictive license. Not only is the code free (both as in
beer and as in freedom), enterprise-quality binaries are also provided
free of charge. All I ask in return is enough money to pay my bills
while I am working on this code. That seems like a good deal to me.
At this point, there are only a few possible paths forward for
libjpeg-turbo:
1. Stagnation. I can’t afford to eat any more labor cost on this
project, so if I can't make up the funding deficit in a timely manner, I
will have to wait for the General Fund to catch up. At the current
funding rate of 100 hours/year, that means I won’t be able to work on
anything except high-priority bug fixes and fully-funded enhancements
(of which there are currently none on tap) for at least the next year.
2. Acquisition. I would entertain the notion of transferring The
libjpeg-turbo Project and all of its resources to the right organization
for the right price, but the "right organization" would have to be a
CPU-neutral and O/S-neutral organization that is committed to the same
high quality and performance standards that have become the hallmark of
libjpeg-turbo, as well as an organization with a proven track record
within the open source community.
3. Additional general funding. If we could get an additional 100
hour/year funding guarantee for 2021, that would shore up the deficit
within the next few months. That's a workable, albeit not ideal,
situation. If we could get the same 100 hour/year funding guarantee for
2022 and beyond, that would be ideal.
Those are listed in increasing order of preference. I feel that, with
10 years of experience developing and maintaining this project (and 20
years working with high-performance JPEG code in general), I am in the
best position to continue developing and maintaining libjpeg-turbo, but
I can't do that without more funding. Barring that funding, I have to
admit that the best way forward for libjpeg-turbo is probably for the
right organization to acquire it. Please contact me offline if you
would like to pursue either of those avenues. Otherwise, the
expectation should be that 2021 will see very little development on
libjpeg-turbo outside of critical break/fix work.
DRC
DRC
Apr 16, 2021, 5:05:42 PM4/16/21
to libjpeg-turbo Announcements
I am pleased to announce that Google has stepped up to cover the remaining deficit incurred with the libjpeg-turbo 2.1 beta release, as well as to fund the labor necessary to integrate libjpeg-turbo with OSS-Fuzz and improve fuzzing code coverage by about 3x. (That will make it easier to proactively catch potential security issues before they are released, thus easing the maintenance burden on me.) libjpeg-turbo no longer has a deficit, but the OSS-Fuzz work took a lot longer than anticipated, so we no longer have much of a surplus either. Thus, if your organization has a burning need for any of these proposed features:
please consider funding the development of those features (or any other features that we haven't thought of yet.)
I'm allowing another few days for OSS-Fuzz to catch up and generate new reports. If no new issues are discovered, then libjpeg-turbo 2.1 will land next week. Thanks for your patience, and a special thanks to all of those who donated to the project earlier this year. You also made the 2.1 release possible.
DRC
Reply all
Reply to author
Forward
0 new messages