Why Email is the Best Discussion Platform

Author: Jake Bauer | Published: 2020-06-07

Lots of very vocal people online advocate moving discussion platforms for free and open source projects from email to other platforms such as Discourse, Slack, or Discord citing that these platforms are “more modern” or “easier to use”. For the most part, I understand where they’re coming from. Email as a text-only medium (ignoring attachments) can be limiting to someone used to the multimedia, resource-heavy landscape of most contemporary collaboration platforms.

I get it. These platforms are more inviting because of a friendly UI, inline image, link preview, and emoji support, and they run in the browser which is where everything else is seemingly done nowadays. The problem is that open source projects typically give up the advantages that come with using open and light platforms for features that are more flashy than they are useful and which rarely improve discussions which could otherwise happen and work just fine over email.

Historically, and still to this day, many free and open source software projects (Debian, git, the Linux kernel, etc) use a combination of email and IRC for their communications. Email is the asynchronous platform where decisions can be announced, questions can be asked no matter who is online, and there can be an open, public record of discussions and questions which can be freely searched by anybody by consulting the published archives of that mailing list, and IRC is the synchronous, ephemeral platform where developers and users can go to hash out quick discussions, get answers to their support questions quickly, and generally hang out like one would in a Slack or Mattermost channel.

The biggest problem with contemporary platforms is that they’re functionally a regression from what already exists. Platforms such as Slack and Discord are closed-source, walled gardens. Discourse and Mattermost are slightly better, but have poor support for third-party clients which is especially a problem for users with disabilities who find text-based interfaces far easier to use.

All of these platforms take a long time to load on a slow connection, download and run many megabytes of JavaScript, and must be run in a browser which is a very resource-hungry piece of software that can be difficult for those with fewer computing resources (such as those using second-hand equipment in poorer countries) to run.

Not to mention that services which use analytics, such as Discord, are monitoring their users all the time. It’s entirely possible for platforms like Discord and Slack to be sharing the information they collect with third party companies who then go on to sell it (if they don’t already sell it themselves).

So, what does email bring to the table over contemporary options? Email is federated, it allows one to use a variety of different clients, it can be used both for patches and discussion, the asynchronous nature is actually beneficial, and it eschews cruft and flash to leave you with nothing but plain text. It’s also nowhere near as difficult to use as people make it out to be.

The fact that email is federated allows anyone with an email address to communicate with any public mailing list no matter who their provider is. For example, there’s no need to create a Debian account to post on a Debian mailing list, anyone with a Gmail account can communicate with anyone using a ProtonMail account, and so on. The barrier to entry is lower than with other platforms. Federation also allows one to run their own email infrastructure if they wish (and they should, in my opinion).

With email, you can also choose whichever client they wish to use. If you work in emacs you can choose mu4e. If you prefer Thunderbird then you can use that. As long as your email client supports plain text email, you can use whichever you like the most. This is important to many hackers who often heavily customize the software they run to fit their workflow and their needs. Using email allows for this freedom, but the wide variety of clients also means that you’re not forced to do this if you don’t want to.

Another great thing about email is that it can be used for patches in addition to discussion. Sending patches via email is as simple and straightforward as using something like pull requests. Just like with pull requests, the discussion can be had in the same thread as a submitted patch and patches can be applied to a repository; all without needing to open a web browser.

Unfortunately, email has a reputation of being hard to use. Frankly, I don’t think this is deserved. Email is not difficult to use, it’s just different and it takes just a little time and effort to learn a different way of doing things. Many thousands of people use it every day contributing to projects like the Linux kernel without issue.

Regarding things like bolding and italicizing, people make do just fine using /italic/, _underline_, or *bold*. There’s even ALL CAPS for when you’re really angry. In short, you’ll have no issue getting your point across. Some also say that email conversations are difficult to follow, but that’s not really true depending on your mail client; they’re more like Reddit threads in any decent email client which supports conversation threading.

The fact that email is fully asynchronous is actually far better for discussions than you might think. Since there are no features showing that someone is online and people don’t expect immediate replies to emails, this gives one room to take the time to draft a much more thoughtful message when compared to the instant messaging structure of most other platforms. There’s also a lot less pressure to respond immediately and there are no anxiety-inducing typing indicators or read markers.

The final point that I want to make about email is that, just like IRC, there are no frills; it’s just regular old plain text. There are no embedded images, flashy moving pictures, reactions or anything else like that. It lets you truly focus on just what is important: the content of the message.