But you can still do distributed repos with github... nothing it preventing you from changing your remote origin...
If your remote goes down but you have an email based workflow, you can continue as if nothing happened. One could argue that your mail server might go down, but it’s better than having your centralized GitHub-like forge go down for two reasons:
1. If not all contributors use the same mail server, it’s much less of an issue since not everyone goes offline at the same time. Additionally, your maildir doesn’t care whether or not you’re online; both the git repo and all mailing lists have offline copies distributed to all collaborators out-of-the-box by default.
2. GitHub’s reliability is significantly poorer than the vast majority of email providers. The great thing about decentralization is that getting good uptime on a small mail server for under 1000 users is much easier than getting good uptime on a centralized forge re-implementing email’s features for millions of users.
If your mailing list server goes down, no one can use the mailing list. Taking it a step further, if its data is lost, everyone has to re-subscribe.
On top of that, you have a mailing list archive. If that's down, or not operating, you've made thing even less open, because now any non-subscribers can't even read what's going on, and if they do subscribe, they only get to see new messages. Existing long-time subscribers have an archive, sure, but it's very possible no one user has a complete archive, and it's a certainty that most users don't.
Someone can run a redundant mailing list archive server, but then someone can also mirror the GitHub repository, PRs and issues.
---
That said, the mailing list server and archive are likely simpler to run, less likely to go down, and easier to move somewhere else.
Transferring from github.com to something else is going to be painful, and I suspect most FOSS authors simply don't think about it or see the ease and benefits of using it as outweighing the risk. Companies should look at that risk much more closely, but ultimately it's the same situation as if they decide not to have fire insurance: if their building burns down, they're SOL, but that was the decision they made.
For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.
Email archives are very easy to transfer, you simply download the mbox file from the old system and import them to the new one [0].
> For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.
In my experience, projects that use a ml-based workflow have higher standards for commit messages and so the information about a commit is usually in the commit.
[0] https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archi...
Mailing lists are trivial to distribute. Thanks to maildir and mbox, everybody has a full copy of the mailing list just as they have a full copy of the repository.
No, that only covers emails that you personally received. You need another mechanism for older emails.