Mozilla Messaging

Standard

Today we’ve announced the launch of Mozilla Messaging, the new name for the entity I’ve been calling MailCo on this blog. As promised, it’s a new subsidiary of the Mozilla Foundation, focused on email and internet communications. We’ve put up the essential information about the organization on the website, but I have more room for background here.

Since I signed up for this job, I’ve repeatedly been struck by the amazing opportunity it represents. No matter who I talk to, people are happy to know that Mozilla is doing this, go out of their way to express their shared optimism in the project, and either send their heartfelt best wishes, or simply offer their assistance. How many organizations can say that?

Email and other forms of internet communications present us with a paradox. The stunning proportion of our days spent communicating online clearly indicates that as a society, we are more intricately connected via the internet than ever before. I’m a case in point, strongly connected to dozens of people over the last few months in a shared effort to launch this new company, which lives nowhere and everywhere at the same time. Email, IM and IRC make that possible.

Yet as the number of such interactions grows, and as the number of ways in which we interact grows, the joy that communication can bring is too often replaced by frustration, confusion, or stress. Furthermore, as we transmit more and more digital data, privacy and control questions become more and more troublesome.

One common short-hand for the above is to say, somewhat flippantly, that “email is broken”.

I’ll explain what we’re going to do about it in the short term, but the more interesting question is for me to ask you “what are you going to do about it?” As I’ve slowly internalized over the last few months, the notion that anyone can and should participate in helping fix whatever is broken is a key tenet of the Mozilla project. It has structural implications for how we build companies, and, I believe, it’s a key advantage compared to all the other companies who are tackling the nest of issues that entangle internet communications.

We know we can’t do it alone, and we’re not even going to try. Indeed, rather than lay out a bold vision and convince people that we’re going to solve all their problems, we see our primary role as that of facilitating collaborative approaches to problem solving and incremental progress, through a combination of leadership and facilitation work. This is an unusual approach, and it can be chaotic and slow. But it seems to have worked well for Firefox and the web, and I believe it can work well for Thundebird and email.

So what’s our plan?

Our plan starts with building a great product. Firefox has shown that if you have a great product that tens of millions of people love to use daily, doors open and more opportunities become within reach. So we’ll focus on the product. Thunderbird 2 is already a hugely successful product by many measures, providing a great email experience to millions of users around the world, in 37 languages, on all three major operating systems.

We can make it even better.

We’ll do that by responding to user feedback, by incorporating key contributions from third party developers, by providing a streamlined user experience which lets people focus on the interactions they want to have with other people rather than with the software that’s in front of them. We’ll do that by taking into consideration the needs that people have today, and planning for the needs that people will have tomorrow. We’ll do it by implementing the best software engineering and open source practices we can.

No, really, what’s our plan?

We’ve started defining what Thunderbird 3 will be, because we think that there is enough consensus to make some of the first decisions on the most important changes to tackle first. Specifically, Thunderbird 3 will build on the great base that is Thunderbird 2 (and the work already performed in trunk by the current and past contributors), and add some key features, such as:

  • integrated calendaring (building on the great work done by the Mozilla Calendar team and their Lightning add-on to Thunderbird),
  • better search facilities,
  • easier configuration,
  • and a set of other user interface improvements.

What each of those means in practice will be worked out in public, on blogs, mailing lists, and newsgroups, as transparently as possible.

In parallel, we’re going to be starting a multi-year process of improving the back-end architecture of Thunderbird. Over the years, Thunderbird hasn’t had the resources devoted to it that Firefox has, and it’s time to catch up, so that we can implement many of the features we have planned, and so that we can take advantage of the improvements to the Mozilla platform that were built for Firefox, but which we can leverage as well.

Longer term

We’re also going to start a broader conversation as to what the long term vision is for Thunderbird, which will feed back into the software development plans. I’ll have more to say about this soon, but I can give a sketch of where my thinking currently is:

First, it’s important to start from a solid understanding of what Thunderbird is today. Most importantly, it’s a desktop client built on the same technology platform as Firefox. This gives it some weaknesses, and some strengths. I think we should build on the strengths and mitigate the weaknesses.

