Mailing Lists

Emails allow responding to any other email message that has been sent. This allows for unlimited threading capabilities.

Emails can be written offline and sent when back online. Being offline might be a choice for some developers, who like to work distraction-free. But it is even more important for developers without constant internet access, although this becomes more and more rare.

Hosting a project on GitHub or any similar plattform locks you into their issue tracking and pull request system, with no easy way to switch from that. Since email is an open protocol, nobody is locked into using any specific client or server, except for the usually self-hosted and (easily) switchable list server.

With GitHub, participants in discussions are required to be registered users on the plattform. Identity authentication is therefore provided by said plattform. However, with email authentication is provided by the ICANN, an international institution.

Email clients have been around for a very long time. People can choose any of those to work with and hook them into their workflow with keyboard shortcuts, scripts and whatever else they desire. Mailing lists make it much easier (or actually possible) to follow the UNIX Philosophy.

On mailing lists contributors don’t create a git branch with suggested changes, but instead submit a list of patches in the emails. These patches will always stay as-is in the email, which means anyone can refer back to them at any time, preserving history. A gitbranch will usually be force-pushed to, to keep a clean history. That deletes any information on the old patches though, making it impossible to re-use any ideas from them, or simply refer to them.

Since pull-requests on GitHub are done by forking a project, other users cannot add any commits to the branches made on the forked project. Continuing the work of another contributor who might have gone MIA requires the creation of another pull request, loosing context. On mailing lists, it’s as simple as answering to the latest message with a new set of proposed patches.

Since patches are hand-crafted or at least hand-pasted into each mail, they can be edited for ease of use. This means no algorithm has to decide how exactly to calculate differences between files, but rather the author of the patch can decide how best to describe their changes.

In mailing lists, implementation of a discussed feature or fix is as simple as responding with a set of patches. On GitHub and similar plattforms however, issue tracking is entirely separate from implementation (pull requests), requiring a context switch and loss of easily discoverable history once the initial discussion stage is over.

Tooling for repository hosting services such as GitHub or gitlab is being developed rapidly. It is very easy to set up automated software testing for any commit to a remote branch. This tooling is harder to set up for mailing lists, where you don’t have a branch to work with but instead have an evolving list of patches to apply to the project.

GitHub has a unified interface for all projects hosted there, and any similar services work basically the same way. That means that once a developer has learned how to contribute to one project, they have an easy time contributing to any other project hosted on the plattform as well. Mailing lists have different sets of guidelines and rules though, getting information on the project itself usually requires you to go to the website or the project’s readme, which are generally harder to get to and have an idea of how to navigate than on the plattforms, which make this experience the same for all projects. The git server is different for projects too, which makes it a different process anytime anyone wants to just look at the source code before deciding to contribute, download or otherwise interact with it.

Plattforms such as GitHub have a concept of starring projects, which gives social credibility to the projects. They also have a global search, which allows easy discoverability of projects for specific topics. Mailing lists on the other hand don’t have any such social credibility system in place. While older projects do just fine without, newer projects need to use tricks such as hosting a read-only mirror on github for reference and social credibility.

The plattforms make it easy to see a list of all open issues and bug reports. Mailing lists do not have any intrinsic feature like this, requiring other tooling to be set-up. However, quite a few options exist here, so this issue can be fixed with a bit of setup.

On GitHub it is very easy to see whether a pull request has been reviewed and accepted for merging. On mailing lists however, there’s no such system in place by default, and external tools have to be set up which might or might not integrate nicely with workflows of the participants.

On GitHub all discussions are hosted on one provider, where all future participants have access to any past discussions. On a mailing list, an archiving system has to be set up (which is easy to do) and past emails have to be imported by the future reader to have easy access to them in the same way they would have access to messages after they’ve joined.