112
edits
No edit summary |
No edit summary |
||
Line 38: | Line 38: | ||
I was more thinking of some clear two-way communication so that contributors on either product are well aware about potential to avoid code duplication, etc. In particular, I might think that there be some form of "gaia email update" on the TB status meetings and v.v. just so people are well aware. | I was more thinking of some clear two-way communication so that contributors on either product are well aware about potential to avoid code duplication, etc. In particular, I might think that there be some form of "gaia email update" on the TB status meetings and v.v. just so people are well aware. | ||
It also struck me that I forgot to mention that having a Thunderbird<->Gaia email sync ought to be a major goal. | It also struck me that I forgot to mention that having a Thunderbird<->Gaia email sync ought to be a major goal. | ||
eric Moore | |||
The proposal doesn't address several issues such as who will maintain the ISP database, and what happens to account provisioning (is anybody left authorized to sign contracts with new email providers?). | |||
I don't see the need for security patches every six weeks for a email client. People can still safely use 2.0.0.24 if they apply common sense. The security advisories seem to deliberately inflate the impact of potential problems. I'd argue that a new release every 6 weeks actually contributes to stability problems, especially if there is no longer a QA lead. | |||
SeaMonkey is a community effort hosted by and under the legal protection of the Mozilla Foundation, with the SeaMonkey Council providing the project leadership. SeaMonkey would seem a better model than maintaining the status quo with a fraction of the existing resources. | |||
Most of the Thunderbird module owners seem to be Mozilla employees. Its not clear why that would change anytime soon. I'm worried that the project will continue to pay the political cost of being a Mozilla project (many decisions dictated by what Firefox does or Mozilla's roadmaps) while losing most of its resources. That doesn't seem viable. | |||
It would help if a few features developed over a long time that are near completion such as maildir support were finished and there was some sort of explicit exit criteria to have a smooth handoff rather than development ending as soon as a new governance model was established. That doesn't necessarily require more investment by Mozilla, it might be done by prioritizing what needs to get done before the transition. | |||
https://wiki.mozilla.org/Features/Thunderbird | |||
It wouldn't hurt to evaluate removing some half-way finished implementations (such as anti-phishing, which most people disable) that will probably never be finished due to lack of interest in order to make Thunderbird a little easier to maintain. | |||
5. The proposal doesn't mention the impact on SeaMonkey. My impression is they leverage bug fixes and new features developed by Mozilla for Thunderbird, and this means they are going to have to divert some of their limited resources. Some volunteers such as rsx11m seem to work on both projects. Perhaps there needs to be some more explicit coordination to help deal with the common lack of resources. | |||
6. "We have come to the conclusion that continued innovation on Thunderbird is not a priority for Mozilla and that the most critical needs for the product are on-going security and stability. In fact, it is quite possible that Thunderbird is already pretty much what its users want and there is not a high demand for innovation in this field. " | |||
Users want a product that is under active development and has a future, even if they don't really care about the new features or get annoyed by some of the changes. I suspect many users will interpret the re-focusing of efforts as Mozilla abandoning Thunderbird, and will look for alternative email clients since they don't perceive the community as providing enough development. I think there would have been a much better reaction if Mozilla had announced they were reducing staffing levels (there were only two full time employees for a good while) but would continue new development at a slower pace. |
edits