<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Ben and I had a very long discussion about this issue today,
particularly as it would affect the next technical direction for
Thunderbird.</p>
<p>The question that I ask myself is, what would Thunderbird need to
look like for it to be a major player in the email world, say with
the same relative market share to Outlook and Gmail that Firefox
currently has relative to Chrome and other mainline browsers?</p>
<p>This is particularly critical in the context of first technical
steps toward a revamping of Thunderbird, which we hope to start
very soon. We've generally agreed that a good context for that
would be a rewrite of the address book, as it is both badly in
need of attention, as well as sufficiently independent from the
rest of Thunderbird that it would be a good experimental platform
for alternate technologies.</p>
<p>What do people expect of their email client in the modern world?</p>
<p><b>Big question #1: Overall scope.</b></p>
<p><b></b> I would say that the product needs to work reliably and
consistently in two dimensions:</p>
<p>1) Platform. Users expect to be able to access their personal
information on a desktop platform (at least Windows and OSX, but
we would undoubtedly also want to include Linux), on mobile
devices (at least Android, iOS if possible), and from a web
browser. (Currently Thunderbird users do this with different apps
on each platform, but there are little inconsistencies in the
behavior that makes that awkward and unsatisfying).</p>
<p>2) Protocol. Users have a wide variety of primary sources for
information, and they expect their email client to work well with
all. That includes both open protocols (IMAP, POP3, and SMTP for
email, iCalendar and calDAV for calendar, cardDAV for address
book) as well as proprietary protocols, including the Google suite
as well as Microsoft and Exchange Web Services. (Currently in
Thunderbird, some protocols are supported in core, others are
supported inconsistently and frequently unreliably in addons).</p>
<p>Is the goal for a future Thunderbird a product that satisfies
both of these dimensions as primary (core) goals? Personally, I
don't see that you can shoot for anything less if you hope to be
competitive. (Whether we can marshal the resources to pull that
off is another question, but related - if there is no vision there
is no hope for the resources either).</p>
<p><b>Big question #2: Security.</b><br>
</p>
<p> Of course anything that we do would need to be immune to malware
attacks, but the issue here is advances in communication pointed
toward end-to-end encryption. There have been a variety of
attempts to provide working products and protocols to this end,
but this has not been a focus of Thunderbird. Should we
re-prioritize our efforts toward accomplishing the goal of
reliable, convenient end-to-end security? (There have been at
least two third-party attempts to implement this in Thunderbird,
which we so far have only hesitatingly encouraged. This priority
could be accomplished in partnership with more commercial entity,
but keeping in mind the backlash against such partnerships that
Firefox has faced).</p>
<p>In addition to the end-to-end encryption issues, closely related
issues hinted at by Ben are the issues of privacy and dependency
resulting from dependence on central servers. Local storage on
Thunderbird is not really prioritized currently as an alternative
to server storage, and there are many details that would need to
be attended to before that was really viable and reliable.<br>
</p>
<p><b>Big question #3: Implementation polish.</b></p>
<p>This may seem like an odd big picture question, but really a
focus here would be in direct conflict, in the short term, with
the other big-picture priorities.</p>
<p>There are many, many details of how Thunderbird currently works
that really could use improvement. I'm sure everyone has their pet
peeves that they would like to see improved. So the question is,
should Thunderbird remain as primarily a desktop product focused
on existing open protocols (IMAP, CalDAV, and CardDAV) and focus
new efforts on performance, usability, and reliability within that
restricted scope?<br>
</p>
<p><b>Big question #4: Betting on Gecko.</b></p>
<p>An issue that we have not come to consensus on is whether we
believe that continuing life as a binary rebuild of Firefox is a
viable future for Thunderbird. If we really wanted to follow
Firefox, we would be moving into Rust and focusing on reliability
and performance. Is that even viable? (I predicted two years ago
that our upcoming release, Thunderbird 59 now 60, would be the
last Gecko release we could successfully achieve.) Where someone
stands on this technical question has largely dominated
discussions of what steps to take next.</p>
<p>As we are currently contemplating a major investment in a future
Thunderbird, I think that we as a community (or as potential
Thunderbird Council members) need to have a clear understanding on
where we stand on this. Without that, we have no clear direction
and no vision that anyone could get behind.</p>
<p><b>My approach</b><br>
</p>
<p>Here's my viewpoint. In the short run, for the address book
rewrite, we explore the technical issues around big question #1
Platform, so that we understand what are the challenges and
tradeoffs involved in targeting all three platforms, as well as
recommending a technical stack and architecture for future work.
Based on the results of that, we make a concrete decision about
future direction in these areas - but with the hope of being able
to have a product that would support consistent workflows on
desktop, mobile, and web platforms. We end up with an address
book that can work as integrated into existing Thunderbird, as a
standalone desktop app, as a standalone web app, and as a
standalone mobile address book. As part of that, (big question #1
Protocol) we would support both open and proprietary protocols.<br>
</p>
<p>After that, we should take on a second major area for revision,
with the likely candidate being the front-end thread pane view.
Here the major focus is whether our choice of technical stack and
architecture can deliver the performance and features we need for
the future. This would also be integrated into the current
product, with possibly a minimally viable prototype email client
using that thread pane view.</p>
<p>At this point, my expectation is that a) Gecko would be
increasingly difficult to maintain, b) the problems in
retrofitting changes to the existing Thunderbird product would be
understood as difficult and limiting, and c) we would have a clear
alternate technology possibility in the address book and MVP email
client. At this point we would decide to re-implement the rest of
the critical functionality of Thunderbird into the future
technical stack and architecture, eventually obsoleting the Gecko
version of Thunderbird. This is a bet (big question #4 Gecko) that
we could maintain Thunderbird on Gecko through a version 67 but
not beyond.</p>
<p>Concerning big question #3 (Polish), the cost of this is that we
would not be able to primarily focus on many small improvements to
Thunderbird, but instead the visible improvements to the existing
product would come from replacing two major components (the
Address Book and email view) with more modern parts. Serious
attention to polish would wait until it is implemented in the next
generation of Thunderbird.</p>
<p>Concerning big question #2 (Security), these issues would not be
prioritized, but reconsidered at the point of the full rewrite.
PGP could reasonably be supported as a core capability, and if
there are any other well established approaches as public
protocols we could consider implementing. But this would not be an
area we would be leaders in.</p>
<p>:rkent<br>
</p>
<div class="moz-cite-prefix">On 1/31/2018 10:09 AM, Ben Bucksch
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6d430ba8-3a8e-88ec-90ba-e5f5e5e29d6f@beonex.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<p>Dear Thunderbird community,</p>
<p>the Thunderbird project currently does not have a clearly
defined, written project manifest or vision in the form as the
Mozilla Manifesto <a class="moz-txt-link-rfc2396E"
href="https://www.mozilla.org/en-US/about/manifesto/"
moz-do-not-send="true"><https://www.mozilla.org/en-US/about/manifesto/></a>.
It would be good to have something like it, but more concrete
for Thunderbird. We appreciate Thunderbird for specific
qualities that it has, and I think many of our reasons will
overlap, but we never really defined it.<br>
</p>
<p>We're kind-of at a cross-roads point with the project right
now, and it would be useful to have it written and clearly
defined, so that we can make sure the future strategy and
developments maintain these core qualities.</p>
<p>So, I would like to start an informal survey about what about
Thunderbird is important for <b>you</b>, personally. Why are
you here, why do <b>you like</b> Thunderbird so much?</p>
<p>Also, I'd like to know where you see Thunderbird in, let's say,
10 years.</p>
<p>So, my two questions for you would be:<br>
</p>
<ol>
<li>What specific qualities do you like about Thunderbird?</li>
<li>Where do you see Thunderbird in 10 years?</li>
</ol>
<p>It would be useful for you to give both keywords (to classify)
and a 1-line answer to know what you mean with that (because
people mean different things with "security", or there's a
specific use case where "performance" is important for you).<br>
</p>
<p>Here's an example answer for the kind of answers would be
helpful:</p>
<p>1. What specific qualities do you like about Thunderbird?</p>
<ul>
<li>Privacy is important for me. I use Thunderbird, because I
don't want to keep all data on central servers.<br>
Keywords: Privacy, decentralization, local processing</li>
<li>I want to keep my emails on my computer, so that I know I
keep access to it, even if I don't have Internet, or even if I
change applications, I want to know to be able to store my
emails locally in a standard format.<br>
Keywords: local storage, standards</li>
<li>I get 150 emails every day. Thunderbird filters help to keep
on top of them. It's also fast to open and read and move
emails into folders.<br>
Keywords: Filters, UI, speed</li>
<li>I have mailboxes with 30000 emails. Thunderbird allows to me
easily access them<br>
Keywords: Speed, large mailboxes</li>
<li>Security: I think Thunderbird does not have many security
holes, and I trust the project to quickly fix and properly any
issues that become known, not just paper over them.<br>
</li>
<li>Encryption: I want to use PGP, and that makes no sense in
webmail.</li>
</ul>
<p>2. Where do you see Thunderbird in 10 years?</p>
<ul>
<li>I want Thunderbird on my Android phone</li>
<li>I want to use WhatsApp from Thunderbird</li>
<li>I want to share pictures with my friends easily and
hassle-free, and allow them to send me pictures and videos<br>
</li>
</ul>
<p><br>
</p>
<p>Once we have a good sample of responses from the community, we
can try to build a common picture. We should also reach out to a
larger group of end users.<br>
</p>
<p>Ben<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
</body>
</html>