Why Email is the Best Discussion Platform
Author: Jake Bauer | Published: 2020-06-07
I get it. These platforms are perhaps more inviting because of a friendly UI, inline image, link preview, and emoji support, and it all runs in the browser which is where everything else is seemingly done nowadays. The problem is that these features really aren’t necessary and they 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, infinite public record of discussions and questions which can be freely searched by anybody by consulting the archives of that mailing list or the various mailing list archiving sites. 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. IRC is a topic for another day, so I’ll just be focusing on why email is better in this post.
The biggest problem with contemporary platforms is that they’re functionally a regression from what already exists. Platforms such as Slack and Discord are walled gardens requiring account creation, Discourse and Mattermost are better, yet you still have to access them through a web browser and those who wish to use their own clients are treated as second-class citizens. This is especially a problem for disabled users who find text-based interfaces (of which there are plenty for email) far easier to use.
When using services such as Slack and others which use analytics, users have to be conscious that they are effectively being monitored by that software 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).
Not to mention the various other issues such as text-based content being far better for accessibility than what the web can offer, most of the web-based packages being very bloated where pages take seconds to load and megabytes of bandwidth, and the fact that web browsers are very resource-hungry pieces of software which can be difficult for those with fewer resources (e.g. people with second-hand equipment in third world countries) to run.
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, it’s nowhere near as difficult to use as people make it out to be, the asynchronous nature is actually beneficial, and it eschews cruft and flash to leave you with nothing but plain text.
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, one 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 either.
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 or use a different piece of software.
Unfortunately, email has a reputation of being hard to use because of what I think is an unwillingness to learn a new paradigm after having become used to the way of doing things over the web. The reality of it is that email is not difficult to use at all, it’s just different and it takes just a little time and effort to learn a different paradigm. 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
*bolds*. 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 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 response 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 a message. The best part? Plain text email still supports emoji because that’s all just Unicode.
This is my thirty-seventh post for the #100DaysToOffload challenge. You can learn more about this challenge over at https://100daystooffload.com.