<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>As you may know, I have been working on Thunderbird since a long
      time. In my day job, I consult companies to create new software
      products, or to solve difficult problems for them. That includes
      the architecture, code design, and writing the framework of large
      applications. The combination of both backgrounds have pushed me
      to think long and hard about the future of Thunderbird, and how we
      can ensure that it's appealing to a large user base today and,
      more importantly, in the future.</p>
    <p><br>
    </p>
    <p>We're living at a time where my 70+ year parents need WhatsApp to
      stay in contact with their friends, or be cut off. I want to
      ensure that the human communication is free, standards-based,
      open-source, decentralized, private, secure, and pleasant and
      efficient both for the work place and for private communication.
      We're losing that game, and there are no free contenders.
      Thunderbird is still one of those with the most users, so I think
      we should be proactive and approach the future, instead of just
      maintaining status quo of 15 years ago.</p>
    <p>For that, we need bold actions into the future, and completely
      rewrite the application, both on a modern platform, given that
      Gecko and XPCOM and XUL and slowly but surely breaking away from
      underneath us, but also - possibly more importantly - with a clean
      code design that is malleable and easy to adapt to new ideas. This
      can be achieved with horizontal and vertical modularity, clean,
      minimal and stable APIs, and thin layers that can easily be
      replaced. I would like to first replicate most of the current
      Thunderbird functionality and its current UI, and then be able to
      quickly and easily write other, alternative UIs, and create an app
      for Android. None of that is possible with the current codebase,
      nor do I think that the current codebase can reasonably be changed
      to do that, in any way or form.</p>
    <p>My ideas are further described on <a
        href="https://wiki.mozilla.org/Thunderbird/NextGeneration">Thunderbird:
        Next Generation</a>.</p>
    <p><br>
    </p>
    <p>For that end, here are some of the motions I have presented
      before the council to get this on track.</p>
    <p><br>
    </p>
    <p> </p>
    <hr width="100%" size="2">
    <p><b>Thunderbird Next Generation</b><br>
      2017-04-19</p>
    <br>
    = Alternatives =<br>
    <br>
    ...<br>
    Integrating new code into old Thunderbird is incredibly hard, as
    those who have actually tried it will know. The deeper you go, the
    harder it is. Case in point: It took Kent months to write JsAccount
    and integrate it into Thunderbird, while it took me hours to write
    my Account API in a fresh pure JS implementation. Hours vs. months
    is a drastic difference. ... If we try to replace Thunderbird bit by
    bit, we will need over 10 years.<br>
    <br>
    On top of that, I think that a clean code design, good high-level
    APIs and efficient code are crucial to the success of the new
    Thunderbird. Rewriting existing Thunderbird would necessarily keep
    most of the old design in place of how the modules interact. This is
    a part of why Thunderbird is so hard to get started with. I would
    like to attract new contributors to join as as well<br>
    ...<br>
    <br>
    = Motion =<br>
    <br>
    Concretely, I propose the following motion for the TB Council:<br>
    <ol>
      <li>We will continue to maintain Thunderbird based on Gecko on the
        current level of effort, as long as it is feasible.</li>
      <li>We will create a second, parallel team that will implement a
        replacement of Thunderbird, based on JavaScript and HTML,
        running as a desktop application. We will seek funding and hire
        developers for this effort. We will first try to create a
        "minimum viable product" with a good code design and solid
        framework, then gradually build out features to match
        Thunderbird closer. </li>
      <li>Where feasible, the first team working on the old Thunderbird
        will backport selected components, for example a new address
        book, from the new implementation to the old Thunderbird based
        on Gecko. </li>
    </ol>
    <p> The goal is to have an application with a clean code design,
      framework and APIs that's a joy to work on and with. One UI should
      imitate current Thunderbird in its design and workflow as much as
      possible, but there may be another mobile app UI for the young
      generation. <br>
    </p>
    <p><br>
    </p>
    <hr width="100%" size="2">
    <p><b>Test balloon: Address book rewrite</b><br>
      2017-11-09<br>
    </p>
    <p>We will start a test of the technologies and code design that
      will be used for the future Thunderbird based on web technologies,
      by implementing the address book based on web technologies.</p>
    <p>We will hire somebody to lead this effort, and work out the
      framework issues with it. Examples of issues to be solved are:</p>
    <ul>
      <li>Which module system to use</li>
      <li>How to share data between several windows</li>
      <li>How the APIs between backend and frontend look like</li>
      <li>Which widget toolkit to use (replacement for XUL)<br>
      </li>
      <li>How to translate the application</li>
    </ul>
    <p>Once these questions are solved, the APIs for the address book
      should be designed, then backend (in this case: data store) and
      the frontend should be implemented.</p>
    <br>
    <hr width="100%" size="2">
    <p><b>Thunderbird Next Generation</b><br>
      2018-01-25<br>
    </p>
    <p> </p>
    <div class="moz-text-html" lang="x-unicode"> </div>
    <p>Goals:</p>
    <ul>
      <li>Untangle Thunderbird from XPCOM and XUL, but base it on <b>JS,
          HTML</b> and a runtime</li>
      <li>Create a UI and desktop application that looks <b>like
          current Thunderbird</b>, for existing users<br>
      </li>
      <li>Create <b>new, alternative UIs</b> for other kinds of devices
        and new user groups. Run on <b>smartphones</b>.</li>
      <li>Create a <b>clear modular API</b>. Separation both horizontal
        (UI -> logic -> storage, or even more layers) and vertical
        (address book, mail, news, blogs, editor etc.).</li>
      <li>A new extension API.<br>
      </li>
    </ul>
    <p>Rationale:</p>
    <ul>
      <li>Removing XPCOM and XUL from Thunderbird means effectively
        rewriting it.</li>
      <li>Thunderbird modules are so <b>entangled</b> that most modules
        cannot reasonably be replaced individually. JsMIME never
        replaced libmime due to this. If it was attempted, it would
        maintain the old, arcane API structure, which was determined by
        XPCOM and internal URL running, which do not fit a JS based
        application.</li>
      <li>Large projects are best done with the <b>MVP</b> "minimum
        viable product" approach. Start with the smallest product that
        has some use (e.g. first only read email, then write email, then
        add local storage, etc.), and gradually gain users as you expand
        feature surface. 20% of the features gains 80% of the users.
        Allow users to switch to the new product <b>voluntarily</b>,
        instead of forcing the new modules on them.</li>
      <li>In contrast, a rewrite module by module will require the new
        implementation to have 100% functionality of the old module, <b>before</b>
        it can be integrated and released. For a feature-rich
        application like Thunderbird with many vocal power users, this
        is highly unlikely to succeed.</li>
      <li>To work on new devices, we also need new UIs. Alternative UIs
        for Thunderbird are currently impossible, because they would
        mean a half rewrite, due to the lack of code separation. A
        gradual rewrite would just perpetuate the current situation and
        not help us with new user groups.</li>
    </ul>
    <p><br>
    </p>
    <p>Motion:</p>
    <p>Implement TB:NG as described on <a class="moz-txt-link-freetext"
        href="https://wiki.mozilla.org/Thunderbird/NextGeneration">https://wiki.mozilla.org/Thunderbird/NextGeneration</a></p>
    ...
  </body>
</html>