What I try to focus on now is more so the commit and release cadence / frequency since in my mind frequent activity means it's more likely to have bugs fixed and security issues handled.
Would love to hear other's input on this.
- look at "latest commit." 4 years ago is not good. 2 days ago is good.
The 30-second test:
- total number of commits. number of active branches. number of PRs.
The 5 minute test:
- are there PRs? How many open PRs vs how many closed? Is there lively discussion in PRs?
- how many different contributors are there? 1 contributor is OK (and often means that the library will be very coherent) but multiple "main" contributors is better.
- are there good code examples available? Are there commits that indicate that examples are kept up to date?
I have never ever used stars to evaluate anything.
in a language like rust or typescript, depending on what the library does, and specially if it has a lot of dependencies, should probably be maintained continually. so in Rust last commit 4 years ago looks very bad
Rust libraries from 4 years ago are still working, js libraries are a hit or miss
Then frontend is way worse than backend
Overall if the code is old but well written, I'm happy to own a fork
Now if the library has tons of dependencies, regardless of language, it's very brittle to bring it unmaintained, because your own dependencies may be expected to interoperate with them. This is actually a plus because with C you may be required to do manual data conversions etc, but it also means that keeping old dependencies is a liability
Open vs Closed, and meat in the issues. Will tell if people are actually using something.
There's one project that, if I'd known how unhelpful the lead dev would be, I'd have never used that project. (Not going to name names)
Evaluating each repo does happen as you wrote, though.
With exception of a handful of “pillar” dependencies used throughout the industry, you should be reviewing your dependencies with the same eye for detail that you bring to pull/merge reviews in your own organization. And you should do it again every time you explicitly tell your package manager to reference a new version.
If you care about the quality of your own project, it doesn’t matter how many stars there are, or the commit frequency, or the responsiveness to issues. What matters is that the code is legible, that it meets your own standards of quality and reliability, and that you understand in detail what it’s doing.
If you can’t do that because a dependency is too large or fast-churning to review, then you should consider whether its actually suitable for your project. Often, in these cases, you’ll remind yourself that you only need 1% of what the dependency provides and that it’s actually less work and better for your skill development to tackle that 1% on your own or with a more narrow dependency that you can properly vet.
But of course, your product manager probably won’t have the patience for any of this, and your colleagues will look at you like you’re a paranoid freak. And that’s why software quality is garbage now and getting constantly worse.
If there are any important unresolved issues, it's a fail. If the issues have been resolved, it's a potential pass.
If there aren't any issues, I'll think about the complexity of the project relative to the number of commits/time since most recent commit, since if there aren't many commits and haven't been any for a while, it's more likely that the library isn't used by other people enough and may be buggy. But if it's still an active project, it might be worth trying anyway since I might be able to work with the maintainers to resolve potential issues (especially if there aren't any better options).
A popular project will have a healthy distribution of types of issues, from novices asking newbie questions to experienced devs making feature PRs. It will also have several contributors.