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)
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:
The benefits of this process are immense:
As a wise Jedi once advised his Padewan:
Great point! I never even thought of actually looking at the code, lol.
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.
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...
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.
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.
When interviewer judge your skill on something other then the code itself you have only one thing to do, RUN!!!
Wow. That employer seemed to have missed the point entirely.
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!
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:
That seems like a very good and thorough approach 👍🏼
If it has more than zero, then they're probably doing it wrong?
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.
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.
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.
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.