People use stars to get a gutcheck on how serious a project is. I'll be honest, I've been trained to look at Github stars, most recent commits, and how responsive the project is to issues to see if I should use something...
My way is way better - just simply look at the entire code base, read every file, make sure nothing phones home, internally criticize the design choices, realize I could have written something way better, start on the project, get halfway done, realize I wasted a lot of time trying to do a stupid project just to save a few keystrokes on a tiny program I almost never use, give up, and finally, realize I didn't want that package anyway.
Clearly. obviously. better.
(There's probably a krazam on this, but /s if anyone needs it)
* stars - the likelihood that an issue affecting us will affect someone else. More people affected, the more likely it gets fixed.
* age and commit frequency - old projects with continuous commit history are preferable. It's okay for recent commits to become trivial/minor. Likely a sign of mature software in a maintenance mode. It's _very_ concerning when there are no commits.
* issues. This is typically a lot harder to simulate simply by buying likes. There are four factors here:
* Do the number of issues line up with the seeming popularity of the project?
* Do the types of issues line up with the types of problems you'd expect from the project?
* Are there any issues, particularly open issues, that block certain functionality or use cases?
* Do the maintainers actually interact/discuss issue?So you are equating stars with adoption, which they are really aren't a good measure of. Even in the most favorable interpretation stars can only serve as a proxy for adoption when used in combination with a lot of other signals.
Especially for hyped topics, even ungamed stars are more directly a proxy for interest rather than adoption. And as many startup founders of failed freemium products can tell you, very often interest doesn't translate to adoption.
I had to learn that myself the hard way when I helped create a top 5 starred Rust project at the time (~5k stars), which I can tell you for certain no more than a handful of people outside the company used.
As I explained, we're building an aggregate view across a bunch of metrics with human judgement making the final call. Further, we're often comparing against alternatives so this isn't really a Yes/No type of thing (especially on stars). It's a general sense of a project's well-being and stability.
----
LangChain is a great example:
* 44k stars, 5.1k forks
* Roughly 8 months old (very young)
* Very active commit history
* Insane number of issues
* Lots of open PRs
This is a tool that we'd be hesitant to use without proper risk mitigations. It's young, it's moving very quickly. While it has a lot of visibility, it's not clear if that's all moving in the right direction.
By contrast, underscore:
* 27k stars, 5.6k forks
* 11+ years old
* Stalling commit history
* Some issues, but not many.
* Not many open PRs
This is clearly a project on the opposite side of the spectrum. If you didn't know about mature alternatives (lodash, rambda, etc), it'd be a safe project to approve.
Next I try to read through issues and PRs to see how the maintainers deal with the community.
Finally I try to develop a bit with the package. Stars generally don't factor in.