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: https://github.com/libjpeg-turbo/libjpeg-turbo/issues?q=is%3Aissue+is%3Aopen+label%3A%22funding+needed%22 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 On Tuesday, January 5, 2021 at 1:39:14 PM UTC-6 DRC wrote: > 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 > -- You received this message because you are subscribed to the Google Groups "libjpeg-turbo User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to libjpeg-turbo-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/libjpeg-turbo-users/227d4053-a5c2-4b13-aaaf-6e01e189ee54n%40googlegroups.com.
