Aside: In all, I’d much rather elaborate on wheres, joins, and orders by, but I have a few unfinished pieces. So on with it.

Laying here as I fade in and out of scope over the waves of recovery from back surgery, and in the quiet of these moments, I can enjoy the blissful roar of silence as it screams past my bedroom windows: the silence only an empty inbox can deliver. I started contemplating an email-abandon-ship (Part 1) a little short of a year ago. I let it simmer, and shortly after last September, I pulled the plug completely (Part 2).

Ultimately, I think I’ve proved my hypothesis: as a medium of communication, email is exactly as useful as flinging a fortune cookie into the ocean and hoping for a response. Email guarantees only two things: your fortune will go somewhere; and wherever it does go, it will probably arrive soggy.

With your head tilted at just the right angle, it’s an interesting phenomenon. From an implementation perspective, it’s very nearly like Microsoft’s decision to reverse engineer JavaScript into JScript for Internet Explorer while faithfully and painfully preserving all of its bugs (I believe +Douglas Crockford’s actual quote is in episode 2). It’s as if the e-postal express pioneers in the early email client space deliberately preserved all of the faults of asynchronous analog communication for the digital revolution. Not satisfied with that, they added spam.

The web blossomed (eventually) atop the HTTP and peer protocols by standardizing the rules for client interfaces, by imposing constraints, by limiting behavior, and by frequently just refusing to do much of anything at all. The HTML spec is a wretched mess not worthy to spread across a puddle for the crossing of a peasant farmer, but it has not yet proved a total failure. Certainly, it’s far from heaven for developers; but it has an API that is sometimes/sort of/maybe consistent across clients. An API just good enough to make beautiful things. Yet most end users are only ever vaguely aware of the browsers or the APIs or the compatibility matrices that stand as a middleman to the Internet–many don’t know which browser they use or how or why in gods’s names would you want to switch?

Compare that to email. Developers don’t care: there is no standard, no API, nothing to build upon. Client “plugins” are mere novelty items. Developers are either wasting away, throwing great creativity after mediocre, building their own new email client which will solve the problems of the world; or developers are doing something useful with their skills (if only!). Users, on the other hand, can immediately tell you which of the thousand available email clients they have used, hated, and finally endured.

And that fundamental difference speaks to the abyss between email and productivity. No one asks, “How do I use the web?” Billions continue to ask, “How do I setup email?”

We need something better, and I don’t think we can monkey patch it onto the bubonic plague infected collection of mail clients propagating throughout the world today.

If you peruse +Kwindla Kramer’s post The Cloud I’d Like to See, I think his arguments for the future of distributed file systems paint a nice parallel to the problem of email. In fact, if we think of emails as just files in folders which are distributed, shared, portable, synchronized, secured, encrypted, searchable, editable, deletable, revocable, streamable, revisionable and tightly managed in the same way we already manage file systems (as well as including some of Mr. Kramer’s insights), the solution seems a bit cleaner.

Of course, there are many more dimensions to communication beyond asynchronous, unidirectional transmission of content–our communication threads start from notes on napkins at the local cafe, transmogrify into mobile calls, mutate into group emails, condense over the course of physical meetings until something resembling a decent cup of tea pops out the end. To this end, its worth remembering that the web itself is a communication platform, not a content delivery platform; and maybe the evolution in multithreaded, asynchronous, highly concurrent, multi-directional, peer-to-peer communication will simply emerge as a natural extension of the web platform itself.

Regardless, I don’t know what the solutions will be, but I can say this:

If the urge strikes you to start a message in a bottle, instead consider talking sternly at the nearest wall. It’s guaranteed to be more productive.

As always, everything I write belongs to the Public Domain. Please take generously.