DEV Community

Cover image for Should the Quality of GitHub Projects Be Evaluated by Their Star Count?
Robert Cooper
Robert Cooper

Posted on • Updated on

Should the Quality of GitHub Projects Be Evaluated by Their Star Count?

GitHub doesn't show you many statistics related to a repository, aside from a repository's star count. When evaluating a repository on GitHub, I often find myself giving a lot of weight towards how many stars the repository has gained.

Repository owners especially love it when they receive a lot of GitHub stars as it provides them with a sense of accomplishment. There are articles written on how developers can get more GitHub stars for their repositories, using tips such as writing an attractive README and even using paid advertising to get more eyes on the repo.

The other day I stumbled upon a set of guidelines for recruiters that are trying to hire developer talent. One of the recommendations was to look for developers who have repositories on GitHub with 100+ stars.

Should we all be evaluating the quality of a GitHub repository based on its star count? Probably not, but it is an easy metric for people to look at. There are a ton of different factors that factor into a great GitHub project.


Here are some things to look at when trying to evaluate the quality of a GitHub repository:

  • Pull Requests

Seeing recently merged pull requests is a good sign that the project is actively being maintained and improved. 

  • Issues

Issues that are answered in a timely fashion by maintainers is usually a good sign. I wouldn't worry too much about the amount of issues in a repository, as large repositories are likely to have a bunch of issues. For example, at the time of writing, the VS Code repo has 3,925 issues, but their app is incredibly useful.

  • NPM downloads

You can also look at the downloads a tool has in NPM to see how popular a project is within the community. There is a good article that talks about when Vue surpassed React in terms of GitHub stars, but React is still downloaded much more than Vue on NPM. If a project is highly downloaded from NPM, it means a lot of other projects rely on it so it hopefully has some good stable features you can take advantage of in your own projects.

  • Documentation

If a project has little to no documentation, it doesn't matter how good the project is because you won't know how to use it. Having detailed and easily to understand documentation associated with a project is a good sign that the project can be used in all the ways described by their own documentation.


Overall, don't just rely on how many stars a project has when trying to evaluate an open source project. A good tool could solve a very specific need for a niche audience, but have a low number of stars on GitHub since it isn't a trendy or popular tool.


If you found this article consider following me on Twitter, Github, or LinkedIn.

Top comments (27)

Collapse
 
jerodsanto profile image
Jerod Santo

Don’t forget to read the code! 💯

There’s no better way to evaluate the quality of software than to inspect the actual software itself. With proprietary stuff this isn’t an option, but the beauty of open source is all the code is right there waiting for you to read it. 🙌

People often skip this (paramount) step because reading code can be difficult and time consuming. Here are a few questions you can ask yourself about a project, to get you started:

  • Does it have tests?
  • Can I run the test suite and they all pass?
  • Are the classes, functions, and variables named well?
  • Is there a logical flow of execution?
  • Would I design a solution similar to this?
  • Are there code comments? If so, are they useful?

The benefits of this process are immense:

  • You’ll learn a lot of tricks and techniques
  • You won’t be as intimidated to dive in and change or fix something if the need arise
  • You’ll be much more confident that the dependency you’re adding to your software is high quality

As a wise Jedi once advised his Padewan:

Use the source, Luke

Collapse
 
robertcoopercode profile image
Robert Cooper

Great point! I never even thought of actually looking at the code, lol.

Collapse
 
itsasine profile image
ItsASine (Kayla)

Especially since there was a bit about how recruiters look at stars. The vast majority of devs that have hobby githubs aren't going to be doing it for the stars!

I'd want to know if I'm hiring someone who writes good code when no one's watching rather than popular code with a lot of eyes on it.

Collapse
 
thejoezack profile image
Joe Zack

Most programmers don't have any (or any non-trivial) code in public, so it is a big bonus to see a programmer with a popular repository.

If nothing else, it's an indicator that the programmer...

  • identified a useful problem to solve, and solved it
  • identified a better way to solve a problem, and solved it
  • cared enough about a problem to solve it, communicate about it, and maintain a professional repo (readme, issues)
Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

Stars aren't a good indicator of quality, but they do demonstrate a programmer's ability to manage a project to some degree. They're another piece of evidence in the big pool of things that could be considered.

