There has been a lot of discussion about the future of Thunderbird as a result of Mitchell’s blog post and Scott’s subsequent post. I hope that presenting some additional information might help focus the discussion.
Scott and I started work on Thunderbird in the spring of 2003. With the subsequent formation of the Mozilla Foundation that summer, Thunderbird become a more focused part of the project along with Firefox. Scott was one of the first three or four Mozilla Foundation employees; I was hired as a contractor for a couple months and came on full-time in January of 2004. We have been Team Thunderbird at the Mozilla Foundation and then Corporation, ever since.
Given this small team size, we would not have been able to ship Thunderbird without a tremendous amount of work by volunteers. For example, our themes and localizations are all done by volunteers. Here are some stats about our community:
Developer Community
Very active QA and Support Communities (bugzilla, MozillaZine, etc).
Some of the discussion comments have been along the lines of “Why doesn’t Thunderbird do X, Y, and Z?” so I thought it might be helpful to talk a little about how my time was spent during the 2.0 release cycle:
Non-coding activities include things like project planning, project management, code reviews, helping contributors, helping extension writers, and supporting users. Scott’s breakdown would probably look similar, except that he spends a lot more time on project & release management fun than I do, the lucky fellow!
Given Thunderbird’s staffing level, I feel that it’s critical I allocate my time in such a way as to get the highest leverage for the project. My hope is that there’s a lot of leverage in helping contributors and extension writers, so I try to spend as much time as possible doing that. We work together with our QA volunteers and users to figure out which bugs to fix. For new features, we have to concentrate on things that have a relatively big bang for the buck, that we can do relatively quickly, and that leverage our existing infrastructure.
Opinions always vary on how time should be allocated, but I have to balance a lot of competing needs. I’m interested to hear what other folks think.
- David
Well cloning would be one answer David,
Other than that, I’m sure your time allocation is just fine.
(being a nightly tester, I see the checkin times, weekends etc.)
Hmmm, A thought just occurred to me. I’d rather be commenting here with Tbird rather than Firefox, from the RSS feed.
Just something to think about in your spare time. LOL
With the proposed split from Mozilla Corp, your time slice for the next 12 month is likely to look like that:
- non-coding activities – 90%
- bug fixing – 5%
- new features – 5%
This is indeed quite sad and this reorganization is likely to be a giant distraction on a small team that doesn’t need it.