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.
>> 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.
All of which is why we're starting MailCo, recruiting full-time devs as well as encouraging volunteer contributors, hiring a build engineer, promoting test suite development, etc.
Joe - don't hesitate to let me know of specific bugs which need attention, and I'll see what I can do about raising their profile. I know for a fact that Myk cares a lot about Thunderbird, and I'm sure that he respects it plenty =).
David Ascher wrote: > * Release-defining features: > - an integrated calendaring feature, based on Lightning > - a better search experience, especially for message content searches > - a better overall user experience
I would add RSS to this list of features:
1. Thunderbird has a very basic RSS support, but it is barely usable due to numerous usability issues (if there were only a few, I would have created issues in Bugzilla).
2. Thunderbird already wraps together an e-mail client and an NNTP client. Although some prefer to read RSS feeds in their browser, many others (including me) think that reading RSS feeds is an activity which closely resembles reading NNTP newsgroups.
3. The basic infrastructure for an excellent RSS reader is already present in Thunderbird (HTML viewer, search folders, proxy options, etc...).
4. An excellent RSS reader would also increase the user base, which is a goal of Thunderbird 3.
Hence, I think that with a reasonable effort Thunderbird could become a great RSS reader.
> 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
My company almost decide to use Exchange. So if we want to have calendar built-in, then maybe there should support for Exchange features. Or at least it should be possible to make extension which provide needed functionality.
> * 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
These sound like fine goals to me.
> * 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
While this sounds great in theory, it has some pretty drastic implications for Calendar development, which one should be aware of.
| Note: I speak only for myself and from my own experience here. The | only person who can speak with authority about the Calendar | project is Daniel Boelzle, our lead developer.
Currently Calendar development happens exclusively on the 1.8 branch to enable us to fully support TB2. All changes are cross-committed to the trunk as well, but due to API and other architectural changes there exist several pretty serious regressions on the trunk that we know about.
There are probably even more regressions which we don't know about, because we've told our testers to focus their testing on the 1.8 branch and only a few are testing trunk builds once in a while.
I'm not a software engineer, but I would expect that it would take us at least a month to play catchup on the trunk and fix the outstanding regressions. This would of course mean that our planned feature implementations for 0.9 and 1.0 would have to be postponed for said month.
In addition it would increase the work for developers and reviewers, who right now are not obliged to test their code on the trunk. It would also mean that we need more manpower in the testing community, but I'm not very concerned about that, since the inclusion into TB3 nightlies would probably result in a QA manpower increase.
> * 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.
We'll have to think long and hard about what we'll do with Sunbird. We'll also have to think whether we want to support SeaMonkey and how much we want to support it, given that those guys will most likely release alpha or beta releases of SM2 during that timeframe as well.
David Ascher wrote: > I'm certainly interested in figuring out the various "enterprise" requirements.
Full Exchange support would be nice :-)
More seriously, I think that one single feature would greatly help the use of Thunderbird in Exchange-based companies: the ability to *answer* to meeting requests (currently, Thunderbird simply *displays* meeting requests).
>> I'm certainly interested in figuring out the various "enterprise" >> requirements.
> Full Exchange support would be nice :-)
> More seriously, I think that one single feature would greatly help the > use of Thunderbird in Exchange-based companies: the ability to *answer* > to meeting requests (currently, Thunderbird simply *displays* meeting > requests).
This is already possible if you install the Lightning extension.
Simon Paquet wrote: >> More seriously, I think that one single feature would greatly help the >> use of Thunderbird in Exchange-based companies: the ability to >> *answer* to meeting requests (currently, Thunderbird simply *displays* >> meeting requests).
> This is already possible if you install the Lightning extension.
Ooops, you're right, Lightning now supports it. However, the message it sends back to the meeting requester is a simple text message, no a (proprietary) Exchange acknowledgment. Hence, the meeting request in the requester's calendar will not be updated, and the requester will notice that I am a "second class citizen" in term of Exchange integration.
Anyway, Lightning is getting better, congratulations!
Pascal Sartoretti wrote: > 1. Thunderbird has a very basic RSS support, but it is barely usable due > to numerous usability issues (if there were only a few, I would have > created issues in Bugzilla).
You should still file bugs, no matter how many or how big the issues are.
Simon Paquet wrote: > Currently Calendar development happens exclusively on the 1.8 branch > to enable us to fully support TB2. All changes are cross-committed > to the trunk as well, but due to API and other architectural changes > there exist several pretty serious regressions on the trunk that we > know about.
Maybe the time is arriving where that cross-commit policy needs to be lifted (I know, that's also a question of manpower).
> We'll have to think long and hard about what we'll do with Sunbird.
True. Unfortunately the case is not as simple as with e.g. ChatZilla here, which is able to run both as an extension and as a XULRunner app with practically the same code - Lightning not being run in its own window complicates things there.
> We'll also have to think whether we want to support SeaMonkey and how > much we want to support it, given that those guys will most likely > release alpha or beta releases of SM2 during that timeframe as well.
Yes, SeaMonkey surely will do Alphas and Betas, hopefully even a final release of SeaMonkey 2 in that timeframe. We do not plan to ship with Lightning in this cycle (yet), but it would be nice if we get it to run in SeaMonkey, part of which can be achieved through making SeaMonkey MailNews more similar to Thunderbird, but other parts might need some patches in Lightning as well.
On Mon, 28 Jan 2008 14:53:49 -0800, David Ascher wrote:
David,
Thanks for sharing the planning. Imho it's a good starting point for discussion.
Personally I think the points you mention are very good. There are also some other points I hear from users around me that would help user adoption, such as:
- Corporate users:
1. Sync the calendar with Exchange, without needing Outlook. Use OWA or a provider to sync with the Exchange calendar;
2. Ease the install and maintainability of the software. Installing updates is a pain, and sometimes users manage to download an update and are unable to apply it, after which it sticks in their profile until someone pinches it out with a needle;
- Home users: Integration with e.g. the Windows Address Book (read and write), Gmail IMAP (including the Google recommended changes to the Thunderbird settings for cache and attachment fetching, saving sent messages etc.)
What I would also appreciate is more external address book functionality - store it on Mozilla servers (Weave?), LDAP server support including ldap-write, Google account address book or something like that, so users with multiple accounts can sync their address book and share it with their family.
The most important one would be Exchange calendar sync. If that cannot be done very soon it might still be worthwhile to _mention_ it so people know that it's on the radar.
>> Currently Calendar development happens exclusively on the 1.8 >> branch to enable us to fully support TB2. All changes are >> cross-committed to the trunk as well, but due to API and other >> architectural changes there exist several pretty serious >> regressions on the trunk that we know about.
> Maybe the time is arriving where that cross-commit policy needs > to be lifted (I know, that's also a question of manpower).
I don't understand this. What do you mean with lift the cross-commit policy of mozilla/calendar?
We can't just switch to the trunk. We have a few hundred thousand users on TB2 and we can't just let them hang out in the open while TB3 is still in alpha, beta or RC stage.
So at least until Lightning 1.0 is released (probably even longer) we will stay on the branch or at least commit a major part of our development resources there.
Robert Kaiser wrote: > You should still file bugs, no matter how many or how big the issues are.
Here is what I think about RSS support in Thunderbird: the whole configuration UI is a mess, I am confused between what is a feed, a subscription, a location and a folder (from a user point of view, they are pretty much all the same...).
I don't know how to express this in a constructive way in Bugzilla :-)
On the other hand, the UI for reading RSS is ok.
Just a question to Thunderbird users: who also uses it for RSS?
> Thanks for sharing the planning. Imho it's a good starting point for > discussion.
> Personally I think the points you mention are very good. There are > also some other points I hear from users around me that would help > user adoption, such as:
> - Corporate users:
> 1. Sync the calendar with Exchange, without needing Outlook. Use OWA > or a provider to sync with the Exchange calendar;
Exchange support would be great to have of course, but it is absolutely impossible to achieve this in the TB3 timeframe that David proposed.
In addition the only viable open source solution that could be used to quickly add Exchange support to Thunderbird and Lightning (libmapi) can not be used because of license imcompatibilities (libmapi uses GPLv3, while we use the MPL/LGPL/GPL tri-license).
Unless the libmapi developers change their license, we would have to implement this stuff from scratch, which would probably take at least 1-2 years to reach a "basic support"-milestone.
