What happened to hiring an architect?
R Kent James
kent at caspia.com
Thu Dec 15 16:35:26 UTC 2016
On 12/15/2016 5:55 AM, Mark Rousell wrote:
> On 12/12/2016 21:29, R Kent James wrote:
>> Another thing that scares me is that we really don't have a good idea
>> why our existing users choose Thunderbird. With the direction that FF
>> is moving, TB is going to have to change in some ways, and there is a
>> serious risk that we will change in ways that alienate our users if
>> we don't understand them that well.
> I agree that understanding what users really need and/or want is
> critical. It's never easy to get this kind of feedback, not least
> because many people cannot express what they really want.
As part of the donations process, we've asked people to subscribe to a
Donors email list. Although only about 15% of donors subscribe, still we
now have a mailing list of 5300 people who cared enough about
Thunderbird to donate, but are not part of the developer community. My
intention in setting up this list was to provide an alternate source of
feedback to us from the people who are willing to fund our way forward.
But I've only sent out one question to that list, and learned enough
lessons that it is a bit of work to do another. Like, 1) we really need
translation of the question and responses, and 2) it is not easy to get
the rest of Thunderbird leadership to take these responses seriously.
And as you say, when it comes to UI or strategic decisions, people
really don't know what they want in a way that is clear, not can they
easily envision a future beyond what they are doing right now.
I've long advocated that one of our first three hires needs to be
someone to focus on donor and community interactions, both from the
perspective of encouraging donations, but also from the perspective of
understanding our donors and engaging them when possible in the decision
making process. But this is a tough sell to many people, it sounds like
pointless administrative overhead.
> For what it's worth, I've introduced many people to Thunderbird, most
> of them non-technical end users. Here are my observations of their needs:
> (1) Above all else, stability. Don't break it. New UI or functionality
> changes must be either optional for existing users or must be easy to
> back out of for existing users. Note that this does not prevent
> innovation or changes: New or changed UI and/or functionality can be
> enabled by default for new users. Remember that success means not only
> that you attract new users but that you retain existing users.
> (2) Flexibility. In a way, this is a feature that appeals to me but it
> is also why I recommend TB to my clients. Apart from TB's own
> settings, "flexibility" means addons. I cannot over-emphasise the
> importance of addons. This also feeds back to point 1 above: Don't
> break addons. Stability in addon compatibility matters as much as
> stability in Thunderbird's own UI and features. Non-technical users
> don't know the difference and don't care -- it just has to work.
> Thunderbird is to a great extent its addons.
My answer to both of these points is what I call first-class addons.
These are addons that follow certain rules, but are considered as
important as the core program. New features could be added as addons
rather than complicating the core. Certain third-party addons that are
recognized as critical to our user base would be somehow tested and
maintained with new releases. For this to work, there needs to be a
well-defined path for monetization of third-party addons.
But at the same time, you really can't have a policy of no changes,
ever, that change the user interactions. I suppose you could decide that
Thunderbird is, as JB expressed in 2012, "pretty much what our users
want already" and then organize to simply do bug and security fixes, but
that is really a short-sighted viewpoint. Look at the rise of Slack to
see that communications is not everything users want it to be. There
have to be some changes, innovation is important, but a healthy respect
for the poor user who just wants to get their job done without having to
rework to understand your new UI is also important.
> On 12/12/2016 08:28, R Kent James wrote:
>> I do see that Thunderbird though has three fundamental options to
>> consider. 1) Continue our traditional path of being a binary rebuild of
>> Firefox, which means probably moving toward Rust and custom
>> WebExtensions or WebIDL features, 2) Move Thunderbird clearly into the
>> an app category using web technologies, or 3) pick an entirely different
>> binary platform to run on, like QT or .NET core. Of these three choices,
>> I think that 2) is the path we are mostly looking at.
> It seems to me that none of these options is a good option stability.
> Is forking Gecko and sticking with a XUL/XPCOM base any more work than
> options 2 or 3 would be anyway? I am quite certain that Thunderbird
> dies if its existing addon infrastructure dies, at least not without
> there being an equally capable migration path (which, I admit, does
> seem least difficult with option 2).
It is really hard for us to predict what mozilla-central is going to do
with XUL and the code that supports it. I should probably have listed a
fourth option, which is actually I think the path that we are on
implicitly, which is 4) continue Thunderbird indefinitely as a XUL/XPCOM
app, forking Gecko at the point where that is no longer viable under
mozilla-central. If we do nothing, that is the future. And that is
probably the future that many people want. A year ago I predicted that
about now we would be no longer be able to maintain day-to-day
compatibility with mozilla-central, forcing us into resyncing with Gecko
periodically, and that at the point of the next major release (59?) we
would have to fork Gecko. In hindsight I was overly pessimistic about
the timing, but I still think that is the path we are on. That is a path
to a slowly dying Thunderbird. If that is what our donors want, then
we'll have to think really hard about whether that is how we should
spend their money, but for me as a volunteer interested in Thunderbird
as a learning opportunity, I have no interest in that.
As to the future of Thunderbird addons, unlike plans for future Firefox
addons, a first-class Thunderbird addon needs to be able to have the
full capability of the core program. In the option 2) that is likely to
be some sort of code injection, like a restartless addon. Whether we can
solve the security issues associated with that is another open question.
More information about the tb-planning