[flutas]

I find myself (as a professional software dev) trying to break that mindset frequently, especially on GitHub, when looking at libraries to use for a task if there's more than 1.

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.

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

[swatcoder]

It’s common, but also absurd, to hold your own teammates to a higher standard than you do some internet rando contributing a big block of code to your project.

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.

[dotnet00]

Agreed, I haven't ever really looked at stars, mainly I look at number of/most recent commit and the state of the issues tab, with more importance assigned to the latter.

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