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

Ben Bucksch ben.bucksch at beonex.com
Wed Apr 5 00:09:09 UTC 2017


Joshua Cranmer 🐧 wrote on 4/4/17 11:54 PM:
> No. The plan B is that you *don't* hold new feature development 
> hostage to rewrites.

I'm not holding anyone hostage. Why this martial terminology?

> If the rewrite succeeds, great we can use it. But if it doesn't 
> succeed, well, at least users get new features in some fashion anyways.

That's exactly what I said.

> With what manpower? Thunderbird has a critical problem: it's short of 
> manpower, and it's been short of it for half a decade.

And a gradual rewrite is at least 5x more work than a rewrite with a 
clean slate, because of thee extra burden of the old architecture, 
design, integration etc.. That in combination with the size of the 
effort and the limited resources is why I know it will fail.

OTOH, we have data on how long it takes to implement a new email client 
in JS, because it's been done before multiple times. Several teams did 
it with 3-5 developers in about 2 years. We might even be able to reuse 
existing JS components. We add on top the features that Thunderbird 
needs - that's just extra work, nothing conceptually different -, and 
we're done. The hard part is the architecture, and that's proven to 
work, by others.

> Everything else is just a multiplier on the burden that this manpower 
> shortage represents.

How did you develop JSMime? You first developed it as a standalone 
component, then integrated it in Thunderbird, didn't you? What I propose 
here would be doing the same thing. How is that a multiplier?

(skipping all the personal attacks on me)

Ben


More information about the tb-planning mailing list