That software forges are often better than email is unfortunate

July 13, 2024

Over on the Fediverse, there was a discussion of doing software development things using email and I said something:

My heretical opinion is that I would rather file a Github issue against your project than send you or your bug tracker email, because I do not trust you to safeguard my email against spammers, so I have to make up an entire new email address for you and carefully manage it. I don't trust Github either, but I have already done all of this email address handling for them.

(I also make up an email address for my Git commits. And yes, spammers have scraped it and spammed me.)

Github is merely a convenient example (and the most common one I deal with). What matters is that the forge is a point of centralization (so it covers a lot of projects) and that it does not require me to expose my email to lots of people. Any widely used forge-style environment has the same appeal (and conversely, small scale forges do not; if I am going to report issues to only one project per forge, it is not much different than a per-project bug tracker or bug mailing list).

That email is so much of a hassle today is a bad and sad thing. Email is a widely implemented open standard with a huge suite of tools that allows for a wide range of ways of working with it. It should be a great light-weight way of sending in issues, bug reports, patches, etc etc, and any centralized, non-email place to do this (like Github) has a collection of potential problems that should make open source/free software people nervous.

Unfortunately email has been overrun by spammers in a way that forges have not (yet) been, and in the case of email the problem is essentially intractable. Even my relatively hard to obtain Github-specific email address gets spam email, and my Git commit email address gets more. And demonstrating the problem with not using forges, the email address I used briefly to make some GNU Emacs bug reports about MH-E got spam almost immediately, which shows why I really don't want to have to send my issues by email to an exposed mailing list with public archives.

While there are things that might make the email situation somewhat better (primarily by hiding your email address from as many parties as possible), I don't think there's any general fix for the situation. Thanks to spam and abuse, we're stuck with a situation where setting yourself up on a few central development sites with good practices about handling your contact methods is generally more convenient than an open protocol, especially for people who don't do this all the time.


Comments on this page:

By Simon at 2024-07-15 05:05:06:

[...] so I have to make up an entire new email address for you and carefully manage it. [...] I also make up an email address for my Git commits.

Why not use the same address for all those public development related activities?

Or if you really want separate addresses, use some catch-all config that allows using a new addresses without any setup effort (like cks-public-*@example.org, so if you write an mail to project foobar you use cks-public-foobar@example.org. If that addresses gets a spam problem you can then filter based on the target address)?

I get the various advantages (and disadvantages) of central forges over other methods, but the mail address argument seems odd to me.

FWIW: In my experience I don't get more spam to addresses that are public via FLOSS mailing lists, git commits or similar than I get to other addresses.

By cks at 2024-07-15 10:18:28:

The reason to have separate addresses is so that I can turn them off when they get too much spam (and change to using a new address in the appropriate places). This requires segmenting address usage aggressively, to reduce how many places I have to change when I change or drop an address. It also makes it clear who leaked or gave away my address to spammers.

Written on 13 July 2024.
« Network switches aren't simple devices (not even basic switches)
The Firefox source code's 'StaticPrefs' system (as of Firefox 128) »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat Jul 13 23:09:48 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.