One huge strength is the extensibility of the platform, which is one key differentiator for Firefox, and which can be even more important for a communications client than it has been for a web browser. Another strength is that we already have a complete web technology stack built into our mail client, and as a result, we can consider deep integration with both websites and web services which other solutions can only dream of. Another, crucial strength, is that as an open source desktop application, Thunderbird “belongs” to the individual person using it, not to the owner of any one website or communications network. As people struggle with keeping track of disparate communication channels and social networks, this nexus of control becomes a sweet spot for integration. There are significant weaknesses as well, most importantly the need to install the software to use it. There are interesting possibilities to consider there as web application technologies become faster, richer, and better integrated with the desktop experience, which will inform our long-term planning.

Second, it’s important to keep an eye on larger trends. Email is more important than ever, and yet it’s no longer the only game in town, or even the dominant one for younger generations or emerging economies. It is worthwhile considering what the right user experience could be for someone using multiple email addresses, multiple instant messaging systems, IRC, reading and writing on blogs, using VoIP, SMS, and the like. What parts of those interactions make sense to integrate, and where? I don’t believe that stuffing all of those communication models inside of one application is the right answer. But the walled gardens that we’re faced with today aren’t the right answer either. There is room for innovation and progress here, and we need to facilitate it.

Finally, it’s important to keep our options open. Thunderbird has a unique opportunity because of its relative uniqueness as a popular open source desktop communications client. There are countless possibilities for evolution even today, and more will show up tomorrow.

Time will tell whether the plan succeeds. I’m happy to hear about other approaches we should consider, so feel free to drop me a line.

People

To build a company that can succeed in this effort requires individuals who share an common perspective on what defines success. I’m extremely proud of the people who have alread chosen to help, signing on as board members, employees and contractors, or as volunteer contributors. If you get to interact with them, I’m sure you’ll understand why. Each of them combine deep competence in some aspect of building a great software company, understands that to succeed we must be part of a broader community, and subscribes to the Mozilla vision of what the internet could and should be. They all could be spending their time doing something more lucrative, but apparently they simply couldn’t resist the opportunity to try and work together to do something really great, and have fun in the process. I can’t wait to work with all of them.

In addition, I’ve been awed by the competence and dedication of all of the people who have helped us get to today’s launch. At this point I think everyone in Mozilla has helped in some key way, starting with legal & recruiting, through engineering, QA, build, marketing, and PR, and finishing, late at night, with IT. Thanks to all, and I look forward to continuing our collaboration!

In some ways, I hope that I won’t have much occasion to write about what Mozilla Messaging, Inc. is doing over the coming months, because it is not the interesting story. We’ll provide significant input and leadership in the direction setting, engineering work, and operational support, but the really interesting story will be whether we can convince people to spend their time working with us.

Email is broken. What are you going to do about it?

Thunderbird/Calendar drinks & food

Standard

After a long day of talking about calendaring at CalConnect, some of the Mozilla calendar & mail folks (hopefully at least Daniel, Christian, Dan, Clint and David) will be going out for drinks & more food on Tuesday Feb 5 Wednesday, Feb 6, starting around 8pm or so at the Oasis beer garden. Please sign up for the event if you’re thinking of going, and we’ll try to save you a seat.

Thunderbird/Calendar drinks & food

Standard

After a long day of talking about calendaring at CalConnect, some of the Mozilla calendar & mail folks (hopefully at least Daniel, Christian, Dan, Clint and David) will be going out for drinks & more food on Tuesday Feb 5 Wednesday, Feb 6, starting around 8pm or so at the Oasis beer garden. Please sign up for the event if you’re thinking of going, and we’ll try to save you a seat.

MailCo: More horsepower!

Standard

I’m very excited to share the following news: Dan Mosedale (dmose to his IRC friends) has agreed to help me launch MailCo. For those of you who don’t know Dan, you should know that he’s been involved in Mozilla since the early days, and has contributed significantly both to Thunderbird and to the Calendar project. I can’t think of a better person to help lead me this project. Not only does he have the coding and architectural chops to help lead the code from a strictly technical point of view, but Dan also has a great rapport with the community, understands what it takes to mentor new contributors and guide them through the various stages of involvement, and shares my ambition for what Thunderbird can become.
The current plan is that he’ll be working with me and the rest of the MailCo staff (being recruited as I write) for the next four months at least, bringing his expertise and knowledge to bear on everything from roadmap and product planning, hiring, community leadership, and whatever else I can throw his way.

