LWN: Comments on "A farewell to email"

A farewell to email

martin.pitt — Sun, 28 Oct 2018 08:34:53 +0000

These days you need to set up SPF and DMARC in private mail servers. Since I did that, I didn't have a single rejection from yahoo, gmail, GMX, hotmail, or other large vendors.

A farewell to email

zblaxell — Sat, 27 Oct 2018 21:20:09 +0000

> So perfecting email notifications ... seems like an interface implementation detail.

Interfaces that, due to identical selective pressures, end up being imitations of email filters.

> there aren't and there will never be dozen of "github wannabees"

There _already_ are. I had almost 20 such accounts before I decided I wouldn't support that behavior any more. Most of them are (or were--attrition is high) gitorious or gitlab instances hosted on Linodes. Some of them are more exotic creatures I don't recognize.

The alternative puts a lot of eggs in the github basket, which doesn't seem like a good idea either.

> Congratulations: you've just implemented the decentralization in the "database first, optional email notification second" approach. Well done!

This doesn't seem like success. I'd expect success would involve me contributing to the other project as opposed to being forced to treat it as abandonware.

> That's not how *your* drive-by patches work, please don't generalize.

Huh? That's the definition of a drive-by patch: one contributor, one bug, one fix, one transaction.

> Less and less often; hence the title of this article.

Uh, no, this article is about developers who spend most of their time contributing to a handful of small or medium-sized projects like Python or Fedora, or some random Github. If you're integrating a hundred open-source components into an enterprise service deployment, or building bespoke hardware with a custom software stack, you're definitely not moving away from email as a primary collaboration tool any time soon.

Every few months I get to experience the next generation of new developers first hand in the form of coop students. They come in adept at using email on their smartphones and git from the command-line, but they navigate filesystems by clicking through GUI tools. They quickly learn to stop doing that--the GUI tools are unauditable (we do audits) and error-prone (we do testing), unrepeatable (we do automated deployments), and while not impossible to communicate, much more awkward and expensive (we work with people in different timezones). It's much easier to fix all that by mastering and using a scripting language day-to-day than by using any GUI tool that currently exists. After a while the students figure out they have to do that with email too, for mostly the same reasons--regardless of what tools they started with or might prefer to use, they need to switch to tools that can keep up with their peers and the workload.

> Normal, 9-5 "enterprise" developers tend to have much bigger, unrelated productivity issues at work than a once-off github account creation or having to cope with its web interface.

My 9-5 enterprise workday is where the pressures toward email-first as the collaboration tool become *most* acute.

If I'm paid to create accounts, I'll create all the accounts my customer/project/manager will approve engineering time for, and every customer/partner/supplier wants me to sign up for at least one. Bad web hosting experiences are just included in the price. Most of the real work still gets done by email, because any four collaborating engineering groups have no common database. All the idle databases seem like a waste to me, but I don't decide what customers want to pay for.

I most strongly object to having to do this as a volunteer or on otherwise unbillable time. We might have only a few hours--or minutes--to evaluate, integrate, and contribute to a small project. If the project's account signup interface takes ten of those minutes to complete, then it has burned the time budget for any kind of helpful feedback we might have. We can't afford to suck that up and continue stumbling through an unfamiliar or broken web interface when the next project is around the corner.

Maybe the project doesn't care it's not getting our contribution, or it only values contributions from people with more available time than we have. I can't care either way--we don't have a billing code for caring about stuff at work, and I usually have other things to spend my own time on. I'm volunteering my time here to inform project owners who otherwise may not be aware of potential contributions that can no longer materialize. This is the price of making cross-project collaboration harder vs. making intra-project collaboration easier.

> For instance they likely have to use Outlook (which can't do email at all!) and dozens of much crappier "home-made" web interfaces internally.

I haven't seen a new home-made web interface in an enterprise recently (though there are still plenty of legacy horrors that won't work on anything newer than IE6 out there). Enterprises seem to be moving to mature third party frameworks with plugins to support enterprise-specific activity. Gerrit, Gitlab, etc., or the equivalent proprietary silos are also taking over. That works for enterprises because they explicitly value intra-project collaboration over cross-project collaboration. It ends up being the individual engineers' job to work around that when working with outsiders.

Even Outlook has email distribution lists that can be created or joined with a few clicks.

A farewell to email

