Some missing features in software forges

A lot of my work happens on software forges like GitHub or GitLab. They are very useful platforms, but they are not perfect. In this post I want to describe a few missing features around the transmission of open source projects to new maintainers.

Discovering active forks of a repository

A lot of projects are maintained by a single person who, after a while, loses interest in the project, or even moves on completely and stops responding to any activity on the repository.

In theory, that’s not a problem, right? If there is still a community of people relying on this project, they can “just fork it” and continue their activity there. Of course it’s not that easy: the project will often be associated with assets that cannot be reclaimed, like a domain name, a package name in some package repository, social media or crowdfunding accounts, and so on. But even ignoring all of those, one basic thing will need to change: the address of the repository.

And this is where I find existing software forges quite disappointing. Most of them (like GitHub or GitLab) have a notion of “fork”, meaning that it’s possible to create a personal clone of a repository under one’s account (or as an organization), but this way of forking a project is rarely helpful when someone (or a group of people) actually want to continue development on a project because they are unable to do so in the original repository.

Why is pressing the “fork” buttons on GitHub or GitLab not a solution in such a situation?

Because they aren’t really meant to fork anything! Those so-called “forks” are primarily designed for a very different situation: making a contribution to a repository that is actively maintained. You fork the repository, create a branch there, make your changes and submit a pull request. One sign of this intention is that commits you make in your fork will not appear in the activity timeline on your profile: those will only be recognized as contributions once they are sent upstream.

The bigger problem, I think, is that people landing on the original repository will have a hard time discovering your actively maintained fork. GitHub’s “Network” page does make it possible to see the list of forks and get a rough sense of which ones seem to be active, but one needs to be quite motivated to go there and investigate the state of the project’s ecosystem in this way.

What I would find useful is that when repositories lose the attention of their owners, the forge starts advertising the most active fork(s) on the main page of the repository. This would require some safeguards, as it would be tempting for spammers or crooks to exploit such a mechanism by creating artificially active forks of very popular repositories, so that they redirect the attention to them.

So how about taking some inspiration from those pedals train drivers need to regularly press to confirm they are still conscious? After one year (say) of the repository owners not being active in the repository, they are sent an email asking if they still feel responsible for the maintenance of that repository. If they do not confirm that they have it on their radar, the repository is marked as inactive and forks are displayed on its main page, ranked by some activity or popularity measure.

I think a feature like this would really help avoiding discontinuing software projects needlessly. GitHub has this helpful “successor” feature, making it possible to transfer the ownership of your repositories to someone else when you die, but that’s of course an extreme case: a lot of people abandon their repositories well before they die. The conditions for this mechanism to kick in are really hard to meet: the owner must have known of the feature and used it before they died, then GitHub must get some sort of official confirmation of the death from some authorities (I suppose, at least) and finally the successor should be available to respond and take on the ownership or transfer it further.

Granting more rights to new contributors

Consider the different situation of a healthy project, actively maintained.

When a new contributor arrives in the project, there is generally no clear route for their onboarding. They might have made dozens of excellent contributions and have shown their commitment to the project over many months, yet they will generally not be allowed to do basic things such as labeling or closing issues. There is generally no clear message as to what bar needs to be met to obtain commit rights.

I believe a lot of projects would benefit from more proactively granting project access to trusted contributors, but the because the forges do not incentivize that at all, they maintain the culture of open source contributors being performers on a scene, delivering their great sauce to an audience of “stargazers”, to put it in GitHub’s terms.

Compare this to how other platforms grant rights automatically after some thresholds are met. On many Wikipedia editions, after you have made a bunch of edits, you become “autoconfirmed”, meaning that your edits to pages are no longer flagged as needing review. On StackExchange, after having earned enough reputation points, you can edit questions or answers written by others, or have access to some review queues. I am not aware of anything comparable on software forges.

Now obviously, automatically granting rights to people after they have met certain thersholds has security implications. People can introduce bugs, vulnerabilities, spam or other sorts of nasty things in projects. Writing software is arguably a bit more sensitive than an encyclopedia or a Q&A site (although, I am sure you can make a lot of nasty stuff on such platforms too). It does make sense to keep the repository owners in the loop, especially to grant higher permissions such as the ability to publish releases. Just like you don’t automatically become an admin on Wikipedia, no matter how many edits you do.

So here are a few measures I am thinking about, which could lower the barrier to onboard people:

• Having a way to request access to a repository. It’s such a basic thing, but GitHub does not have that (GitLab does). Whenever I think I could help out on a GitHub project, I try to identify who is in charge by looking at recent repository activity, and then try to find an email address for that person. Sometimes it’s visible in the commit log, sometimes not, so I would then try to stalk the person via a search engine, or awkwardly open an issue about my offer to help. One needs to be pretty self-assured and motivated to go that far!
• Having the forge actively suggest to the maintainers granting more rights to recurrent contributors. I would love to get a message along the lines of “this is the third pull request you approved from this person. Why not invite them to the repository?” You could even imagine that for some projects it would be appropriate to automatically grant such accesses after some threshold is met. The thing is, as a maintainer this is something I really don’t have on my radar all the time: I try to keep the issue and pull request backlog under control, publish releases regularly, respond to security advisories, do some user support, and probably other things on top. It’s already a lot of things to keep track of, so the task of proactively inviting people in the project gets easily forgotten. When our own interest in running a project fades away, it’s often too late to find a successor, so I think it’s really worth inviting people over earlier, when the excitement and activity are still running high.

Some open source projects are by design meant to be only run by a certain team and are explicitly closed to other contributors. Some public Git repositories are merely used as online storage space with versioning, for a single user. That’s fine too, but I don’t think that should be the default that forges draw us towards.