We need to talk about email clients. | Hacker News Reader

We need to talk about email clients.

inessential.com

18 pointsbensummers44 comments

this is a perfect example of a project that will go nowhere.

The app would need not just coders but testers, designers, documentation writers, bloggers, at least one project manager, and so on. It would need a bug tracker. Repository. Wiki. Website. It will need a name. (I started a Twitter account, which I’ll turn over to whoever leads this once we know who that person is.)

oh my. surely a twitter account is needed for a successful open source project, right?

no, it needs none of those. write some code, put it up on github, let people hack on it, /then/ setup that stuff if you still need it.

trying to create a new piece of software (especially something as large as an e-mail client) by committee is a terrible idea. everyone will have opinions, they'll throw them into the hat, nobody will agree on anything, nobody will write any code, and the project will go nowhere. but hey it has a logo and a wiki and a "project manager" so that's useful, right?

a better idea would be to take an existing client like thunderbird, mutt, etc. and figure out what you don't like about it. i'd wager anything you don't like can be easily changed in the source code or even coded up as an add-on for thunderbird. i have a hard time believing the entire thing has to be redone from scratch.

The biggest problem, I think, is that there's no vision. He says we need a better email client, but we don't know what he thinks better means.

We don't even know what he doesn't like about existing clients.

Even if this project does manage get started, it will almost certainly turn out to be something completely different than what he's imagining.

The biggest problem, I think, is that there's no vision.

from experience, open source developers don't like writing code to someone else's vision; it feels like work. they write code to solve their own problems, according to their own vision. if their vision correlates with an existing project's, then all the better, and they can just work on that project. if not, they start their own. nobody's going to sign up for a mailing list and crank out code just because someone else is asking for it.

Uh... Did I miss the part where he explained what was wrong with existing clients? Without a clear, specific problem to solve, this is going to be an exercise in wasted time.

