DEV Community

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

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

Robert Cooper on October 14, 2018

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

Collapse
 
elmuerte profile image
Michiel Hendriks • Edited

Is that what stars on github are for? I thought they were there to bookmark a repo and not to give of any judgement on a repository.

Stars, downloads, issues, ... they do not say much about quality of code.
Static analysis, unit test code coverage, ... they do say something about the quality of the code.

Collapse
 
robertcoopercode profile image
Robert Cooper

I also use stars to bookmark repositories I find interesting, usually just based off their Readme description

Collapse
 
rhymes profile image
rhymes

I use stars as bookmarks and when I review a project later on, if it's not useful or if it becomes part of my toolbox usually I remove the star 🤔

I would add the ability to write a changelog. I get increasingly frustrated by libraries without a changelog, I don't want to read a bunch of diffs to figure out what's changed. It's not a metric of quality per se but it's a signal the author cares about the users and probably a sign there's no rush in the release process.

 
_bigblind profile image
Frederik 👨‍💻➡️🌐 Creemers

readable.

A huge percentage of websites run on WordPress, so I'd say the code there is incredibly useful. But the last time I looked at it, I found it quite hard to grok.

But that's just my opinion :).

Collapse
 
adimail profile image
Aditya

I work in a startup. we were looking for interns for a technical role and we received few responses. While going through the resume projects they have listed in their CV I noticed most of those projects were just copied from other people on GitHub. The quality of the repo is another thing but sometimes I find it difficult if the project is really genuine, or is it copied from someone and that could be easily find out from looking at the commit history and I do that now

Collapse
 
bennypowers profile image
Benny Powers 🇮🇱🇨🇦

Nope, they shouldn't.

Collapse
 
wjnbreu profile image
William J.N. Breuer

i gave this post a unicorn to mitigate against over-reliance on evaluating based on hearts 🤙

Collapse
 
robertcoopercode profile image
Robert Cooper

This post was never going to make it to the big leagues either way

 
_bigblind profile image
Frederik 👨‍💻➡️🌐 Creemers

I'm not sure it always means good code, but it does usually mean useful or interesting code.

Collapse
 
notriddle profile image
Michael "notriddle" Howell
Collapse
 
elmuerte profile image
Michiel Hendriks

Most people are not Donald Knuth.