As he’s currently working on important Firefox 3 features, we’ll find a transition plan which works well both for Thunderbird and Firefox. I’m expecting a gradual transition, as I know that I want Firefox 3 to succeed as much as the Firefox team wants Thunderbird to succeed.

Now Dan, about the demorkification project

Organizational Deployments, AKA enterprise users

Standard

One of the TODO items I brought back from France last year was to start a discussion area for what I’ve been thinking of as “organizational deployments” — everything related to making it easier for organizations to deploy Thunderbird, in particular in larger organizations, where the scale of these deployments makes the “standard” processes hard to manage. (Yes, the standard term is “enterprise” users, but I find that word problematic — still, it’s the same topic)

Well, someone beat me to it. Mike Kaply, a Firefox advocate within IBM, setup a few great starting points:

These will be great place to discuss things that are Mozilla-general. We may even find it a fine place to branch out discussions of Thunderbird specific issues, as I wouldn’t be surprised if topics that may seem Thunderbird specific have analogs in Firefox-land, or at least could benefit from platform-level attention.

If we need to create a Thunderbird specific mailing list, we can do that, but let’s start on the shared list first. I know that many of the topics I’ve heard about, from auto-configuration, to more control over AUS, to hosting add-ons sites, etc., are cross-product issues.

I look forward to hearing from institutional users, corporate, educational, governmental, and other!

Thoughts on Thunderbird’s Evolution

Standard

Aside from all of the organizational stuff I’m doing like recruiting (more news soon I hope), dealing with the incorporation papers, budgeting, etc., I’ve been spending a lot of time thinking about Thunderbird’s evolution.

Specifically, how should we, as a project, figure out what to work on?

Some of my thinking about this hasn’t changed since I joined, but many of the details have, in reaction to talking to people on IRC, on the newsgroup, and, significantly, by watching a lot of bugmail.

First, a reality check. Thunderbird exists, today, and works, today, for large numbers of users, large numbers of use cases, against a variety of servers, in a huge array of different environments, from individual home users to massive organizational deployments. That’s a precious asset which I don’t want to either ignore or disrupt. So for example, any plans for Thunderbird evolution which start with “first, start over”, or “first, remove feature X” aren’t likely to go far.

Furthermore, there is an incredible store of community knowledge about known issues, good features to add, known architectural challenges, etc., which I’m slowly absorbing. And there is existing momentum there, with bugs being worked on daily, which I most certainly don’t want to stop. In the shortest term, all I’m likely to suggest are small course changes, although they’ll all be motivated by bigger picture motivations.

As an example of that kind of small influence, a little story: Mark Banner has been working on the Address Book for a long time. Joshua Cranmer, a more recent contributor, started to help out with a long-standing bug to convert the address book store from the “idiosyncratic” Mork database to the shiny new SQLite database now available. My contribution to that effort was to suggest in IRC that it’d be good to start with some unit tests, as changing backends without a test suite struck me as risky. A few days later, Mark had the beginnings of a test suite ready, that Joshua can use to move faster with the conversion. The bigger theme there is clearly that I believe we should build enough infrastructure such as test suites and test farms so that we can take on architectural changes with more confidence. That’s a theme you can expect to hear again. Much of the work that MailCo can do in the short term will be to help with setting up a context which is favorable to product evolution, so that people outside of MailCo find working on Thunderbird as rewarding an experience as possible. There are a surprising number of people who have tried to contribute to Thunderbird over the years, but there was no one with resources and the overall vantage point to help them help the project. (A related effort which I’m hoping to launch soon is to make it much, much easier for people to build, distribute, and install Thunderbird Extensions.)

There’s more to leading a project than making work safer or easier, though. Many people on the project would be happy to help move the project forward, if they only had a clear picture of where the project was going. Knowing about that long-term direction also makes it easier to figure out which of the existing feature enhancement requests (numbering over 1300 in bugzilla alone) fit in with the long-term vision for the project.

There’s a clear need for a long term vision, from which we can build a roadmap, taking into consideration the platform roadmap in particular. From that document we should be able to specify release goals, and then prioritize work items, identify areas needing contributor involvement, etc.

My approach to identifying this long term vision has been two-pronged. There are macro-level, contextual drivers, and there are micro-level, operational constraints. Understanding the current state of the project, is crucial to identifying what’s doable with a small paid staff and a lot of code, users, bugs, etc. On the flip side, the societal and market trends help us figure out where it’s worth trying to take the project. For example, instant messaging use is now pervasive. Newsgroup usage is declining. All other things being equal (and they never are), I’m more likely to encourage IM integration than newsgroup tweaks. But it’s a balance, because we may have (as we do) existing code and contributors who care about NNTP (such as the aforementioned Joshua!), and I’m not about to stop them from fixing bugs!

Other high-level points which influence me and will influence the long-term vision:

  • Mozilla is unique in that among all of the “vendors” of messaging technology, it is the only organization driven by the public benefit. This should allow us to meet the user’s needs directly, without having to get distracted by exit strategies, analysts, etc. It also makes it easier to recruit volunteers!
  • Thunderbird has a unique position in the market due to its relationship with Firefox, the larger trends regarding open source adoption, and its technology base. The Mozilla platform’s extensibility capabilities are unparalleled, and this gives Thunderbird huge potential for fitting in “niches” that are hard for others to reach.
  • The world of messaging has changed radically in the last decade, and not always for the better, from the user’s perspective. With increasing volume, spam, and diversity in communication modes, interacting via computers is getting more stressful, not less. From a product management perspective, there is “customer pain,” which means that there are problems to be solved. That’s a good thing!

In some ways, then, I’m forming a picture in my head which has a faraway, slightly fuzzy picture, of the Thunderbird that could be. And I’m also learning a lot daily about the Thunderbird that is. Interpolation is then just a small matter of design, architecture, coding, testing, inspiration, perspiration, patches, reviews, tests, parties, t-shirts, arguments, celebrations, conflicts, and conversations — lots of conversations…

Thoughts on Thunderbird's Evolution

Standard

Aside from all of the organizational stuff I’m doing like recruiting (more news soon I hope), dealing with the incorporation papers, budgeting, etc., I’ve been spending a lot of time thinking about Thunderbird’s evolution.

Specifically, how should we, as a project, figure out what to work on?

Some of my thinking about this hasn’t changed since I joined, but many of the details have, in reaction to talking to people on IRC, on the newsgroup, and, significantly, by watching a lot of bugmail.

First, a reality check. Thunderbird exists, today, and works, today, for large numbers of users, large numbers of use cases, against a variety of servers, in a huge array of different environments, from individual home users to massive organizational deployments. That’s a precious asset which I don’t want to either ignore or disrupt. So for example, any plans for Thunderbird evolution which start with “first, start over”, or “first, remove feature X” aren’t likely to go far.

Furthermore, there is an incredible store of community knowledge about known issues, good features to add, known architectural challenges, etc., which I’m slowly absorbing. And there is existing momentum there, with bugs being worked on daily, which I most certainly don’t want to stop. In the shortest term, all I’m likely to suggest are small course changes, although they’ll all be motivated by bigger picture motivations.

As an example of that kind of small influence, a little story: Mark Banner has been working on the Address Book for a long time. Joshua Cranmer, a more recent contributor, started to help out with a long-standing bug to convert the address book store from the “idiosyncratic” Mork database to the shiny new SQLite database now available. My contribution to that effort was to suggest in IRC that it’d be good to start with some unit tests, as changing backends without a test suite struck me as risky. A few days later, Mark had the beginnings of a test suite ready, that Joshua can use to move faster with the conversion. The bigger theme there is clearly that I believe we should build enough infrastructure such as test suites and test farms so that we can take on architectural changes with more confidence. That’s a theme you can expect to hear again. Much of the work that MailCo can do in the short term will be to help with setting up a context which is favorable to product evolution, so that people outside of MailCo find working on Thunderbird as rewarding an experience as possible. There are a surprising number of people who have tried to contribute to Thunderbird over the years, but there was no one with resources and the overall vantage point to help them help the project. (A related effort which I’m hoping to launch soon is to make it much, much easier for people to build, distribute, and install Thunderbird Extensions.)

There’s more to leading a project than making work safer or easier, though. Many people on the project would be happy to help move the project forward, if they only had a clear picture of where the project was going. Knowing about that long-term direction also makes it easier to figure out which of the existing feature enhancement requests (numbering over 1300 in bugzilla alone) fit in with the long-term vision for the project.

There’s a clear need for a long term vision, from which we can build a roadmap, taking into consideration the platform roadmap in particular. From that document we should be able to specify release goals, and then prioritize work items, identify areas needing contributor involvement, etc.

My approach to identifying this long term vision has been two-pronged. There are macro-level, contextual drivers, and there are micro-level, operational constraints. Understanding the current state of the project, is crucial to identifying what’s doable with a small paid staff and a lot of code, users, bugs, etc. On the flip side, the societal and market trends help us figure out where it’s worth trying to take the project. For example, instant messaging use is now pervasive. Newsgroup usage is declining. All other things being equal (and they never are), I’m more likely to encourage IM integration than newsgroup tweaks. But it’s a balance, because we may have (as we do) existing code and contributors who care about NNTP (such as the aforementioned Joshua!), and I’m not about to stop them from fixing bugs!

Other high-level points which influence me and will influence the long-term vision:

  • Mozilla is unique in that among all of the “vendors” of messaging technology, it is the only organization driven by the public benefit. This should allow us to meet the user’s needs directly, without having to get distracted by exit strategies, analysts, etc. It also makes it easier to recruit volunteers!
  • Thunderbird has a unique position in the market due to its relationship with Firefox, the larger trends regarding open source adoption, and its technology base. The Mozilla platform’s extensibility capabilities are unparalleled, and this gives Thunderbird huge potential for fitting in “niches” that are hard for others to reach.
  • The world of messaging has changed radically in the last decade, and not always for the better, from the user’s perspective. With increasing volume, spam, and diversity in communication modes, interacting via computers is getting more stressful, not less. From a product management perspective, there is “customer pain,” which means that there are problems to be solved. That’s a good thing!

In some ways, then, I’m forming a picture in my head which has a faraway, slightly fuzzy picture, of the Thunderbird that could be. And I’m also learning a lot daily about the Thunderbird that is. Interpolation is then just a small matter of design, architecture, coding, testing, inspiration, perspiration, patches, reviews, tests, parties, t-shirts, arguments, celebrations, conflicts, and conversations — lots of conversations…

Thunderbird and Institutional users

Standard

During my trip to Paris last week, I met with a set of representatives from public sector institutions which are deploying Thunderbird to large sets of users, as part of a larger (and long-term) move towards open source and open standards. It was fascinating to find out what their goals were, what they’d been able to achieve, what hurdles they were still facing, and how we might be able to work together.

User control vs. centralized responsibility

In enterprises, people expect their IT department to help them if they have problems using the software they use for work. Especially if the IT told them to use Thunderbird, that means that the same IT department has to be able to support it, in the local language, using customized, organization-specific documentation. In that kind of scenario, it’s seen as important that the IT department has the right level of control over exactly what version of Thunderbird is in use. Many of the things that make both Firefox and Thunderbird wonderful consumer products end up inadvertently making it harder for those IT administrators to support it. Auto-update, which is key to keeping the web safe and any desktop application up to date especially with security fixes but also with continuous improvement, is a possible time-bomb for the people handling support in large installations. The ability for end-users to install extensions which solve a need they have as individuals, if it breaks core functionality in the product, and results in calls to tech support, end up hurting the product.

I like these topics because I think that while on the surface they seem like points of conflict between the end-user focus of Mozilla products and enterprise deployments, longer term I see opportunities for progress on both “sides”.

  • The AUS technologies that Mozilla built to support updating hundreds of millions of users at once can be redeployed inside enterprises to give them the control they need and facilitating faster update cycles.
  • The support concerns that IT managers have about extensions aren’t that different than the concerns the Firefox team probably has about possible “rogue” extensions, and together I suspect both groups can help each other.
  • Improving the configuration experience for Thunderbird will help the home user as much as the IT administrator.

Annoyingly for me, when these institutions distribute Thunderbird, the update-checking mechanism is deliberately disabled as part of a global security policy, meaning that not only do bug fix releases like last week’s 2.0.0.9 don’t reach those users, but I have no way of even guessing how many such users there are! This makes understanding user trends like total user population, the speed at which users upgrade, etc., much harder.

The power of extensions

Extensions are great. Everyone says it, and they’re usually referring to Firefox extensions. But I believe the potential power of extensions is even greater in the world of messaging than in the world of the web. Browsers are made to interact with websites, most of which try very hard to make the experience be the same across browsers. Firefox extensions, in some way, fight the dominant mode of the web. In a messaging client, however, extensions can work hand-in-hand with server-side technology, or the sometimes very idiosyncratic needs of a specific organization. I was shown several fascinating Thunderbird extensions implementing CRM-like features, global account management features, integration with custom calendaring software, specialized mail handling, etc. In these organizations, the email client is deeply customized to fit the local needs, and the Mozilla platform’s story on extensibility is unbeatable. There are definite issues in the Thunderbird extensions story, but there are also low-hanging fruit there.

Pre-configuration and mass deployment

If you think Thunderbird is hard to configure right now (I do), imagine being responsible for configuring 80,000 desktops for non-technical users! There are some systems in place already, but I understand there are still issues that make it a challenge to deploy Thunderbird in such large installations. This is likely more problematic for Thunderbird than for Firefox, as there are more environmental settings involved in email than in web browsing. Indeed, several of these enterprises deploy Thunderbird but not Firefox, countering the notion that Firefox is always the “lead”.

Opportunities for peer-help and a Thunderbird consultant market

If last week’s conversations are any indication, there are likely hundreds of individuals responsible for hundreds of thousands and maybe soon millions of Thunderbird installations, and yet they likely don’t know each other. One of them may even have solved a problem that the others are struggling with, or don’t yet know they’ll have. Today, it’s hard for these people to find each other. That’s a problem we should be able to solve, using basic tools like Wikis and a dedicated mailing list/newsgroup.

Another opportunity is that institutional users tend to have core competencies which don’t include writing Thunderbird patches or extensions. There are, however, a growing number of small and not-so-small service companies which are learning how to do that better and better. There’s a market gap there, especially as MailCo itself is not likely to build custom extensions, for example. Given that my number one goal is to facilitate adoption of Thunderbird, I want to facilitate the creation of a market for custom Thunderbird extensions, and for fixes to bugs which may be urgent for some but which we may not get to soon enough. If you’re interested in either side of that marketplace, let me know.

The debate is different

More specifically, the people I talked to represent a new type of customer for me. Thanks to years of evangelism by people like Tristan Nitot, I didn’t have to argue for releasing code under compatible open source licenses, or for working hard to avoid the need for forks. Even more interesting is the fact that in North America, when I describe what I’m up to, the most common first question is “but how will you make money?”, while at least in one big meeting with lots of people, no one asked. The people I talked to were more interested in the non-financial aspects of the Mozilla endeavor. That money is being made is fine, but one gets the feeling that it’s not a particular point of interest by users or pride by community members. Knowing that Mozilla is willing to take on fights that no one else is willing to take on, that’s inspiring and exciting, and worth taking some risks for.

Next Steps

The single most common complaint I heard regarding Mozilla’s handling of Thunderbird is not enough communications. Communications about everything from the roadmap (on my plate), the APIs for extensions (FUEL for Thunderbird anyone?), the wiki, the strategy to change the world, and more. I agree wholeheartedly, even with the criticism that I should blog more. Mea culpa, will try to do more in the coming weeks.

MailCo Jobs

Standard

I have the enviable task ahead of me to recruit a from-scratch team for MailCo, to help me lead Thunderbird in particular and email & internet communications in general. In this post, I highlight some of the requirements I’ve identified for MailCo, and what that means for who would be a good fit. I then give high level descriptions of the roles I’ve identified as being my first priorities.

What will MailCo be like?

This is going to be one unusual company. We’re going to be a small team (probably fewer than 10 people in the first year), with, from day 1, an awesome responsibility towards hundreds of contributors, tens of thousands of beta testers, and millions of users. People will also look to us to do innovative, industry changing (and still unspecified) things. While few will expect us to mirror Firefox’s success, for a variety of reasons, I think we have much to gain by simply trying. At the same time, while we’ll have an ambitious mandate, we’ll also have to carefully manage the existing codebase, support today’s community, and incrementally make both the project and the community stronger. We’ll be part of the Mozilla world, but have our own identity as an organization and a band of co-workers.

What does that mean for recruiting? I think the best summary of my thinking here is that I’m looking for “thoughtful, ambitious people who can have extraordinary impact through leverage”. By thoughtful, I mean that it would be a disaster to bring in people with wonderful blue-sky ideas as to how the world should be, and who will push their ideas forward without considering the existing state of affairs. By ambitious, I mean that there is too much stop energy in the world, and it’s too easy to look at any situation and see unsurmountable problems. Especially in a startup environment, I need people who, when faced with a roadblock, will either ask “where should we start clearing?” or “can we go around it?”. (I’m well aware that my job as a leader is to make those questions be questions that are both reasonable and safe to ask). By leverage, I mean that regardless of the functional role, MailCo’s success will depend on our ability to draw in contributions of code, sweat, passion, talent, and enthusiasm from people outside of MailCo. This will be as hard as it is rewarding. Bright, competent people are rarely comfortable asking for others to help them. It may even feel inefficient at times. But the only way we’ll ever be able to radically improve things is to build the same kind of thriving community that Firefox has built. So I’ll be looking for people who understand that and can help identify and amplify “scaling factors”.

The long-term goals for MailCo and Thunderbird will be discussed in detail later. For the purposes of today’s post, I can summarize the medium-term goals for Thunderbird as:

Build and continually tune a software production machine

This first goal has all to do with code, process, infrastructure. There’s a lot of work to do there, from build and test automation, architectural cleanups, fine-tuning of the release definition, bugflow, outreach to the various related communities, etc. The best news there is that many people seem to agree on what’s needed — all that’s been missing is time to do the work, and that’s exactly what the seed funding is for.

Massively increase the number of people using Thunderbird

I believe that while today’s Thunderbird is a great product for several million people (!), there are some relatively small changes which could make it a great product for millions more, while not detracting from the user experience of its current fans. Simple things like spending time (key word again!) on UI cleanup and simplifying initial configuration could, in collaboration with a grassroots marketing effort, significantly
impact the number of people we reach.



by Stacina

Build a platform for long-term innovation

The Mozilla project (platform, community, infrastructure, people) is remarkable for its powerful customizability, extensibility, and reach, both enabling innovations and taking them into the hands of users. Thunderbird has already done a lot there, fostering great innovations through extensions, and as part of its product evolution. I think we should and can do more. We should increase our support of add-on developers through advocacy, marketing, and access to infrastructure. We should also use some of our resources to do some of the hard engineering and documentation work which will make it easier for the next generation of extension developers, partners, and advocates to do more.

Note that these three goals feed each other. You can’t reach millions if you can’t smoothly produce and evolve software, and market impact will make innovation relevant.

A few other important points before I dive into specifics:

  • I’m in Vancouver, but not everyone has to be. I’d love to have people join me, for a couple of reasons: for some roles, especially those involving a lot of coordination, having people nearby is helpful. Also, Vancouver is a great city, moving here tends to be easier than many other places, and living here is a privilege I don’t mind sharing. At the same time, I expect MailCo will be a global organization, reflecting the nature of the project, and I’ll cheerfully consider remote workers.
  • Experience with the Mozilla project is a huge asset to a candidate. Mozilla does software in a unique way. While each project has its own twist on how decisions are made, work is coordinated, releases are driven, etc., there is a general agreement regarding the basic model. If you’ve never encountered Mozilla technologies or the Mozilla process, you are at a disadvantage — however, it’s not an insurmountable one for many positions.
  • At this point, I’m not looking to fill “management” positions. If you’re not interested in being an “individual contributor”, then check back in a few months.

With that in mind, here are the broad categories of roles that I’ve identified so far, after talking to Mozilla Corporation staff, Thunderbird, Seamonkey, and Calendar contributors, managers at other companies with relevant experience, and drawing on my own background.

In no particular order, and titles to be negotiated:

Brick-laying architect

