Proposal to start a new implementation of Thunderbird based on web technologies
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)
More information about the tb-planning