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.
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.
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".
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.
The one thing I would look at instead is open issues.
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)
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!"?)
Actually, a big exception is libraries that have external dependencies that change. A client library for an API, for example. Those can break quickly.
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.
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?
> 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.