Thunderbird is a huge codebase. Lots of JS and C++. Some of it ugly. Lots and lots of known enhancement requests, bugs, interdependencies, protocols, use cases, preference switches, configuration options. I and others have ambitious plans to evolve it over the next few years. I won’t have the bandwidth to keep the entire project in my head, and I know that I don’t have the C++ chops to help orchestrate such large-scale changes gracefully. I need someone who can help lead that. Such a person must be able to assist the community of existing developers as well as nurture new developers and help them become productive. This is not a “management” or pure architecture job, by the way — code reviews & patches are the currency of the project, and for this person to be effective their coding and related practice must be top-notch. Relevant experience with client-side software and industrial-grade C++ is a requirement.

Virtuoso developers

In collaboration with the big-picture role above, there is plenty of urgent, high priority work to be done in the codebase, and I expect at least a couple of people to be working at the module level or feature level to help drive changes, refactor cheerfully, and help others day-to-day through the usual IRC and bugzilla channels. I’m in particular looking for people who can think “vertically” about the software, understanding not only the engineering issues, but the user-facing issues as well. We’re building a tool to be used by millions of regular people, and people who are driven to make the “computer stuff” just work for end users will find this an opportunity to have a huge impact. People who have “shipped” software and understand the messy, stressful, frustrating but necessary compromises involved will have a leg up.

Automation Fanatic

One effective lever is judicious use of computers in the software production process, including automation. There is urgent work needed to simplify the build machinery, building on the work that Mozilla’s build group has already done. Once that’s done, there’s work to build a strong test automation system. When that’s done, there will be more to do. The ideal candidate here is driven to make normal operations automatic and invisible, and yet always wants to improve processes. Experience and passion for build automation, test automation, sysadmin and configuration management skills required. Knowledge of Perl, Python, makefiles also required.

User Experience Lead

UI and user experience in general is a topic I have a lot of interest in, and I think it’s one of those areas where Thunderbird has been particularly starved for resources. I’d like to see someone become the driver for user experience for Thunderbird, using a similar model to what Mike Beltzner has been doing for Firefox. This is a prime example of where being good at your trade isn’t enough, and you also need to understand, appreciate, and leverage the community to broaden your own perspective, and scale your impact.

QA Community Lead

Thunderbird keeps some of the most personal and important data that people have, their email. For that reason alone, it’s important that the quality initiative for Thunderbird remain central to the project. There are tens of thousands of people who are willing to help in various ways, and at least one person will be needed to coordinate their efforts, lead test days, help drive the test infrastructure, assist with bug triage, etc.

Extension Lead

I believe that the extension-writing community is one of the layers of community around Thunderbird with most latent impact, and I need someone to focus on them. This means making sure that extension writers are listened to when planning the product’s evolution, helping with our developer documentation story, implementing strategic extensions, demonstrating and stretching the extensibility of the platform, and looking out for Thunderbird extension authors and users in general. Experience with mozilla front-end technologies in particular is important, as well as strong people and troubleshooting skills.

Next steps

If you think you have what it takes, let us know by emailing mailcojobs@mozilla.com. Feel free to send traditional CVs/resumes, as well as more idiosyncratic descriptions of what you do if that’s likely to be helpful (closed bug lists, screenshots, URLs to relevant work, etc).
If you think there are other jobs that are more important, or if you just want to put your two cents in on the above, feel free to add comments to this post. Don’t apply in the comments, please, that’s much more likely to get lost in the shuffle.

Note that this isn’t an exhaustive list of the roles I hope to fill over time. It’s just the first cut. And if you don’t fit neatly in one of the roles above but you think we should hear from you anyway, send us an email. I reserve the right to change my mind when faced with real people rather than job descriptions.

Shared contacts, the cheap & cheerful way

Standard

I’ve been meaning to write more about groupware and collaboration, and hopefully will find the time for a longer post on the topic, but here’s a bit of timely news. Ludovic Marcotte and friends have just released a combination of some of their previous extensions to Thunderbird and Lightning as something they call the SOGo connector: it’s an extension to Thunderbird which, when combined with Lightning, provides features like remote address book through CardDAV (sending vCards through CalDAV, AFAICT), and an informal protocol called GroupDAV. While CardDAV is an extension to CalDAV which is an IETF spec, GroupDAV is currently an ad-hoc, simple protocol built to let clients interoperate with open source groupware servers, which probably explains both why it’s simple and why only a few servers (including SOGo, of course) support it.
I still need some education as to what relevant standards have to say (even in non-final form) about shared contact lists. More on this topic later I’m sure.