What happened to hiring an architect?

Disaster Master disasterlistmanager at gmail.com
Tue Dec 20 19:18:03 UTC 2016


On 12/20/2016 1:48 PM, Ben Bucksch <ben.bucksch at beonex.com> wrote:
> I don't want Thunderbird to make the same fatal mistake. Slipping into
> it is one thing. Running into it consciously is just inexcusable.

I don't think anyone is 'running into it', we are simply pointing out
the reality.

> As magnus said, it's a "choice" that effectively means abandoning the
> product. I hope nobody wants that for Thunderbird.

Do you not understand that that is precisely the reason that we are
discussing this?

If we are unable to:

a) agree on a path forward, and
b) muster the man hours to accomplish the goal

then we will be *forced* into a choice of *fork or die*.

You say that forking Gecko would 'kill Thunderbird'.

I say that, eventually, if things don't change, *not* forking Gecko will
kill Thunderbird.

This will happen the day that Thunderbird refuses to build - or the
builds refuse to run - because of the loss of the critical Gecko
components (XUL/XBL/XPCOM). *This* is the day Thunderbird really, truly
and actually *dies* - well, rather, it *begins* to die. Obviously it
won't happen overnight. There is nothing preventing me from continuing
to use the last working version, and I could do so for many years.

At that point, if both options a and b above have not been achieved,
then forking Gecko, while highly undesirable, is the *only* option
available, if we want to have any more working versions of Thunderbird
past that point.

> Please stop posting "fork gecko" as choice. It's a straw man. It's the
> "kill thunderbird" choice.

Actually, it may be the *only* option to keep it *alive* (albeit on life
support).

> (And kill its users at the same time, because they'll get hacked by
> worms and loose control over their computer.

Or we simply start disabling HTML features that said malware/worms rely
on (ie loading/executing remote content, etc), with an option to
re-enable it via about:config (complete with all the necessary
warnings), unless/until we get the core components rewritten.

But, the bottom line is, even current versions of email clients are
vulnerable, because the primary vector are and always have been *users*.
We could even take such a bad situation and make some lemonade - ie,
start educating users about how to stay safe online.

Maybe even get with the KnowBe4 people, and create a general
'Thunderbird' account with them, and let users take advantage of their
training as part of their donation/fee (maybe make it a perk for a
certain level of recurring donation or something).

> Why am i insisting on this, you asked? We might not have another
> choice, you said? 
>
> I'm saying: we need to accept that fact that foregoing gecko is not an
> option. Unmarrying thunderbird doesn't work either.

You left out the other option - rewrite the parts of Thunderbird that
rely on the deprecated Gecko components.

I honestly want to know why you seem to think that would be impossible -
or even harder than writing an email client from scratch that has
reasonable UI and feature parity with current Thunderbird.

> So, that leaves only one choice: Write a new client. Yes, that will
> take 1-3 years.

Really. You believe we can have a reasonably close facsimile of current
Thunderbird, with the resources we currently have, in 3 to 5 years.

Kent said it would be more like 30 man-years. He seems to have a
reasonably good grasp of what it would take, so I think it isn't asking
too much to see some reasoning to back your claim of only 1 to 3 years,
because I just don't see that as being even *remotely* possible.

> That's why we need to start now. Once gecko is not usable by
> thunderbird anymore, it will be to late to start. It will be game
> over. Accept that, and act accordingly. That's my point.

I understand your point, I simply don't think it is valid.

I'd like to see Kent respond to this though. His opinion here is much
more valuable than mine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161220/aa11768c/attachment-0001.html>


More information about the tb-planning mailing list