Collapse
 
balintd profile image
Bálint Deáki

I think going as far as filtering for developers based on their Github repo star counts is not a good idea.

I was on an interview once where the CEO anc CTO tried to figure out if I write good code or not. I mentioned a Github repo of mine that I made entirely to be able to show what kind of code I write. The CTO then mentioned that the repo doesn't seem to be very popular and did that in a snarky way.

Sure, it didn't have any starts or any activity on it, but it had many hours of my work in it and it was a perfect indicator of how I coded at the time. Even though I probably dodged a bullet there, them dismissing that entirely because it had no stars was still discouraging.

Collapse
 
hasnayeen profile image
Nehal Hasnayeen

When interviewer judge your skill on something other then the code itself you have only one thing to do, RUN!!!

Collapse
 
robertcoopercode profile image
Robert Cooper

Wow. That employer seemed to have missed the point entirely.

Collapse
 
tiagodenoronha profile image
Tiago de Noronha

All my projects have one star (mine :)) but even tho I'm the only one using it, I try to have the most code coverage and the most comments on the code. You never know if this might be something useful to someone and you best make sure it's easy for another person to use it!

Collapse
 
cjbrooks12 profile image
Casey Brooks

The first thing I check when evaluating a Github project is the commit history. In my opinion, it gives me the best overall impression of the quality the code and the health of the whole project/community. Specifically I'm looking for:

  1. What has been changed recently? Lots of features with no commits for bug fixes indicate a project early in its life. Are there lots of merge commits, but few "normal" commits? This could indicate the project is mature and feature-complete, and very stable. As long as there are recent commits, even if they are mostly community-contributed, means it is still actively maintained.
  2. When was the last commit made? And when was the last commit before that? I typically consider repos as no longer maintained if they haven't been updated in a more than a year, or if they have been updated less than once a month for over a year (not necessarily one commit per month, but infrequent "spurts" of activity with no consistency).
  3. Who is contributing to the project? For projects with fewer stars I would expect just one or two committers, but projects with lots of stars and few recent contributors may indicate the project is dying.
Collapse
 
robertcoopercode profile image
Robert Cooper

That seems like a very good and thorough approach 👍🏼

Collapse
 
moopet profile image
Ben Sinclair

If it has more than zero, then they're probably doing it wrong?

 
_bigblind profile image
Frederik 👨‍💻➡️🌐 Creemers

I'm not convinced. Hard-to-understand code can be hard to maintain as the codebase grows and evolves. It also becomes hell when there's a bug in code that uses that library, and you have to dig through incomprehensible stack traces.

Collapse
 
krofdrakula profile image
Klemen Slavič

You have to look at it from the perspective of a recruiter; they don't have the skills to rank developers, nor is there a unified and published metric that you can rank them in general. Even after interviewing someone you might pass up or hire the wrong person, and you're much more qualified. I'm using the general you in this context, not you personally, but we all fall in this category.

The reason they use this metric is because there are no other prominent ones to use and compare other candidates against, so in their view, anything that serves as a proxy for the real value is useful to them, regardless of absolute quality. It's good enough for them; they're just the initial filter.

Collapse
 
aghost7 profile image
Jonathan Boudreau

While I agree that the number of open issues alone isn't very indicative, I think the ratio of open vs closed issues is useful. This can tell you how well the scope of the project is being controlled, how well organised the owner of the repository is, etc.

In your example, VSCode has 3k+ issues of open, but there's a total of 55k issues in their tracker. I start would worry if I saw a tracker with a ratio of around 1 open issue for every 4 closed, depending on maturity of the project.

Collapse
 
smalluban profile image
Dominik Lubański

I agree, that stars should not be used to rank the quality of the project, but they can be really useful. When I published the major release of my recent project (some newsletters, hacker news, etc.), stars on the GitHub helped me a lot.

If your project gets a lot of stars in a short period of time, it is shown on the trending page. This makes your project more visible to other news creators, which also make it more visible to the community.

After super fast growing, it is not soo much important anymore. However, it shows people, that project is noticed by a wider group of programmers.

Unfortunately, people use stars more like something, that tell them if it is worth to read more about a project at all, rather than a clue, that more people already know that, so maybe I should too.