Maintain old Thunderbird code base
During the time while the new rewrite is implemented, a smaller part of the staff will maintain Thunderbird, as they have done in the last 2 years. We keep up with Gecko changes, and fix smaller bugs. But we will not do major refactoring or big new features on the old codebase.
This gives users a continuously updates Thunderbird. Particularly important are security updates for security holes found in Gecko, which Thunderbird inherits. They might be exposed in HTML emails, RSS feeds or other places where Thunderbird shows HTML and renders images.
I would estimate that we need a team of 10 full time developers, for 3 years. We need 2 persons for the framework, 3 for backend modules, 4 for frontend UI, and 1 for theming.
Those who work on TB:NG need to concentrate exclusively on this project, to not be distracted.
In the first year, we are laying the foundation, getting the framework sorted out, building infrastructure etc..
After 1 year, I would expect a first demo that can read and write email, but with a very minimal feature set and many rough edges. A few enthusiastic first alpha users might be able to use it for their email needs, and some developers can use it for their daily needs.
In the second year, we would concentrate on building the important features that are needed for most users.
After 2 years, we should have an email client that's appealing to most normal users. Even some power users might like it, because we have advanced features that no other client has, but they will miss some features.
In the third year, we concentrate on feature parity to the old Thunderbird. We add any features that Thunderbird currently has and are appreciated by the existing userbase. We also add functionality that allows larger deployments, as a significant part of userbase are enterprises.
Any features that are used by significantly less than 1% of the userbase will not be implemented, in favor of other features that are desperately needed today.
After 3 years, 95% of the existing Thunderbird userbase should find the features they need in the new implementation. There will be some changes and adoptions necessary, but there should be a way to do what they need. That's what I call "feature parity".