A New GitHub Rank Algorithm

November 26, 2018 · 3 minute read

Every budding Software Engineer longs for the day that one of their GitHub projects hits 100 stars. I am proud to say that I recently hit this coveted milestone. I have this Hacker News post—which went viral for about 24 hours—to thank for that.

At the time of this writing, funky has 317 stars on GitHub. But, with that said, I imagine that only a small percentage of the users who starred the project have actually continued to use it. In fact, I’m fairly confident that the project has been overcompensated (with stars) considering how much actual use it has seen from the developer community.

Alas, I have come to a bitter conclusion regarding GitHub projects: a larger number of GitHub stars does NOT indicate a larger value added to the developer community (which IMHO should be the ultimate goal of any open source project). This realization has led me on a search for a better way.

tl;dr: GitHub stars have long been an insufficient means of determining a repository’s worth. It’s time for a new ranking system.

The Rank Algorithm

In this section, I provide an example of an algorithm that I believe provides a better metric for how useful a GitHub project is to the developer community. From this point forward we shall refer to the idea of a GitHub repository’s worth or usefulness to the developer community as the repository’s rank. The rank algorithm is based on a simple pair of assumptions:

1) GitHub stars are unreliable for determining a repository’s rank, but are a good indicator of the amount of long-term traffic that the repository has seen.

2) GitHub forks represent a form of active engagement with the repository and are thus a more valuable metric for determining repository rank.

Keeping these two assumptions in mind, I propose the following algorithm: