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.