The Future of Messaging

The web has incredible potential to improve our lives even more than it already has.  I believe that nowhere else is this more true than in the space of personal communications.

Mitchell Baker, Chair of the Mozilla Foundation, today announced that Mozilla will be increasing our focus on messaging and communications on the web.  As part of this, here are some of the steps that we are taking.

We’re going to be consolidating the teams working on messaging on the Web and related topics like identity and contacts, by integrating the Mozilla Messaging team with Mozilla Labs.

People who have followed Mozilla Messaging are already aware of our first investments in this arena, such as the popular F1 add-on for Firefox, and the experimental Raindrop project.  The expanded Mozilla Labs team has more plans for both research and product initiatives in the field of online communications and social interactions on the Web, which we look forward to sharing.

Thunderbird users will likely be curious to know what this change means for them.  The short answer is almost nothing will change.  We’ll move pages around websites, but that will be the extent of the impact on Thunderbird users.  In particular, the Thunderbird team will remain a tight-knit self-contained product team with full responsibility for the stewardship, development and support of Thunderbird.  I’m continually proud of the Thunderbird team, as they continue to produce high quality releases on the platform that Firefox is continually improving, while supporting exciting developments like Blake Winton’s GetAnAccount, Jonathan Protzenko’s radical Conversations view add-on or Mike Conley’s Unity integration work to name a few.

I’ll still be managing the Thunderbird team, as well as lead our innovation efforts at the intersection of the Web and messaging.

When I told the team about this change, there was universal nodding — this is an obvious move for Mozilla.  I’ve had the chance to work with many people in all parts of Mozilla over the last few years, and I’ve never met a more competent or kinder group of passionate professionals, and I’ve never been more excited and optimistic about the chances of having impact, both personally and as a part of the fascinating group that is Mozilla.

Jonas Sicking, a superlative Mozilla developer, recently tweeted:

one of the most awesome things about the web is how it enables new ways of communication. What can we do to improve that even more?

That is a nice summary of our focus in the next phase.

Sometimes an add-on is transformative…

In my years of using Thunderbird, there have been a few notable transition points in my personal experience with it. One that I remember well is when we optimized deletion to be asynchronous, which completely got rid of the delay in deleting messages. Another that I’m happy to be able to share now is Jonathan Protzenko’s Conversations add-on, now available through this Labs blog post. It’s remarkable how well Jonathan was able to take an early mockup from a couple of years ago and carry it through to a very, very useful and pleasant and quite full-featured conversation view. Try it out, if you’re like me you won’t want to go back.

On a technical note, it’s nice to see how the various bits of the refactorings and new technology pieces we’ve been building into Thunderbird can be used to build compelling new UIs.

Congrats Jonathan!

Outlook PST importer anyone?

This week, Microsoft published an open source (Apache 2) SDK to read PST files. From what I heard, it works with Unicode PST files as generated by Outlook 2003 or later.

It’s a healthy move on Microsoft’s part, as it releases their users from feeling like their data is locked in to their relationship with Outlook. I hope the code is easy to use, etc.

I’d naturally be very interested to hear of anyone experimenting with using this code in an add-on to make the process of importing all one’s data from Outlook into Thunderbird. If you know of such an effort, let me know!

Thunderbird in 2010

2010 will be a big year for Thunderbird. Last year, we launched Thunderbird 3, which is a huge milestone for us. In this post, I’d like to give people a heads-up as to what the coming year will look like. I’ll focus on three topics: our plans for innovation through add-ons, Thunderbird 3.1, and our first steps towards making Thunderbird self-sustaining.

Innovation through Add-ons

