[mlsu]

The 5-second test:

- 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.

[nextaccountic]

in old languages that don't encourage tons of dependencies like C, it's okay to call a library finished and stop developing it, so last commit 4 years ago is ok

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

[jokethrowaway]

I agree with js but disagree on rust

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

[nextaccountic]

Maybe 4 years isn't the right time frame but at some point there were sweeping changes in the language, like futures and async/await, that invalidated large parts of the ecosystem overnight (if you made a bet on a particular ecosystem you would either be stuck at maintaining an evolutionary dead end, or eventually migrate to tokio). It seems that Rust evolution is slowing down though.

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

[ziml77]

I was about to say there needs to be a tool that accounts for all these metrics and generates a summary with a score, but then I realized that if a rating algorithm is out in the open, people will game it.

[yumraj]

You forgot issues.

Open vs Closed, and meat in the issues. Will tell if people are actually using something.

[bloopernova]

And whether the project owner/originator/maintainers are open to suggestions, how they interact with people, and whether those issues are linked to commits.

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)

[hotnfresh]

I often use stars to pick out which projects to evaluate and only start looking at very-low-star repos if none of the highest-star ones look decent.

Evaluating each repo does happen as you wrote, though.