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. 40 comments
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.
Neil Henning
@rygorous I don’t have anywhere near the popularity nor amount of libs - but my 6 C libs take about 5-6 weekends a year just to maintain them on life support. Very tempted to just archive them.
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
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.
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
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
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
And the reason I'm writing a whole thread about this is that fundamentally, I refuse to treat this as a problem when a lot of discourse around open-source libs very much wants to pretend that it is. I don't know, man. Some projects just exist to scratch a very particular niche itch and are maintained by people who have plenty of other things going on in their life and... that has to be OK?
Fabian Giesen
Like yes, I agree that it sucks that stb_image has a lot of exploitable bugs that often are around for months or years at a time but at the same time... we're completely transparent about this. Don't put this code in a security-sensitive context, especially if you need timely updates. We realistically can't serve that need and we have never claimed that we could.
Fabian Giesen
I do have plenty of code that I professionally maintain (you know, at work, where I get paid to do so) where security issues get handled ASAP but... that's work. Like that's actual work. I do that (and other support, and other coding) full-time every week. I'm not going to spend my weekends doing the exact same thing I do at work too. (I did for a while and it was _bad_ for me. I'm not going back.)
Fabian Giesen replied to Fabian
...so what's my point here? For foundational libs (including xz/liblzma) tons of people depend on, it sure would be nice if, assuming there are people who _want_ to be full-time maintainers, get to actually be paid for doing so. For something like the stb libs? I really don't know. I don't think we're foundational. If those libs disappeared overnight, nothing terrible would happen, people would just use other alternatives.
Fabian Giesen replied to Fabian
And "any open-source lib anywhere in the wild must be up to professional quality standards and respond to all bug reports in a timely fashion" is also a bullshit standard to apply to anything. It just doesn't work that way.
Kevin Gibson replied to Fabian
@rygorous people love the part of open source licenses that give them permissions, and always ignore the parts about the software being without warranty of any kind. It's not always just a legal cover!
Fabian Giesen replied to Fabian
The majority of libs you know at the very least _started out_ as someone just noodling around on their private project and then over time turned into the go-to solution for XYZ. But for many libs, that's just never been the goal, and pretending that not having that level of ambition is tantamount to failure is also not serving anybody. 
Irenes (many) replied to Fabian
@rygorous well said, and thank you for speaking to this angle on it! we haven't seen enough people talking about that 
railmeat replied to Fabian
“It just doesn't work that way.” It should not work that way. People should be able to publish software for free without incurring the obligations that come from commercial software. That idea is backwards. People or companies that take a dependency on software with no warranty get what they deserve. They have to make the effort test it and check the dependencies on their own.
Maciej Sinilo replied to railmeat
@railmeat @rygorous the most mind boggling example is probably cURL which was still a part-time project until very recently.. and the author was getting "charming" emails like https://un.curl.dev/emails/slaughter 
Per Vognsen replied to Kevin
@kkarhan @msinilo @railmeat @rygorous But even that is missing the point in some of these cases. Many people don't want code contributions to their open source projects from outsiders (or perhaps from anyone). But it's probably worth "standardizing" some of the messaging around this in the way we do with licenses so the expectations can be super clear to everyone. 
Soso replied to Fabian
> any open-source lib anywhere in the wild must be up to professional quality standards and respond to all bug reports in a timely fashion I think the proper standard should be to request that on vendors selling production software. « all libs you depend on must be up to o professional standards of security ». If upstream can't meet that, for the reasons you described, then it's downstream responsibility to either fork or vendor to meet that criteria. 
Seasonal Stompy Robot replied to Fabian
@rygorous "How many machines is this on, and how frequently is it invoked, and with what privileges?" Are the real questions. 
Marsh Ray
@rygorous People have packaged your knowingly-insecure code and uploaded it to an online package repo from which there have been 30,000 downloads: Similarly, 3,177 downloads for this package: Would you please at least consider adding the words “insecure-unmaintained-“ to your package names so that people can understand what they’re getting?
Fabian Giesen replied to Marsh
We don't make distributions as distro packages at all, and have repeatedly told people in the issue tracker not to do it. The README.md, which shows up on the front page when you navigate to the project on Github, has a warning up top that is literally larger than the name of the library itself. https://github.com/nothings/stb/blob/master/README.md
Kevin Karhan replied to Marsh
I mean, people should be able to see at a glance if something's maintained or not. There's a solution for that: #PayYourDistroMaintainers to cover that for you! But I guess you are too cheap for the 3-4 digits per year and Desktop/Server that would cost... 
Raven667 replied to Krzysztof
@wronglang @marshray @rygorous that needs to be a meme when dealing with demanding users of volunteer projects ;-)
Krzysztof Sakrejda replied to Raven667
@raven667 I think so too but there's probably a canonical example out there I should use, I think some research is required to pick the right name.
Andrew Jeffery
@rygorous "If you can't hack on it, I'm not supporting you using it" is my rough approach to things I'm not charged with maintaining professionally. Unless the problem interests me for some reason. I'm not prepared to burden myself with responsibility and drudge work for internet randoms. That said, I haven't yet been the target of abuse either. I maintain some pretty niche stuff so that probably helps 
wakingrufus
@rygorous 
Toon Van de Putte
@rygorous the crux is imho the shift in power dynamics these 'but I'm willing to pay' requests imply. These are just people being cheap. If they really wanted speedy reliable releases, shouldn't they just fork the project and pay someone to maintain that fork for their specific purpose? Which would be far above their planned commitment of time and money, but it is what they're asking of you. |
Gregory's Server
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.