Thunderbird Architecture Analysis SOW

R Kent James kent at caspia.com
Tue Mar 22 17:38:13 UTC 2016


I have not been able to give this any attention as I was focused on the
code for the Thunderbird 45 release, but with my work on that mostly
done, let me respond to this initiative.

First, there are a few known possible solutions to the issues being
raised in this analysis. The SOW would be stronger if these are
specified, while at the same time leaving open the possibility that
there might be other possibilities of which we are unaware.

I would call out each of the following solutions as specifically
deserving an answer in the SOW (I don't really even know if all of these
are feasible):

1.    Continue to mirror the approaches taken in Firefox, adapting
Thunderbird to changes as they occur. This is the existing approach
which will lead us into Rust and deprecated XUL eventually per current
FF plans.

2.    Fork the Gecko repos in some manner, and maintain Thunderbird as a
partly C++ XUL project.

3.    Convert Thunderbird entirely to HTML & Javascript, and run in a
Firefox-derived container of some sort (like a FirefoxOS or BTG app, or
wherever Firefox-based JS/HTML client apps are going).

4.    Convert Thunderbird to an Electron-based app.

5.    Convert Thunderbird to run under the TDF/LibreOffice platform.

6.    Convert to some other multi-platform client environment
(.NET/Mono? QT?)

Second, there needs to be some understanding of the scope of the changes
in functionality that we are talking about. The document mentions
technical debt and missing features, but I don't think that is really
the question here. The question is how do we maintain the bulk of the
existing feature set, essential security updates, and application
support infrastructure such as updates and addons, along with capacity
to adapt and improve. That might include some essential technology
changes (like nobody would reasonably try to adapt Mork to JS) but not
an attempt to solve all known issues, or add a laundry list of missing
features.

Third, in the SOW you specify some of the challenges, but you don't give
many details of the questions that you would like answered. You simply
ask for "options available (with pros and cons) for how the Thunderbird
community can tackle these issues" which could be interpreted in many
possible ways. The document needs to address for example whether we are
looking for some sort of required resource estimate, or more of a
business statement of whether Thunderbird tries to remain
volunteer-driven or become partially commercial.

I think that we are looking for more of a resource estimate, along with
technical risk assessments for each direction. That needs to be done
under the constraint of the likely availability of resources. So here's
one recommendation. For each of the possible approaches identified, give
the following estimates as probability of success (or total resource
required if the probability is zero):

1.    Initial adaptation of the application to the target environment
using volunteers plus a) no paid developers, b) two person-years of paid
developers, and c) ten person-years of paid developers.

2.    Ongoing maintenance of the application in the target environment
using volunteers plus a) no paid developers, b) a half-time paid
developer, c) two FTE of paid developers.

Fourth, there is a clear tradeoff here between the present and future
that needs to be addressed in the report. The path that we are currently
on is to "mirror Firefox" as long as is feasible, eventually
transitioning to "fork Gecko to maintain XUL". That requires the least
commitment of resources in the short-run, or change to our existing
practices, but also results in the eventual demise of the project as we
are unable to reasonably maintain and improve our own run-time
environment except for a limited amount of time. Any of the other
options will require a significant injection of resources to accomplish
the initial transition, that is only justified if there is the
expectation that eventually a vibrant long-term project results. From
this perspective, the main point of this report is to evaluate the cost
and likelihood of success of various alternate technical paths that
might be available to us, and to estimate the long-term viability of
these alternate paths as platforms for a much-improved, vibrant
Thunderbird product. So for example if "Convert Thunderbird to an
Electron-based app" is a recommended path, then the report needs to make
clear both what the short-term resource cost of this transition is
likely to be, and why this path is more likely to result in a vibrant
future for Thunderbird than "follow FF then fork Gecko". Given a clear
set of short-term costs and long-term benefits to potential technical
paths from the report, we will then as a project evaluate whether we
have any reasonable prospects of acquiring those resources, or what
changes to our practices are needed to attract those resources.

R Kent James



More information about the tb-planning mailing list