Proposal to start a new implementation of Thunderbird based on web technologies

[Joshua Cranmer 🐧]

There's been a lot of discussion about this proposal, and I think some 
people have modified their opinions or clarified them in ways that 
aren't necessarily collected in one place. I think we can come to a 
better agreement if we go back and start our positions more clearly.

For my part, I have one non-negotiable requirement: we should be able to 
ship CardDAV support to our users by 2018. Beyond that, I think there 
should be means to implement new features in TB in a more rapid basis 
"if prudent" (and I'm leaving it vague on what exact criteria that entails).

To that end, here are some suggestions to the proposal:
1. Delete the requirement that feature development in Thunderbird is 
unfunded. It's okay to leave it vague which features would be 
implemented sooner--the only two that really come to my mind are CardDAV 
and EAI. Beyond that, I don't think that there are many features which 
are urgent to implement (e.g., JMAP would be nice, but no one's really 
clamoring for it).
2. Make it clear that being able to transfer features to Thunderbird is 
a priority. i.e., you'd rather a 100% complete address book and 50% 
complete IMAP than 80% of both. This also means that whatever platform 
support library you have would include support for 
xpcshell/xpconnect/whatever else is being used by Gecko as a base layer.

I realize this is something you're likely to disagree with, but I 
suspect the disagreement is more over perception than fundamental 
semantics. I believe that it would be fairly easy to replace the address 
book, import, mime, and compose code; that replacing the search and 
protocol implementations are probably doable (with SMTP being easiest 
and IMAP hardest); that replacing the database is challenging, but 
possible if you look to only implement a well-defined new DB API that 
coexists with the old one but doesn't eliminate it; and that replacing 
the account implementations and associated frontend bits (e.g., 
nsMsgDBView) is probably so difficult it's not worth attempting. 
Accordingly, to me, there seems to me to be little reason not to throw 
some people at porting over the first few bits rapidly.

3. This may be controversial, but I suspect it's less controversial than 
it seems. Paid support, if necessary, would be available to do the 
porting of bits to Thunderbird. I'm sure we disagree on where the line 
should be drawn, but I'm not proposing that everything would be 
considered a viable candidate (i.e., I'm fine with you objecting to 
having to port nsMsgDBView-replacement), and I suspect you're open to 
letting mostly standalone stuff get done (e.g., the address book). So 
I'm happy if we can both agree that a line should be drawn, it should be 
drawn somewhere in the middle, and we can agree to defer the discussion 
of where it should be drawn until an actual relevant case comes up. The 
question of who is paid to do so is also something that I'm fine with a 
fuzzy answer.

Beyond that, I think the crux of the issue is in the manner of a pitch. 
Most users aren't going to notice backend changes at all unless it 
impacts them, but front-end changes tend to engender a lot of 
complaints. I've mentioned several times the Servo model, and if that's 
essentially what you're proposing, I don't have problems with it. That 
model (to me, at least) is that you use an entirely different product to 
develop all of the backend pieces which you can then reintegrate into 
Thunderbird as they become feasible replacements--and in terms of pitch, 
you don't describe it as being the replacement for Thunderbird. It's 
also clear that, unlike Firefox, the UI of Thunderbird cannot be easily 
decoupled from its backend, and as to how to deal with that... I have no 
opinion; I'm a backend guy through-and-through.

I would also suggest an effective mandate that developers on the new 
project should be sensitive to disruption to Thunderbird UI (if the 
intent is to replace the UI of Thunderbird with new UI). As well, they 
should also have explicit mandates to have better testing infrastructure 
and documentation than Thunderbird has traditionally maintained, 
including performance tests (as a rough baseline, the question should be 
"how well do we perform on a 1M message folder?"--and yes, I'm aware 
that Thunderbird doesn't look good on that regard right now). I also 
think that the testing infrastructure should be shared with TB as much 
as practicable--e.g., sharing the same datasets for performance tests.

How does that sound?

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist