Thunderbird Architecture Analysis SOW
gerv at mozilla.org
Tue Mar 22 17:49:21 UTC 2016
On 22/03/16 17:38, R Kent James wrote:
> 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 certainly hope and expect that one of the first tasks of the person
when assessing both problems and potential solutions would be to talk to
community members and get opinions (and strong ones) on the challenges
and possible solutions such as the ones you lay out here. But both for
reasons of space in the advert, and for reasons of not over-constraining
the solution space too early, I am reluctant to be too specific in the
> 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.
This is a reasonable point.
> I think that we are looking for more of a resource estimate, along with
> technical risk assessments for each direction.
I think you are right; it will clearly be an interactive process, but I
would expect the 'business' guidance on Thunderbird's preferred
direction to come from the Council, and the architect to advise on how
best to move that way.
How can we make this more clear in the text, do you think?
I don't think, however, that the architect need be to concerned about
where the resources come from - FTEs employed by Thunderbird Developers
Inc., volunteers, or something in between.
> 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.
Yep, I agree with all that too, and would appreciate concrete text
suggestions if you think the current SOW does not allow for this.
More information about the tb-planning