Cyberax — Sat, 27 Oct 2018 19:52:56 +0000

Want to make a bet?

A farewell to email

patrakov — Sat, 27 Oct 2018 15:01:04 +0000

No, spacex won't solve anything. Their satellites will be perceived as a threat by countries like China and Russia whose governments require censored internet. They have willingness and resources to just shoot down those unauthorized satellites.

A farewell to email

marcH — Sat, 27 Oct 2018 03:41:26 +0000

> > How many people still read lkml?

> lkml doesn't require doing the account setup dance before you can post to it. You certainly don't have to subscribe to it.

And now it's also "write-only". That example was about reading not writing.

> these [email notifications] features tend to be...

I'm trying to focus on the fundamental, core design question(s). So perfecting email notifications (for new, demanding users who are ex-email addicts) seems like an interface implementation detail.

> The effort is far from zero: one has to do a dance with the project's account creation system,

Fair point, this account overhead is the (IMHO reasonable) price to pay for personalizing and controlling the flow of incoming information - and taming spam which is as already discussed here a massive problem for "fully decentralized accounts" systems like mailing-lists. I don't see how you could have that cake and eat it. Maybe some genius will figure this one out.

There are many ways this overhead is kept reasonably small: OpenID and similar, large sites like github (there aren't and there will never be dozen of "github wannabees"), password managers, etc.

> I just close the browser window and fork the project instead.

Congratulations: you've just implemented the decentralization in the "database first, optional email notification second" approach. Well done!

> That's not how drive-by patches work.

That's not how *your* drive-by patches work, please don't generalize.

> Most of them can't do things like...

"Most" => perfectible implementation detail. Answered above.

> ... at least until the database schema reaches a critical level of maturity so that multiple interface tools can share a database. [...] -email is awful [...] The problem is that nobody seems to have produced anything better yet, [...] when we need something equivalent to bitkeeper or git.

Agreed, agreed and can't wait.

> until someone does, email remains the tool of choice for developers contributing across multiple projects.

Less and less often; hence the title of this article. This l33t and extremely productive community is IMHO underestimating how much "normal people" disliked email, spam, configuring filters and how much people can cope with poor web interfaces. Normal, 9-5 "enterprise" developers tend to have much bigger, unrelated productivity issues at work than a once-off github account creation or having to cope with its web interface. For instance they likely have to use Outlook (which can't do email at all!) and dozens of much crappier "home-made" web interfaces internally.

A farewell to email

marcH — Sat, 27 Oct 2018 01:50:06 +0000

To be clear I never meant "email for database replication" (that would be... patchwork v2?). The longer version: "Replicated/cached database first, optional and personalized email notifications second"

> Pulling the data into a local git instance solves many of the problems, but only if the database schema never changes; otherwise, you have half your project's history in one replicated silo and the other half in an incompatible replicated silo that eventually only runs inside a VM running an OS nobody supports any more.

Code reviews and other "human" conversations have a high read/write ratio and low volume compared to other database workloads. If nothing fancier comes for free then a simple scheme with 1 master + N throw-away, read-only slaves scheme is good enough.

A farewell to email

zblaxell — Sat, 27 Oct 2018 01:43:37 +0000

> Yet people are not interested. Something must have gone terribly wrong :-)

Well, somebody spent a lot of time implementing Thunderbird's email filtering capability, so I can't be the only one who uses it.

> Casual / drive-by contribution is all about NOT being copied to the entire project activity, that's the whole point. How many people still read lkml?

lkml doesn't require doing the account setup dance before you can post to it. You certainly don't have to subscribe to it. Even mailing lists with subscribe-to-post policies are problematic, as you can't just CC relevant people or projects to add them to a discussion.

> Most projects also offer "whole project" notifications for non-casual contributors (and/or email addicts) and stuff in between.

If email isn't a first-class collaboration tool for the project, these features tend to be missing, or only available to core developers, or the email content isn't sufficient to keep up to date (i.e. it's just noise, or an advisory trigger for polling).

> By default and with absolutely zero effort, every code review tool in the universe...

The effort is far from zero: one has to do a dance with the project's account creation system, diagnose why it can't send a working email address verification link, maybe wait a couple of hours (or days!) before the account becomes active with posting privileges. Even the list of barriers that have to be cleared isn't standard.

This is OK for the handful of sites I have previously volunteered (or am paid) to use, but these days if I can't find an email address to send a patch to, and I have to sign up to one more github wannabe site whose only salable feature is that it's not github, I just close the browser window and fork the project instead. Even a "post as guest" feature would be an improvement.

> ...automatically notifies casual contributors of: 1. everything happening to their drive-by contribution. 2. nothing else.

That's not how drive-by patches work. Either the project accepts the patch, or converts the patch into a bug report and fixes it some other way, or I fork the project. It's not like I'm going to remove a bugfix patch from my copy of the code because the maintainer has doubled down on unusual whitespace preferences or grandiose conflicting plans I don't care about. The transaction requires no second message.

> Are you commenting without having ever used a code review tool?

Ironically, code review tools are a huge portion of my notification workload. Most of them can't do things like flag reviews for notification because they add or remove strings, or touch parts of a source tree I'm interested in, so I have to suck all the reviews in, filter, and generate my own self-notification when something interesting pops up. This is *much* more code and work than any content-based email filter.

Tools like patchwork are much better as I can just consume their input stream directly with fairly ordinary mail filters.

> Understanding the universal move to "database first, email second" and learning from it requires temporarily setting aside any disgust for web interfaces and look *beyond* that.

Moving to a "database first, email second" model necessarily makes disgusting interfaces (web or otherwise) the contributor's first problem to solve, at least until the database schema reaches a critical level of maturity so that multiple interface tools can share a database.

Don't get me wrong--email is awful, and we do need something better. The problem is that nobody seems to have produced anything better yet, and until someone does, email remains the tool of choice for developers contributing across multiple projects. To reuse the CVS-vs-tarballs analogy, people keep proposing ClearCase and SVN when we need something equivalent to bitkeeper or git.

A farewell to email

zblaxell — Fri, 26 Oct 2018 17:42:06 +0000

> Why I care is *control*. Whereas open-source is all about end users being in control, email is the exact opposite.

This difference in perspective is interesting.

Of all the communications platforms I use, email is the only one I would say I, as an end user, fully control. Even then, my control is limited because I can't override someone else's decision to _not_ send me stuff when I want them to.

> most receivers are helpless...Can't suppress images of a crowd of preschoolers raising their hands and screaming "me! me!".

...aaand here we are back at the "enforcement as a feature" idea I mentioned earlier.

A farewell to email

marcH — Fri, 26 Oct 2018 17:39:49 +0000

> The scripts tend to be trivial to write,

Yet people are not interested. Something must have gone terribly wrong :-)

> Even a tiny amount of additional effort above "send an email to list@example.org to create a new topic" or "click this button to send me a copy of all project activity by email so my mail robots can inject it into the correct places in my personal news feed" can be a permanent barrier to casual technical contribution-

Casual / drive-by contribution is all about NOT being copied to the entire project activity, that's the whole point. How many people still read lkml?

By default and with absolutely zero effort, every code review tool in the universe automatically notifies casual contributors of: 1. everything happening to their drive-by contribution. 2. nothing else. Are you commenting without having ever used a code review tool?

Most projects also offer "whole project" notifications for non-casual contributors (and/or email addicts) and stuff in between. Extreme example with several emails per minute: https://groups.google.com/a/chromium.org/forum/#!forum/ch...

> Web pages [...] web forums [...] crazy developer's bizarre UX choices [...] web forum

Understanding the universal move to "database first, email second" and learning from it requires temporarily setting aside any disgust for web interfaces and look *beyond* that.

> At that point, any project that isn't providing me with a stream of informative, actionable, filterable emails never hears from me again.

As in the title: farewell. Learning is hard; un-learning is harder.

> but at that point, you're just running a mailing list with a fancy interactive archive.

No, not a mailing-list: a database with control over personal email notifications.

A farewell to email

zblaxell — Fri, 26 Oct 2018 17:34:22 +0000

> *database first, email second"

Ideally, database first, email for replication (i.e. you'd have a multipart message with text, html, and/or "blob of semi-readable bytes that the application can import to replicate the change in state of the master database").

We're running out of platforms where email MUAs can automatically feed data to an application, and maybe we never had a widely deployed, working, and secure transport for that data. On the other hand, polling works almost as well, so maybe we won't miss that feature when it's completely gone.

Pulling the data into a local git instance solves many of the problems, but only if the database schema never changes; otherwise, you have half your project's history in one replicated silo and the other half in an incompatible replicated silo that eventually only runs inside a VM running an OS nobody supports any more.

For things like code review records, it's important to capture the presentation of the data at the time the data was created, because it's a big deal if a later version of the database has a bug interpreting or converting old data (e.g. it attributes review comments to the wrong developer). This kind of thing is important in environments where a saved copy of a patch review email can change the outcome of a lawsuit.

The ossification of email standards has ensured that's not a problem for mailing lists (though a really deep archive search has to understand things like uuencoding).

A farewell to email

zblaxell — Fri, 26 Oct 2018 17:01:37 +0000

> Email MUST be processed with optimized setups and scripts; otherwise email = JUMBLE.

Email CAN be processed with optimized setups and scripts (or even clunky and awkward ones--modern hardware has billions of cycles to spend on each mail). The scripts tend to be trivial to write, and nearly identical from one sender (or receiver!) context to the next. Web pages (excluding a few RSS feeds, thank you LWN) are not so easy to filter, and many site owners even actively try to fight such automation.

I find that tracking projects through web forums only scales up to about 70 or 80 sites at any time (and let's be honest, anything after the top 15 or 20 is not getting much attention). At that point, any project that isn't providing me with a stream of informative, actionable, filterable emails never hears from me again. For most projects it's easier to just fork the project than deal with some crazy developer's bizarre UX choices.

Even a tiny amount of additional effort above "send an email to list@example.org to create a new topic" or "click this button to send me a copy of all project activity by email so my mail robots can inject it into the correct places in my personal news feed" can be a permanent barrier to casual technical contribution--especially the kind where a passing developer sends in a drive-by bug fix before moving on to the next project they have to integrate that day.

If you're going to run a web forum/bug tracker/code review site with a transparent bidirectional email gateway and superset database schema (with a working In-Reply-To field) then that's fine--but at that point, you're just running a mailing list with a fancy interactive archive.

A farewell to email

debacle — Fri, 26 Oct 2018 07:58:23 +0000

Signal sets a far too high bar for me:

it requires from me to buy a mobile phone (specifically one with Android or iOS) and make a contract with a mobile phone provider, I cannot easily use it on my Linux distribution
it requires, that I give my phone number to all communication peers, and to the service provider
it requires, that I use a specific service in a specific country on servers of a specific company, which I find too limiting to be useful

Maybe it's just me, but I'm not into mobile phones.

A farewell to email

nix — Thu, 25 Oct 2018 22:11:55 +0000

*Especially* those living in big cities like London, full of youngsters who were weaned on the Internet and more or less have it wired into their brains, loads of aging physical infrastructure that is really hard to upgrade (dig a new tunnel in London and expect to take years at it and probably uncover a plague pit or two) and lots of tall buildings to fubar mobile reception and make any attempts at municipal wifi slow at best.

The middle of nowhere is also difficult: I'm writing this from an isolated forested valley covered by a 20CN exchange (one of a few dozen left in the country) which is full, so no ADSL for me, only satellite internet. But hey we don't have municipal sewage or gas either and even the POTS phone line tends to go down surprisingly often. I guess we're lucky to have electricity :)

Medium-sized UK towns seem to be better off.

A farewell to email

Wol — Thu, 25 Oct 2018 15:02:57 +0000

> And some of us old fogeys do disconnect sometimes still while working.

And some of us - with what many would consider a GOOD internet connection (I have a 17Mb ADSL-2+ connection) - regularly get disconnected at peak time because our local uplink (the nearby British Telecom exchange) seems to get overloaded.

A decent, working, always-on, internet connection is somewhat of an unattainable luxury for many of us, even those living in big cities (London, hey, don-cha-know).

Cheers,
Wol

A farewell to email

Cyberax — Tue, 23 Oct 2018 23:32:36 +0000

The subscriber devices will have a small phased-array antenna and active tracking. The complexity of these devices is going to be stunning, but it appears to be doable.

I can’t wait to be able to work from a mountaintop in South America.

A farewell to email

mattdm — Tue, 23 Oct 2018 22:50:02 +0000

My experience with grey-listing was that yes, it reduced incoming spam, but it didn't have any effect at all on the amount of spam getting through my later spamassassin and baysian filters. So, reduced CPU load, but not actually reduced annoyance. For my small mail server, that wasn't worth the downsides.

A farewell to email

dbnichol — Tue, 23 Oct 2018 12:34:59 +0000

Interesting, I hadn't heard of that. I worked for the company that made both the other satellites that are referred to in that article, ViaSat and HughesNet. They have very reasonable bandwidth, but indeed there's not a lot you can do to get over the fact that physical link length is really long to a geostationary orbit.

That said, I don't know how you'd do high bandwidth communications on a non-stationary orbit. So much of the link quality is dependent on the alignment of all the antennas in play to get the best possible gain out of them. The worst case link (which is what you have to design to) at the edge of that coverage must be much worse than at the peak. I guess it's just another degradation parameter. People have been doing LEO communications forever.

A farewell to email

neilbrown — Mon, 22 Oct 2018 20:54:53 +0000

> Most people on the IMs do expect more immediate response,

It is not your duty to fulfill other peoples expectation. It is your duty to set them, by behaving consistently.
I like to wait a day before replying to anything non-trivial (Admittedly, most of IM is trivial.....as is this comment)
Being in a different timezone to EU and US makes this easier.

A farewell to email

medicalwei — Mon, 22 Oct 2018 15:34:43 +0000

Most people on the IMs do expect more immediate response, Especially with the convenience of always-on internet devices. Emails users are less likely so as far as I know.

Though technically you can treat IM like email and vice versa, the mindset people using them are different.

A farewell to email

pj — Mon, 22 Oct 2018 13:18:02 +0000

Please explain the difference between email and an IM service with a notification rate-limiter such that it only raises notifications at a prescribed 'polling interval'.

Don't confuse the surface with the substance.

A farewell to email

Frogging101 — Sun, 21 Oct 2018 19:31:03 +0000

I just want to say that I find Discourse absolutely awful to use. It's Javascript-heavy and uses infinite scrolling, which makes it impossible to archive. It's annoying to search and has too much whitespace. I really wish people would stop using it.

A farewell to email

nix — Sat, 20 Oct 2018 23:07:41 +0000

You don't need to suspect it: larsi (who is one person) said as much in the blog post when he announced it was shutting down.

A farewell to email

creichert — Sat, 20 Oct 2018 20:51:20 +0000

> there are various email notification mechanisms for new topics and such, and users by default get handy notifications every time somebody "likes" one of their posts.

I'm not sure if the author is making an explicit point with this line, but I've built a personal habit of aggressively trimming notifications and completely disabling all "like", "share", and alerts that I can't or won't act on.

I'm not saying it's pragmatic to recommend this for new users, but it's a
an effective system that allows me to maintain my focus, reduce overall noise in my inboxes (mail or otherwise), and handle higher volumes communication.

To the point, I appreciate services that allow me the option of using Email *or* their web interface seamlessly so I can reduce context switching as much as possible.

Take communication over GitHub for example:

When I'm in my mail client and come across a pull-request, issue, or discussion, I can choose to reply from the email or browse the URL and continue a discussion from the web client. Thus, I can reduce context switching and fragmenting my attention.

> As others have often said, what we need is a modern replacement for email — some sort of decentralized solution that preserves the advantages of email while being suitable to the 2018 Internet

I'm certainly not opposed to this argument, but it seems that the alternative system vaguely proposed is just like email, with a web interface, and less SPAM.

A farewell to email

marcH — Sat, 20 Oct 2018 14:56:09 +0000

Code review is where the worst filtering problem is but you can apply the same and widespread "[distributed] discussion database first, optional email second" fix to any mailing list problem. You can also leave the moderated, low-traffic and "gentlemen's club" lists as they are cause they're not where the problem shows.

NNTP would be a good (re)starting point. groups.google.com has one cool feature: per-thread fine-grained email notification.

A farewell to email

jani — Sat, 20 Oct 2018 08:16:12 +0000

I wasn't talking about software development or code review, I was talking about communication in general...

A farewell to email

marcH — Sat, 20 Oct 2018 06:20:03 +0000

http://www.catb.org/esr/writings/taoup/html/ch01s06.html#...

Rule of Representation: Fold [code review!] knowledge into data, so program logic can be stupid and robust.

A farewell to email

marcH — Sat, 20 Oct 2018 06:02:41 +0000

Please everyone put web services and user experiences aside for a moment, that's really not the main point. The core of any gerrit/gitlab/patchwork/etc. instance is basically a git repo with a _database_ of code reviews on top and databases have always spoilt their users with a huge variety of interfaces.

Most communities use a single database instance per git project for convenience/laziness but if you're paranoid about centralization then you can have multiple decentralized instances, either mirroring each other or with pull requests between them - just like plain git. All database instances send email to a single mailing-list for backward-compatibility with old maintainers. Other users can choose to receive all those emails, none or anything in between and that is how they're back in control of their inbox. Drive-by submissions become easy.

While most of the above is real today, I understand today's tools like gerrit or gitlab are far from perfect and not checking the boxes of the demanding and sometimes peculiar Linux kernel community. However long before bikeshedding how bad are gerrit's command line interface, emails or other fixable implementation detail, the very first, baby step would be to consider that the *database first, email second" design choice followed by most of the software world is maybe not totally stupid. I bet many patchwork users already agree.

This is like the attitude difference between:
A. CVS sucks, tarballs forever! versus:
B. CVS sucks, tarballs until we find something that doesn't suck.

A farewell to email

ThinkRob — Sat, 20 Oct 2018 04:56:50 +0000

Fair point. But (donning my optimist hat): that's only on the relay side of the equation, not the client side.

Even if you do use one of the "big players" in the e-mail space -- and there are a lot of commercial e-mail providers out there, evil and otherwise -- it's still totally open on the consumption side. Until SMTP, POP, and IMAP are purged from the face of the earth, my provider can't reasonably prevent me from using whatever interface I'd like to access my mail[1]. And (thankfully) the stalemate between the various providers means that nobody's going to do that in the foreseeable future.

That's a vanishingly rare property for a hosted service nowadays, and it makes me quite reluctant to declare e-mail "dead"!

[1] Although IMAP is such a wacky standard that it may as well be obfuscated!

A farewell to email

jani — Fri, 19 Oct 2018 20:24:06 +0000

Interesting. Why I care is control too, but it's the end user control of the user experience I care about. I am not sure how giving up control of the user interface helps the receiver regain control. In centralized web based services, the receiver gets just as much control as the service provider has deemed appropriate, using an interface the service provider has deemed appropriate.

Surely an alternative to email that would address your problems as well as mine could be developed, but it's not here. It seems to me all of the popular alternatives are centralized with a control point.

A farewell to email

zoobab — Fri, 19 Oct 2018 14:44:05 +0000

Same here, I really miss Gmane. They probably got harrassed by people who wanted to get their names removed from the archive, GDPR and all that, I suspect that was the main reason why they stopped.

We need the archive back online.

A farewell to email

mstone_ — Fri, 19 Oct 2018 12:52:32 +0000

Plus, the big email providers just don't want to deal with independent mail servers. I'm currently getting rejected by yahoo, no idea why, no way to get it resolved.

A farewell to email

marcH — Fri, 19 Oct 2018 04:18:05 +0000

> Having a system to organize your e-mail is no different than having a system to store files (e.g. a file tree).

There are huge differences: - no one wakes up every morning finding a bunch of new local files; - a child can move files across folder and it's a manual, once-off operation whereas configuring email filters is automation = some form of programming; - everyone is free to organize (or not) local files without anyone else having any idea of how he or she does it whereas email is a communication channel.

> Would you say that local storage is a dead-end because files can be so numerous...

Local files are numerous only if you inflict that to yourself, you're in control. When you download or copy files you've just put yourself in the best context to organize them, it's not a stream of unpredictable interruptions like email.

> Would you argue that we should *instead* get rid of files and move to a world where all content is stored and presented remotely by whatever web service generated it;

I'm not arguing any of that and I doubt it will ever happen (beyond DRM'ed music and video streaming)

I observe that not all but many files have indeed been replaced by something like this. Will all local files eventually be replaced like this? Probably not. I'm personally (and foolishly?) happy to have fewer local files and I don't think we should care what others do as long as we still have some latitude.

> That's an even worse jumble,

I think I get why you use the word "jumble" here and I'm pretty sure I used it to refer to something much narrower and specific. So neither better or "worse"; just unrelated.

> It's impossible for e-mail to die anytime soon;

Agreed, it's basically mailing-lists that need to die (and are dying).

> the withering promise of the Internet--that we could disintermediate consumers and producers of content through a technologically egalitarian system.

The People have voted with their feet and the winner is fake book. Or the next one.

The Internet: yet another technological miracle which was supposed to make humankind fundamentally better in less than one generation. Guess what happened.

A farewell to email

marcH — Fri, 19 Oct 2018 03:14:53 +0000

You're simply confusing private and secure (or pretending to be for some unclear reason)

A farewell to email

da4089 — Thu, 18 Oct 2018 23:32:26 +0000

I would happily pay an additional subscription fee for an NNTP feed of LWN.

A farewell to email

pizza — Thu, 18 Oct 2018 20:11:39 +0000

Let's not forget that the average person is incapable of distinguishing the "app" from the service needed to make it useful.

XMPP is a protocol. There are a ton of clients for every OS out there. But those clients are useless without a service to communicate with. Most folks are not capable of running their own service, but fortunately there are still many organizations providing XMPP services to the general public.

A farewell to email

spaetz — Thu, 18 Oct 2018 19:45:01 +0000

That would be jabber/XMPP with OMEMO available on Android, IPhone, Linux, MacOSX, and apparently evenWindows?!.

A farewell to email

flussence — Thu, 18 Oct 2018 18:17:49 +0000

I honestly can't say I'd miss it if it went away — my distro runs its forums on phpBB, which is *fully* usable in every browser. I can fire up /usr/bin/links from a CD and look up documentation, or ask for help with hardware troubleshooting. By comparison I don't know any distro that puts a working mail client on its install media, and on top of that it needs a pre-existing account. If you're using a silo like GMail, it's becoming increasingly impossible to even authenticate using a standard mail application.

That's not to say mail infrastructure doesn't have any use, but it only seems useful for people already heavily invested in long-term participation and willing to deal with the spam problem. Some projects don't have enough of that demographic left to justify the upkeep costs.

A farewell to email

marcH — Thu, 18 Oct 2018 17:46:55 +0000

I've been wondering why I care about email to the point I sometimes answer myself which I'm afraid is one definition of ranting. Now of course I'm not ranting over email, so you can just stop unsubscribe from this discussion in a few clicks :-)

Why I care is *control*. Whereas open-source is all about end users being in control, email is the exact opposite. Whether it's spam or lkml, most receivers are helpless and senders are in control. While there are of course massively more powerful mind-control tools than email like for instance fake book, every email is a tiny, disorganized attempt at controlling what's on the receiver's mind. Can't suppress images of a crowd of preschoolers raising their hands and screaming "me! me!". Email was great in the gentlemen's clubs where it and the Internet were invented and I heard that a few gentlemen's clubs are still holding on to it, however it never really scaled beyond those.

Thank you email, you had a good ride with spam and mailing-lists but sorry, we have to demote you to private conversations and optional notifications cause bigger things went out of control and you couldn't scale. We gave your old job to this new database guy instead.

A farewell to email

marcH — Thu, 18 Oct 2018 16:38:51 +0000

Speaking of databases, unsurprisingly: http://damien.lespiau.name/2016/02/augmenting-mailing-lis...

Now instead of sending copies of patches and review comments by email as an *optional* feature, the SQL+git patchwork database is fed by... parsing emails. This inversion and resistance to acknowledge the change already happening is a bit ridiculous.

If the centralization aspect scares (some of) you then just replicate the database, on your laptop even. I don't think database replication is rocket science anymore, I bet easier than configuring procmail or mirroring mailman.

(again this has nothing to do with web interfaces)

A farewell to email

marcH — Thu, 18 Oct 2018 16:21:25 +0000

> I'm using kmail with "Current Activity/Threaded" view and one archive folder. No filters, no scripts and I'm quite happy.

This means you can't for instance prioritize work (code reviews, bugs,...) received weeks ago against what you received more recently. That's OK if what you received weeks ago were actually just notifications from another system than just email, likely some actual database[*]. This means email is not the primary reference of information anymore: it's become just a *secondary, optional notification channel* / "newsfeed" that workers are free to subscribe to, or not at all, or anything in between. Looks Good To Me.

[*] whether that database has a good or bad web interface or no web interface at all is IMHO far from the main, "design" questions.