<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>