Loose correlation with adoption and community size. For me it's one more signal to consider when choosing a specific tool or library for a production environment. More popular projects usually have a lower chance of being abandoned and have better docs, tests, etc.
With regards to the signal aspect of it, I personally only star repos that I am using on a project.
I naively believe that there are many others like me and it helps me determine which projects are "I actually use this" vs "I starred this because it's the cool thing to do/use".
I find if I want to explore a new API I like to find boilerplate projects that are usually <Something>-Example. I know if they have one star, it's probably high-quality boilerplate.
If there's no stars, I might still investigate, but it's likely unusable.
The flip side is nothing stops a lot of users from starring something and that's it. The implied popularity of a library only comes from how active the project is, not how many stars it has.
A recent example: I saw an advertisement on the freeway for some tire brand I've never heard of, with the quote "The most liked tire page on Facebook." What does liking (or in the case of staring something) have to do with the quality of the project, especially when liking/staring takes so little effort?
I look first at whether the project solves my problem within my constraints. Then I look at who is involved, what is their commitment level to the project (if it matters), and how they seem to be handling issues and PRs. Then I do a quick scan of the code to see if it’s reasonable, look at dependencies, etc.
Then I test it out.
If I’m weighing it against other projects, I usually do a back-of-the-envelope muscow type analysis and comparison and weight them based on my proclivities.
General popularity? Not usually a big factor unless it seems like the project might get abandoned (if that even matters).
It's a sign that there's a corporate backer whose social media person thinks stars are important. But I usually already know if it has a corporate backer, and I've usually already decided whether that is relevant.
For golang projects I usually check go-search.org [0] to see how many other packages import a given package.
Number of users of a package seems like a better metric than number of people who "favorited" something through the stars feature.
Would be really cool if github provided a way to surface "number of users" or "number of downloads" data in a way that it could be used to rank github search results [1].
I will not even possibly consider introducing a 3rd party dependency unless it has one of the following:
1. A reasonably release cadence of packages (APT/PPA/RPM).
2. A well defined release cycle with a sane download path (for tarballs).
3. Obvious community support by way of GitHub stars, pull requests, issues.
That said, in the traditional adoption curve, I am somewhere between 'late majority' and 'laggard'. Mostly because I don't have time to evaluate most things.
I've found that the average age of uncommented, open issues are the best indicators of the likelihood that a project is actively maintained (even if it's in the "no activity because it's already finished" stage). Another good but not as useful indicator is raw number of commits.
GitHub forks aren't contribution, they are just github forks. People fork without any intention to contribute all the time.
Both stars and github forks are the same for me. A tiny metric used to indicate how interesting a project is to the general masses. This is useful data, it's just not all that important.
There are three things to figure out when you use a project
1. Quality
2. Maintenance
3. Adoption
Github stars imply #3 adoption, moreso I believe than raw download stats.
It doesn't tell you the quality or maintenance of the project. It tells you how large the community is, and what you can expect on eyeballs, public Q/A forums, etc.
To me it signals that the community support is good on a project and I am more likely to go with a project with more stars over one that has less (that is a substitute project).
I treat it as one indicator out of many that I use to evaluate a project. IMO, commit activity, quality of communication on PRs and open issues, quality of documentation, attention to detail in README, etc. are usually more important. Stars are more of an indicator of whether I'll be able to find blog posts and answered questions on Stack Overflow.
And something to keep in mind: if you're comparing two projects, you should pay attention to which project is older. If I see a fork or a newer project that has almost as many stars as a much older project, that is a very positive indicator to me, since it means that people are actively deciding to go with the newer project.
However I put more weight on the number of issues a project has. If there are a lot of stars but not many issues, that could indicate a project that isn't really used that widely, or actively.
However, if it has a lot of issues that means it's a popular project with a lot of users that are actively working on making it better.
It certainly can. But that's where digging into the issues comes in. You can learn a ton about a project by seeing what kind of issues pop up and the discussion around issues.
Issues are used as often for feature requests and potential improvements as for bugs, so a high number of issues is not a strong indicator of poor quality. (Also, people usually look at existing issues, so a common bug only shows up as a small number of issues.)
I'm surprised at how much dislike there is for the stars metric, and I wonder if it's an allergy that devs tend to have for software development metrics (which is understandable when they are abused).
I try my best, at minimum, to star anything I use on github as a way of supporting it , and in addition to other factors you mention, take this number as an indication of the likelihood it will continue to be developed.
Some discounting and adjustment sometimes needs to be done for projects that managed to get on the front-page for something 'cool', but then that's where the other factors help.
From the giving standpoint, people read too much into the meaning of individuals starring repos. Employee for $CORP starring a repo just means that person felt compelled to star the repo, and has no broader implication that $CORP is using the project in question. Maintainers behind the repo sometimes construe that as a company endorsement, and in some cases use that as the basis for including logos in marketing material.
From the interpretation side, the statistic itself is subject to gamification. There used to be a website where you could essentially "buy stars", ultimately calling into question any sort of usage-based signaling.
From the maintainer side, GitHub stars are basically the equivalent of likes and retweets. There's no magical bank that we can go to exchange GitHub stars for dollars. While it is certainly exciting to see major thresholds crossed, the prospect of receiving extra stars does not usually compel people to put more time and energy into a project.
(full disclosure: our largest open source project https://github.com/SheetJS/js-xlsx/ has over 10K stars and the perceived popularity certainly is surprising for a seemingly niche project)
Metrics like Github stars can be gamed, but it doesn't mean that the number has no value. I would conjecture that the # of stars correlates strongly with other desirable things.
I think of it as similar to the # of citations that an academic paper has - genius can remain ignored and undiscovered, but overall the citation count has embedded in it a whole series of factors that correlate to "should I bother reading this".
Ironically before citing a paper that studied this very thing, I checked many citations it had :)
I'd guess it's related to how ambiguous a "star" is, and people use them for very different purposes, a common issue with sites that do not have distinct options but only "star"/"like"/....
E.g. I treat stars as bookmarks: I star everything I come across that seems somewhat related to my interests, but isn't relevant right now. In the vast majority of cases, I at best have skimmed the readme. If I'm looking deeply into something, I might even be more likely to not star it.
This conflation of purposes means a lot of noise in the signal you can get out of it. It's some kind of popularity metric, but not a clearly defined one.
> I try my best, at minimum, to star anything I use on github as a way of supporting it , and in addition to other factors you mention, take this number as an indication of the likelihood it will continue to be developed.
I don't understand how these are correlated. Do you mean that it's likely that one of the starrers will fork it if the original project team disappears?
There are much stronger metrics for whether a project is likely to be maintained in the future. The problem with stars isn't that it's a metric, it's that it's a bad metric.
This seems like it might be a bit of a contrarian view based on the other comments but I use them to get a quick overall sense of a project. Generally I'm interested in using projects with a relatively proven history and a good community -- both of which roughly translates to stars. They're also a pretty good metric for comparing similar projects at a glance.
That said, I'm certainly not put off by or dismiss project with few or no stars, it just means that I'll look slightly deeper before making an assessment.
For me, staring GitHub repos means that I like this project, I will not remember it though in the future, so I star it to find it easily. Also, I revisit my stars list every 6-12 months and usually un-star projects I'm no longer interested, or I have learned and now can find them with their name.
65 comments
[ 2.7 ms ] story [ 113 ms ] threadI naively believe that there are many others like me and it helps me determine which projects are "I actually use this" vs "I starred this because it's the cool thing to do/use".
If there's no stars, I might still investigate, but it's likely unusable.
I am way more interested in how active the community is supporting the project than any popularity contest.
A recent example: I saw an advertisement on the freeway for some tire brand I've never heard of, with the quote "The most liked tire page on Facebook." What does liking (or in the case of staring something) have to do with the quality of the project, especially when liking/staring takes so little effort?
I look first at whether the project solves my problem within my constraints. Then I look at who is involved, what is their commitment level to the project (if it matters), and how they seem to be handling issues and PRs. Then I do a quick scan of the code to see if it’s reasonable, look at dependencies, etc.
Then I test it out.
If I’m weighing it against other projects, I usually do a back-of-the-envelope muscow type analysis and comparison and weight them based on my proclivities.
General popularity? Not usually a big factor unless it seems like the project might get abandoned (if that even matters).
What percentage of people star repo's where they like the idea but never get pass the Readme....thinking they'll come back to it but never unstar it.
What about people who star something, try it and decided it's not very good and will keep it starred to see how it evolves...
Number of users of a package seems like a better metric than number of people who "favorited" something through the stars feature.
Would be really cool if github provided a way to surface "number of users" or "number of downloads" data in a way that it could be used to rank github search results [1].
[0] https://go-search.org/
[1] https://github.com/search?utf8=%E2%9C%93&q=&type=
For example https://github.com/ochinchina/supervisord
https://go-search.org/search?q=supervisord
I guess we can say that while it'd be a useful metric, clearly not in all cases :)
1. A reasonably release cadence of packages (APT/PPA/RPM).
2. A well defined release cycle with a sane download path (for tarballs).
3. Obvious community support by way of GitHub stars, pull requests, issues.
That said, in the traditional adoption curve, I am somewhere between 'late majority' and 'laggard'. Mostly because I don't have time to evaluate most things.
Anything else is pretty meaningless.
Both stars and github forks are the same for me. A tiny metric used to indicate how interesting a project is to the general masses. This is useful data, it's just not all that important.
1. Quality
2. Maintenance
3. Adoption
Github stars imply #3 adoption, moreso I believe than raw download stats.
It doesn't tell you the quality or maintenance of the project. It tells you how large the community is, and what you can expect on eyeballs, public Q/A forums, etc.
And something to keep in mind: if you're comparing two projects, you should pay attention to which project is older. If I see a fork or a newer project that has almost as many stars as a much older project, that is a very positive indicator to me, since it means that people are actively deciding to go with the newer project.
However I put more weight on the number of issues a project has. If there are a lot of stars but not many issues, that could indicate a project that isn't really used that widely, or actively.
However, if it has a lot of issues that means it's a popular project with a lot of users that are actively working on making it better.
I try my best, at minimum, to star anything I use on github as a way of supporting it , and in addition to other factors you mention, take this number as an indication of the likelihood it will continue to be developed.
Some discounting and adjustment sometimes needs to be done for projects that managed to get on the front-page for something 'cool', but then that's where the other factors help.
From the giving standpoint, people read too much into the meaning of individuals starring repos. Employee for $CORP starring a repo just means that person felt compelled to star the repo, and has no broader implication that $CORP is using the project in question. Maintainers behind the repo sometimes construe that as a company endorsement, and in some cases use that as the basis for including logos in marketing material.
From the interpretation side, the statistic itself is subject to gamification. There used to be a website where you could essentially "buy stars", ultimately calling into question any sort of usage-based signaling.
From the maintainer side, GitHub stars are basically the equivalent of likes and retweets. There's no magical bank that we can go to exchange GitHub stars for dollars. While it is certainly exciting to see major thresholds crossed, the prospect of receiving extra stars does not usually compel people to put more time and energy into a project.
(full disclosure: our largest open source project https://github.com/SheetJS/js-xlsx/ has over 10K stars and the perceived popularity certainly is surprising for a seemingly niche project)
I think of it as similar to the # of citations that an academic paper has - genius can remain ignored and undiscovered, but overall the citation count has embedded in it a whole series of factors that correlate to "should I bother reading this".
Ironically before citing a paper that studied this very thing, I checked many citations it had :)
http://ieeexplore.ieee.org/abstract/document/7816479/
E.g. I treat stars as bookmarks: I star everything I come across that seems somewhat related to my interests, but isn't relevant right now. In the vast majority of cases, I at best have skimmed the readme. If I'm looking deeply into something, I might even be more likely to not star it.
This conflation of purposes means a lot of noise in the signal you can get out of it. It's some kind of popularity metric, but not a clearly defined one.
I don't understand how these are correlated. Do you mean that it's likely that one of the starrers will fork it if the original project team disappears?
There are much stronger metrics for whether a project is likely to be maintained in the future. The problem with stars isn't that it's a metric, it's that it's a bad metric.
That said, I'm certainly not put off by or dismiss project with few or no stars, it just means that I'll look slightly deeper before making an assessment.
https://github.com/cloudflare/ahocorasick - 285 stars. https://github.com/anknown/ahocorasick - 70 stars
Anknown's implementation is more than 10x faster than CloudFlare's, and typically uses 10% of the memory!
elif stars < 10: Probably shared with some friends or tweeted.
elif stars < 1000: Probably announced officially, shared on some news aggregators, maybe there's a blog post about it.
elif stars < 10000: Probably pushed by a funded company or a tech celeb.
elif stars < 100000: Probably a meme.
else: Probably a bug in Github.