Thunderbird development

Paul Fernhout pdfernhout at
Tue Nov 28 04:15:36 UTC 2017

On 27.11.2017 16:43, Martin Genet wrote:
> Since Mozilla seems very concerned about people's privacy, I believe
> it should go back to actively develop Thunderbird, on the desktop but
> also develop a mobile app. Indeed, there seems to be more and more
> people switching from emails to chat apps, and most of them probably
> do not really understand the difference in terms of where their data
> is stored and how they can access it. In order to reach the maximum
> number of people, I believe Mozilla should develop a simple interface
> based on conversations, similar to widespread chat apps. Is there a
> chance that it might happen? Is there a better place to ask about it?
> Many thanks for your comments/suggestions.

If you just want chat, you might want to look at Mattermost (a FOSS 
Slack clone) or (a distributed communications platform). Or 
even Google's abandoned Wave (now Apache Wave).

On the broader topic of new development, we all know, especially now 
that Firefox 57 (Quantum) is out, the clock is ticking on how long 
Thunderbird as-is can be maintained. Thunderbird depends on 
now-in-the-process-of-being-abandoned Gecko/XUL technology with a high 
maintenance cost. It is not much fun to work on legacy convoluted C++ of 
an abandoned web browser that makes up most of Thunderbird's current 
total codebase because it embeds a Gecko-based web browser in itself. 
The complex build process makes it next-to-impossible for any programmer 
to contribute time to maintaining that in limited spare time. 
Essentially, that means Thunderbird needs to be rewritten essentially 
from scratch, with a core ideally in a more type-safe language than 
C/C++ while leveraging existing libraries and tools (such as using 
Firefox Quantum as a client via web protocols and not via embedding).

The abandonment of the current codebase means the biggest assets that 
tb-planning has are some money and a big community centered around a 
well-known name ("Thunderbird"). The money is about one million US$ or 
so (IIRC what someone posted recently here) -- which is both a lot of 
money that could support several person-years of development and also 
not very much for something with millions of users that runs on many 
platforms and is essential to the online identity of everyone who uses 
it. More important than money, the Thunderbird community cares a lot 
about decentralized distributed communications, redundancy, and privacy 
and collectively knows a lot about email standards and email handling in 
practice. A big question is, how can the community make the most of 
itself going forward?

To summarize my previous posts, I feel the world really does not 
especially need another stand-alone from-scratch email client or server 
given there are several out there already (as nice as we can imagine 
some new email client could be). What the world needs more is a 
general-purpose locally-installable free-as-in-freedom personal 
communication platform to consolidate all of someone's communications in 
one place (a bit like the aspiration of FreedomBox, but at the 
application level). That platform needs to handle not just email, but 
also social media and chat apps and so on -- including memos to one's 
self, calendaring, and CRM-level sophisticated address books. It should 
also support systematically making sense of all of that data in more 
ways than just staring at the original messages.

That new platform needs to make those communications accessible from any 
device on the internet the person uses including any web browser or 
mobile device, which implies it must have a server aspect. For example, 
I'm writing this email in a web browser on a cheap Chromebook (running 
GalliumOS now though) connected to a RoundCube install hosted by our web 
services provider for our domain. Nowadays I only fire up Thunderbird 
every couple of weeks on a 2008 Mac Pro to POP a copy of everything and 
delete the old stuff. That sadly loses most of the value of my hundreds 
of Thunderbird filters built up over the years.

That personal communications platform niche is open and important right 
now -- in the same way there was a niche twenty years ago for a good 
free email client that became Thunderbird. Unfortunately, it is a tough 
sell to this group to explore that niche because it is much broader in 
scope than an email client. One can reasonably question if money given 
towards Thunderbird should be risked on something broader or instead 
just all plowed into more Gecko/XUL-based Thunderbird maintenance until 
the C/C++ codebase becomes effectively unmaintainable from increasing 
browser-based security risks.

While Mozilla does say it is concerned about privacy, it is also 
ironically a tough sell to do this project under the Mozilla banner 
because a decentralized communications platform supporting increased 
privacy is fundamentally at odds with the big-business-centric-model 
(e.g. promoting Google and Yahoo) that Mozilla's revenue has been based 
on for many years.

Anyway, I'm still working on communication/sensemaking alternatives in 
my very limited spare time. I feel the perceived risk is likely too high 
for the Thunderbird Council to endorse something new from scratch no 
matter who develops it. I can still hope that if there was a working 
prototype of something new, then the perceived risk might seem low 
enough to get behind turning a prototype into a more comprehensive 
communications/sensemaking platform.

Another different option (for someone who wanted to wrestle with the 
Thunderbird codebase as-is) could be to add a server aspect to the 
existing Thunderbird codebase (perhaps implementing JMAP?). Then people 
could write new browser-based single-page applications in 
JavaScript/WASM while still using their existing Thunderbird installs to 
host all their email content. Then eventually just the server aspect 
would be moved forward (perhaps via completely new code as a new server) 
along with one or more single-page apps that used it. But such an 
approach would likely be limited at first -- like how do you map 
multi-user chat onto JMAP?

--Paul Fernhout (
"The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those still thinking in terms of scarcity."

More information about the tb-planning mailing list