Fabian Giesen
There's a recurring talking point in The Discourse about "this is why you need to pay OS lib devs" that is not entirely wrong yet simultaneously seems to be missing the point in a rather profound way for many scenarios.
It's true that many important libs that a lot of programs rely on (another example would be libjpeg-turbo) are underfunded and lack for resources, but beyond that still is code that doesn't even want to try, and I don't see space made for that either.
Fabian Giesen
As in, pay isn't the problem. Your feature requests/bug reports/whatever would not be handled any quicker if you tried to give us money for it (which people have tried to do).
I repeat, it's a 3-weekends-a-year spare-time project. I'm OK spending that amount of time on it, because sometimes I feel like doing so. No realistic amount of money is going to make me want to spend more than that, though. And sometimes it doesn't happen for other reasons.
Fabian Giesen
So I find myself the "emergency contact" for 20-odd libs, some of which I have used myself, most of which I have not.
Both Sean and I have full-time jobs doing other things, both of us have limited spare time, and realistically, either of us is actually willing to spend about 3 weekends worth of time in any given year on stb library maintenance.
And both of us keep getting angry/snide comments from people who fundamentally don't understand this.
Fabian Giesen
To explain, I'm sort-of co-maintainer of the stb libs at https://github.com/nothings/stb. I say "sort of" because the way that originally worked is that Sean and I are friends and years ago Sean said "can I add you as maintainer to that repo in case something happens to me so it's not completely orphaned" and I said yes.
Fabian Giesen
But, realistically, _we just don't have the time and energy_.
The current schedule for stb lib maintenance is what works for us. The alternative is not "pay us and you get monthly releases". The real choice here is between either we update these libraries at all, at the leisurely schedule we do, or we abandon them entirely. Nagging us does not magically make us have more free time or energy.
Fabian Giesen
The code was not originally written with security in mind and it shows. Now we do treat security bugs as bugs and _will_ fix them, eventually, but they're on the same schedule as any other bugs and feature requests, which is to say, realistically we do a real release once or twice a year.
Filing 20 bug reports will not make us respond any faster. Nor will filing CVEs or whatever.
Yes, I agree that it's not great that we don't get to these sooner.
Fabian Giesen
Most of the maintenance I end up doing is security fixes in stb_image. These take a comically long time (often these stay open for more than 6 months).
I don't know what to say other than that stb_image has always had a note up top, which currently reads " Primarily of interest to game developers and other people who can avoid problematic images".
stb_image was _always_ meant for indie games and throwaway tools where you're in full control of the data.
Fabian Giesen
For example, I usually take some time off around Christmas, and _usually_, 1-2 weekends around that time I spend on stb lib maintenance, because I'm on vacation anyway so it's not a context switch from work, and the weather is usually miserable where I live around that time.
2023 that didn't happen because I badly sprained my ankle early Dec and then got a cold in early Jan, so all my winter holiday time end-of-2023/early 2024 was spent being sick in some form or other.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.