Cross-border telephony

I’m tired of paying silly cellphone roaming charges when I travel south of the border.

I’m curious about the possibility of getting a US SIM card for my iPhone, and switching my “main” contact number to my GrandCentral number, which will then call various numbers (two cell numbers, landline, possibly softphone).

I used a European pre-paid SIM card last time I was there, and that worked fine, but I’m asking about the GrandCentral bit in particular, as well as any good plans/prepaid cards for the US that work for my episodic usage needs.

Any advice?

Mozilla Messaging

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.


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?

Email idea #435: find-the-questions

As my friend Simon Wex mentions in his latest post, I think there are interesting avenues that a desktop client can explore, an exploration which is harder to do in a web context. Simon being Simon, he even wrote some draft code to see if one idea we batted around (having an email client detect questions in email) idea held water.

Note that Simon says that there are features which he thinks server-side solutions wouldn’t reasonably be able to scale up to. I don’t think performance scaling is the issue, although it’s true that desktop and server side solutions scale differently. Being able to scale the pool of innovators is much more important, in my mind, than being able to scale a particular feature. And that’s where open source, and per-desktop experimentation levers like Thunderbird add-ons, become really interesting.

Finally, I suspect that it might feel somehow better to Simon to have analyses like “which questions from my girlfriend have I not answered yet?” computed locally, as opposed to by some sort of computer in the sky who compares all such questions, auto-suggest answers based on answers Simon gave to his previous girlfriend, or answers the current girlfriend got from her last boyfriend, or even just the most popular answer to said question…

Important “Little Black Books”

I’ve been thinking a lot about the future of Thunderbird, and what areas we should invest in in addition to the obvious ones like long-term maintainability, user experience, and the like. One area which is growing in importance in my mind is what’s referred to as “contacts”. By that I don’t mean the current address book features in Thunderbird, which are useful, and a starting point, but minimal. I mean something much more connected, much more central to what the user experience of a communications client should be.

After all, we don’t send emails to email addresses. We send emails to friends, family, colleagues, partners, bosses. We mostly don’t read corporate blogs, we read the blogs of our friends, idols, and enemies. We don’t send instant messages to aliases, but to significant others, co-conspirators, and other people.

What this means for Thunderbird’s future is still to be figured out, but I thought I’d mention it today because I saw this story from InfoWorld about a Yahoo initiative called oneConnect, which seems to be along similar lines of thought as my own, including interoperation with various social networking to build up a fuller picture of one’s true relationships, which is richer than any one provider’s perspective.

There’s one major distinction between my vision and the one oneConnect seems to promote, which is that I think individuals should be at the center of their own “social manifold”, not Yahoo, or Yahoo/Microsoft, or Google, or any other central party. And that’s a place where I think Mozilla’s approach, whether through the use of desktop software or hosted storage of client-side encrypted data, is the approach worth advocating. Individuals should be able to choose to trust providers to store that data for them, or not. And they should be able to change their mind as to the state of those trust relationships, especially given this heady M&A frenzy.

In particular, consider the implications of something like Yahoo’s oneConnect and the possible Yahoo/Microsoft merger, given this other story from Fortune about Microsoft’s approach to data portability.

Josh Quittner summarizes his perspective as: “My contacts should belong to me”. Couldn’t have said it better myself.


This picture was sent to the Mozilla webmaster from a friend of Mozilla in Bariloche, Argentina. Julian says (w/ minor english tweaks):

“I’m from Bariloche, Patagonia, Argentina, and yesterday I took this picture while I was climbing a mountain in the heart of the andes. It reminded me of your logo and I want you to have it. I hope you like it!
The bird is a ‘Condor Andino'”

How cool is that?