I was looking over the mailing list and just about everything I see mentioned can be done with Mutt (or Sup). Personally, I use gnus on emacs. Add in some org-mode magic and you have just about everything anyone could ask for (well, search is not as nice as I'd like it).

sup++

I just wish it was faster (on large mailboxes) and more stable. I'm stuck on gmail for now.

http://sup.rubyforge.org/

I'd love to try sup, but the incompatibility with other email clients makes it a non-starter for me. At minimum I need to use my phone's mail client without sup having to rebuild its index every time.

I love "everything is just fine, all you have to use is (20 year old|text based software)" comments, especially when the suggested software has an FAQ with this entry:

+ I'm an average user. Why should I switch to Mutt? The top two reasons to switch are color support and threading.

To be fair, threading is a very important feature in a mail client, and by no means all mail clients have it. Yes, there's a lot of very crappy webmail around.

Gmail has everything I want from email. I consider email to be a solved problem.

I almost agree. Gmail has everything I want in email, but it's tied to Google. You can (and I do) use your own domains with Google, but you still have to go through them.

Is that a problem for me right now? No, not really. Might it become a problem in the future? Maybe, although probably not for a while. Is it a problem for some people? Yes.

What we do need is an open-source webmail implementation like GMail. SquirrelMail just doesn't cut it anymore.

Roundcube is slightly better.

Zimbra is definitely better if you're willing to put up with it's overhead.

But really, email is one of those things, where your preferences are unlikely to be the same as those of others.

Exactly. I am glad the trend is turning back from desktop clients to web ones. Before, the common statement from web mail hosts was that the web client was for minimal use, and a desktop client was the preferred way to go.

As an example, I think rackspace thought this up until a few months ago. They weren't improving their web client and just recommended you use a desktop client. Just these past few months they have added a lot of new features. I think they see the light now.

I still prefer a desktop client (well emacs gnus). I like access to my email when I'm offline and traveling, which is often. I prefer the speed of processing email locally and the integration I can have with other local tools and scripts.

All that said, I still use GMail as a sort of online archive and client when I'm away from my laptop.

Email is not a solved problem when you get to ~50-100 messages per day.

For email powerusers -- I've spent a lot of time setting up gnus (others use mutt) for really rapid email editing. Hurts to be super efficient with keybindings for other tasks but back to click/click/click for email.

Agreed. I've been a longtime user of Thunderbird, and only a casual user of mutt when I've needed to do some quick processing of email on a server or over a slow connection. But my latest upgrade to Thunderbird 3 has been very disappointing, with continual freeze ups, extensions not loading, and too many restarts required each day where previously I'd let it run for weeks at a time. So I tricked out mutt with complete configs for my IMAP accounts and RTFM. I must say, I'm impressed and feel like I made a huge leap forward. I now have an email processor, not just a point-and-click dartboard. Still, it's not perfect, and I don't think any email client can be.

Color me naive, but doesn't an open source email client already exist, i'm pretty sure its called Thunderbird ... http://www.mozillamessaging.com/en-US/thunderbird/

Am i missing the point of the post?

Yes, you are. Thunderbird is a e-mail client that attempts to please the "masses". You may have noticed but the "masses" aren't developers, they aren't coders, they aren't testers, or designers.

They send e-mails to mother's web-tv, tell their boss they're sick, and talk to Nigerian princes.

Honestly, I can't think of anything I need that Thunderbird doesn't do. IMAP support? Yup, and the offline support works great too. Search got awesome in the new version. Calendar is supported with Lightning, and works well with Google Calendar. Multiple languages and encodings? Also just works.

So what if it can also be used by non-technical people? If you want something with more geek cred, set up emacs to do your email. Otherwise just write an extension to Thunderbird that implements whatever functionality it's currently missing. There is no need for more fragmentation.

It's not all that easy to write an extension. The threshold effort is enormous.

So for all practical intents and purposes, I can't define my own mail categories (tags, whatever), and I can't specify a simple script to run when something comes in, and I can't access my mail as a database for bulk processing.

I still use Thunderbird, of course, and have for years - but these are the things I periodically try to figure out in it, and I always end up entirely stymied. To the point where I've also seriously considered writing my own email client, if it just exposed its guts to Python or Perl or something.

I'd still say adding just one feature to an already working client is less work than writing one from the ground up. It's easy to think you can just grab a library to do IMAP. But what about attachments? Encodings? HTML mail? Storage? Search? Remember, all these will need a UI of some sort. And this is just the tip of the iceberg.

Thunderbird 3.0 has custom tags. OpenOffice eats Thunderbird address books and can do mail merge. The one thing that's left is running a script when a message is received. That is actually a good idea for an extension.

It's not about usability for non-technical people. It's about focus on developers. Can Thunderbird do syntax highlighting in email? Fuck no.

And suggesting that technical people should use emacs is dumb. Seriously dumb.

You're new around here. Please read this: http://ycombinator.com/newsguidelines.html

Yeah, I've read it. I've also realized most of it doesn't matter. What points I lose here can be made up x10 in one or two comments agreeing/pushing popular opinion.

You have mistaken the purpose of the karma system here. It's just a system to encourage civil discussion. Earning back points doesn't matter - points don't matter. Keep up what you're doing and there's a good chance you'll be banned. But you won't know it.

nonsense. a look at the available add-ons for thunderbird clearly shows that enough advanced users are using it, and tweaking it to their liking without having to reinvent the wheel.

i think you are confusing thunderbird with outlook express or hotmail. i've never seen anyone not tech-savvy use thunderbird.

"reinvent the wheel"

Fuck you. I hate that phrase. Fucking hate it.

(Yes, I know this will be downvoted, no I don't care)

what about "don't throw the baby out with the bath water" or "don't count your chickens before they're hatched", perhaps "i before e except after c", how do you feel about those phrases?

wait, what was this discussion about?

e is such a better programming language than c!

edit: Oh come on, it wasn't that bad a joke.

I'd guess that there are actually far more open source clients than closed-source. The author's asking in particular for a Cocoa email client, which Thunderbird is not, but I don't really see why that's an important factor.

Clever satire on open source projects that go nowhere.

(If its not a satire, sorry.)

It doesn't appear to be a satire.

Mailing list: http://lists.ranchero.com/pipermail/email-init-ranchero.com/

Twitter: http://twitter.com/emailinit

Every couple of months I probably leave a comment here something like this:

Where is the "tweetdeck of email"? Columns, filtered lists, simple, and cross OS compliant. Let me plug in my IMAP info, then start creating columns based upon filters, people,etc. Make writing a message more like writing a tweet, so that things are more orientated towards being short. Give me some social context about the person similar to Xobni.

What you're describing isn't really email any longer. It sounds more like Google Wave.

sure it is. it's just a semi different way of visualizing it. I'm not talking about real-time updating and all the crazy stuff google wave does. I think the columns concept of tweetdeck works well, and it might make sense for email.

We discussed Google Wave a few days back: http://news.ycombinator.com/item?id=1048227

It sounds to me like it solves your problems; it certainly helped the author of that post.

Don't reinvent the wheel! You might change my world view! No, no! Go away! Everything's fine! :(

(+1)

For anyone looking at this and wondering about the process of starting an open source project, I humbly recommend reading Karl Fogel's Producing Open Source Software.

It's CC-SA 3.0, and available at http://producingoss.com/

Can someone help me understand why the poster's first requirement is that this be a Cocoa app? Honest question; it's just tossed out there as though it were obvious and I have no idea why.

Brent Simmonds is a Mac developer and there's been a discussion about the Mac email client landscape brewing for a while. The Coccoa requirement is due to the unstated context that we're talking about an email client for Mac OS X.

By shipping Mail with every Mac, Apple basically makes it impossible for someone else to come along and compete with a commercial product. Thunderbird, while a fantastic piece of work, doesn't behave quite like a Mac-native application. By saying it's got to be Coccoa, Brent's saying it has to be through-and-though Mac-like.

I have to agree with many who've commented here. The author doesn't list a single problem with current email clients, except maybe that he hints at wanting one with keyboard accessibility rather than requiring a mouse. Either he has no idea what's available (in which case, he should search first), or he hasn't really thought about what he wants in an email client.

Regarding what he considers obvious: - Cocoa? I have no idea why Cocoa would be obvious. Surely an email client for developers would need to run on at least Windows, Linux and Mac OSX since there are enough developers that use each of these. - IMAP only? Good idea, but that's really the easiest part of the problem. I'd say defer this to fetchmail to start with and just read from a local directory. Add actual IMAP support once you've figured out the UI. That's the real hard part. - twitter account? yeah. 'nuff said.

The biggest problem with email today is not that a client doesn't exist to satisfy your needs. Every developer I've met does in fact have at least one email client that satisfies all their requirements. For some it's thunderbird, for others it's gnus or mutt or pine, others like gmail, still others like Mail.app, and believe it or not, there are actually developers who like MS Outlook or Entourage. No, the biggest problem with email is that trust isn't yet built into it. PGP/GPG/DKIM/Authenticated SMTP, and others exist, but the majority of email users have no idea what these are or how to use them, and unless every email user in the world switches to using some kind of trusted authentication system, email will stay the way it is today.

See also discussion thread on the new mailing list.

http://lists.ranchero.com/pipermail/email-init-ranchero.com/...

I agree with the post that there needs to be a developer specific e-mail client, open source and designed from the ground up.

I disagree on: * Cocoa specific design * IMAP based specs * The community tools he's using. This is a perfect project for librelist.

Would you like champagne with your happy meal, too?

Reply on news.ycombinator.com