We believe that Thunderbird is a much better development platform than ever. This means that building innovative experiences on top of Thunderbird is easier than ever. We’ll be building on that platform ourselves and helping others innovate as well. In particular, we’re going to be using add-ons in a few ways:

  • If we have an idea for a change to an existing Thunderbird feature, we’d like to roll it out first as an add-on, so that we can get feedback on early versions of the idea without having to incur all of the up-front costs of landing that change into the “trunk” builds. This should allow us to validate (or reject) ideas much faster. A great example of how this can work is the Personas feature, which matured as an add-on, and is now a standard (and awesome) feature of Firefox 3.6.
  • We sometimes think of features that “would be cool” (see e.g. conversation arcs, tagsoup), but don’t necessarily make sense to integrate into the core product. Making an add-on here makes sense because it lets us share those ideas with others who think they’re worthwhile. Sometimes “cool ideas” become “big ideas” over time (google calendar add-on.

Having core engineers develop add-ons is also one of the best ways to ensure that the add-on platform is as good as possible.

Thunderbird 3.1

In parallel with some exciting innovations in add-ons, we’ll be pursuing more gradual change strategies within Thunderbird 3 itself.

Thunderbird 3.0 is getting security & bugfix releases (3.0.1 is out, 3.0.2 is coming soon).

Thunderbird 3.1 is also underway. We’ve already released the first alpha, and a first beta is getting defined. It will be focused on a couple of areas:

  • Making the upgrade from Thunderbird 2 as painless as possible: Some of the features that we introduced in 3.0 were confusing to Thunderbird 2 users, and some of the defaults which we think made sense to new users were quite surprising to long-term Thunderbird users. We’re reviewing the upgrade process and making sure that users get to opt-in to the more radical changes. We realize it can be quite unpleasant to have your software change unexpectedly.
  • Improving some of the new features in Thunderbird 3: The feedback for the new features has been both positive and constructive — look for refinements on the concepts introduced in Thunderbird 3.

Ensuring Economic Sustainability

Thunderbird deserves to be self-sustaining. Paying one’s way is a great validation of any effort, and it’s in the interest of Thunderbird users everywhere that we figure out a way to get there. As promised when we formed Mozilla Messaging, we’re starting to explore ways to make Thunderbird self-sustaining while at the same time promoting the Mozilla mission (as articulated by the Mozilla Manifesto). We’re specifically looking to identify business models that create economic value by improving the user experience of Thunderbird users. This is nothing new for Mozilla. The foundations of an open source codebase, the ability for users to opt-out of commercial relationships, and an architecture that allows plugging in alternative providers for whatever service or product we end up partnering with are non-negotiable requirements. With that as a foundation, we’re looking for ways to make the online life of our users better, and within those ways, identifying those which can help ensure Thunderbird’s long life.

This will happen through a set of public opt-in experiments. For each business model that we try, we’ll build a prototype, announce it, get data to evaluate it, solicit feedback from users, and evaluate whether it’s worth continuing. Anecdotal data suggests that plenty of Thunderbird users are happy to be offered commercial services which provide them value and help Mozilla too.

In addition, I’ll be actively soliciting input and help from what I’d like to call “business contributors”. Just like we encourage programmers and others to contributing to Mozilla through patches and other internet-mediated activities, I’m going to setup ways to “open source” the business model and business development activities. I’ve found in conversations with my peers that almost every business leader who’s aware of what we do would like to contribute, but we haven’t made it easy. Identifying and facilitating such contributions is one of my personal goals for the year.

To start, here are two possible ways for business folks to contribute:

  • I’ll be in the Bay Area next week for a panel at MAAWG in San Francisco and other meetings, and will be organizing a dinner/drinks event for people who want to chat about Mozilla Messaging business models. Contact me by email if you’re interested (dascher at
  • We’re hiring a business development lead to help drive this effort. If you know someone who you think understands business development and would be a great fit for Mozilla, point them to the job description.

I’m looking forward to the conversations!

Webdev & Add-on jobs @ Mozilla Messaging

A few more rough job descriptions, which I’ll polish soon, but may as well start getting resumes now:

First, we’re looking for a jack-of-all-trades web developer. We have a fair number of websites and webapps, and depend on/want to contribute to a bunch more. It’s time we had someone on staff to help us power through those changes. The ideal candidate will have experience with at least PHP and Python-based webapps on Unix/Linux, comfortable with the usual Apache, MySQL, stack (preferably with some HA scars), and be happy to help do some JS/CSS/HTML client-side work as well. The job will include a blend of new web development, maintenance of existing sites, and patches to project-wide apps. Past experience working in open source, distributed, transparent projects is a huge plus. If not located in Vancouver, experience working remotely will be required.

Second, we’re looking for some contractors to help us work on Thunderbird add-ons. A strong JavaScript application developer with good CSS/HTML skills is a minimal requirement, past experience writing add-ons for Gecko-based apps a definite plus. You’ll be working with the Vancouver-based design team and the broader distributed developer community to quickly iterate on add-ons that enhance the Thunderbird user experience. Being located near Vancouver, BC, would be great, but we would consider remote candidates in nearby timezones.

Email jobs at mozillamessaging dot com with relevant background information.

Looking for an awesome test engineer

I don’t yet have a full job description handy, but figured I could start with a draft:

Mozilla Messaging is looking someone who can help us drive forward Thunderbird’s test automation framework, tooling, coverage, and community. We’re looking for someone who combines the usual skills we need:

  • Strong domain expertise: in this case test automation of a multi-platform desktop application
  • Big-picture thinking: you’d be the first paid test engineer working on a huge codebase with lots of developers and millions of users, so the hard thing won’t be to find things to do, rather figuring out what’s the right thing to work on
  • Ability to lead and build a community of peers and contributors
  • Ability to prioritize and drive your own work, and happy to collaborate with a wide variety of contributors

Our current test infrastructure relies primarily on MozMill, and most tests are written in Python or JavaScript, so solid understanding of those technologies is obviously useful.

This is a unique opportunity for someone who takes testing, engineering, and community seriously, and who wants to have a huge impact on software that is used daily by millions of people.

Relocation not necessary.

Pass the word!

(resume submissions to jobs at

A public internet deserves great beaches

Firefox releases have cool codenames while in gestation. As Chelsea explains, Firefox picks national parks as codenames, as metaphors for the values that go into making a Firefox release.

The idea made a lot of sense to us, so we decided to follow suit for Thunderbird. Rather than parks, we picked beaches. A good beach is a clear and compelling example of a public good. We can all go to the beach, share in the beauty and poetry of the place, swim, maybe surf. All that’s required of us in exchange is to treat it well — don’t fence it in, don’t litter, don’t crash your oil tankers into it. Yet beaches as a public commons are under threat. If Thunderbird can help beaches and beaches can help make it clear why Thunderbird matters, we all win.

Given the weather outside, it’s not too surprising that the codename for the next version of Thunderbird is Lanakai, in sunny Hawaii. “Warm turquoise green waters brush up against a fine sand beach while gentle trade winds offer a cool relief from the hot Hawaiian days. This beach is great for relaxing on the sand or taking a swim in it’s clear waters”. That pretty much sold us. Also, we can dream about having a Thunderbird summit there someday.

Dear ISPs

Dear ISPs,

By far the largest set of support requests that we end up seeing for Thunderbird have to do with being unable to receive or send mail. By far the largest single cause of these failures is some unilateral change by the ISP which cause previously working configurations to stop working. In other words, people come to us for help solving problems we can’t solve. It makes us feel bad, it makes you look uncaring, and it certainly doesn’t help your customers (except for those cases when we go beyond the call of duty and help them as neighbors would, guiding them through the diagnostic & fix).

In our next revisions of Thunderbird, we’ll probably work on making our error dialogs better, so that we transmit whatever wisdom we can to your users to give them a fighting chance. But we can do better for your customers, if you get involved.

Let’s figure out how to work together to provide better experiences for your customers and our users. I’m quite sure that we can come up with solutions which would save you costs compared to having your customers tie up your tech support lines only to be rebuffed by your staff who often don’t understand how email systems work. It might also help you avoid commoditization…

Here are some ideas to start the conversation going:

  • Let’s make sure that our configuration of ISP databases works for as many users as possible. We’ll likely need to evolve the format and protocol over time, but we can only do that with input (some ESPs have already joined the effort, which is great!).
  • Consider making a useful add-on that would let you inform your customers of planned service downtime, configuration changes, etc. (no marketing messages, please, or your customers will not use it).
  • If there are changes we could make in Thunderbird that would help you help your customers, let’s talk!.

Together, we can figure out how to get your customers setup with a Thunderbird that works for them, for us, and for you.

Looking forward to a productive conversation,

— David Ascher
(dascher at mozillamessaging)

Support job with Mozilla Messaging

frustration, from e-magic on Flickr
"frustration", from e-magic on Flickr

One of my first jobs in IT was as a “computer consultant” for my university.  I got to learn a lot about computers of various kinds (including currently useless but still formative bits like writing REXX programs on a CP/CMS IBM 3090 mainframe), and, more importantly, I learned a lot about what it takes to really help people solve computer problems.  We had all the kinds of users you’d expect in a decent-sized community: haughty faculty (and haughtier grad students, for some reason), who absolutely demanded that you stop whatever you were doing to help them fix their margins <em>right now</em>.  We had to mediate between first-year students lost and confused in their first exposure to the net, and technical staff who were straining under the onslaught of the first week of classes.

Still, it was a lot of fun — we had autonomy to decide what problems were worthy of paper handouts, to hand out as answers to FAQs — we had special accounts with free access to the high-resolution printers — but most of all, we had lots of interactions daily with people who were truly grateful for the help we provided.  Not all interactions were positive, but the vast majority of them were.  There was a real community between the student staff, the full-time staff, and the avid users who spent their days in the computer center working on their papers, homework, and assignments.

The job

These memories come back as we’re now looking for someone to help coordinate Thunderbird’s technical support communities.  The challenge is orders of magnitude harder, but the opportunities to help are equally huge.

Mountain Lion Safety by ekai on flickr
Mountain Lion Safety by ekai on flickr (helpful, no?)

It’s become clear to me that this job is fairly unique, both in scope, and in what we’re looking for.  The right candidate will have a rare blend of empathy & technical knowledge, clear organization skills.  She or he must have the ability to bring people off the ledge, recognize and encourage peer leaders, but also know how to deal with poisonous people.  This requires both clarity of thought and clear, efficient expression.  Our ideal candidate knows Thunderbird well, but most importantly can understand both the requirements of providing technical support for hugely diverse populations of users, who often come for help when they have critical issues that are often caused by external actors like email providers.  A hard job to fill.

A big part of the job is also to understand the existing bits of the existing world of Thunderbird support, and figure out ways of connecting the bits that work, and building new bits if needed.  From where I’m standing, this ecosystem includes forums like mozillazine, which have garnered huge numbers of posts with very valuable information, but which don’t necessarily provide the best experience for novices.  It also includes the GetSatisfaction forums, which provide a lower barrier-to-entry for many users, but which are still in their infancy, both in terms of content and in terms of people providing answers.  The ecosystem also importantly includes SUMO, which right now is focused on Firefox, but which could hopefully be deployed for Thunderbird use someday.  A comprehensive solution also likely involves figuring out how to help people over Twitter, on Facebook, or wherever Thunderbird users are likely to look for answers or express frustrations.  Whoever gets this job will end up diving deep into the world of Mozilla support overall, and learn from all of the people who’ve built those foundations — then build upon them.

As the central point of contact for support issues, this person will be incredibly helpful in working with the QA and dev teams to prioritize bugs and other issues, so that the next revisions of Thunderbird or Thunderbird websites work better for more people.  Finally, it would be great to coordinate with the support micro-communities that exist around the world.  In general, the job is clear: help people with Thunderbird, and help people help each other.

If this sounds like you, send us an email, explaining why you’re the right person for the job.

Getting insight into one’s own email

Thunderbird knows a lot about your email. After all, it’s got access to large amounts of data, and builds sophisticated databases so that it can be very responsive, even when dealing with large folders containing thousands of messages. Wouldn’t it be nice if we could use this information to extract either faster workflow, or even insight into our email habits?

On Tuesday, as he was slogging through some somewhat antique code in the front-end of Thunderbird, Andrew asked whether Thunderbird’s “start page” was what we wanted it to be, which is Andrew-speak for “this is broken, we should fix it”. We’d actually discussed what to do with that page for a long time, but had focused on other, more infrastructure bits for a while. I decided it was time to dust off those plans, and see what we could do.

First, some background. The “start page”, which makes a lot of sense in Firefox, never made a huge amount of sense to me in Thunderbird. In particular, it’s shown only when a folder is selected, and no message is selected. That’s hardly a logical time to show the (colorful, pretty, but fairly useless) page we show now. Instead, why not show information about the selected folder, and help people who clearly intended to select a folder, so most likely wanted to do something related to that folder!

We could still use a small part of the pane to display interesting news snippets, as a way of keeping users aware of new developments, such as new add-ons that we want to promote, or Mozilla events. In fact, by making that page useful, we’re more likely to get people to read a sentence or two which might change periodically, as opposed to changing a page that is so big, wordy and useless, that I suspect most users are completely blind to it.

A couple of days later, we have an early patch, which feels pretty compelling to me:

  • It summarizes critical data about the folder (name, number of messages, number of unread messages);
  • if you were recently reading that folder, it points out the last message you were reading, so you can quickly find it again;
  • it shows you a few of the messages that are most likely of interest (because they’re unread or starred);
  • and finally it gives some information about the activity in the folder: a histogram showing activity over the last 52 weeks, and most prolific authors and most active threads during that same period.

For example:

Folder summary

The icing on the cake is that if you hover over an author or a thread title, it will highlight when those messages occurred in the histogram (in this case, the “An alternate take on HTML 5” thread). Readers of m.d.platform won’t be surprised at any of the names that show up above!

There are lots of possible additions: Some of the ones we’ve thought of include:

  • showing how much disk space is used by the folder
  • showing the “largest” messages
  • showing the status of autosync/indexing jobs

Note: this hasn’t been through a visual design phase yet — the look will change, once someone who knows what they’re doing has a chance to make it nicer! There’s also a lot of work to do to make sure that it does the right thing for saved searches, smart folders, etc. And yes, we’ll make it optional, just like the start page is now.

I’ve been playing with it for only a little bit, and it’s fascinating how interesting it is to get some data on one’s email. For example, I more-or-less follow a small-inbox model, where emails don’t stay in my inbox if I can avoid it — they get deleted, or archived. As a result, the sparkline for my inbox is:

inbox sparkline

which isn’t as short as it should be, telling me pretty quickly that I have some old messages that need attention. It’ll be interesting to see what else we learn from these kinds of simple personal analytics.

What other kinds of visualizations, summaries, and analysis would you like to see in Thunderbird, or in add-ons?

[Update]: I liked the idea that a commenter suggested of showing what tags were in use in the folder, so I had some fun, first with a “tagpie”, which proved mostly useless, just like most piecharts; then with a “tagdots” small-multiples visualization:

tagpies, tagdots, sparklines oh my!

I don’t think the tagpie is worth keeping, but the dots are tempting. As an aside, the Protovis library really is as easy to use as I’d hoped.