The reason that "email" will never die is that the limitations of the human mind compel user interface designers to employ the principle of least surprise and to extend existing metaphors slowly. In practice, many people are using "email" which runs on internal Exchange systems and is accessed using Outlook or web applications. When I send an email via Gmail on my "phone" (Which is as much a camera that can make calls as it is a telephone that can take pictures - the only reason we use one metaphor and not the other is path dependence) to someone else using Gmail, I am "sending them an email" without using the protocols that the original implementers of email had in mind.
It's the same reason that we can call a web site a "page" or a "document" despite the fact that a modern web site is actually several programs running insider your browser (flash, custom JS, HTML rendering) working together with programs running on a number of different servers. That's nothing like a paper document, but we use the metaphor because it's been extended a little bit at a time.
Email can only be replaced by another system which does not require you to be on any particular network (decentralized).
Email doesn't die because gmail can send to hotmail and to every other domain.
The entrepreneurs trying to replace it will focus their effort on one exclusive platform which they know they could monetize if they hit a tipping point. Unfortunately, the very motivation to profit is what creates the biggest problem.
The only true solution to email is a decentralized system, that many other companies could utilize. Unfortunately, once you have a system which is easy to create competitors you get instant commoditization. Once you have that, the economics of the idea suck which means that VC, and other investment money will never chase that system. In other words, a decentralized system is worthless from the idea stage due to the expectation of commoditization.
That sounds nice and I hope you are right. But I can certainly see a scenario where one of these walled-gardens gets big enough to where most people communicate using this platform and email ends up being like usenet or irc. Email can never be disabled (right?) so we'll still be able to use it technically, but it could cease to be practical for everyday business and personal correspondence.
I've been saying for a while that the only problem with email is one of management. As the volume of incoming emails increases we need better tools to avoid a similar increase in the amount of time we spend checking it.
To that end (shameless plug) some friends and I have been building Lightermail to solve this problem for us. We're getting close to opening the service up to a wider pool of private beta users and would love to have some HN users and their feedback in the mix. If interested head over to https://lightermail.com and we'll be sure to get back to you in the next couple weeks with an invite code.
I'm not sure if you're trying to be ironic or you really don't know that Exchange is just a (mostly) RFC compliant SMTP server and a (mostly) RFC compliant IMAP server rolled into one.
My point was that Exchange is not compliant enough to be usable from a non-Outlook email client. At my current job I run a windows VM just to run Outlook in it; at my previous^2 job I had a second physical machine for the same thing (though I eventually put mysql on it).
> My point was that Exchange is not compliant enough to be usable from a non-Outlook email client.
Well, you kind of have a point there. I use Apple mail and iCal against our corporate Exchange, but when I have to schedule a meeting, I either have to log into the Windows terminal server or use the outlook web interface to do it reliably.
It would be nice if there were an RFC for calendaring protocols, even if that RFC was just codifying Exchange.
That is only a mechanism for encapsulating an event and giving it to someone else: it doesn't really help any of the actual use cases people have for the kinds of group calendar management that everyone is used to having from Exchange.
The more related standard that could have done this is ICAP, but that spec never happened and died as a draft back in 1998, long enough ago that the acronym got reused in 2003 by RFC 3507 for something unrelated to calendar access.
Right now, it seems like all of the effort is behind CalDAV (which is based on WebDAV), which actually has some published RFCs behind it (dating back through 2007) and multiple clients (including Apple's iCal and Google Calendar).
Right, but CalDAV doesn't seem to support everything. Or to put it another way, using a CalDAV client and using actual Exchange don't get the same results.
My employer uses exchange, and I use Apple Mail and iCal to connect. It works perfectly. (Exchange provides an proprietary connection between the server and the client. It also supports IMAP, but many admins don't enable that. It's server to server connections are fully interoperable.)
You could have said the same thing about Lotus Notes 15 years ago.
The email works fine, apart from the annoying thing where sometimes outlook doesn't include all the recipients properly as they're internal exchange users.
How long did it take for the traditional post office to die? It didn't die even after the arrival of FedEx or DHLs.
Email is a basic and all inclusive communication method. People later on have added and tagged along their businesses to ride on the same method. Those who are facebooking, tweetering, chatting, texting, etc, are still communicating on the same basic principle which binds the email.
However, headlines like "email will never die" or "email is dead" are as stupid as they can be.
Reading that, it seems like there is no one inventor of email, but a bunch of different solutions, perhaps leading to the 1981 RFC for SMTP by Jonathan B. Postel, which I would guess is the beginning of the actual current email implementation:
It's the same reason that we can call a web site a "page" or a "document" despite the fact that a modern web site is actually several programs running insider your browser (flash, custom JS, HTML rendering) working together with programs running on a number of different servers. That's nothing like a paper document, but we use the metaphor because it's been extended a little bit at a time.