The GitHub Silverware Drawer Dilemma, Or: Finding Active Repository Forks

An fortunate reality of GitHub and similar sites is that projects that are abandoned by the maintainer are often continued by someone else who forked the project. Unfortunately, the ease of forking also means that GitHub projects tend to have a lot of forks, with the popular projects having hundreds of them. Since GitHub has elected to not provide a way to filter or sort these forks, finding the most active fork can be rather harrowing.

In addition, a popular project’s dead repository tends to score higher in search results than replacement forks. For these particular situations a couple of very useful websites and browser add-ons have been developed. The Lovely Forks add-on by [Utkarsh Upadhyay] seeks to insert information on forks that are notable or newer than the repository one is looking at.

Meanwhile, the Active Forks project by [Samar Dhwoj Acharya] provides a sortable list of project forks when provided with a GitHub repository name. This helps enormously when trying to find the freshest forks in a whole list. This is similar to the Useful Forks project that provides a web-based interface in addition to a Chrome extension. Do note that these queries will count towards the GitHub API rate-limits, so you may need to add an access token.

It’s a shame that GitHub doesn’t offer such functionality by default, but thanks to these projects the times of clicking through a hundred forks to find the freshest one is at least over. For now.

11 thoughts on “The GitHub Silverware Drawer Dilemma, Or: Finding Active Repository Forks

      1. I just tried the tool with openssl as repo. The results were just forks of the aria2 dev, another one was openssl+QUIC protocol, and deprecated fork by Microsoft. The recently pushed ones were suspicious repos with 0 or 1 star only.

        There can only be the original repo and a secondary if the dev of the previous repo doesn’t want or can work on the project anymore. Youtube-dl -> youtube-dlp springs to mind.

        Personally all my forks are for pull requests in other projects. Sometimes it takes years for a PR to be approved and I have already moved on. It’s beyond frustrating when it is a security improvement. Chances are I remain the only person using the fork. Last reply from the owner of the original repo was very positive, but they didn’t approve yet for reasons to support legacy ciphers.

  1. A lot of forks on GitHub are due to the fact that one cannot create a branch on repos that aren’t owned by them (or are part of a GH group/organisation that has access). These forks are often abandoned once the person got the changes they wanted, mainstreamed. I too have about a dozen projects forked just for a few small changes.

    What would be immensely helpful is if GH allowed marking a fork as a ‘true fork’ (i.e. “we’re changing the code and keeping it our own/continuing the work”), or a ‘change fork’ (i.e. “I’m forking this repo so I can commit some stuff back).

    Another useful feature would be sorting forks based on a more complex criteria than the current “last updated”. So many projects have forks that are “fresh”, but the only change was a selfish update to the changelog/readme… If the forks were sorted based on a more complex metric that takes things like number of changes, change frequency, change type (e.g. what kind of files were changed – just some Markdown files, or lots of actual code changes?), and so on.

  2. Quite a long ago GRBL grew out of the ATMEGA328. Codespace was far too small processing speed was barely enough maybe it got out of pins and other tings too. Then quite a lot of forks for 32bit uC’s were made, and over the years they came together again in the GrblHAL project. That was quite nice to see happen.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.