TB council motions: Thunderbird Next Generation

Ben Bucksch ben.bucksch at beonex.com
Tue Jan 30 01:50:00 UTC 2018

As you may know, I have been working on Thunderbird since a long time. 
In my day job, I consult companies to create new software products, or 
to solve difficult problems for them. That includes the architecture, 
code design, and writing the framework of large applications. The 
combination of both backgrounds have pushed me to think long and hard 
about the future of Thunderbird, and how we can ensure that it's 
appealing to a large user base today and, more importantly, in the future.

We're living at a time where my 70+ year parents need WhatsApp to stay 
in contact with their friends, or be cut off. I want to ensure that the 
human communication is free, standards-based, open-source, 
decentralized, private, secure, and pleasant and efficient both for the 
work place and for private communication. We're losing that game, and 
there are no free contenders. Thunderbird is still one of those with the 
most users, so I think we should be proactive and approach the future, 
instead of just maintaining status quo of 15 years ago.

For that, we need bold actions into the future, and completely rewrite 
the application, both on a modern platform, given that Gecko and XPCOM 
and XUL and slowly but surely breaking away from underneath us, but also 
- possibly more importantly - with a clean code design that is malleable 
and easy to adapt to new ideas. This can be achieved with horizontal and 
vertical modularity, clean, minimal and stable APIs, and thin layers 
that can easily be replaced. I would like to first replicate most of the 
current Thunderbird functionality and its current UI, and then be able 
to quickly and easily write other, alternative UIs, and create an app 
for Android. None of that is possible with the current codebase, nor do 
I think that the current codebase can reasonably be changed to do that, 
in any way or form.

My ideas are further described on Thunderbird: Next Generation 

For that end, here are some of the motions I have presented before the 
council to get this on track.


*Thunderbird Next Generation*

= Alternatives =

Integrating new code into old Thunderbird is incredibly hard, as those 
who have actually tried it will know. The deeper you go, the harder it 
is. Case in point: It took Kent months to write JsAccount and integrate 
it into Thunderbird, while it took me hours to write my Account API in a 
fresh pure JS implementation. Hours vs. months is a drastic difference. 
... If we try to replace Thunderbird bit by bit, we will need over 10 years.

On top of that, I think that a clean code design, good high-level APIs 
and efficient code are crucial to the success of the new Thunderbird. 
Rewriting existing Thunderbird would necessarily keep most of the old 
design in place of how the modules interact. This is a part of why 
Thunderbird is so hard to get started with. I would like to attract new 
contributors to join as as well

= Motion =

Concretely, I propose the following motion for the TB Council:

 1. We will continue to maintain Thunderbird based on Gecko on the
    current level of effort, as long as it is feasible.
 2. We will create a second, parallel team that will implement a
    replacement of Thunderbird, based on JavaScript and HTML, running as
    a desktop application. We will seek funding and hire developers for
    this effort. We will first try to create a "minimum viable product"
    with a good code design and solid framework, then gradually build
    out features to match Thunderbird closer.
 3. Where feasible, the first team working on the old Thunderbird will
    backport selected components, for example a new address book, from
    the new implementation to the old Thunderbird based on Gecko.

The goal is to have an application with a clean code design, framework 
and APIs that's a joy to work on and with. One UI should imitate current 
Thunderbird in its design and workflow as much as possible, but there 
may be another mobile app UI for the young generation.


*Test balloon: Address book rewrite*

We will start a test of the technologies and code design that will be 
used for the future Thunderbird based on web technologies, by 
implementing the address book based on web technologies.

We will hire somebody to lead this effort, and work out the framework 
issues with it. Examples of issues to be solved are:

  * Which module system to use
  * How to share data between several windows
  * How the APIs between backend and frontend look like
  * Which widget toolkit to use (replacement for XUL)
  * How to translate the application

Once these questions are solved, the APIs for the address book should be 
designed, then backend (in this case: data store) and the frontend 
should be implemented.


*Thunderbird Next Generation*


  * Untangle Thunderbird from XPCOM and XUL, but base it on *JS, HTML*
    and a runtime
  * Create a UI and desktop application that looks *like current
    Thunderbird*, for existing users
  * Create *new, alternative UIs* for other kinds of devices and new
    user groups. Run on *smartphones*.
  * Create a *clear modular API*. Separation both horizontal (UI ->
    logic -> storage, or even more layers) and vertical (address book,
    mail, news, blogs, editor etc.).
  * A new extension API.


  * Removing XPCOM and XUL from Thunderbird means effectively rewriting it.
  * Thunderbird modules are so *entangled* that most modules cannot
    reasonably be replaced individually. JsMIME never replaced libmime
    due to this. If it was attempted, it would maintain the old, arcane
    API structure, which was determined by XPCOM and internal URL
    running, which do not fit a JS based application.
  * Large projects are best done with the *MVP* "minimum viable product"
    approach. Start with the smallest product that has some use (e.g.
    first only read email, then write email, then add local storage,
    etc.), and gradually gain users as you expand feature surface. 20%
    of the features gains 80% of the users. Allow users to switch to the
    new product *voluntarily*, instead of forcing the new modules on them.
  * In contrast, a rewrite module by module will require the new
    implementation to have 100% functionality of the old module,
    *before* it can be integrated and released. For a feature-rich
    application like Thunderbird with many vocal power users, this is
    highly unlikely to succeed.
  * To work on new devices, we also need new UIs. Alternative UIs for
    Thunderbird are currently impossible, because they would mean a half
    rewrite, due to the lack of code separation. A gradual rewrite would
    just perpetuate the current situation and not help us with new user


Implement TB:NG as described on 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20180130/b0defad0/attachment-0001.html>

More information about the tb-planning mailing list