>, but I think email lists the most accessible decentralized substitute. [...] my comment where I select email precisely because it uses boring old technology that is already available as native applications. No one has to install FTP servers to use email, they simply have to use their existing email setup.
If you're talking about pure email-clients-to-email-clients (p2p) as an implementation of a "mailing list", then yes, no extra software or host server has to be installed. However, this type of p2p setup is not scalable for adding new contributors. (E.g., many users would not want 1000s of email addresses of people they don't know in their personal address book just to facilitate FOSS discussions or bug reports.)
Instead, the typical mailing list requires a server to host the messages for people to subscribe to. Most programmers (e.g. leaders of a FOSS project) would only have "existing email setup" like Thunderbird/MSOutlook _clients_ and therefore missing the mail _server_ architecture. This means your assumption of "already available native apps" doesn't apply.
If a FOSS project wants to use a mail server, they need to figure out which software/service to use and how to pay for hosting.
Compare the decision tree, effort, and costs for email server -vs- Discord "server":
> If a FOSS project wants to use a mail server, they need to figure out which software/service to use and how to pay for hosting.
I think that even when using a third-party server, like, say, Google Groups or https://lists.sr.ht/ for this, the amount of control you get over your data and conversations is much higher than something like Discord. All of the conversations on the list during your membership of it are trivially archivable and searchable using software that is probably built into your operating system.
This is not to say that the server-side component of it, i.e. setting up an email server is easy. On the contrary, I'm saying that we should work to make it so. The link you post is a good example of the contrast, and I think that a Discord-like FOSS email list solution would be a great project.
>I think that even when using a third-party server, like, say, Google Groups or https://lists.sr.ht/ for this, the amount of control you get over your data and conversations is much higher than something like Discord. All of the conversations on the list during your membership of it are trivially archivable and searchable using software that is probably built into your operating system.
Again, your statements above emphasize the advantages of client side tools but not the tradeoffs of various server side options for the FOSS admins. You've listed the positives of your use case in multiple messages but surely you'd know that the tech audience of HN and the FOSS admins are already aware of them.
To make progress, we need to dissect the server landscape from the admins' perspective. Consider your proposals of, "Google Groups or https://lists.sr.ht/"
- lists.sr.ht : Costs money. It's not a lot but it's more than $0. (https://sourcehut.org/pricing/) This is also a small hosting business and some project may be uncomfortable basing their discussions there rather than a bigger company like Microsoft/Google/Discord/etc. The sr.ht owner likes to emphasize the infrastructure's "alpha" status which seems like a "caveat emptor" : https://drewdevault.com/2019/01/13/Backups-and-redundancy-at...
- Google Groups : $0 cost but a lot of projects are dissatisfied with GG and want to switch to more modernized[1] discussion software. (And some for ideology reasons would rather avoid using Google services.) Examples:
(Yes, Github/Microsoft is a walled-garden but that didn't seem to be the biggest concern. Their immediate desire was to switch from GoogleGroups. And Github Discussions being free $0 probably helps.)
(You don't have to read that whole thing but here's an example comment[2]. The tldr is they eventually decided on Discourse self-hosted. Now they have a new complication of how to pay for ongoing server costs at Digital Ocean for the Discourse server: https://talk.tiddlywiki.org/t/paying-for-discourse/289)
So what project leaders are trying to do is find the optimal tradeoffs on the server side :
- ideally $0 cost
- ideally zero setup and maintenance. E.g. click "+" button to create instant server in Discord rather than install phpBB or vBulletin or mailing-list software
- ideally have modern features[1]
- ideally open source if possible. Discourse is open-source but then you have to decide on SaaS hosting at $1200/yr (https://www.discourse.org/pricing) -- or pay for self-hosted costs.
- ideally avoid massive scope creep by not developing a "Discord-like FOSS email list solution" even though some users envision an ideal world where such software exists. In that spirit, I thought it was amusing that in TiddlyWiki discussion to migrate to different forum software, they toyed with the idea of extending TiddlyWiki itself (aka dogfooding TiddlyWiki) to handle the forum discussion. They abandoned that idea and just went with Discourse.
Ultimately, whenever an end user is frustrated that "FOSS project leaders don't do what I want them to do!" and wonder why they end up choosing Github Discussions or Discord ... it's the result of tradeoffs above. The hypothetical forum discussion software that makes all clients and admins happy doesn't exist.
[2] a comment excerpt : >[...] One new deal breaker for me with google groups is that now I can't reply from the browser on my phone. This is some new change that happened in recent months I guess. Yes, I can subscribe to emails and reply that way, but my gmail is already clogged enough as it is and this list is very high traffic. For forums like this I prefer to read and interact with it on the web, or else use discord/slack. [...]
- ideally zero setup and maintenance. E.g. click "+" button to create instant server in Discord rather than install phpBB or vBulletin or mailing-list software
Zulip has a topic-threaded model that threads the needle between email threads and instant messaging in a way that's much better than Slack threads: https://zulip.com/help/streams-and-topics
- ideally open source if possible. Discourse is open-source but then you have to decide on SaaS hosting at $1200/yr (https://www.discourse.org/pricing) -- or pay for self-hosted costs.
> Ultimately, whenever an end user is frustrated that "FOSS project leaders don't do what I want them to do!" and wonder why they end up choosing Github Discussions or Discord ... it's the result of tradeoffs above. The hypothetical forum discussion software that makes all clients and admins happy doesn't exist.
It's a bit hard for me to understand why Zulip is so lightly represented in these discussions – for example I saw it mentioned in the TiddlyWiki thread you linked, but the talk seems to have tailed off and mysteriously settled on Discourse. Someone seems to have the incorrect idea that Zulip requires running your own instance of it; that's not the case.
My hypothesis here is that there's a decent level of groupthink which tends to reject perfectly available FOSS solutions in favor of equivalent proprietary ones because FOSS solutions have (perhaps rightly) gained a bad reputation over the years as being difficult to use and operate. My thesis in this thread is that it's high time we began re-evaluating that, and giving FOSS tools a fair chance rather than prematurely declaring them to be bad; especially in light of data portability concerns.
If you're talking about pure email-clients-to-email-clients (p2p) as an implementation of a "mailing list", then yes, no extra software or host server has to be installed. However, this type of p2p setup is not scalable for adding new contributors. (E.g., many users would not want 1000s of email addresses of people they don't know in their personal address book just to facilitate FOSS discussions or bug reports.)
Instead, the typical mailing list requires a server to host the messages for people to subscribe to. Most programmers (e.g. leaders of a FOSS project) would only have "existing email setup" like Thunderbird/MSOutlook _clients_ and therefore missing the mail _server_ architecture. This means your assumption of "already available native apps" doesn't apply.
If a FOSS project wants to use a mail server, they need to figure out which software/service to use and how to pay for hosting.
Compare the decision tree, effort, and costs for email server -vs- Discord "server":
- https://huridocs.org/2016/06/setting-up-an-email-discussion-...
... vs ...
- https://support.discord.com/hc/en-us/articles/204849977-How-...
> Guess what you also have to use to reset your Discord password -- that's right, email.
Right but an existing email account (on somebody else's mail server) -- is a different beast than an email server to host mailing lists.