Mozilla no longer developing Thunderbird
mbanner at mozilla.com
Sun Jul 8 15:08:07 UTC 2012
On 07/07/2012 22:34, Eric Moore wrote:
>> Yesterday Mitchell Baker posted on the future of Thunderbird:
> 1. "Support will continue to be provided by the Thunderbird community
> and Mozilla will continue to provide the required infrastructure."
> Is the official support forum part of the required infrastructure? The
> proposal should include a overview of the required infrastructure, and
> what is being explicitly dropped.
No infrastructure will be dropped.
> The proposal doesn't address several issues such as who will maintain
> the ISP database
The ISP database has at least one community member already doing reviews
for new entries, I believe the reviews can be done by almost anyone with
a knowledge of the APIs, but I'm sure Ben can correct me if I'm wrong.
For the server part of the ISP database, that's within Mozilla. If the
GSoC student completes the work on the new ISPDB application, then that
could be hosted somewhere and the ISP database run from there.
> 2. "At the same time, Thunderbird will be released with the same
> feature set as Thunderbird ESR and will be updated every six-weeks for
> security and stability."
> Does that include updating Thunderbird to use the latest version of
> I don't see the need for security patches every six weeks for a email
> client. People can still safely use 126.96.36.199 if they apply common sense.
I'd challenge that assertion. When new releases come out, the details of
the possible security exploits are known. It is very common to hear of
hack kits including those exploits as then they can catch older users
who haven't updated. Whilst we don't hear of many attacks on email at
the moment, users of anything that isn't current are at significant risk
if a hacker decides to target them. Whilst there may be safer practices,
that doesn't protect against every eventuality.
> 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.
I think you're basing this argument on the assumption that we'll update
gecko every 6 weeks, as that isn't true, then I don't think this is a
> 3. ...
> 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.
"Most" may be currently true, although we are in the middle of a
revision to bring that more up to date. We are open (and always have
been) to welcome contributors stepping up to ownership roles, although
obviously as you indicate there would be a ramp-up time for that to happen.
I would say though, that removing the existing owners without
replacements that have the experience would actually put the project in
a worse place as it would remove that experience of people that are
still willing to help.
> 4. 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.
Most of the features that are in progress should be incorporated before
the new model, although obviously at this stage, we won't know the full
> 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.
I believe there won't be a significant amount of change for SeaMonkey,
though there may be some, and they are in a better position to assess it
as we progress through the detail.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning