Ask HN: What do GitHub stars mean to you when evaluating a project, if anything? | Hacker News Reader

Ask HN: What do GitHub stars mean to you when evaluating a project, if anything?

38 pointsceohockey6063 comments

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.

I do the exact same.

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.

Couldn’t it also mean that the code quality is poor?

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.

> how much dislike there is for the stars metric

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

http://ieeexplore.ieee.org/abstract/document/7816479/

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.

Nothing really for me. Personally I like to look at: 1) Last commit date 2) Number of open issues vs closed 3) Number of open PRs vs closed

I am way more interested in how active the community is supporting the project than any popularity contest.

But projects that draw an active, supportive community are generally, by definition, popular.

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?

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.

When evaluating projects for business projects, I'm going to look at github stars as a rough indicator of popularity and community. The larger the number of stars, the less likely the project will be abandoned, and the more likely it will be supported in some way. The immediate next thing I look at is the date of the last commit and the issues. How recent were the changes, how responsive are they to issues, how long do PRs hang around without comment? Then I start looking at documentation and potentially the code to see if this would fit my need.

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.

If the project is fairly new, a large number of stars mean that the author is popular/famous and/or they won the Show HN lottery.

LOL I posted my GitHub project here on HN a few years back and picked up 8 stars. More like a scratch-off win for me.

I star repos when I want to bookmark them. I plan to use it in the future or am interested in reading through the source.

There are many factors, "stars" among the more important and obvious ones. It indicates that this project was popular at one time for one reason or another. There's not enough info in the "stars" alone to draw any more conclusions without looking at other factors (although I am biased and favor a project with a lot of stars without looking at any other factors).

Other factors that I will consider:

* How old is the last commit? (is this actively maintained)

* How many contributors? (have multiple developers reviewed and worked on this code base)

* How many open issues (vs how many closed issues)?

* When was the last issue resolved? (also actively maintained)

* Are there CI tests built in and are they passing?

* Is there test coverage reported and is it acceptable?

I'll also:

* read through a few issues, make sure no one is saying "This does not build" etc.

* scroll through some of the dependencies (badges can help by indicating if the dependencies are out of date).

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.

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

[0] https://go-search.org/

[1] https://github.com/search?utf8=%E2%9C%93&q=&type=

What about golang projects that are not imported?

For example https://github.com/ochinchina/supervisord

That's a good point, today it has 0 imports:

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

Nothing. Nothing whatsoever.

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

My concern is over the quality of the stars.

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

Nothing at all. My biggest indicators are, amount of commit activity, the recency of said activity, and most importantly how widely used is it?

Think Netty or Guava vs MyCollegeDataStructureLibrary

I never star repos myself so I suspect stars don't represent real endorsement. But using people using a library is.

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

Not a whole lot by itself. But certainly an indicator of quality/use that I'll use when evaluating options. # of stars, contributors, commits, branches, what the README looks like, check out the pulse on a weekly/monthly basis, contributions per person (is 99% of it written by 1-2 people). When were the last meaningful commits, is the build passing. Many other things go into evaluating a project when I'm considering taking it on as a dependency. But those are just a few I look at glancing at the repo for a minute or so. And of course, I compare all these metrics to the alternatives.

Edit: another couple I forgot was # of issues (and what those issues are ie. bugs vs feature requests), and types of PRs open

I'll use it while comparing multiple projects to guage community support and how "alive" the project is. Stars are obviously not the best representation, but it's a nice way to see how many other people have evualuated the project and are either using it or at least thought it looked good in some way.

This past weekend, while trying to choose a JS framework for a webapp, stars played a decent role in my choice when it came down to two that seemed to have similar features and comparable commit activity. One project has ~200 stars, while the other had ~13,000, which definitely helped push me toward the latter.

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.

This is not an answer, but today I was hunting for an implementation of Aho-Corasick in Go.

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!

Well I star things just to remember to go back and see if they're any use to me: so I think that should give you an indication of how reliable they are as a measure of quality.

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 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'd add one more option to that list: it is _finished_ (and implemented in a language with good backwards-compatibility discipline).

To me they mean merely that other people have also looked at this project and found it interesting enough to star, so I might expect less resistance from others to using it if I too decide it's cool and want to use it.

I wouldn't be comfortable inferring much about adoption from number of stars, based on my own starring behavior, which is often "this seems cool, maybe I'll look into it more deeply later".

If there are competing projects that I am unfamiliar with, stars count and last commit date decide which I try using first. If it works, I go with it.

I may star both repos in case an issue comes up and I need to try something else. I use stars to “save” repos so I can find them later if I forget the names.

I am a bootstrapped founder and I find this to be the quickest approach.

Stars mean different things to different people. Some people use them to like something, others just to bookmark it for later.

I use them as exactly this - Bookmarks.

I use stars as bookmarks, but i also use the watch feature to keep track of stuff i find interesting.

Less than ~20 stars = I’m gonna have to maintain it myself. Whether this is practical depends on the scope.

Anything else is pretty meaningless.

A star means "I think your project is cool, but just not enough to contribute to it (with a fork)."

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.

if stars == 0: Nobody heard of it yet.

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.

I assumed stars were like favorites.

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.

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.

Github watches mean much more than stars imo. it means people are actively paying attention

They don't mean anything for me. To be honest, I barely even remember they exist, let alone look at what score a project has when I look it up on Github.

Maybe it's the way it's placed on screen that makes it so easy to overlook for me...

Literally nothing. If it's a thing I need to use, I look at how actively it's being maintained, whether issues get responded to quickly, and whether issues get closed within a reasonable time or linger for three years.

Depends a lot on the type of project. If it's something trendy, like a new JS framework, it means nothing for me. If it's something more specific and there are other alternatives, then it starts to mean something.

Lack of stars usually means that project is dead or has absolutely no community, so a red flag. Plenty of stars only says it's popular, not that it's a good fit for you.

Absolutely nothing.

More interesting is what uses it (if it is a library), when the last commit was, and is there any old issues with no updates from owners.

How many people have viewed this repository and decided to save it for later. Basically, how many people have bookmarked this project?

I use them to bookmark something I want to evaluate for use later and don't really use them for any other reason.

That it's popular. Nothing more. There are cases where it matters, there are cases where it does not.

i feel stars is a fair indicator of popularity but is low on the list of metrics used to evaluate the project.

documentation over everything, followed by using a rough mental calculation of open issues and recency of commits.

Single digits stars are a signal to me that no-one has used the code yet.

I honestly didn't even realize they were still a thing that existed.

A quick way to select top 3 options for a deeper look.

Coolness of the project and/or the author.

Meaningless

Reply on news.ycombinator.com