It's time to define the Thunderbird 3 plan. I've spent a fair bit of time learning about the state of affairs and talking to many people, and I feel I've accumulated enough information to start this process.
Note: I'm cross-posting this to the planning, calendar and thunderbird newsgroups, but expect discussion on the thunderbird newsgroup and have set followup-to accordingly. There will be a summary post in the planning newsgroup if the final plan differs significantly from the one outlined here.
The long-term roadmap of Thunderbird is still in flux, but there are four high-level points which drive my thinking about Thunderbird 3:
1. Thunderbird's impact is proportional to its user count. Thus driving adoption is my primary concern. Our current user base is very significant (many millions of mostly quite satisfied users), but the number of possible users of Thunderbird is orders of magnitude greater than our current reach.
2. The reasons why people don't choose to use Thunderbird are varied, but two primary reasons appear to be: the lack of a built-in calendar integration (compared to Outlook for example), or a search experience that doesn't match that offered by competitors (gmail and Mail.app for example).
3. In addition, Thunderbird's codebase has a fair bit of technical debt due to insufficient resourcing over the years, which has led to a codebase which has too many scary bits, not enough test coverage, and isn't yet able to leverage the ongoing platform improvements. In addition, while communications clients are by nature great targets for extension authors, the current codebase isn't extension-friendly enough, making it too hard to build installation-specific features or experiment with new feature ideas.
4. A fair number of Thunderbird changes have already landed on trunk, including some important bug fixes, by a variety of contributors. There's appropriate pressure to ship an update to Thunderbird 2 to take advantage of those and of the platform improvements.
With all that as background, I propose:
* Goal: to have at public milestone build of Thunderbird 3 in 2008. Thunderbird 3's overall aim is to significantly grow its user base worldwide, as well as build a strong foundation for later Thunderbird releases.
* Release-defining features: - an integrated calendaring feature, based on Lightning - a better search experience, especially for message content searches - a better overall user experience
* Less user-visible but important goals include: - Significant headway on getting rid of Mork and RDF - A concerted effort to improving the extensions ecosystem for Thunderbird, including refactorings, FUEL, developer documentation, and user experience - Better test coverage and performance metrics in place to support refactoring goals
There will be of course lots of other bug fixes and enhancements (patches welcome ;-))
* Schedule: Figuring out the schedule at this stage is hard, as it will depend on who shows up with energy and talent. I would like to set some placeholder milestones for discussion, however:
- alpha builds in Q1 - beta builds without calendaring starting in Q2 - beta builds with calendaring starting in Q3 - widely useful builds by Q4 (although whether they're branded "release" will depend on quality, as always).
We're revise the schedule as we gain knowledge.
* Thunderbird 3 work will happen on trunk, with branching strategy to be figured out closer to the endgame (and reviewed next when 1.9 is cut),
* The Mailnews/Thunderbird folks and the Calendar folks will have to figure out how to best allocate dev and testing effort on the calendaring features, how we support Sunbird, etc.
Given the scope of the work, the aggressive schedule, and the amount of new feature develoment, integration and stabilization work involved, help of all kinds is more than welcome! Thanks in advance for any input you may have, either on process or on deliverables.
The central wiki page for Thunderbird 3 is http://wiki.mozilla.org/Thunderbird:Thunderbird3. IRC discussion will take place in #maildev. The newsgroup/mailing list of record for Tb3 is mozilla.dev.apps.thunderbird.
This plan looks to me overall as modest and doable, with the right set of priorities to prepare for future and bolder goals and aims. Perhaps the time line could be squeezed a little bit in order to have a release in 2008, considering that Lightning has improved quite a bit lately. However the plan looks realistic and serious to me.
David Ascher wrote: > It's time to define the Thunderbird 3 plan. I've spent a fair bit of > time learning about the state of affairs and talking to many people, and > I feel I've accumulated enough information to start this process.
> Note: I'm cross-posting this to the planning, calendar and thunderbird > newsgroups, but expect discussion on the thunderbird newsgroup and have > set followup-to accordingly. There will be a summary post in the > planning newsgroup if the final plan differs significantly from the one > outlined here.
> The long-term roadmap of Thunderbird is still in flux, but there are > four high-level points which drive my thinking about Thunderbird 3:
> 1. Thunderbird's impact is proportional to its user count. Thus driving > adoption is my primary concern. Our current user base is very > significant (many millions of mostly quite satisfied users), but the > number of possible users of Thunderbird is orders of magnitude greater > than our current reach.
> 2. The reasons why people don't choose to use Thunderbird are varied, > but two primary reasons appear to be: the lack of a built-in calendar > integration (compared to Outlook for example), or a search experience > that doesn't match that offered by competitors (gmail and Mail.app for > example).
> 3. In addition, Thunderbird's codebase has a fair bit of technical debt > due to insufficient resourcing over the years, which has led to a > codebase which has too many scary bits, not enough test coverage, and > isn't yet able to leverage the ongoing platform improvements. In > addition, while communications clients are by nature great targets for > extension authors, the current codebase isn't extension-friendly enough, > making it too hard to build installation-specific features or experiment > with new feature ideas.
> 4. A fair number of Thunderbird changes have already landed on trunk, > including some important bug fixes, by a variety of contributors. > There's appropriate pressure to ship an update to Thunderbird 2 to take > advantage of those and of the platform improvements.
> With all that as background, I propose:
> * Goal: to have at public milestone build of Thunderbird 3 in 2008. > Thunderbird 3's overall aim is to significantly grow its user base > worldwide, as well as build a strong foundation for later Thunderbird > releases.
> * Release-defining features: > - an integrated calendaring feature, based on Lightning > - a better search experience, especially for message content searches > - a better overall user experience
> * Less user-visible but important goals include: > - Significant headway on getting rid of Mork and RDF > - A concerted effort to improving the extensions ecosystem for > Thunderbird, including refactorings, FUEL, developer documentation, and > user experience > - Better test coverage and performance metrics in place to support > refactoring goals
> There will be of course lots of other bug fixes and enhancements > (patches welcome ;-))
> * Schedule: Figuring out the schedule at this stage is hard, as it will > depend on who shows up with energy and talent. I would like to set some > placeholder milestones for discussion, however:
> - alpha builds in Q1 > - beta builds without calendaring starting in Q2 > - beta builds with calendaring starting in Q3 > - widely useful builds by Q4 (although whether they're branded > "release" will depend on quality, as always).
> We're revise the schedule as we gain knowledge.
> * Thunderbird 3 work will happen on trunk, with branching strategy to be > figured out closer to the endgame (and reviewed next when 1.9 is cut),
> * The Mailnews/Thunderbird folks and the Calendar folks will have to > figure out how to best allocate dev and testing effort on the > calendaring features, how we support Sunbird, etc.
> Given the scope of the work, the aggressive schedule, and the amount of > new feature develoment, integration and stabilization work involved, > help of all kinds is more than welcome! Thanks in advance for any input > you may have, either on process or on deliverables.
> The central wiki page for Thunderbird 3 is > http://wiki.mozilla.org/Thunderbird:Thunderbird3. IRC discussion will > take place in #maildev. The newsgroup/mailing list of record for Tb3 is > mozilla.dev.apps.thunderbird.
David Ascher wrote: > With all that as background, I propose:
> * Goal: to have at public milestone build of Thunderbird 3 in 2008. > Thunderbird 3's overall aim is to significantly grow its user base > worldwide, as well as build a strong foundation for later Thunderbird > releases.
> * Release-defining features: > - an integrated calendaring feature, based on Lightning > - a better search experience, especially for message content searches > - a better overall user experience
> * Less user-visible but important goals include: > - Significant headway on getting rid of Mork and RDF > - A concerted effort to improving the extensions ecosystem for > Thunderbird, including refactorings, FUEL, developer documentation, and > user experience > - Better test coverage and performance metrics in place to support > refactoring goals
> There will be of course lots of other bug fixes and enhancements > (patches welcome ;-))
This may also be cool: * Improved administrator experience: - MSI; - Group Policy Options.
There is a thread 'Firefox for Corporations' in m.d.platform, which fully applies to Thunderbird. Please check bug 231062 for MSI patches :)
> - alpha builds in Q1 > - beta builds without calendaring starting in Q2 > - beta builds with calendaring starting in Q3 > - widely useful builds by Q4 (although whether they're branded "release" > will depend on quality, as always).
That will also depend on the timeframe that Calendar hits 1.0, though I think it's projected for 2008 as well.
I'm of the opinion that the first beta should have already included Lightning if it's one of the main pillars of the Thunderbird 3 release. What's the point of calling it a beta when one of the main backbone features is not present?
I am leaning towards the possibility of including Lightning 0.9 in an Alpha / Beta 1 build, as a form of "dress rehearsal" for 1.0.
> * The Mailnews/Thunderbird folks and the Calendar folks will have to > figure out how to best allocate dev and testing effort on the > calendaring features, how we support Sunbird, etc.
There's substantial code that overlaps with Lightning, and also there's code that doesn't. If 100% of Lightning's tested to work fine, chances are that 60%++ of Sunbird already works well, the other 40% being non-overlapping stuff. (something to keep in mind for QA)
Sergey Yanovich wrote: > This may also be cool: > * Improved administrator experience: > - MSI; > - Group Policy Options.
> There is a thread 'Firefox for Corporations' in m.d.platform, which > fully applies to Thunderbird. Please check bug 231062 for MSI patches :
Thanks for the note. I'm certainly interested in figuring out the various "enterprise" requirements. In addition to MSI and Group Policy issues, there are update management issues, as well as UI-limiting ideas like those outlined in bug 414301.
We should discuss this on the community-enterprise list, however -- I'm still trying to figure out how many sub-communities there are trying to tackle organizational deployments of Thunderbird, and which of the requirements are highest priority.
David Ascher wrote: > It's time to define the Thunderbird 3 plan. I've spent a fair bit of > time learning about the state of affairs and talking to many people, and > I feel I've accumulated enough information to start this process.
To me this looks like a great plan, appropriately scoped but with real and significant progress and promise for Thunderbird futures. I second Eddy's desire for a final release this year, but my reading of your proposal is that it plans for exactly that outcome, just with a bit of hedging given the difficulty of making that prediction and the desire for a quality- rather than merely date-driven release.
>> It's time to define the Thunderbird 3 plan. I've spent a fair bit of >> time learning about the state of affairs and talking to many people, and >> I feel I've accumulated enough information to start this process.
> To me this looks like a great plan, appropriately scoped but with real > and significant progress and promise for Thunderbird futures. I second > Eddy's desire for a final release this year, but my reading of your > proposal is that it plans for exactly that outcome, just with a bit of > hedging given the difficulty of making that prediction and the desire > for a quality- rather than merely date-driven release.
Gee, I'm that transparent. ;-)
I'm very keen to see a public release in 2008. But it's a foolish dev manager who sets scope and schedule with absolutely no visibility on available resources =)
While adding people to a late project makes it later, having too few hands on keyboards makes it hard to produce good releases -- there's a careful balance to be found.
My plan is to focus on getting as many bright people interested in working on it as soon as possible, and with enough planning, enthusiasm, luck, and the right discipline regarding scope creep, we may just get there...
Myk Melez wrote: > David Ascher wrote: >> It's time to define the Thunderbird 3 plan. I've spent a fair bit of >> time learning about the state of affairs and talking to many people, >> and I feel I've accumulated enough information to start this process.
> To me this looks like a great plan, appropriately scoped but with real > and significant progress and promise for Thunderbird futures. I second > Eddy's desire for a final release this year, but my reading of your > proposal is that it plans for exactly that outcome, just with a bit of > hedging given the difficulty of making that prediction and the desire > for a quality- rather than merely date-driven release.
> -myk
Ah.. regarding quality, might we address the issue of core code changes that affect apps like thunderbird. Since https://bugzilla.mozilla.org/show_bug.cgi?id=385740 which was a great change for Firefox myk, the trunk for Tbird was severely impacted. If you save an action, as far as opening a link or calling a helper app, there is absolutely no way to edit that pref. Apart from saving your mimeTypes.rdf (or a null version of same) you are stuck with your decision. These things are constantly cropping up, some serious, some not. https://bugzilla.mozilla.org/show_bug.cgi?id=413200 has lingered now for a week or so.
JoeS wrote: > Since https://bugzilla.mozilla.org/show_bug.cgi?id=385740 which was a > great change for Firefox myk, the trunk > for Tbird was severely impacted. If you save an action, as far as > opening a link or calling a helper app, there > is absolutely no way to edit that pref. Apart from saving your > mimeTypes.rdf (or a null version of same) you are > stuck with your decision.
Sorry, I wasn't aware of this regression. It does sound like a problem. I'll follow up in the bug.
> Well, a bug with so much activity in one week...I wouldn't call that > "lingering" ;-) I guess your expectations are quite high...
That's just a minor bug, but my point is that core bugs that break Tbird don't seem to get the attention that they deserve. I'll just call that "Firefox centric" development. If we are going to get more nightly testers involved, which I think is really necessary for the advancement of 3.0 we deserve a little respect (as does tbird itself) The trunk has been busted for periods of several weeks in the past due to core problems. Not a good incentive for testing.
