[nocommandline]

A significant number of folks (especially non-professional developers) make a choice on which library/project to use based on the number of GitHub stars. For these people, the more number of stars, the more it means the 'package is good/useful'. You can argue it isn't the best/most effective way but it's quite common.

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

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

[bdw5204]

That's the argumentum ad populum ("popular = good") fallacy[0] which is probably most of the most common logical fallacies. You can tell quite a bit about a person, not just as a developer but in general, by whether they always go with whatever's popular, they always go with something obscure or they go with a mixture of popular and obscure.

[0]: https://en.wikipedia.org/wiki/Argumentum_ad_populum

[janalsncm]

If we look at “best” more broadly, popularity isn’t a terrible metric. I want a library to be actively fixing bugs and I want support if things aren’t behaving as expected. Stars is a rough measure, but we can look at resolved issues as a better metric.

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.