Email is just about as old as networked computing itself. But 40 years later, the same basic technology still very much a part of our online lives—and for good reason: It's pretty darn useful. But email is also one of the most infuriating technologies we have, and one of these days, we're going to finally produce something that can make it obsolete.

Some of tech's best minds are hard at work on doing just that. But in the meantime, we need more tools that can at least make email work a bit better—email apps like Acompli and Dropbox's Mailbox, or email analysis tools like Mailstrom and Sanebox that seek to better organize your messaging life.

The problem is that building these kinds of applications is much harder than it should be. Our email technologies are just too old and too limited. "A lot of that is because the underlying technology hasn't kept pace," says ex-Dropbox engineer Michael Grinich. "Working with email is super confusing and complicated for most developers."

Christine Spang and Michael Grinich. Kavya Joshi

That's why Grinich and fellow MIT alum Christine Spang built Inbox, a software creation designed to make it much easier for developers to build email-centric applications, whether they be new email clients or something else entirely. This might include, say, an application that spots an airline reservation in your messages and automatically adds it to your online calendar. But the possibilities are limitless. By making it easier to actually work with existing email technologies, they aim to start an enormous new wave of applications, hoping that one of them could someday solve the email problem once and for all.

>By making it easier to actually work with existing email technologies, they aim to start an enormous new wave of applications, hoping that one of them could someday solve the email problem once and for all.

One of the big reasons that email is so hard to work with is that one of the most important protocols—IMAP, short for Internet Message Access Protocol—can be implemented in many different ways. This means that if you're a developer trying to build a client that works with two different email services, those services might be radically different from each other, even if both ostensibly use the same standard. If you want to build an email client, or any other application that directly interfaces with an email server, you've got to be ready to support every single different variation. To make matters worse, there are multiple different ways to format emails and encode text. That means developers who want to build email applications end up spending much of their time building the most basic underlying code, and much less time actually building the new features they want to enable.

Yes, we could fix the problem by creating a new standard for email. But actually getting the world to adopt yet another new standard is always a difficult task. "What developers need today isn't a new committee or a standards body," Grinich says. "Developers need code. And that's what Inbox provides." Inbox is a kind of like a universal translator for email protocols and formats. It sits between your app and an email server—or group of email servers—and translates the commands that pass between them. At least that's the plan. So far, the open source version only works with Gmail and Yahoo Mail, but the team will eventually handle other providers as well.

To make money, the company will offer an online version of its tool—now available as a developer preview—that can plug into Microsoft's Exchange email server. But since the service's underlying code is open source and available on GitHub, developers can also choose to host their own version of the Inbox on their own computer servers. That also provides a nice hedge, in case Inbox is ever acquired or shut down, though Grinich insists that won't happen any time soon. It also means that—unlike something like Google's new Gmail API, another tool that seeks to extend the scope of email—any developer can contribute new code to Inbox, and extend its capabilities even further.