The notion that a library must be “bug-ridden” and “filled with vulnerabilities” just because it hasn’t changed in a while is a strange one. If it were true, it would also be true for libraries that do change. It’s not like libraries accumulate new bugs and vulnerabilities by not changing. Libraries that constantly gain new features, on the other hand, are prone to also gain new bugs and vulnerabilities.

Agreed -

It's beyond wrong. For example, at the core of plenty of numerical libraries is 30+ year old fortran code from netlib that works great. It's just done.

It does what it's supposed to. It does not have meaningful bugs. There is no reason to change it.

Obviously, one can (and people do) rewrite it in another language to avoid having to have a fortran compiler around, or because they want to make some other tradeoff (usually performance).

But it's otherwise done. There is no need to make new releases of the code. It does what it is supposed to do.

That's what you want out of libraries past a certain point - not new features, you just want them to do what you want and not break you.

I like Donald Knuth's approach where his version numbers of TeX and Metafont asymptotically approach pi and e, respectively, emphasizing the slow approach toward perfection.

And communicating nothing to the end user except a sense of whimsy? Nah, that's useless.

What do the version numbers of programs communicate to end users anyway? Basically just that it's newer than the last version.

Libraries are a bit different though, because of semver compatibility, but unfortunately they are wrong often enough that you can't really rely on them anyway.

> It’s not like libraries accumulate new bugs and vulnerabilities by not changing.

That's not actually true, for libraries that interact with the platform. For example, Mac OS changed some type definition in header files in their arch transition, which makes building a pre-M1 rust project that depends on a contemporary library version that interfaces with the OS (like SDL) on an ARM host without any changes impossible. You need to update your dep (and potentially the way you consume them) just to be able to build the project, or procure a host supported by your dependency (one that existed when it was written, so an X86 machine).

We could argue all day that this is "not a bug" or the user's fault for using a new host and it was never supported or any other deflection. But it is a concrete example of "this code hasn't changed and the passage of time shifted the ground from under it".

Agree, I think we need to speak of abandoned, versus maintained.

No activity doesn't mean abandoned, it can just mean super stable and few bugs to fix.

Abandoned is a big worry though.

I wonder if we need a canary file, but in the repo. An "I'm still here" file.

I still question that. It's generally as good as the day it came out. Discovered vulnerabilities are going to be in the language, probably not in the library itself. As long as it's not dependent on a language that's so old it's not getting security fixes, it should be fine.

Actually, a big exception is libraries that have external dependencies that change. A client library for an API, for example. Those can break quickly.

Hm, vulns are more common in libraries in general than in the compiler, I'd say. Or am I misunderstanding?

By "discovered vulnerabilities", I mean a security issue that wasn't known when the library was first written but then came to be known. This is what's fixed when a library is maintained.

This entirely depends on the library, but I just generally don't see a lot of security fixes in library updates. But for compiler updates, I do.

I'm speaking super broadly, and this will be very different for a Python graphing library versus a C networking library.

The vulnerability is almost never in the compiler (not never - I have seen a case, but very rare). Most attacks are in the library itself. If your library has a buffer overflow you are vulnerable. If your library has a C style buffer length + size parameters and you mess them up is it the libraries fault for such a bad API?

If a library is stable with no major bugs, then I don’t see much of a difference between abandoned and maintained.

The one thing I would look at instead is open issues.

Abandoned means no one around to deal with security issues, or impacting bugs.

Maintained means they are. There may be no new features though.

(these are my definitions, but I think there should be similar concepts in all dev's heads)

It changes nothing about the current version of the library though. It only impacts how quickly or easily one would be able to get a fix in case some issue does come up. But I’m questioning the expectation that such issues will come up, and the associated expectation that one will have to regularly update the library because new issues won’t ever stop coming up.

It's about perception. When I look at a old page on GitHub and there haven't been any code changes in two years but it does look like the Issues page is addressed quickly then I can trust the old code. On the other hand if the Issues page isn't addressed I can assume that the code will cause me problems in the future and I'll look for a different library.

There are endless examples of libraries being updated, due to bad code in the library. It's not a rare event, it's very, very common.

If a library is abandoned, and no one is around updating the code for vulnerabilities, it's trouble. That's because one day you can use it, and the next you cannot.

(Yes you can personally patch it, but that's an issue that's come up. And how will you know? Look at all the bugtrackers daily to see people yelling "HEY!"?)

Reading through, they're describing kindof "eras" of best practices. Like "hex" and "base64" might never change (so might never update), but those are kindof prime name tokens.

It made me think: `std::hex,base64` vs `boost::hex,base64`, but then assuredly those would be incompatible because $REASONS.

...but what if it was like: `v2025::std::hex,base64` vs `boost::v2025::std::hex,base64` (ie: explicitly stating you're adhering to the v2025 guidelines w.r.t. memory management or parameter naming or whatnot).

It's a roundabout way of saying: `tokio::async_foo`, `boost::async_bar`, `v2026::std::async::foo,bar`, where as the marketplace of ideas settles on "better" ways of dealing with async (or whatever) there can eventually be compatibility between different object "modalities" (ways of working).

`std::hex,base64` should be quite stable, but having a path for `...::webapp::` and `...::database::` to eventually interop seems really useful for a language to encourage?

If the author intends for:

> apparently abandoned

To mean:

> hasn't changed in a while

Then I will agree that that doesn't need to mean it has to be laden with problems. I was going more on the basis of it meaning that there are a number of unresolved bug reports as well as a lack of activity. In the Common Lisp community there is generally agreement that software can be simply finished (although there is also an amount of broken abandonware).

My main point is if people are using libraries with problems that aren't getting fixed, they shouldn't be afraid to take over maintenance or to migrate to libraries which don't have those problems.