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.
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.
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!"?)
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?