On Tue, Dec 1, 2015, at 03:21 AM, Dirkjan Ochtman wrote: > On Mon, Nov 30, 2015 at 10:11 PM, Mitchell Baker <[email protected]> > wrote: > > 7. Some Mozillians are eager to see Mozilla support community-managed > > projects within our main development efforts. I am also sympathetic to this > > view, with a key precondition. Community-managed projects that make the > > main effort less nimble and likely to succeed don’t fit very well into this > > category for me. They can still be great open source projects -- this is a > > separate question from whether the fit in our main development systems. I > > feel so strongly about this because I am so concerned that “the Web” we > > love is at risk. If we want the traits of the Web to live and prosper in > > the world of mobile, social and data then we have to be laser-focused on > > this. > > Can you comment why you think Thunderbird (or maybe even email in > general) is not part of this Web that we love that is at risk?
A contextual digression before addressing your comment/question (way) below: Thunderbird is still, at its heart, a C++ mail client with a HTML/CSS/JS UI grafted on top with JS logic slowly chipping-away-at and replacing pieces of the C++ logic. It is an email/newsgroup client (and sometimes RSS client) that is part of the federated messaging system of email (and others). And this is important. Mail User Agents are absolutely important. Just as Firefox endeavors to put users in control of their web browsing, Thunderbird endeavors to put users in control of their messaging in a way that closed-source webmail UIs running on third-party server infrastructures outside of the user's control inherently cannot. The problem with Thunderbird is not that it is a mail user agent or that user agency in messaging is unimportant. The problem is that Thunderbird has had a serious technical debt problem since the day its code-base transitioned from Netscape. Its low-level integration with Gecko has been a maintenance burden for Thunderbird developers and non-Thunderbird developers alike. The Mozilla Foundation and Mozilla Corporation put serious financial resources into trying to address both of these problems with the creation of Mozilla Messaging. The idea, as I understand it, was to attempt to alleviate the burden on Firefox development by separating Thunderbird development while simultaneously providing Thunderbird with people and resources to attempt to address this technical debt. Probably the core takeaways from working on Thunderbird during that time were: 1) There was and continues to be a lot of technical debt. (Despite serious efforts to address it.) 2) When you have addressed the technical debt, you potentially are left with something that is not the same product that Thunderbird was to begin with[1]. (:rkent's post at https://mail.mozilla.org/pipermail/tb-planning/2015-September/004066.html "Future Planning: Thunderbird as a Web App" could be interpreted as a variation on this.) An important question that falls out from all of this is and your original question is: which is more important? Mail user agency or Thunderbird the product, especially if there are serious opportunity costs related to Thunderbird? Within the funded efforts of the Mozilla Corporation[2], mail user agency has not been abandoned and continues to be advanced as part of an open development process. For Firefox OS, a mail app was developed with a back-end based on experience from working on Thunderbird and other messaging projects. There was some time lost due to the initial product targets and related engineering complications, but we now have a branch which does many things that were out of reach and continue to be out of reach for Thunderbird: * Conversation-centric[3] but also capable of supporting message-centric UI's. Specific sync support for gmail's conversation model in addition to "vanilla" IMAP and POP3 and ActiveSync. * The offline-first back-end is entirely implemented in JS, which means that it can run in content space in Firefox or any JS engine as long as appropriate (web) API's are exposed to it, mainly a (priviliged/permission based for security reasons) TCP implementation. There is no C++ or deep integration into Gecko that slows down Gecko. * The back end runs in a worker thread modulo some proxied web APIs so it does not interfere with the responsiveness of the UI. * Back-end designed to support desired Thunderbird UI features like multi-line thread pane support while also allowing a virtual list implementation that does not require the entire message store being displayed to be loaded into memory. * Back-end is decoupled from the UI, allowing multiple different UIs. For example: ** Screenshot of the conversations branch of FxOS gaia mail UI showing its conversations list running in b2g-desktop: https://clicky.visophyte.org/files/screenshots/20151201-064354.png ** Screenshot of the (ugly) lazy-developer react.js desktop UI running in Firefox nightly: https://clicky.visophyte.org/files/screenshots/20151201-061945.png And now back to your original point/question (responding only for myself; I speak for no one else!): > Can you comment why you think Thunderbird (or maybe even email in > general) is not part of this Web that we love that is at risk? As I read this question, the first implication I see is that Thunderbird is important to the web/internet. And it is. But I think what is really important is user agency. User agency on the web, user agency in messaging. The second implication I see is that Thunderbird is important in a way that no other product can be and a choice to prioritize Firefox over Thunderbird is a choice to ignore user agency in messaging. I don't think that's the case, and as I hopefully indicated above, I do not believe the Mozilla Corporation is ignoring user agency in messaging. Andrew 1: Of course, with enough effort, it may be possible to create a UI that mimics Thunderbird's existing interface with a high degree of fidelity. But "enough effort" can be very high. For example, Thunderbird's global faceted search UI came into existence because the performance of feeding the global search results directly into the thread pane was very poor because of Thunderbird's main-thread I/O and need to load entire folders at a time entirely into memory using an append-only custom database where compaction was frequently risky/scary (pre-rkent doing a fantastic job of fixing the compaction!) Feeding the thread pane synthetic headers backed by JS resulted in massively reduced scrolling performance due to the treeview's draw model in addition to losses of fidelity and consistency. 2: Note that I'm explicitly saying Mozilla Corporation/Foundation etc. just to be clear about the entities involved. A lot of times the bare term "Mozilla" is used to mean any of the corporation, foundation, project/community, etc. and it can get very confusing and potentially even seem exclusionary. I'm trying to avoid that. 3: Noting that Thunderbird's global database provides a best-effort conversation overlay data model on top of the underlying folder and message-centric view of things. Unfortunately there were many compromises inherent in this approach, including that the whole layer is entirely optional, so most core functionality can't depend on gloda at all. _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
