Thunderbird Server as a Way Forward for Mozilla -- ThunderbirdS Are Grow! Manifesto

Update 2015-12-10: Kent James suggested I look at the tb-planning email list when I made a post about this proposal to the Thunderbird blog:
https://blog.mozilla.org/thunderbird/2015/12/thunderbird-active-daily-inquiries-surpass-10-million/#comment-986

Looking there, I've found a previous suggestion from about three months ago (also by Kent), called:
"Future Planning: Thunderbird as a Web App"
https://mail.mozilla.org/pipermail/tb-planning/2015-September/004066.html

So, great minds think alike. :-) I plan on posting this proposal there too as Kent suggested. It covers some extra ground beyond that discussion.

This is in response to a thread on Mozilla Governance called:
"Thunderbird, the future, mozilla-central and comm-central"
https://groups.google.com/forum/#!topic/mozilla.governance/kAyVlhfEcXg

On Tuesday, December 1, 2015 at 7:47:58 AM UTC-5, Andrew Sutherland wrote:

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

To deal with Thunderbird's technical debt (which Andrew Sutherland described on the Mozilla Governance thread that Mitchell Baker started), I propose Mozilla fund a "skunkworks" team of about seven people for a year to create a new server version of Thunderbird (called "Thunderbird Server", or "ThunderbirdS" for short) that runs initially as a locally-installed Node.js app providing a single-page JavaScript/TypeScript/Mithril/D3 webapp for email handling and other peer-to-peer communications using the local file system. Thunderbird Server would use Firefox (desktop or mobile) as its primary client; Firefox would access Thunderbird Server just like any other (local) web server using web standards. The most significant Thunderbird Desktop plugins (based on downloads or other metrics) would be ported by the team to this new Thunderbird Server platform (ideally, aided by a custom tool for such porting). Some of the most popular plugins might be unneeded though for Thunderbird Server given they could run directly in Firefox (like translation tools and ad blockers). This Thunderbird Server platform would, through plugins, eventually become a social semantic desktop that could change the nature of the web as we know it, reducing the significance of the distinction between local copies shared with peers and centralized content shared with clients.

This is a feasible way to deal with the technical debt in Thunderbird and move Thunderbird to Mozilla-promoted web technologies while still being true to the idea of distributed data and peer-to-peer communications which is the soul of Thunderbird. Sadly, Thunderbird Desktop itself would then probably be left to eventual technical bankruptcy (or self-serve fixes) once the Thunderbird Server version proved stable and popular and the migration path was clear and easy (unless others wanted to maintain Thunderbird Desktop in the absence of Mozilla's ongoing financial support). If Thunderbird Server was not a clear improvement over Thunderbird Desktop for almost all Thunderbird users all things considered, making them want to switch to it, the project could be deemed a failure though. However, even in such a case, Firefox itself might benefit a lot from this effort via indirect means as it grew to meet new challenges posed by an expanding Thunderbird Server platform; Node.js would also benefit with improved email handling libraries usable by many web applications.

I'd be happy to either help lead such a Thunderbird Server project myself or just help out with it full-time under another developer's leadership. I just applied as a "Mozilla Growth Engineer" suggesting something in this direction. Below is a manifesto about this idea with more detail on such a plan and a lot more reasons as to why Mozilla should fund this effort. But in short, the big issue here is, as Andrew points out, not messaging. The deeper issues is local data and peer-to-peer communications versus central data and client-to-shared-server communications -- and related privacy, security, and reliability concerns.

Mark Surman said the Mozilla Foundation offered a modest amount of money to pay for contractors to help develop options for the technical future of Thunderbird. In a couple of months, building on the same infrastructure of a complex FOSS webapp I've already written called NarraFirma, I'm confident I could produce a proof of concept of this Thunderbird Server idea even just working by myself -- but it would be better to do it as part of a team.

And we all know, as Mark Surman suggested, that "Open Source is the Answer to Giving". :-)
http://news.slashdot.org/story/08/04/20/1313223/is-open-source-the-answer-to-giving
http://www.pdfernhout.net/open-letter-to-grantmakers-and-donors-on-copyright-policy.html

A Thunderbird Server could instead become a Kickstarter/Indiegogo campaign or such, but, even ignoring "Thunderbird" trademark problems with such a campaign, it would no doubt be best if Mozilla itself got behind such a manifesto -- best both for the Thunderbird project itself *and* also for Firefox's own future, for reasons explained below.

Redistribution of this manifesto under CC-BY-SA is encouraged. People should feel free to improve it or rewrite it or reduce some redundancy in it. In that sense, it's more of a first draft.

--Paul Fernhout (pdfernhout@kurtz-fernhout.com)

The "ThunderbirdS are Grow!" Manifesto

Web technologies are important, and Mozilla is doing amazing stuff to improve web standards via FireFox. Mozilla also is doing great work with the Webmaker movement to help more people to understand web technologies. And as Douglas Turner wrote: "I want people to be able to build products like Thunderbird and BlueGriffon directly on the web. This is where we're heading." That is a great vision and I agree we are going there. However, such web technologies like HTML, CSS, JavaScript, and the DOM are almost orthogonal to the real issue here. That deeper issue is about centralized data vs. localized data and also about client-to-shared-server transactions vs. peer-to-peer transactions. Mozilla seems be ready to discard its support for distributed private data which is transferred from peer to peer (as via email) -- decentralized data which was used day-by-day to build the web and still is! That is a bit like someone sawing off their legs because they want to "focus" on just using their arms now that they have gotten somewhere they want to be at the moment. :-(

Firefox and web standards does not care much about local data

For example, here is a Firefox issue I filed a year and a half ago, and is still unfixed, related to IndexedDB. I discovered it while trying to write a JavaScript IDE that ran purely within Firefox. Essentially, almost nobody cares about it, even to disagree whether it should be fixed.
"IndexedDB same-origin policy implementation for local files with query string"
https://bugzilla.mozilla.org/show_bug.cgi?id=1005634

As I eventually wrote there in a bit of frustration a couple months ago:

"In general, and given that this (in my opinion) bug has been sitting around for so long (both on the user side and on the Mozilla side), it seems to me this situation relates in part to changing cultural expectations on the use of a web browser. For me, I increasingly see the web browser with JavaScript as a new non-proprietary well-supported cross-platform technology to deliver applications of all sorts for the desktop, mobile, and embedded (a bit like the proprietary VisualWorks Smalltalk could do in the 1980s way before Java). I can think that even if at the same time I feel we should have better standards for exchanging information in structured ways. To me, the app part of that means a web browser should fully support running applications from local files including all functionality -- but in a "sandbox" with fine-grained security permissions (something any OS should ideally be supporting from the ground up for all apps and subapps, but that's another story). Full functionality could include support for peer-to-peer web browser interactions without the need for a central server (like WebRTC moves towards). However, I get the feeling most people using web browsers (including likely many at Mozilla) still see a web browser as something always connecting to servers which host web pages. Even Mozilla's Webmaker movement focuses on using a server to make content, not to edit local files. To make things worse, web site creators have adopted approaches involving loading code from many sites just to make basic functionality work (which is also in part based on a third-party-advertising-based revenue model). So, thinking through this sort of security issues related to running code from local files is presumably not a priority or seems just to big an issue to wrestle with. So, it is easier to just deny all access as much as possible when loading from files (as a choice between security and convenience, as opposed to devoting substantial resources to innovation to deliver both security and convenience). In many ways the entire web browser security model (including with per-origin cookies) was unfortunately just not well thought through from the start. As Jeremiah Grossman suggests, "... Web Security is Fundamentally Broken". Opening files saved from the web in FireFox pushes on pain points from a fundamentally broken web security model. ... [A possible resolution] might even end up with local pages being served from some internal webserver in FireFox and other browsers as some sort of new "local web server for browsers" standard? ... Until then, it seems the most predictable behavior results from running apps from local servers (like say NodeJS wrapped into a desktop application), which at least then just creates the usual security and user expectation issues and not extra ones and additional confusion from loading directly from files. It's a sad situation though. ..."

You know where the code I wrote on Firefox actually works as I might expect? Chrome. :-(

So, as I know from personal experience (and don't get me started on Mozilla's WebSQL decision), Firefox does not seem to really prioritize making it easy for developers to store local data in the web browser in a generally usable way -- or to load fully useable web pages that are stored in local files. Yes there are good reasons for most of of Firefox's security and standards decisions -- but having good theoretical reasons doesn't matter if the end result is still unusable in practice. :-( https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

But, it is not just Mozilla's choices here. As Daniel Glazman wrote: "The dismissal of the File API a while ago is one of the crucial holes in the platform."

Node.js to the International Rescue

But as R Kent James points out: "This is in the context of a Firefox that is under enormous pressure to re-establish themselves as a market- and mind- share leader. They could have decided to do that by stressing the flexibility of the Mozilla platform, and encouraging third-party applications, and complex addons. Apparently though they have not chosen that path."

Instead, rather than abandon Firefox which I've used almost since the first version, I've resorted to hosting stuff in Node.js as a local server so Firefox can then access it without unexpected issues -- even as that makes software less easy to install for any other users. It was sad to give up on expecting Firefox would be robustly supportive of storing and indexing data locally (even though you can do it within excessively tight restrictions, or in that browser-based IDE's case, if I use a hash instead of a query string to launch applications, and thus break internal page navigation). I understand how Firefox might reflect a certain central-server-based vision of Mozilla that seems to have crept into the organization without anyone noticing, and I can work around it with a local server, but it is still sad to me.

This other point by R Kent James really resonated with me though: "But beyond that, many of us are loyal Mozillians who are not excited about being driven to things like NodeJS to get any real work done. Today's inconveniences like Thunderbird could be tomorrow's web innovation. Just look how AJAX and XHR originally arose as attempts to make better email clients in GMail and Outlook. Yet we are pushed away and isolated, so that Firefox can "Go Fast"."

And that is, sadly, just what I did -- turned to Node.js.

Thunderbird is about storing data locally and sharing peer-to-peer

Thunderbird by contrast to Firefox is all about storing data locally and sharing that data in a peer-to-peer way via email servers. That is why I have used Thunderbird as well almost since it initial release.

Still, there are web email systems (and I even use one sometimes on my email relay server as I leave messages there a couple of days in case my local system crashes). So, I have to agree with Andrew that the issue is not about messaging by itself. There are also plenty of web bulletin boards run by whoever (even Mozilla). The cultural divide goes deeper than messaging. A focus on messaging may just be a red herring, since every web request is essentially a messaging transaction, or could be thought of as one. The web is all about messaging in that sense.

The cultural divide is really more about locally-stored data and peer-to-peer versus centrally-stored data and client-to-shared-server. And that is why some people (like me) are so strongly upset by what Mozilla seems to be saying about abandoning Thunderbird. Even if Mozilla spins off Thunderbird with a good severance package, that act comes across as Mozilla abandoning locality and peer-to-peer and so also abandoning the reliability/security and privacy that locality and peer-to-peer can in theory provide. Sure Mozilla talks a lot about privacy and security, and within a web context Firefox does a good job about that in practice -- but web-related privacy and security is only part of the whole privacy and security landscape. Thunderbird covers another big part of the privacy and security landscape that depends on locality and peer-to-peer.

Is a C++ Thunderbird Desktop obsolete -- yes!!! But its localish peering essence is not!

Are Andrew and others posting in this thread right about Thunderbird essentially being technically and even organizationally obsolete? Yes. We have much better tools than C++ for most coding tasks now -- tools like JavaScript/TypeScript that are less prone to buffer overruns and deallocation errors and so forth. Tools that most web developers actually know how to use reasonably correctly or can be motivated to learn about, in a way they never will with C++. Tools that have a vastly larger potentially pool of contributing developers (even as I'm the first to say JavaScript has a lot of warts). Tools that Mozilla is pushing via the Webmaker movement and most of its other end-user training materials. And the whole idea of Mozilla maintaining a separate parallel rendering and UX stack in Thunderbird at this point is increasingly problematical organizationally as Mozilla moves on to new technologies for Firefox. That all is true. Sad, but true.

I taught C/C++ about 25 years ago to biology majors near the beginning of my career -- I'm a graybeard if you could not tell by my love of distributed email systems. :-) However, I avoid C++ now myself whenever possible. I have next-to-zero natural interest in looking under the hood of any application written in C++ by dozens of developers for over a decade with another GUI layer like XUL thrown on top of it (even if a small well-written C++ program can be a joy to behold). I recently spent 2.5 years doing exactly that sort of thing, contracting for NBCUniversal with their huge fifteen-year-old messaging-based broadcast automation software (translating C++/Tcl to Java, while helping to maintain both) and that C++/Tcl part of the job was not that much fun, even though the C++/Tcl code was on the whole well-written and worked well. :-)

So yes, at this point, the current C++/XUL Thunderbird implementation will eventually die, just like a Tulip plant shrivels up after it has bloomed. Hardly anybody new is really going to *want* to maintain a huge collage of someone else's C++/XUL code voluntarily. No doubt Mozilla could find people to hire to do a good job anyway, like I was hired for that NBCUniversal project -- but having people *want* to play with the code under the hood is an important part of any open source project. There is nothing wrong with C++ in various applications -- it's just generally not a great choice for complex applications where you want to emphasize flexibility, reliability, and approachability over speed, low-level interfacing, and memory footprint. And of course, XUL is on its way out entirely to be replaced by plain JavaScript and the regular DOM. Mozilla is just not encouraging people to be C++ (or XUL) developers -- it is encouraging people to become good JavaScript/HTML/CSS/DOM programmers. But like a Tulip plant with a still-living bulb underground, the local-storage peer-to-peer email-ish essence of Thunderbird, if nurtured well, can still grow again in a year's time and we could have something beautiful -- something even better than last year's plant. Something that could even make Firefox itself better as they co-evolve together. We could have Thunderbird Server, a local webserver that can organize all your messages and do lots of other stuff via plugins including keep a local copy of the web if you want, a local server that you quickly wonder how you lived without for so long. :-)

While I say above Mozilla promotes JavaScript, I would not start such a big project in JavaScript though compared to TypeScript. I learned that lesson on NarraFirma, as once the NarraFirma application passed about 100 JavaScript modules, it became harder and harder to refactor in pure JavaScript until I finally changed the project over to TypeScript. Another reason to choose TypeScript is ironically that it is actually easier for someone to learn JavaScript when using TypeScript because of better autocompletion in IDEs and less minor frustrations from JavaScript warts. Is TypeScript my favorite language? No. I prefer Smalltalk or even Java (ignoring other practical issues like libraries or installation or existing developer base and so on). To me, JavaScript/TypeScript is like a somewhat harder-to-read-and-debug version of Smalltalk but with other redeeming practical qualities. TypeScript is just a better JavaScript. TypeScript does need a build step (which IDEs can make transparent in many cases) -- but most big JavaScript projects (and even many little ones) end up with a build step. TypeScript can make debugging a bit more difficult in terms of line numbers not quite matching up unless you use source maps (which are their own problem on a big project). Wrapping existing JavaScript libraries with type definitions can be a very small nuisance sometimes. Still, other than those sorts of issues, I have seen nothing but benefits from using TypeScript instead of JavaScript. Dealing with those sorts of issues is like 1% of my time when developing in TypeScript. With TypeScript, I can spend hours at a time confidently coding and refactoring (as I could in Java), whereas in JavaScript I often had to keep running the code every five or ten minutes to check if it still worked or if there was some silly error somewhere JSHint could not tell me about. In theory more automated testing might help with the need to run JavaScript code often, of course, but unit tests don't provide any direct help when trying to do complex refactorings on big applications, whereas TypeScript does help with such refactoring.

And while something like Mozilla Rust may well be an excellent system-level programming language, it is probably too far from JavaScript to be worth considering for Thunderbird Server if part of the goal here is to get even more people programming in JavaScript, given a hope that Thunderbird Server becomes *the* application everyone runs locally and tinkers with to store most (or even all) of their local data while integrating that local data with a larger web. Within broad bounds, a 3X speed decrease for JavaScript over Rust does not really matter much in this application. Also Rust does not use an automated garbage collection, which means developing such applications can be a lot harder. That said, if implementing the code in Rust would be required to get this project approved, I myself would be willing to learn (and even improve) Rust to do this. But I would question if that would be the best choice for the project (but maybe I just don't know enough about Rust). Also, for some plugins to Thunderbird Server, like ones doing data mining or textual analysis of tens of millions of messages and web pages that someone has squirrel away in Thunderbird Server, Rust might be a natural fit for writing part of such plugins, which could then be integrated with Node.js via Node's ffi module like shown here: https://blog.risingstack.com/how-to-use-rust-with-node-when-performance-matters/

Mozilla sagged and let too much Slack in

Slack is an alternative example of a web replacement for Thunderbird Desktop -- but a centralized proprietary one. Slack is what happens when Mozilla itself stops keeping up the tension on having developers support distributed peer-to-peer content well. There are emerging free alternatives to Slack, but they are facing an uphill battle, have little traction, and some maybe are lacking a bit in their own innovation if they just try to copy Slack. Because it is centralized and proprietary, Slack is the newest threat to reliability/security and privacy on the web related to encouraging yet more centralized messaging. For example, Automattic has been proudly adopting Slack, meaning much of their real-time internal communications are now archived and monitorable by a potential major competitor.

Any vulnerability in Slack can compromise everyone's data (as in, entire companies destroyed). Related:
"Slack Hack and Broken Model of Centralized Data"
https://medium.com/@muneeb/slack-hack-and-centralized-data-b71bbe1b9377

"To me the Slack hack is yet another reminder that centralized models are broken by design. Slack is an awesome company and I’m sure they’ll comply with the best security practices. It doesn’t look like the hacker got access to chat logs in this hack. But that still means that Slack is a single point of failure. They’re a prime target for hackers. A single place from where confidential information of a lot of other companies can be accessed. ... This model of centralized services and data repositories is broken by design. We need to move to a decentralized world, where users are in control of their own data, their own chat logs, with their own private keys. If Slack is managing access control (figure above) then a hack on Slack means data of all companies can get compromised. Compare this to a model where the hacker needs to compromise companies individually. I can live in that world."

Personally, I just can't understand such a choice to use Slack for anyone tech-savvy, let alone a major player in the web communications space like Automattic. But then, I don't like Gmail either for that same reasons. As akerb...@gmail.com pointed out: "I find it ironically telling that, with all the good intentions, plans and features the Foundation has regarding privacy online etc this discussion is taking place on - Google Groups. With many a participant chipping in via addresses ending in ... @gmail.com. So we're all using a browser that respects our privacy to debate issues on a platform hosted by a data grabber second only to the NSA perhaps. ... But I do think that it's a fallacy to believe that privacy and user control on the web can truly be achieved *just* through a browser and/or OS, no matter how good."

That is why I use Thunderbird and a reliable independent email host as a relay. Even knowing that no doubt the US government and some other groups probably copy everything (especially anything I send to gmail users or Google Groups), at least I still have some local security, privacy, and reliability, if not as much as I might like. Granted, I'm technically savvy and do backups and such, and I can see the argument for Gmail or Slack or other web services for those who are not -- just like I myself both use WordPress.com and also host WordPress elsewhere depending on who I've set the site up for (others or myself). So this is not to say such services should not exist -- just that people should have a choice, and people should be encouraged to think about that choice (including perhaps by peer pressure and new social norms if new options become easy to use). Another similar choice is when people choose to set up their own local GitLab server instead of hosting projects at GitLab.com or GitHub.com.

I've argued a bit with Paul Jones about #noemail on his blog to no effect. He's right that email is often abused. In general, people use computers to much in all sorts of ways. Spam can be a terrible nuisance. But I feel he is wrong to essentially suggest social media is the practical answer and by implication that we should all be using big services to mediate our communications with each other. Blogs open to the internet get spam too now -- lots of it. And I can't even now easily find the messages I posted on his #noemail blog years ago. If they were in Thunderbird, I could easily find them.
http://ibiblio.org/pjones/blog/category/noemail/

Taking too much for granted when the first woodpecker that comes along can destroy civilization

But just because many people can't use a tool right does not mean no one should use it when it otherwise can serve a useful purpose. What happens to the "web" Mozilla says it cares about if Gmail and Slack were both to disappear overnight for economic or political reasons in five or ten years? How can the web be maintained if most of the personal email archives and chat archives in the world suddenly vanished through someone (government, extortionist, script kiddie) shutting down just two de-facto monopoly companies? And worse, what happens to all the pretty HTML, CSS, and JavaScript on the web if the web itself becomes inaccessible? Where is all that civilization's knowledge then, when you can't get to WordPress.com, and you can't get to archive.org, and you can't get to Mozilla.org -- like after a huge solar flare? Why bother having saved local copies of web pages if FireFox is not very good at making the local copies link together like the live centralized web?

Peer-to-peer is actually the soul of the web

Peer-to-peer is now, and has always been, the soul of the web. Email specifically is still the single most-important way people validate their identity on the web. Thunderbird is essentially Mozilla's one widely-used peer-to-peer product -- a real success story in that sense (even if email is relayed through various servers). As Dirkjan Ochtman wrote: "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? I've been wondering whether the focus of Mozilla on HTML and related technology is a bit too narrow , when a lot of the battle in my view is being fought around ecosystems (both in terms of app stores and "cloud" technology) where Thunderbird/Lightning and its ecosystem might actually be more of an asset." Or as Benjamin Kerensa wrote: "Thunderbird has continued to grow despite Mozilla removing paid staff from its development and eliminating resources it had. (Actually has more users than Firefox OS)". Or as Mitchell Baker wrote: "I use Thunderbird to organize vast parts of my life". I feel that way too about Thunderbird. Others wrote even more passionate pleas, pointing out the lack of workable alternatives like for encrypted communications. Why throw that peer-to-peer local-storage successful concept away even if the Thunderbird implementation needs to be refreshed ideally in some creative way to link more closely with web technologies like HTML, CSS, JavaScript, and DOM?

Distributed data is not just about email. It is not even just about email plus calendaring and TODO lists and PIM data and such as with the mostly abandoned Chandler project. Or both those plus small federated wikis like with Ward Cunningham's latest great effort. Or even that plus just real-time white-boarding and real-time chat conversations. Or even that plus just a git-compatible distributed versioned file system. Distributed data, along with real-time interaction, is a far grander vision -- a vision much greater than the sum of its parts.

The social semantic desktop vision

If you look at ideas like the "Social Semantic Desktop", all sorts of things are possible. See for example:
http://semanticweb.org/wiki/Semantic_Desktop

"The Internet, electronic mail, and the Web have revolutionized the way we communicate and collaborate - their mass adoption is one of the major technological success stories of the 20th century. We all are now much more connected, and in turn face new resulting problems: information overload caused by insufficient support for information organization and collaboration. For example, sending a single file to a mailing list multiplies the cognitive processing effort of filtering and organizing this file times the number of recipients - leading to more and more of peoples' time going into information filtering and information management activities. There is a need for smarter and more fine-grained computer support for personal and networked information that has to blend the boundaries between personal and group data, while simultaneously safeguarding privacy and establishing and deploying trust among collaborators. The Semantic Web holds promises for information organization and selective access, providing standards means for formulating and distributing metadata and Ontologies. Still, we miss a wide use of Semantic Web technologies on personal computers. The use of ontologies, metadata annotations, and semantic web protocols on desktop computers will allow the integration of desktop applications and the web, enabling a much more focused and integrated personal information management as well as focused information distribution and collaboration on the Web beyond sending emails. The vision of the Semantic Desktop for personal information management and collaboration has been around for a long time: visionaries like Vannevar Bush and Doug Engelbart have formulated and partially realized these ideas. However, for the largest part their ideas remained a vision for far too long since the foundational technologies necessary to render their ideas into reality were not yet invented - these ideas were proposing jet planes, where the rest of the world had just invented the parts to build a bicycle. However, recently the computer science community has developed the means to make this vision a reality: ..."

That is a vision of a "web" worth working towards. And it is one with both central data and local data. It is a world with both client-to-shared-server and peer-to-peer connections. In fact, it's a world where it is hard to tell the difference between any of those categories -- where really good tools make such distinctions invisible unless you choose to care about them.

And such a vision is far beyond just having a web email system. As Henri Sivonen mentions suggesting mailpile as another alternative under discussion -- and if we are only talking email, an existing system like mailpile might well be a better migration path. But as R Kent James wrote: "I sometimes imagine a world in which Thunderbird, Postbox, N1, and Gaia Email all decide to work together to make a common, killer communication client." That is really just a start though.

Part of this effort might involve working with the W3C to help define standards for semantic data which might be useful in such a distributed Thunderbird Server as well as in other webapps. For example, ideally, the project would promote a standard for exchanging calendaring data as RDF-like triples, or contact info, or whiteboard data, or anything else. Such standards may already exist, so the project would ideally inventory these and pick ones to promote.

Groove and Notes were good examples even if proprietary

The original Groove software, by Ray Ozzie, also the creator of IBM's Lotus Notes application, showed what could be possible (as did Notes). Groove ahd all sorts of pluggable third-party tools (including arbitrary file storage and wikis) on a distributed platform as a peer-to-peer system that also had store-and-forward relay servers. Apache CouchDB as well as Apache Accumulo and similar also show what is possible for distributed data with indexes.

NarraFirma shows what is possible with sophisticated FOSS single-page webapps

Further, as with the FOSS NarraFirma software for Participatory Narrative Inquiry my wife (Cynthia F. Kurtz) and I created (written using TypeScript, Mithril, D3, and Node.js -- plus a PHP WordPress plugin for easy install), groups can collaborate in fine-grained ways on projects when supported by good applications that support such fine-grained collaboration. NarraFirma still uses a centralized webserver, but it would be easy enough to make it work in a more distributed way such as CouchDB/PouchDB enables or potentially using IndexedDB and some browser-to-browser direct communications like WebRTC since it is based on messages that generally define triples in a triple store. As Andrew implies, you can do messaging with central servers. That itself is not the issue. The issue is central vs. local, and shared vs. peered.

Browsers have not prioritized local and peer-to-peer

Why do we not see more of these possibilities in practice? Part of the reasons is that web browsers like Firefox have chosen not to prioritize making distributed local data easy to manage or exchange (even as that may be slowly improving). This Thunderbird announcement is just one more reflection of that.

It has even been suggested by others in a recent Soylent News discussion on the Thunderbird issue that some of that may be due to there not being an easy way to monetize supporting distributed data given an advertising-supported web model? https://soylentnews.org/comments.pl?threshold=0&highlightthresh=4&mode=nested&commentsort=0&op=Change&sid=10910#post_comment

I don't know if that is true, but as I said in my own comment there: https://soylentnews.org/comments.pl?sid=10910&cid=270813#commentwrap

"I can look in my Thunderbird app and privately review and privately search more than a million messages I've received stretching back for over a decade, as well as review and search tens of thousands of messages I've sent during that time. Tell me how to do that with a scattering of web services (other than poorly and publicly with a web search engine)."

I perhaps should have also added I can search a million messages in Thunderbird without an advertisement in view?

A co-evolution of a community with its tools, data, policies, and processes

As both Doug Engelbart and Clay Shirky have said in their own ways, a group needs to co-evolve with its tools, data, policies, and processes. Mozilla seems about to decide to stop co-evolving with a huge segment of the web community who still cares about privacy and security and reliability that comes from decentralized local data and peer-to-peer interactions as reflected in Thunderbird. While a small group, these people are often the ones who actually made the low-level infrastructure of the web. Unless Mozilla revisits that policy, whether that policy is intentional or accidental, ultimately it may be Mozilla that gets left behind -- not the core web community. Sure, Firefox has some peer-to-peer support (and that should be improved), but without reliable easy-to-use local data storage and without supporting current email protocols (email being the biggest peer-to-peer system there is), Firefox in those ways is just a shadow of Thunderbird.

Proposing Thunderbird Server to replace Thunderbird Desktop

So, what is to be done? Here is a a compromise until Mozilla creates better web standards for storing and viewing and exchanging local data and then implements them well (which I am all for). In the short term, we could create a Node.js application in JavaScript/TypeScript as a for storing, indexing, and searching millions of messages locally. It could use Mithril and D3 for the front-end, defining a complex singe-page webapp like NarraFirma has. In particular, Mithril can support browsing tens of thousands of list items if the code is written a certain way (as one demo shows). Mithril is very close to native HTML, one reason I prefer Mithril over Niklas's suggestion of AngularJS (even as I applaud Angular2's move to TypeScript). The backend could use using reliable mbox flat files of messages plus a more brittle rebuildable index based on sqlite as a start,. The backend would support complex searches commanded from the webapp via some JSON api (and run in the background). The index could support RDF-like triples exchanged in some messages (like NarraFirma uses) to support arbitrary distributed applications as plugins. Maybe CouchDB or Accumulo support would be added as storage plugins down the road, for people who want to store and search trillions of messages (including major parts of the freely licensed or fair use surface web they might copy locally or share with friends). Firefox (or any other standards-compliant web browser) could connect to this local Thunderbird Server. Being a server, families could share just one server if they wanted, or even companies could share just one, same as with, say, WordPress.

This system could as eventually do everything Slack could do, but would be open so that more plugins (written in JavaScript-compatible languages) could be added for real-time shared whiteboards, chatting, note taking, crowdsourced structure arguments, multi-perspective sensemaking tools, Compendium-like IBIS concept maps, and more. Such plugin applications might go way beyond regular email, to support things like splitting up long messages (like this one) into individual points that could become structured arguments in a web, or expandable outlines with summaries written later for major sections, or with added semantic metadata, with such textual refactorings then sent out as more emails or as other types of messages to be processed by others with those plugins. There could be a variety of plugins to democratize sensemaking and decision support by taking lots of non-secret technology ideas from the intelligence community (like ex-CIA officer Robert Steele writes about in "The Open-Source Everything Manifesto: Transparency, Truth, and Trust") and putting them in the hands of the everyone as Thunderbird Server plugins. Plugins could also be added to publish directly to WordPress or other platforms. Plugins could support basic JavaScript/TypeScript development locally (and some simple local JavaScript IDE examples are on my GitHub repositories but others could no doubt do better). Plugins could be written to allow new versions of emails to be sent with typo fixes. Plugins could be written to check the license status of viewed content and filter out unfree content by various criterion. Plugins could be written to keep local copies of Wikipedia pages, perhaps with improvements local to some community, more like Knol supported. Plugins could we written to interface with a variety of backend messaging services, like IRC, Jabber, Twitter, or whatever. Plugins could support end-to-end encryption in various ways, or even just coordinating direct https connections between web-based servers and relays (with this caveat I suggest on the limits of encryption when advocating for social change). A plugin could be written so Thunderbird Server could act as a proxy for web browsing, which would open a whole new level to provide customization and filtering to incoming web content a user was viewing (like Greasemonkey but at the server level). Such a proxy plugin could also provide easy local archiving of all websites you visit that you want to archive, and perhaps would support local group discussion tools and semantic desktop tools overlayed on all that third-party content. Such a proxy might also include a built-in "Read Later" functionality to help manage information overload. Node's socket.io would be used to support real-time collaboration beyond support for all the usual email protocols. An API could be added for plugins so these local servers could connect with each other via https as people wanted to collaborate in real-time across a network of Thunderbird Servers.

This Thunderbird Server software could run on a Raspberry Pi, or any desktop where Node.js is installed, and maybe even eventually Firefox OS someday (like when JXcore runs there). The team could work hard to make install go smoothly on all those systems, potentially even piggybacking on Firefox's install and updating process where a Firefox plugin would manage the Thunderbird install. Vendors might even sell US$50 Freedom-box-like "wallwarts" providing Thunderbird Server pre-configured for home use (in a FreedomBox-like way) where you just plug it in to power and your network and surf with Firefox to a local address like a home router and suddenly have all these amazing local semantic desktop tools. For those still stuck on an OS that does not run Thunderbird Server for some reason, they could buy a Raspberry Pi for cheap that does run Thunderbird server and connect to it over the network, or set up Thunderbird Server on a VPS somewhere.

There might even be a release that bundles Firefox in with Node.js as an executable application (similar to Chrome equivalents with Node.js apps and how Automattic now makes a WordPress Desktop App for Mac and Windows that wraps Calypso using Electron build on Chromium). Had Mozilla supported such a project four years ago, maybe Automattic would be building a desktop app based on Firefox and not Chromium?

While this would not be an initial effort, eventually it would be great if Thunderbird Server could run on Android and Firefox OS, so such devices could be used to host Thunderbird Server in a portable way you can carry with you everywhere you go. Using ideas from CouchDB, my own Pointrel system, Thunderbird Server could support master-to-master replication, so that you could keep some selected part of your Thunderbird content synchronized between, say, a desktop and your phone. But even without that kind of direct mobile deployment support for Thunderbird Server, an effort would be made so that Firefox users on mobile phones could easily use Thunderbird Server via the network in a mobile-friendly way for at least basic functions (such as reading recent new emails fitting some search criterion and sending simple short emails).

All the most important Thunderbird desktop plugins would be ported to this new Thunderbird Server system either by the project or by third-party owners. Hopefully the team could write a porting tool in TypeScript to make this easy, translating XUL to Mithril. Frankly, a major reason I've not written plugins for Mozilla products and been more tempted by Chrome is not wanting to learn yet another system (XUL) when I want to be using just plain HTML. I'd expect other existing plugin developers might be eager to leave XUL behind, so such a tool would be popular.

Security

The best arguments against this Thunderbird Server approach may relate to security.

The biggest one is about tool diversity and is that given your web identity is closely tied with your email address used to sign up for services, it is better to have a completely separate tool for managing those identity emails. So, if you are just using Firefox to browse your email, and Firefox is compromised, then your entire web identity could be compromised. I don't have a great answer to this, other that to point out that a lot of people already use webmail services. Also, if Mozilla is sponsoring this project, then the extra pressure and scrutiny for security may be of benefit to Firefox development. But if there were a single biggest conceptual reason this was a dumb idea, this would be it. On the other hand, if Thunderbird gets left behind as Firefox moves on to new rendering engines, unpatched vulnerabilities in Thunderbird will put Thunderbird users at increasing risk as time goes by.

Ideally, there should be some way to separate web identity emails more cleanly from other emails so they could be handled specially. That is probably an area that needs more research.

However, beyond that big conceptual issue of reducing tool diversity, there are other practical issues related to security. Existing webmail systems like SquirrelMail talk about multiple attack vectors:
http://squirrelmail.org/docs/admin/admin-8.html#ss8.1

"SquirrelMail is webmail interface written in PHP. Webmail interface could be attacked through specifically crafted emails, interface programming mistakes and user information hijacking. It can be used to send unsolicited email messages from a hijacked or abused email account. ... In order to prevent crafted email exploits SquirrelMail uses special htmlfilter library to filter dangerous html code and prevents loading of remote web data. Htmlfilter code needs constant updates because crackers discover various design problems in web browser and can try exploiting them in webmail interfaces. If you want to be safe, make sure that you are running latest secured web browser version and SquirrelMail scripts are not outdated."

Of those, the most crucial one here is probably malicious html email (even as the others would always be risks). Since it is hoped that Thunderbird Server will be extended by plugins, this risk goes even further to people sending each other copies of webpages or closely collaborating via whiteboards.

A few ways malicious html could compromise the system are if it tickles some browser bug to gain control of Firefox, if it does the equivalent of cross-site scripting, or if it affects locally stored data. Unlike malicious html you need to surf to, there is greater risk in a system where people can send you arbitrary content. That is a point made by Ben Bucksch on the tb-planning list.

There are few ways to deal with this risk; however managing this risk has to be an essential part of the project from the start, so these are just a few initial ideas. They are:

1. As much as possible could be displayed in plain text. That is the default I normally use for Thunderbird Desktop myself. When users don't choose this option, they could be informed about the risks, and maybe there could be a visual indicator of such?

2. Rather than use a blacklist htmlfilter that is brittle (as SquirrelMail says), an approach similar to the one NarraFirma uses would be a second level, where only whitelisted simple HTML constructs were approved. I have some code that uses Mithril to construct such output that is intrinsically safe, where problematical html results in an error message instead of the problematical HTML.
https://github.com/pdfernhout/narrafirma/blob/v0.9.5/webapp/source/sanitizeHTML.ts

3. Some sort of code that worked like Squirrelmail's htmlfilter could be added, as another display level (filtered HTML). Similar code could also score the likely threat potential of html, as in, if the html just has a few formatting tags, it might be low risk, but it if has images it might be medium risk, and if it has JavaScript it could be extremely high risk.

4. When you really wanted to see exactly the HTML sent, that could be displayed in an iframe with the content hosted in a subdomain. Since the Node.js server was running the whole system, it could easily create subdomains for every single email or other content to isolate content items from each other and from the core email application. This is a big difference from the setup something like a typical PHP webmail app like SquirrelMail would assume with just one responding domain that talked to the PHP code. Then Firefox's normal security boundaries would protect the user from malicious html that tried to affect the rest of the email system. Displaying such html email could still tickle bugs in Firefox, but there is no real way for Thunderbird Server to prevent that if a user wants to display complete HTML as sent -- other than maybe rendering the HTML on the server perhaps. A variant of this level might strip out JavaScript, but that can be problematical to do correctly.

5. As another level of security, Thunderbird Server could track digital signatures for content, and perhaps warn about unsigned content when you tried to display it as full HTML.

Let's say some of these are not good enough. This is an example of where Thunderbird Server could drive Firefox innovation. Firefox should then change to make it possible to do this safely -- whatever changes it takes to Firefox like enhancements to the security model for safe rendering of untrusted HTML. Third parties should not be having to constantly create adhoc mini-renderers and filters in JavaScript to display untrusted content; a web browser and perhaps the DOM itself should make that easy. Such security changes would not just be supporting Thunderbird Server. They would be supporting an entire new possibilities for peer-to-peer webapps. This is probably the most important reasons Thunderbird Server should be done as a Mozilla project, not as a project spunoff somewhere else.

A wild guess as to how long it would take

First, the following is just a wild guess, mostly based on the functionality that I use in Thunderbird (which is fairly basic), and how long NarraFirma took to make. It may be completely off. I downloaded a Thunderbird source tarball (comm-esr31) to try to get a line count, and it expanded to over one gigabyte of source. That seems just a crazy large amount of code. Much of it is no doubt duplicating what is in Firefox and so can be ignored if Firefox itself was used. I'm assuming that is the 922MB in the "mozilla" folder.

Of the remaining 8% of the non-Firefox code, "suite/mailnews" folder totaled 1.7MB which seems in the ballpark of the amount of code I might expect for an email application. Obviously, there may be various libraries and such that support that application. There is a "browser" folder under the "suite" directory that looks like it might belong to Thunderbird Desktop. So, stepping back a bit, the "suite" directory itself is 22MB. But there is also a "mail" directory at 22MB and an "ldap" directory at 15MB, and a "mailnews" folder at 26MB. And there are some other smaller ones like "chat", "calendar", "im", and "editor". I'm not really sure which of these is used by Thunderbird Desktop, as Seamonkey is perhaps mixed in there too? As an upper limit, the Thunderbird Desktop application itself is about 80MB of source. Probably, with duplication, that number might be smaller, so I'd guess at most 50MB? So, that is a big reason Thunderbird is so hard to maintain -- probably at least 95% of the Thunderbird source is complex software written mostly in C++ that has nothing to do directly with Thunderbird.

I'm guessing that number might even be as high as 97% of the Thunderbird codebase not being about email?

Further, it is possible some of the need for writing equivalents for that code would just go away if existing Node.js email libraries could be leveraged somehow? There is a 4MB "mailnews/test" file (a lot of it is data, but some is JavaScript), so it seems like there are at least some unit tests?

I'm sure I could figure this all out in more detail if I took more than the few minutes I've given to looking at that structure. But certainly, this indicates how Andrew is right about the "technical debt". It is hard to maintain code when you have to download and then paw through literally a gigabyte of code, where about 97% of it has nothing to do with the application in question.

It would be good to have a better estimate of application complexity from someone who knows the Thunderbird codebase well. And also, any estimate based on just the Thunderbird source ignores the issue of porting plugins.

I'm guesstimating, more based more on my use of Thunderbird than the above code size, that it would take is a year-long effort by a team of about seven people (developers, UX, testers, evangelists) to get a workable reliable Thunderbird Server system that almost all Thunderbird desktop users would want to switch to. In parallel with initial working prototypes for early feedback, another first step would be to inventory the available FOSS mail libraries and existing mail-related webapps (including the Firefox OS mail app) and see what might be useful and what needs to be written. Basic email import, retrieval from servers, reading, and search functionality could probably be running in a couple of months (perhaps building on something like emailjs), with more and more functionality then iterated driven from community feedback afterwards (like to make search better).

The results could be awesome. :-) And Mozilla could take all the credit for supporting an innovative effort created by working in public in an open way, including via the Mozilla Governance and tb-planning mailing lists. :-)

On whether much Thunderbird Desktop code would be reused

Writing an software application is often equivalent to walking through a maze when mapping it. You really can't see the whole thing at once, and you have to backtrack, and you may even end up going in circles for a time. When you get out of the maze, you probably will know the shortest way through it. It might have taken you hours to figure out such a path, but then someone with the map can walk through the maze in minutes by just following what you did. In that sense, I feel the biggest part of what Thunderbird Desktop supplies in the intial requirements -- that the end result of Thunderbird Server should do pretty much everything Thunderbird Desktop does. That is the maze of user expectations that has been mapped by Thunderbird so far.

As far as code goes, I expect most of the JavaScript/TypeScript code would be developed from scratch because most would relate to the UX or the Node.js backend.

The XUL code might just be completely thrown away, after perhaps consulting it for ideas and requirements. Still, if a XUL to Mithril/JavaScript tool was written, maybe some of the XUL might be worth using in translation to start with?

Essential parts of the C++ of Thunderbird Desktop could be extracted and translated automatically to JavaScript/TypeScript using Emscriptem/asm.js perhaps. Such transpiled code could then be refactored in idiomatic JavaScript/TypeScript as time permits. I'm not sure it would be worth that for any of such C++ code though, given email has standards which are consultable, and which should be improved if they are ambiguous or hard to understand. Extracting snippets of C++ so they compile might be a big chore with a lot of interdependencies. Without good tests to match the snippets, it is hard to know if they do the right thing. But writing such tests is probably a lot more work than actually writing the code. Still, it's likely that at least some of the C++ code would be an important reference, so I just don't know how much would prove useful.

Again, someone who knew the Thunderbird Desktop codebase well might have some valuable opinions on all this.

Eventually Thunderbird Server becomes a Firefox plugin

Eventually, the Firefox team could figure out how to integrate this sort of localized storage and peer-to-peer Thunderbird functionality directly into the Firefox web browser (like adding a Node.js-compatible JavaScript-based server to every Firefox install). Then all this Thunderbird Server code might even get folded into a major new Firefox plugin that used this new emerging defacto standard of robust-local-storage peer-to-peer capacity in Firefox.

As Niklas points out, such a complex and demanding application would provide another way to stress test Firefox, which might drive further Firefox innovation (as via providing ideas for Mozilla Servo). If there was some reason this Thunderbird Server approach hit a brick wall because of some limitation of Firefox (like poor performance in scrolling lists of items, or managing multiple windows, or whatever else) -- the Firefox team could prioritize fixing that in the next Firefox release, which would help Firefox grow. It would be reasonable for Mozilla to say that Thunderbird Server required Firefox for best performance.

Pick me! Pick me! Ooh, Ooh, Pick me! (Put your hand down already!!!)

I just applied for a Mozilla Growth Engineer job suggesting improving Thunderbird. So, I'd be very happy to implement this exact project over the next year. :-) Seriously, I could start today. I's be tempted to start it on my own if I hadn't just spent the past year or so blowing all my cash/credit on working for free on another JavaScript/TypeScript/Mithril/D3/Node.js FOSS project (NarraFirma) and so I now need to find a paying gig again. :-) But there is also not much point in my writing such software if there won't be users, and I doubt something I wrote on my own would have much traction no matter how good it was, and one person can also only do so much anyway. But there might soon be lots of users *if* Mozilla got behind this manifesto with a small skunkworks team, and said: "This is the way we are retiring Thunderbird desktop -- by replacing it with a modern web-technologies-based locally-storing peer-to-peer semantic-desktop-aspiring Firefox-friendly Thunderbird Server!" :-)

Make the old Thunderbird obsolete while moving forward to a web future

As Buckminster Fuller said, "You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."

The above is a sketch of how to produce something that most (admittedly, not all) Thunderbird desktop users would see worth the effort of switching to once such a server was proven stable. There would no doubt be a lot of complaints even if 10% of Thunderbird Desktop users did not want to switch (as that would be still almost a million users). But is's the best I have to offer that seems like a good path forward. As a downside, if 90% of Thunderbird Desktop users moved to Thunderbird Server, the remaining 10% of Thunderbird Desktop users would have an even harder time maintaining Thunderbird Desktop given less users to contribute; sorry about that. :-(

Software is hard, but it can still be worth trying anyway

It is possible the project was a flop for all of the many reasons
"Software is Hard" (and many software projects do flop):
http://www.gamearchitect.net/Articles/SoftwareIsHard.html

"But the nature of software is that the problems are always different. You never have to solve the exact problem that someone's solved before, because if software already existed that solved your need, you wouldn't have to write it. Writing software is expensive. Copying software is cheap. Scott Rosenberg coins this as Rosenberg's Law: Software is easy to make, except when you want it to do something new. The corollary is, The only software that's worth making is software that does something new."

Still, despite that risk, this effort would still be doing the right thing to affirm the core essential values of locality and peering that make Thunderbird great. And Firefox at least might still get better because of the entire process of trying to be a frontend to Thunderbird, so in that sense it could still be money well spent as far as just the Firefox team was concerned. :-)

Software as gardening leads to "ThunderbirdS are Grow!"

As Andy Hunt and Dave Thomas said related to their best-selling book of software best practices, The Pragmatic Programmer: From Journeyman to Master, "Rather than construction, programming is more like gardening."
http://www.artima.com/intv/garden.html

Bill Venners: In your book, The Pragmatic Programmer, you say, "Rather than construction, programming is more like gardening." I really like your gardening metaphor for software development. Can you elaborate on it?

Andy Hunt: There is a persistent notion in a lot of literature that software development should be like engineering. First, an architect draws up some great plans. Then you get a flood of warm bodies to come in and fill the chairs, bang out all the code, and you're done. A lot of people still feel that way. I saw an interview in the last six months of a big outsourcing house in India where this was how they felt. They paint a picture of constructing software like buildings. The high talent architects do the design. The coders do the constructing. The tenants move in, and everyone lives happily ever after. We don't think that's very realistic. It doesn't work that way with software.

We paint a different picture. Instead of that very neat and orderly procession, which doesn't happen even in the real world with buildings, software is much more like gardening. You do plan. You plan you're going to make a plot this big. You're going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You've got a great plan, a whole design.

But when you plant the bulbs and the seeds, what happens? The garden doesn't quite come up the way you drew the picture. This plant gets a lot bigger than you thought it would. You've got to prune it. You've got to split it. You've got to move it around the garden. This big plant in the back died. You've got to dig it up and throw it into the compost pile. These colors ended up not looking like they did on the package. They don't look good next to each other. You've got to transplant this one over to the other side of the garden.

Dave Thomas: Also with a garden, there's a constant assumption of maintenance. Everybody says, I want a low maintenance garden, but the reality is a garden is something that you're always interacting with to improve or even just keep the same. Although I know there's building maintenance, you typically don't change the shape of a building. It just sits there. We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time.

So, if Mozilla wants to continue to grow in a co-evolving local-data-respecting peer-to-peer way as above, I'm ready to help lead an international team of software gardeners to rescue Thunderbird from a decade of technical debt -- a team whose motto could be "ThunderbirdS are Grow!". :-)

Collaboration possibilities

And any current or previous Thunderbird desktop maintainers and C++ experts at Mozilla (including Andrew) who wanted to work on such a Thunderbird Server in TypeScript would be very welcome to join me. There is no doubt a lot of valuable domain knowledge about email they know which would make a Thunderbird Server project go a lot better and faster if they chose to help. I doubt the Node.js email handling libraries are very complete. But they would be by the time we were done with them -- another big plus for the web community whatever else happens. :-)

I'd also be happy to let someone else already at Mozilla take the lead here and just help out by coding away full-time on a Mithril GUI that duplicates Thunderbird desktop's functionality as a webapp and/or writing Node.js modules or such.

I'd much rather be coding cool stuff in TypeScript myself than begging higher ups for more resources or trying to "herd cats". But I'm willing to take the lead if no one else better qualified wants to.

--Paul Fernhout
http://pdfernhout.net

The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.

Update: 2015-12-11

I mentioned this manifesto on a Mithril mailing list.
https://groups.google.com/forum/?_escaped_fragment_=topic/mithriljs/RByPM02InVQ#!topic/mithriljs/RByPM02InVQ

Kyle Hayes there pointed out that Roundcube has just raised about US$100K on indegogo and suggested joining forces with them:
"Creating the future of email, together!"
https://www.indiegogo.com/projects/roundcube-next--2#/

"Online communication connects us all: friends, family, teachers, co-workers and collaborators. The Internet has transformed societies, and personal communication has been at the heart of that. Email, contacts, calendaring, instant messaging, collaborative editing and cloud storage are part of how we live, work and participate in society each and every day. Roundcube is the world's most popular open source webmail application. It is used by millions of people to access their email (and much more) on their own terms every single day. But we can't sit still. The web has evolved a lot in the last decade, and we want Roundcube to take full advantage of the best web technologies available as well as meet the expectations of today's users. We are calling this project "Roundcube Next"."

Glad to see someone in the web space understanding the importance of combining ideas about local storage and peer-to-peer messaging to provide privacy and security on the web and succeeding with funding that idea. :-)

Someone who is not waving dangerous bird-harming focused lasers around. :-(

After relying on Thunderbird for so long, it would be very saddening to have to consider something like an improved Roundcube for local email. Too bad Roundcube is in PHP (assuming they stay with that). Still as with NarraFirma, if most of the webapp front-end is in JavaScript (or transpiles to JavaScript), it almost does not matter what the backend it is in, because you may hardly touch it depending on the architecture.

Barney Carroll afterwards pointed me to mailpile.js which could be another project to join forces with up with (though the backend there is Python).

Sean Pappalardo on the tb-planning list pointed to SOGo as an open-source product with a Thunderbird-lookalike web interface. He raised some licensing concerns from a Mozilla perpective related to it's GPL/LGPL licensing. Another system (more of a library?) that has been mentioned on that list is email.js, most recently by Joshua Cranmer asking for help related to sharing code between email projects.

Quite likely, between RoundCube, mailpile.js, SOGo, SquirrelMail, email.js, and various other systems around, there could be various overlaps and synergies that could benefit the whole web mail (and more) ecosystem. Still, it's in the nature of writing complex software applications that differing assumptions get made that may make it hard to integrate components from one into the other. Andrew Sutherland made that point on the tb-planning list. It generally takes 3X to 10X the effort to make a reusable component than to make a locally-usable one. And often you just can't see the essentially generality to design a reusable component well until you have at least three examples from substantially different contexts.

Joshua Cramner suggested on the tb-planning list that:

For what it's worth, the rough list of stuff that is sanely shareable IMHO: POP, IMAP, SMTP, NNTP, chat protocols (IRC, Oscar, Yahoo, MSN, ???), LDIF, vCard, CardDAV, iCal, CalDAV, MIME (+ mbox, S/MIME, PGP, TNEF, uuencode, yEnc), SASL, Bayesian message classification, SIEVE/MANAGESIEVE. Probably a few utility libraries as well.

As I suggest in the proposal, it could be unfortunate for Firefox and Mozilla if someone other than Mozilla does this, because they would be missing the boat towards, as Niklas said, a way to really stress Firefox in new directions to help Firefox grow. As Ben Bucksch pointed out in "Why we need Gecko updates", it is hard to do webmail securely given the potential risks of processing HTML (especially when sent to you in messages targeted at you specifically). Putting those ideas together in the proposal, I suggest Mozilla and Firefox and the web itself would benefit from that challenge, as it might take changes to Firefox and even web standards to make such webmail reasonably secure if the webmail system was intended to support all kind of fancy plugins. Still, maybe Roundcube will prod Mozilla to improve Firefox, so that might work out OK in the end.

However, even then, current Thunderbird users relying on popular plugins will have to figure out how to manage without the plugins. Firefox marketshare won't be boosted by Thunderbird users who stay with Firefox *because* Thunderbird Server works best with it (from the most testing and from any emerging standards Firefox has implemented for Thunderbird Server).

Roundcube is good. I actually use it myself sometimes to check for new email via my email host sometimes when using a laptop computer I develop on besides my office desktop (before downloading my email to Thunderbird on the desktop). I even use Roundcube more and more to compose some short replies from that development laptop; I then BCC myself so Thunderbird gets a copy (although those unfortunately don't go in the sent folder). I wish Roundcube the best of success, and that success will benefit me in things I already do. However, "the woods would be pretty quiet if no bird sang there but the best" -- so, I don't think the web is better off having one less community with its own diverse approach to email.

How can a company like Mozilla that prides itself on diversity be so willing to discard the diversity of local peer-to-peer?

Anyway, we can dream even if our dreams may not come true any time soon. I had applied this week on Wednesday to Mozilla as a Growth Engineer suggesting improving Thunderbird, and I got rejected Thursday, which seems like some new record in HR turnaround. :-)

However, I've applied to Mozilla a couple of times before, including over four years ago for the Thunderbird team (also suggesting the social semantic desktop idea, and never hearing back that time that I recall). So, I'm probably in some list somewhere, maybe even for a good reason unrelated to liking Thunderbird a lot. :-)

It probably did not help my application that I mentioned the first two times I tried to submit my application using jobvite and Firefox, jobvite just discarded what I wrote without acknowledgement, and so, ironically, on the third time, I ended up using Chrome to apply to Mozilla for a job about growing Mozilla. :-( Still, as I use NoScript with Firefox, it is possible I did not enable enough stuff for that jobvite site to work correctly (but I have a lot of experience doing that).

It is not the first time I have not been able to use Firefox at a website. Uploads fail at Workable (where I applied recently for a Lead Software Engineer at VolunteerMatch). Even for GitHub, I have to use Chrome to upload releases now. That situation just makes me sad -- especially when I read in the news yesterday that after Mozilla's "laser focus" on Firefox OS, a focus that has for years starved both Thunderbird and Firefox Desktop of resources, and which many people have suggested from the start was a very problematical choice given all the failures in the mobile space, Mozilla is starting to throw the results away. :-( A related Soylent News comment and followup by me about that. But in essence, even as important as mobile is now, desktop Firefox and peer-to-peer email remain very important to the web. Is a "laser focus" even compatible with a realistic diversity needed by a large organization to grow? It is seedlings that someday grow into huge oak trees; burning all your seedlings down every year with a laser to protect the big oaks means that you will not have more big oak trees when the last ones fall over from internal bitrot and the winds of social change.

The mighty oak tree of Thunderbird Desktop seems about to fall over since, as above, about 97% of the code is unrelated to the application, and that technical debt makes it hard to maintain. I can still hope that Mozilla will put the laser down and think about the importance of birds and seedlings in a healthy ecosystem. :-)

As mentioned above, had Mozilla supported such a project four years ago, maybe Automattic would be building a WordPress desktop app based on Firefox and not Chromium? We'll never know...

What happened in China in the 1950s with a laser focus on eliminating sparrows is a cautionary ecological tale for Mozilla to reflect on: https://en.wikipedia.org/wiki/Four_Pests_Campaign

The four pests to be eliminated were rats, flies, mosquitoes, and sparrows. The extermination of the last upset the ecological balance, and enabled crop-eating insects to proliferate. ... The campaign against the 'Four Pests' was initiated in 1958 as a hygiene campaign by Mao Zedong, who identified the need to exterminate mosquitoes, flies, rats, and sparrows. Sparrows – mainly the Eurasian tree sparrow – were included on the list because they ate grain seeds, robbing the people of the fruits of their labour. The masses of China were mobilized to eradicate the birds, and citizens took to banging pots and pans or beating drums to scare the birds from landing, forcing them to fly until they fell from the sky in exhaustion. Sparrow nests were torn down, eggs were broken, and nestlings were killed. Sparrows and other birds were shot down from the sky, resulting in the near-extinction of the birds in China. Non-material rewards and recognition were offered to schools, work units and government agencies in accordance with the volume of pests they had killed. By April 1960, Chinese leaders realized that sparrows ate a large amount of insects, as well as grains. Rather than being increased, rice yields after the campaign were substantially decreased. Mao ordered the end of the campaign against sparrows, replacing them with bed bugs in the ongoing campaign against the Four Pests. By this time, however, it was too late. With no sparrows to eat them, locust populations ballooned, swarming the country and compounding the ecological problems already caused by the Great Leap Forward, including widespread deforestation and misuse of poisons and pesticides. Ecological imbalance is credited with exacerbating the Great Chinese Famine, in which at least 20 million people died of starvation.

So, sometimes a laser focus is incompatible with a healthy diversity.

Update: 2015-12-12

I sent this to the Mozilla Governance email list, but it still as of yet has not been approved by the moderator. Further update (2015-12-14): they posted it, but no replies yet: https://groups.google.com/d/msg/mozilla.governance/kAyVlhfEcXg/-NST0ZTeCQAJ

I fixed a few of the worst typos in it. Posting stuff at 5:30am after staying up all night working on it is always a dumb idea in a typographical sense -- or probably for other reasons too. :-)

Mitchell-

Thank you for bringing up these issues in a public forum and encouraging people to be vocal.

The Mozilla mission page says, at the top, "We’re building a better Internet", but then says lower down, "Our mission is to promote openness, innovation & opportunity on the Web." That mission page is surprising when you think about it, given that Mozilla seems to be confused about the difference between a whole (the internet) and a part (the web). On the the Mozilla Manifesto that situation is reversed -- "the web" is mentioned in the title up top and then not mentioned directly in any of the next ten points which almost all mention "the internet". That confusion may in turn lead to some conflicts and related strong feelings based on related misunderstandings or widely differing priorities.

If Mozilla's mission in really to build a "better internet", then abandoning email and instant messaging and other forms of peer-to-peer communication is a clear dereliction of duty, because those are important internet applications (even if sometimes limited resources do force difficult choices).

If Mozilla's mission is just to improve "the web" somehow, then it is easier to say email and IM do not matter to that narrower mission -- except incidentally, given the web would likely quickly collapse without email and IM to connect the maintainers of the web closely together in near real-time, and also that email and IM can be done via webapps communicating with web servers that act as gateways to non-HTTP internet services.

Below are observations, opinions, questions, and suggestions that elaborate on that theme to try to help move past that fundamentally confusing mission statement as it relates to Thunderbird. The deep question is, should such peer-to-peer internet tools that use local file storage like Thunderbird be something Mozilla cares deeply enough about to put a lot of money behind them? I hope Mozilla will consider the below before making a final decision on the issues you raised in your original email.

--Paul Fernhout (pdfernhout@kurtz-fernhout.com)

On Tuesday, December 1, 2015 at 12:29:47 PM UTC-5, Mitchell Baker wrote:

> Communications tools remain key, that's clear.  Today the big tools
> are WhatsApp, Viber, Line, etc.  These are the communications tools
> that hundreds of millions of people use as their home, and which are
> pushing us away from the Web and into individual proprietary product
> offerings.

Proprietary internet-connected applications like WhatsApp (instant messaging client for smartphones), Viber (text, picture and video messaging, voice calling), and Line (exchange texts, images, video and audio, and conduct free VoIP conversations and video conferences on a range of platforms) will come and go "today" based on paid promotion to drive up user numbers linked with fads about "the next great thing". I've only heard of one of those three before. I have not used any of them and nor do I want to (especially because they are proprietary). Granted, I'm not a teenager, and I am also not a big mobile phone user. In round numbers, investors have poured about twenty billion dollars into those three proprietary ventures taken together (just basing that mostly on Facebook's purchase of WhatsApp) -- but all three of these specific services can be replaced by similar alternatives as far as basic functionality. Each may not even exist as viable businesses in five years -- although no doubt then people will still be exchanging pictures and chatting with each other in some way or another, like via improved email tools. :-) None of those three apps are essential to maintaining a secure identity on the web in the way that reliable email is.

Twenty billion dollars could have funded more than 200,000 FOSS full-time developer-years of work on better email tools (perhaps a million developer-years total if in China or Eastern Europe or Russia). Socially, it is hard to argue those proprietary products were good social investments, even if they turn a profit someday. One may argue some of that money went to physical infrastructure for servers, but that infrastructure would not have been needed with a more distributed data and networking model. Also, the money to fund those proprietary products ultimately still comes from the pockets of the users, even if in indirect ways related to eventual product purchasing decisions shaped by advertising rather than, say, a direct tax. So, those three apps potentially cost society million person-years of FOSS development that did not happen. :-( Do you think even Facebook itself would still be interesting to anyone after a million person-years of coordinated development went into an improved Thunderbird that ran everywhere and did everything one might want to do related to real-time collaborative communications over the internet? What could our networked lives and the web be like right now if those (potential) million developer years would have been spent differently?

By the way, from Wikipedia on Viber:

"On November 4, 2014, Viber scored 1 out of 7 points on the Electronic Frontier Foundation's secure messaging scorecard. Viber received a point for encryption during transit but lost points because communications are not encrypted with a key the provider doesn't have access to (i.e. the communications are not end-to-end encrypted), users can't verify contacts' identities, past messages are not secure if the encryption keys are stolen (i.e. the service does not provide forward secrecy), the code is not open to independent review (i.e. the code is not open-source), the security design is not properly documented, and there has not been a recent independent security audit. AIM, BlackBerry Messenger, Ebuddy XMS, Hushmail, Kik Messenger, Skype, and Yahoo Messenger also scored 1 out of 7 points. In contrast, OpenWhisper Systems' free, open source TextSecure and Signal scored perfect 7 out of 7 on the EFF Secure Messaging Scorecard, as did the free ChatSecure, Cryptocat, Pidgin with Off-the-Record Messaging, and the commercial Silent Circle suite. Also Telegram scored a perfect score for its "secret chats.""

Those highly ranked systems mostly seem to follow the general open-source distributed Thunderbird model more? And presumably none of them had the same amount of money put into them as Viber?

Email has been with us for decades and shows little sign of going away. Mozilla had neglected this need for reliable email by reducing funding to Thunderbird and email-related research over recent years. Now Mozilla seems about to disregard entirely a fundamental need of literally billions of internet users by spinning off Thunderbird rather than investing in it to grow it into something even greater than it is now. A decision to spin off Thunderbird may be justifiable on short-term business grounds, but it is still sad.

Consider this report that predicts the continued growth of email in parallel with social networks:
http://www.radicati.com/wp/wp-content/uploads/2013/04/Email-Statistics-Report-2013-2017-Executive-Summary.pdf

"The total number of worldwide email accounts is expected to increase from nearly 3.9 billion accounts in 2013 to over 4.9 billion accounts by the end of 2017. This represents an average annual growth rate of about 6% over the next four years. ... Email is remains the go-to form of communication in the Business world. In 2013, Business email accounts total 929 million mailboxes. This figure is expected grow at an average annual growth rate of about 5% over the next four years, and reach over 1.1 billion by the end of 2017. ... In 2013, the majority of email traffic comes from business email, which accounts for over 100 billion emails sent and received per day. Email remains the predominant form of communication in the business space. This trend is expected to continue, and business email will account for over 132 billion emails sent and received per day by the end of 2017. ... Instant Messaging (IM) is also showing slower growth due to increased usage of social networking, text messaging, Mobile IM, and other forms of communication by both Business and Consumer users. In 2013, the number of worldwide IM accounts totals over 2.9 billion. ... Social Networking will grow from about 3.2 billion accounts in 2013 to over 4.8 billion accounts by the end of 2017."

Key point: "100 billion emails sent and received per day". Email is how the web was built. Email is still what is used to keep the web running. Maybe that was and is a dumb idea given what a mess email is in practice (including from spam), but that's the way it is, and it does not seem about to change anytime soon.

I don't want to call those three proprietary services you mentioned fluff because I'm sure people like them and find value in them. Maybe I'll even feel forced someday by peer pressure to use one to communicate with someone I care about. But if those three services did not exist, people would easily get by through picking alternatives, including even better open source alternatives (or by just using email), and the web would hardly notice it.

By contrast, shut down all email communications, and how long would the web as we know it exist practically speaking, with no new validated website signups, no notifications, and no address books? How would most technologists do their jobs without email archives or newsgroup archives to consult? How would Mozilla itself function? Sure, Automattic uses blogs internally to great effect and reduced email traffic; however, it is not clear that scales to the public web though as at they very least you still need a notification system for new messages and some common reliable authentication system (which email generally is still used for). That is one reason why, as above, there are about a billion business-related email accounts in the world.

A downside of working in the middle of a jumping tech scene is it is all too easy to get caught up in hype cycles. Anyone around the Silicon Valley area is surrounded by technophiles rushing after the latest fad or the latest huge venture investment to be the next well-funded pets.com (as well as being a target of the paid hype machines that support them).

By contrast, I'm a trustee of my local rural historical society, and the whole board agrees computers are a real pain -- although since my career has involved programming computers starting with a KIM-1, my reasons for agreeing with that sentiment are mostly somewhat different than most of the other trustees' reasons. :-) From a historical perspective, it's not even clear any of these applications you list or many others have made our lives much better compared to face-to-face interactions (including eating meals together) than they have often displaced. They are for the most part all optional and can be done in multiple ways. Email is not optional today for almost any involved citizen. Every board member, even one who is over 90 years old, has at least one email account (even if they may not check them very often).

I predict that in ten years, all my local historical society's board members will still have an email account (or equivalent, if peer-to-peer email etc. improves fundamentally), and each of those three services you mentioned will be long forgotten and replaced by some new similar service (or via an improved email or IRC system).

Of course, as Alan Kay says, the best way to predict the future is to invent it. On and off, something better is what I and many others been working towards for many years with hopes for creating something like a
"social semantic desktop". I'd suggest Mozilla consider innovating in that area as well, such as by bringing web technologies to the local desktop (as with creating a new Thunderbird server version to replace a hard-to-maintain Thunderbird desktop version).

> As advocates of open source or public benefit, and / or
> standards-based interoperability we have a lot of work to do here. I
> do not believe an email centric client like Thunderbird is going to
> win these people back to the old model.  Mozilla needs to lead in the
> new model.

Thunderbird's current implementation is hard to maintain. Why is that? Looking at the codebase for the first time yesterday, about 95% of the Mozilla communications codebase (literally more than a gigabyte of source) has nothing to do with the communications task as it is a copy of Firefox (yet, that copy must be kept in sync with a mainline Firefox, that essentially does not care about downstream breakage, for security reasons). C++ is a terrible choice today for an application where speed or low-level control is not a significant issue (and they are not for Thunderbird). XUL is on its way out. You made these points more indirectly in your original post to this thread. So, yes, the bathwater (the Thunderbird implementation) needs to be thrown out sooner or later. But the baby, email (or more generally, peer-to-peer data exchange of locally stored data), as well as the existing Thunderbird developers and users, should not be thrown out with the bathwater.

Yes, Mozilla should lead in the "new model". But what is the new model? And what should it be? And is the new model "the internet" or is it just
"the web"?

For a while, Firefox OS was the shiny new model (even with a huge chorus of people pointing out a landscape littered with mobile phone failures). But now Mozilla is starting to back away from that Firefox OS model after watching Firefox desktop get starved for resources and seeing Firefox OS get little traction in the cell phone market (as many predicted).

Especially, should the new model be more centralized and client-to-server and proprietary or more decentralized and peer-to-peer and FOSS? I'd argue decentralized and peer-to-peer and FOSS is more democratic and more resilient. Mozilla could still perhaps win big in the mobile space by making peer-to-peer FOSS apps for all mobile platforms that interoperate with the desktop and relay servers. Such mobile apps, built for Android and iOS with web technologies, but operating via "the internet" than "the web", could still produce a huge positive benefit for connecting people and supporting small groups in our society. As Margaret Mead said, "Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has." Such apps to support such small ad-hoc groups could even be called "Thunderbird" apps.

> Mozilla has both the opportunity and the challenge to have impact at
> a large scale.  I'm serious about the challenge part.  It's hard to
> do of course.  But the challenge I mean here is that there are plenty
> of good open source projects that one wants to see succeed that don't
> make sense to integrate into mozilla build or technology
> infrastructure.  I recognize this is painful for Thunderbird, which
> is partially integrated now.

The above statistics say there are about four billion email accounts, three billion instant messaging (IM) accounts, and three billion social media accounts globally -- or about ten billion accounts in total in the world. So, from one point of view, maybe this suggests Mozilla should be spending about 70% of its budget on supporting better email and instant messaging to have a proportional impact at a large scale on the internet (as opposed to just "the web")? :-)

What percentage of Mozilla's budget does it actually spend on supporting those two types of accounts (email and IM)? Maybe one percent if that? How is that justified?

As above, yes, please throw away the Thunderbird implementation as soon as is reasonably possible. :-) Even the remaining maintainers will probably cheer! :-) Who wants to spend all their time mostly just dealing with breaking changes from an underlying HTML rendering engine not designed to have stable APIs instead of improving an important application? But don't throw away the developers or the user community. Let's just take the essence of Thunderbird and put it on modern web technologies (JavaScript, HTML, CSS, and DOM). And let's have a clear path forward for existing Thunderbird users.

A way forward, suggested in September by Kent James (and later reprised by me, not knowing then of his earlier suggestion) is for Mozilla to create a locally installable Thunderbird Server that provides peer-to-peer communications services accessible through a webapp or possibly other clients as well. These services could include email, IRC, news group reading, RSS feed reading, notifications, and also a variety of other services via plugins (audio, video, whiteboarding, note taking, web page archiving, structured arguments, IBIS diagramming, file sharing, and more). Initially that server could be on Node.js, with the hope that Firefox itself could host that as a plugin at some point. Such an approach could also be adapted to create Android and iOS Thunderbird mobile apps as well, although ideally the Thunderbird Server webapp would run well in Firefox mobile (or Firefox should be improved until that was the case).

The direct cost of such an effort initially would probably be (guesstimating) about a million US dollars, as it would probably take about a year for seven developers building on existing JavaScript libraries for email handling and other peer-to-peer communications and custom service interactions. Or about 1/20000 of what went into those three apps you mentioned. The results would be Mozilla empowering users to store data locally and share it peer-to-peer across the internet -- as well as a whole new industry of web hosts supporting this same email system for users who want someone else to do backups and keep up with patches and security issue. That is clearly within the mandate of making the web a better place. And it clearly just a tiny fraction (less than one percent) of Mozilla's annual budget.

Such an effort would provide a huge incentive to improve Firefox to support use in new ways (including easily displaying untrusted content securely in webapps, and supporting custom desktop apps in the same way Chromium does without requiring people write them using XUL). Firefox has emulated Chromium recently in all kinds of ways that many people have complained endlessly about, yet in this essential way of supporting easy embedding into desktop apps that any Firefox aficionado would approve of, Mozilla has lagged behind.

Beyond the value of such a communications platform itself, if Mozilla had prioritized this need to improve Thunderbird four years ago, Mozilla might have improved the Firefox platform in ways that helped keep up its market share up because Thunderbird was showing a need that became Electron and Phonegap and other similar software. Then open-source-friendly companies like Automattic might not be turning to Electron/Chromium for creating a desktop WordPress/Calypso app instead of using the Firefox platform. In fact, if Mozilla has done such a thing, is it possible that much of the time and money and attention that has gone into WhatsApp, Viber, Line, etc. might have gone into an enhanced Mozilla Thunderbird and Firefox instead? Maybe then Firefox market's share and Mozilla's revenues might have even expanded rather than contracted? Instead, by ignoring the needs of Thunderbird and the internet users it serves, by not trying to grow in that area, Mozilla missed a huge business opportunity.

It's too late to change the past, but we can think about improving the future. One issue may just be that Mozilla has a fundamental conflict of interest between supporting access to proprietary mostly-advertising-supported web sites (Firefox) and making them less necessary (Thunderbird)? That's a difficult issue to think through. Within a capitalist society, there is a lot of money to be made by privatizing gains (usually by centralizing systems), socializing costs and risks (including the social cost of harming face-to-face community), and creating barriers to entry (including by disempowering users and reducing their options for switching services when possible). Many web services fit that model (although rare exceptions like Craigslist buck that model with their focus on helping users get together locally). By contrast, socializing gains, privatizing costs and risks, and empowering users is traditionally what charities or governments do.

So, there is lots of money available to tell people how important centralized proprietary systems are (even when they really are not). There is little money to tell people how important decentralized open systems are (even when they really are). I'm writing this email staying up to 5:30am local time when I should be sleeping, and I'm sure those three companies you mentioned could instead put 100 people working 9-5 for months to convince you the ideas in here are stupid. :-) Even if they probably won't, on the assumption this will just be mostly ignored. Perhaps the same thing might happen with different groups if I was vocal enough about broccoli being generally healthier than candy? :-)

Thunderbird is something really different from a typical web startup by empowering users to manage their own data. The problem is, for Thunderbird, as with other FOSS applications, it is hard to find a big source of revenue empowering users with free software. And it is very hard for people to maintain complex software and support a large user community when they have a separate day job (it can even hard when it is your day job). Selling access to eyeballs is just more profitable -- but that does not make that more important in a democracy. Ideally, governments and foundations interested in promoting democracy would be pouring billions of dollars year into peer-to-peer research and an even better Thunderbird, but instead we get more draconian copyright laws where people (in theory) face more jail time for sharing music than for committing murder and also lots of funny commercials on how wonderful it is to use proprietary services and related potential spyware. Mozilla is caught in the middle of that socioeconomic situation.

There are around half a billion Firefox users globally, but only about ten million Thunderbird users (so the Thunderbird user base is about 2% of FireFox's user base). Mozilla makes most of its revenue from partnerships with big companies related to advertising (especially for a default search engine); so there is indeed no large short-term business reason for Mozilla to spend any significant part of that revenue on something like Thunderbird in itself. But even 2% of the Yahoo US$300 million a year would be US$6 million a year, which is a lot more than I suggest a project to create a Thunderbird Server would cost if run well.

It's also not clear how Thunderbird, even a server version, would ever bring in significant revenue (beyond a search engine partnership or other advertising). Thunderbird is a bit like Craigslist in that sense -- it can help millions live better lives in a clutter-free way if it stays modest, but most of those users won't ever appreciate the technical effort and personal generosity that went into all that. Ideally some foundation would pour millions (or even billions) of US dollars into a new Thunderbird just because it is the right thing to do (while also funding other great FOSS webmail systems out there like Roundcube or mailpile to provide a diversity of implementations). I feel, historically, that foundation should be Mozilla as far as Thunderbird goes, and Firefox would also indirectly benefit from it. Still, maybe politically from a short-term business perspective, Thunderbird should better find a new home -- maybe it should just go somewhere it is really wanted even just for community morale reasons?

Frankly, as I see it, if you look at the adoption trends, and consider the rapid rise of Slack, between Firefox and Thunderbird, an expanded Thunderbird is actually the more viable product concept long-term. :-) But I am sorry to have to say that as a long-time Firefox user. :-( As a supporting example, after a couple of failed tries with Firefox, I had to use Chrome just to send in a job application via Jobvite as the submit button did not work correctly with Firefox and selectively-enabled NoScript options (it just ate the entire application as it reset the form). So, I eventually had to use Chrome to apply to Mozilla earlier this week for a Growth Engineer job. :-( And I'm finding I need to use Chrome to upload things to GitHub and Workable as well. Meanwhile, applying for jobs via Thunderbird still works as well as always. :-) Those are just a couple anecdotal data points; I can hope they do not really reflect a permanent trend.

The key reason for Mozilla not wanting Thunderbird and seeing it as a "tax" is not, as above, that email and IM and other peer-to-peer and local file storage are not essential to the internet and even the web. They are essential.

The key reason is not that Thunderbird is drowning in technical debt and needs a complete refresh. Lots of apps need complete overhauls from bitrot now and then. Like G. K. Chesterton said: "All conservatism is based upon the idea that if you leave things alone you leave them as they are. But you do not. If you leave a thing alone you leave it to a torrent of change. If you leave a white post alone it will soon be a black post. If you particularly want it to be white you must be always painting it again; that is, you must be always having a revolution. Briefly, if you want the old white post you must have a new white post."
As above, companies are willing to spend *billions* of dollars to get software that works. For many, a million dollars would be next-to-nothing. Even for Mozilla, it's not much.

The real key reason and deeper issue is just that empowering internet users is not a very profitable part of "the web". It is hard to swim agains a tide of social recession that (web) capitalism can create.

In a different sort of world, there would be a bunch of well-funded people eager and able to take on the challenge that Joshua Cranmer laid out a dozen hours ago on the tb-planning email list (Fri Dec 11 16:08:08 UTC 2015, Why we need Gecko updates) of finding commonalities across email application libraries -- with so far no replies. He wrote: "Having talked with both the Gaia email and the emailjs.org people, I've more or less gotten people to agree on some of the changes to be made, but I've lacked any time to actually develop those changes. If people can spare some time, fleshing out the email-socket library and hooking up smtpclient and email-sasl to that would open the doors to being able to share some more code between various email projects." That is amazing progress -- if there were more cycles to help him. But those cycles mostly go to Slack, WhatsApp, Viber, Line, etc..

And also, Mozilla has just not in the past culturally emphasized supporting those seven billion accounts (email and IM, 70% of the total) by writing breakthrough new software to support those activities well. That cultural bias to ignore the less visible part of the internet is perhaps one reason proprietary solutions like those three examples you provided and even now Slack have proliferated in that instant messaging void. That is why the funds for up to a million FOSS developer years have instead gone to forge shackles instead of keys. If Mozilla had poured a tiny fraction of the money that went into Firefox OS into re-envisioning Thunderbird, maybe FOSS developer Automattic would not have recently embraced a proprietary Slack as the way to store a lot of potentially sensitive information (including job interviews) at a potential major competitor in the internet communications space. And maybe Mozilla Governance might not be hosting its email list on Google Groups (where, to begin with, there is no easy way to get all the archives in mbox format).

So, given the confused Mozilla mission statement, and given current web economic realities, it's hard to disagree that it makes short-term business sense for Mozilla-as-it-is to continue to defund Thunderbird and throw it away (maybe hoping someone else funds it, which indeed might happen). It is mainly just bad for democracy not to have tools like Thunderbird and to have no one who seriously promotes them. And in the long term, it might be bad for Firefox to not be co-evolving with tools for email and IM and other more peer-to-peer real-time activities (like white-boarding) that an enhanced Thunderbird Server could provide.

Update: 2015-12-12 again, with Thunderbird server / Twirlip sprint agenda

Below is an ambitious "hard fun" agenda I am pursuing over the next week with user stories and task to create a proof-of-concept for a Thunderbird Server application along the lines of the "ThunderbirdS are Grow!" manifesto. The hope is that by the end of the week the entire system will work well enough to actually be useable directly (if no doubt painfully) by a development team to discuss further improvements of that software in a bootstrapping (Engelbart) way towards becoming a "social semantic desktop". Goals include reading and annotating RSS feeds, IRC chat messages, and Thunderbird and pipermail archives; receiving POP3 email and sending email via SMTP; and supporting creating and editing wiki pages and IBIS diagrams via sending structured emails composed by plugins. If the sprint goes according to plan (and things rarely do) hopefully this next Thursday I will be able to send an email to this tb-planning list from the resulting application. :-)

As I said, it is an ambitious agenda, but not quite as impossible as it may seem at first given I've just spent a year making a single page FOSS webapp and have also written some other code that I can draw from. Of course the UX is going to be simple and ugly, but hopefully it will prove the concept anyway.

Even if that project goes no further than a one week sprint, it hopefully will be something people on the tb-planning list could point to that implements Kent James' suggestion from September (however pitifully) when discussing what might be possible for a more serious project with broad community support. That way, people without webapp experience could see what might be possible by looking at some screenshots from real software (and maybe a demo video eventually).

Because this is not an official Mozilla project, I'm calling it Twirlip and not Thunderbird (not wanting to get into legal trouble with Mozilla for trademark infringement or to cause any confusion with Thunderbird Desktop users). I've used that Twirlip name for previous information management experiments, and I feel it fits this as well, even if the focus is a bit different this time by putting email at the center of things. By coincidence, the "T" in Twirlip can be seen to stand for "Thunderbird". :-) However, the project obviously could be renamed to Thunderbird Server or whatever if the project's status with Mozilla changed down the road (unlikely, but who knows) or with whoever ends up controlling the Thunderbird trademark after a spinoff. And as the project is under the MPL 2, Mozilla or anyone else could fork it and give it a new name they liked better.

If I had more time, I'd have involved people on the tb-planning list in planning this sprint, rather than just forge ahead without substantial discussion. Sorry for not doing that, as I'm sure the plan would be a lot better with feedback from people from the tb-planning list. Reading through the tb-planning archives, you all seem like a really great (if busy) bunch of people. Also, sometimes you just have to "code first and ask questions later" in an agile way (so, small coding steps), to get good feedback given an all too common "failure of the imagination". :-)

Below is the sprint plan, initial architectural choices, my motivations for doing it, a long-term invitation to collaborate down the road if this first sprint produces some good results, an explanation of why the plan is broad but shallow, and some other contextual information -- including at least one very good reason I should not be doing this proof of concept project. :-)

The project can be found on GitHub, but not much to see there yet beyond the MPL 2 license file and the agenda that is outlined below: https://github.com/pdfernhout/Twirlip2

Wish me luck! :-)

--Paul Fernhout

## Day-by-day user stories and tasks for Thunderbird Server / Twirlip

### Saturday/Sunday:

User stories:

* As a project owner, I need an initial project plan to develop a
proof-of-concept of a Thunderbird Server to help others imagine what is possible.
* As a project owner, I need a GitHub site so project developers can
share code.
* As a developer, I need a basic infrastructure so I can collaborate
with others to developers to create and test great software.

Tasks:

* DONE Write up this document.
* DONE Set up GitHub project (https://github.com/pdfernhout/Twirlip2)
* Create initial project package
* Make initial decision about file format for backend
* Create initial project build script
* Pick unit testing framework for client
* Pick unit testing framework for server
* Have Node.js host a webapp that displays "Hello World" or similar with
Mithril
* Verify the results of the hello world display as a test
* Create code to store immutable data in file system
* Create initial unit test for server that then stores and retrieves
immutable data from the local file system
* BACKLOG Hooking up tests and build script to a continuous integration
build server (would be nice, but that CI part is probably not gonna happen this week by me)

### Monday

User stories:

* As a user, I want to read project feeds so I can know what is going on
with specific projects of interest.
* As a user, I want to annotate feed information I am reading so I can
take further action on it later.

Tasks:

* Read basic RSS feeds into local storage
* Display feeds in a single-page webapp that uses JSON to retrieve data
from Node.js
* Support annotating specific items with text strings
* Support searching for items with specific text strings
* Support searching annotations with specific text strings
* Unit tests for each of the above (ideally written beforehand)

### Tuesday

User stories:

* As a user, I want to chat with other users so I can work as part of a
team.
* As a user, I want to make local notes on what other users chat about
so I can take action on them later.

Tasks:

* Create chat client to post and receive messages from IRC
* Store IRC messages locally
* Support searching an archive of chat messages locally
* Support annotating chat messages locally with a string (like for
further action)
* Use socket.io for real-time notifications to refresh the webapp GUI
* Unit tests for each of the above (ideally written beforehand)

### Wednesday

User stories:

* As a user, I want to be able to display existing email archives so I
can understand what is going on in projects.
* As a user I want to make local notes on prior email discussions so
that I can remember thoughts about them, plan actions based on them, or create summaries or outlines.

Tasks:

* Read existing Thunderbird mbox archives and store them locally
* BACKLOG Read emails from an IMAP account
* Read existing pipermail web archives and store them locally
* Displaying stored emails in a minimal way
* Support very simple exact text searching through stored emails
* Support annotations for stored emails
* Support overlays on top of existing messages with summaries or
outlines or typo fixes
* At a minimum as a test case, the application should be able to read
and display the tb-planning email list from pointing it here: https://mail.mozilla.org/pipermail/tb-planning/
* Unit tests for each of the above (ideally written beforehand)

### Thursday

User stories:

* As a user, I want to be able to send and receive plain text emails and
display simple HTML emails safely so I can exchange information with other users.
* As a user, I want to be able to use this system alongside an existing
Thunderbird Desktop install so that I can feel confident even if this system fails that I can just use Thunderbird Desktop

Tasks:

* Create GUI for adding information about email POP3 accounts
* Read emails from a POP3 account (without deleting them!)
* Provide configuration instructions for Thunderbird users on how to
leave POP3 email on the server for a few days after reading so this application can also pick them up (or do the next task)
* BACKLOG Read new emails from an IMAP account
* Make it easy for this system to quickly read new mail from a
* Support composing new emails in the webapp
* Support saving drafts of new emails without sending them
* Create GUI for defining basic SMTP information
* Send plain text email messages via SMTP
* Make first post to tb-planning sent from the application
* Read new tb-planning post either from a local Thunderbird mbox or by
reloading the pipermail archive.
* Unit tests for each of the above (ideally written beforehand)

### Friday

User stories:

* As a user, I want to be able to send all the annotations I made
locally in previous steps to others so they can review and comment on them and send back revisions.
* As a user, I want to create a wiki that other users can read and
improve with versioning so we can work together as a team.
* As a user, I want to be able to make, share, and collaboratively edit
Issue-Based Information System (IBIS) diagrams so I can work with others to understand complex situations.

Tasks:

* Create a module to send and receive annotations via email messages
* Send and receive email messages defining a triple store
* Create a module to interpret that triple store to define a wiki and
send wiki-related triple store messages to support updating the wiki
* Create a mailing list with a pipermail archive (or similar readable
archive) for this project which can support wiki interactions
* Put this document into the wiki by sending email about it to the new list
* Create a module to interpret that triple store as an IBIS map
(inspired by Compendium) and support editing of it in 2D
* Create screenshots and put them on GitHub
* BACKLOG Implement other plugin modules to support making lists of to
do items or user stories (like in this email), creating shared calendars, creating shared address books, using a virtual shared hierarchical file repository, creating and editing free form notes, creating and editing a spreadsheet of numbers and formulas in JavaScript, using 2D whiteboards, using 2D clustering diagrams, and/or sharing 3D objects.
* BACKLOG Support doing the same via IRC and RSS using a common
infrastructure if time permits
* Unit tests for each of the above (ideally written beforehand)

The results of all of these tasks will be very crude as far as UX but should be minimally useable for the tasks outlined. Ideally the resulting application should work well enough that current Thunderbird users with POP3 accounts with very basic email needs could switch to it as their primary email client and only use Thunderbird desktop only for more specialized cases (not without some pain and loss of functionality, of course). So, this first week will create a minimal "eat our own dog food" base that could be improved upon by a team using this exact tool over the next year to discuss and plan how to make something really awesome. :-)

## Architecture and other project information

License: MPL 2 for now. I'm open to perhaps changing that to Apache or maybe something else based on feedback if someone made a case for that soon. I don't especially know what is best here, and have tended to use GPL for previous large projects and MIT/BSD for smaller ones. Mozilla says Apache 2 is acceptable for new projects, but still seems to suggest MPL 2 for product code: https://www.mozilla.org/en-US/MPL/license-policy/

Storage: The system will work with immutable stored data when possible for reliability (with copies of archives being made if compaction of deleted data from files is desired, like with Thunderbird currently does). For that reason, the mutable mbox format Thunderbird uses can't be used as-is, because a character in mbox files for each message is changed to indicate flags. A file format that stores data incrementally will be used. This could either be some improvement to mbox to make it immutable but still support flagging items (as as read, deleted, important, etc.). Or, it could be very different as with CouchDB (looks like versioned documents) or recent Pointrel versions (storing JSON for each message that represents a change, either in separate files or in big files or segments of big virtual files). Eventually, to avoid archiving spam, a short-term staging area could be use for incoming messages, where only some get copied to a more permanent long-term archive (a bit like maildir). The storage system should be pluggable, so the initial decision of backend should be changeable. I'm open to using an existing Node.js module for this backend if that makes sense, as long as the data was immutable. But I feel flat files plus sqlite for indexing are probably the best way to go at first.

Webapp: The GUI will be Mithril because I know it and like it and it is simple to pick up and understand. TypeScript will be used for the webapp code. I will borrow from the NarraFirma project which used those technologies as needed (NarraFirma is GPLv2 but I am willing to re-license such tangential borrowings under the project's MPL2 license). The GUI should have pluggable modules eventually. BTW, I explain some reasons why I prefer Mithril over the more currently well-known React here:
http://buytaert.net/comment/120741#comment-120741

Server: The server will be Node.js because I know it and like it and it has a lot of basic email handling support. TypeScript will be used eventually on the server, but for this first week sprint, I'll stick with JavaScript on the server. Eventually such server code should ideally run under Firefox directly. The server modules should be pluggable too eventually.

Webapp-to-server communications: As with NarraFirma, all communications (aside from module loading) will be done via JSON to specify what data the webapp wants from the server and for the server to send back a response.

Plugin architecture: Just gonna wing it using JavaScript modules and some adhoc API... :-)

Trademark: Since this project has no official approval, it can't be called Thunderbird Server. So, I'm calling it "Twirlip" because I already have Vernor Vinge's approval from years ago to use that term for information management software -- the term comes from his book "A Fire Upon the Deep". :-) In this context, "Twirlip" could be seen to stand for: "Thunderbird Wholistic Information Resource Linking Integrated Platform". For now, I'm keeping Twirlip as a trademark I control myself. If Mozilla really wanted to support such a project, trademark ownership might be a non-issue as the project would probably then be called Thunderbird, or we could talk about Mozilla controlling the Twirlip trademark if it was used in a way to identify the sort of broad platform I've defined here and elsewhere, such as:
http://pdfernhout.net/thunderbirds-are-grow-manifesto.html

## Thanks and pull-requests welcome

In a way, I've been preparing for the next week for the last thirty-five years. :-) I've essentially been thinking about it fairly directly for about over decade on-and-off (even the idea of using email to define concept maps and such by extracting triples from emailed attachments or the body text). And such an ambitious agenda would not be (potentially) feasible without all the years of hard work a lot of other people have put into to creating the basic software components needed here (Node.js, Firefox, mail libraries, Mithril, etc.). It would also not be feasible in such a short time without my having written the FOSS NarraFirma webapp first and so having solved some issues that otherwise might vex me for weeks on ends (like rendering a limited subset of HTML safely, implementing a client-side triplestore, choosing languages like TypeScript, handling dialogs, providing toast notifications, making choices of other supporting libraries such as for server authentication, previous experiments with socket.io, and so on). And I have a lot of previous code to draw from on GitHub (like for IBIS diagrams). So, this project is hopefully going to bring together a lot of stuff in my life into a coherent whole. This would easily be a many-month-long project if I had not done all that preparation already.

And if you see I'm making progress down the road, feel free to submit pull requests for improved functionality for backlog items or all the many, many things the plan above does not include (to begin with, plugins to integrate with WordPress sites for reading and writing blogs, plugins to integrate with third-party proprietary services like Twitter, end-to-end encryption, composing emails in HTML, alternative conversational interfaces to improve a11y, complex content searches including with prepared indexes, markdown support, improved display of sortable lists of emails by having special server indexes, archiving web pages and displaying them in subdomains, acting as a proxy, and on and on). Anyone is welcome to join me constructively under the terms of the license sooner, but I doubt anyone will until you see significant working results after a week or more (and it may be hard to sync up at first, which might even slow this one week down but otherwise would be good to do long-term). I would not join such a project myself at the start either having seen so many people and projects not deliver, so no hard feelings. :-) Nor would I probably believe it was possible in such a short time. :-) The internet is littered with failed projects (and this may indeed become another one) and unfulfilled overly ambitious promises, so there is no real reason to expect this to be any different all things being equal. Also, people on the tb-planning list already have a lot of commitments to supporting other very good stuff (especially Thunderbird Desktop as-it-is which about ten million people rely on). So, I know there are few spare cycles here.

I appreciate people here being an audience though; thanks for that. :-) In the children's book "Mike Mulligan and his Steam Shovel", Mike and his steam shovel dig faster the more people watch (which tends to be the case for experienced workers, whereas novices tend to crumble in front of an audience). So, as with Mike Mulligan, just by just being on this tb-planning list, you are helping me do more and better work and make progress to towards the Thursday goal of sending an email to the tb-planning list from the ThunderbirdServer/Twirlip webapp. :-) Given "Software is Hard"
it is quite possible this effort will fail for all sorts of reasons. So, I too have my doubts, just like Mike Mulligan himself did. :-) That's the nature of software development. But at least this project will "fail fast" given this agile agenda, and hopefully even a failure might inform future attempts by others.

## What I might get out of this myself

I absolutely should not be doing this myself as my wife is going to be *very* cross with me when she finds out I'm doing this to take a week off instead of continuing to look for paying work to stave off impending financial doom related to a year spent developing our FOSS NarraFirma webapp. :-) As Mozilla already rejected my job application to do such work as a Growth Engineer, this effort is obviously not going to go anywhere financially that way. That is why I'm planning to ask her for forgiveness and not permission. :-) Then afterwards I'll stop procrastinating with projects like this and go get some "real" paying job somewhere propping up a proprietary status quo again (as I did with NBCUniversal for 2.5 years previously and so earned the cash/credit to write NarraFirma and even coast a little into this smaller project). Still, hopefully, a small success with this project will add to my webapp portfolio though and so make it easier to find a interesting job (once I lower my expectations from doing FOSS stuff). So, this project is not complete procrastination -- while still doing what I want to do anyway having gotten excited about Thunderbird Server. Seeing Kent James' earlier proposal about a Thunderbird server/webapp idea at least gives me some confidence this is not a completely useless idea; I probably would not be trying this if I had not seen someone else here thought some variant of such an idea was worth considering as a way forward. Thanks, Kent! :-)

And who knows, there is some tiny chance that maybe some organization other than Mozilla like that p≡p foundation in Switzerland mentioned by Ben Bucksch might see the proof-of-concept and think it is worth helping it move forward into something better? Related: https://pep.foundation/blog/thunderbird-is-endangered-and-needs-new-wings/index.html
"With the p≡p project, it is set to finally deliver free software for what the cypher-punk movement has been striving for since the late 1980s: Easy Encryption for Everyone!"

Still, what I wrote at the next link about the limits of encryption might not endear me to such a foundation. :-) Even as I feel encryption can be useful same as locks on houses, I feel it important for people to understand that encryption is not some magic shield protecting anyone from government, just the same as a team of police officers would make short work of almost any house door (or window) if they really want to get in. These days, you have to assume all your systems are compromised by multiple actors and always will be, and then go from there to build the best life you can given that -- either that or maybe I just watched to many "The Prisoner" episodes as a kid. :-)
http://www.pdfernhout.net/why-encryption-use-is-problematical-when-advocating-for-social-change.html

So, it's also a financial gamble for me in that sense -- very low odds of success financially, but possibly a high payoff of a good job. :-) At least, that is how I will try to spin this project to my wife when I eventually talk to her about it. :-)

But mostly I'm just doing the project because I think it will be fun and worthwhile and I want to use the result. I've been trying to find a good FOSS job for about six weeks and it is nice to take a break for a week from the job search before I lower my expectations for a next round of applications to proprietary places. As I mentioned in a post currently pending in the moderation queue at Mozilla Governance (and copied to the end of the Thunderbirds are Grow! manifesto), proprietary companies have tons of money to pour into privatizing gains and socializing costs (e.g. WhatsApp and Slack) and hiring full-time programmers to help them do that (typically by centralizing information and creating vendor lock in). While governments and foundations should be funding more work like this, they often don't for all sorts of reasons. In Mozilla's case, I think that is due in part to a fundamental confusion in the mission statement between supporting a whole ("the internet") and a part ("the web"). Peer-to-peer is a big part of the internet, and email is the real peer-to-peer success story (even if most email goes through relay servers). So, through a failure of collective social imagination, we see essentially the same money that could go into funding millions of person-years of FOSS development supporting privacy and freedom on the internet instead go into funding proprietary development supporting surveillance and constraints by the nature of how our current socioeconomic system works. Sad, but at least there are some small things one can do now and then as an independent here and there to help make a difference, including in this case, provide a proof-of-concept to think about. Hopefully this effort will help more than just waste valuable limited time of people here to read about it.

That all means that after a week full-time, it is most likely that this project will become, at best, something I can only put a couple of hours a week into as a hobby, like to merge in pull requests now and then. Or I might fix specific issues if I feel brave enough to start using it myself for all my own email instead of relying on Thunderbird Desktop most of the time. That is my hope that it works well enough to do that, but after a week I'll have to evaluate how realistic that is given how much I depend on reliable email and Thunderbird desktop. Part of the design goals above are to be able to run this system in parallel with a working Thunderbird install though, so I hope that may lower the bar of reliability enough that I could use Twirlip for things like writing this sort of email. For me, that would be a big win, to be using something I helped write to process my most core data (email). I've been toying with that idea for years, of software that could read my Thunderbird archives and do something with them, and this is finally a chance to turn those ideas into action.

## Why not a more realistic agenda?

This agenda perhaps should realistically be six weeks of work where each day here becomes a week-long sprint involving multiple developers where the whole planning process involves feedback from other developers here and the user community, especially in the creation of user stories. That would make such a project more true to the spirit of Thunderbird and its community of developers an no doubt would go beyond what I can provide myself (even as a long-time Thunderbird user, but one who has mostly avoided plugins and so has a narrower view than some). Not having that time luxury at this point though, I'll still do what I can where I can given a week-long timebox. While it might otherwise might make sense to spend a full week if I have that on just one of these days projects and do it better, without doing every phase of this agenda even in an abbreviated way, the results would not reflect the breadth of the proof-of-concept I have in mind. With a more limited approach, people would then just reasonable say, "oh that is another RSS feed reader", or
"oh, that is some poorly done email client", or "oh, yet another IBIS system big whoop", or "I already have a better IRC client", or whatever. It is putting these modules all together into something that aspires to be a "social semantic desktop" that is the essence of the big picture I'm trying to convey. So that is why this first sprint is going to cover a lot of ground but very shallowly.

As one of my personal heroes, Dan Ingalls, said about the initial coding of the innovative Smalltalk (in BASIC of all things): https://jaortega.wordpress.com/2006/01/31/dan-ingalls-videos-on-object-oriented-programming/
"You just do it and it’s done." :-)

This project is an iffy proposition for all sorts of reasons, like if existing Node.js mail handling and IRC libraries are just too buggy, or if I get called away from this project for some reason. I'm still hoping though something usable might be ready in a week if I try hard to do it. Time will tell.

Even if this specific project accomplishes this agenda in a week, the project may not go anywhere after that limited success though for all sorts of reasons. But even a limited success could still be a useful example for this tb-planning group to think about in terms of what a real Thunderbird Server project might look like if Mozilla got behind some future effort. So, I hope this project eventually adds to the discussion here one way or another.

If I don't respond to any emails about this project anytime soon, it will hopefully be because I am busy coding. :-)

ThunderbirdS are grow! :-)

--Paul Fernhout
http://www.pdfernhout.net/

The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.

Update: 2015-12-22 On funding

Responding to: https://mail.mozilla.org/pipermail/tb-planning/2015-December/004318.html

(Still coding away; got stuck in the mud of data storage so it feels like mbox but is more expandable, but feel like I'm getting some traction now... Also, one person volunteered to do some QA on it, so social progress!)

Still not ready to send stuff from Twirlip / Thunderbird server (still working on that), but as I wrote most of this already, I put together an alternative direction (or parallel direction) to what Kent wrote. Rambly, sorry, but all I have time for right now.

In general, it agrees with the key points Kent makes (volunteers are not enough in the current situation). It talks about four types of transactions (subsistence, gift, exchange, and planned) and the uses those to consider other alternative funding approaches (essentially, government and foundations), and provides specific people and groups who could be contacted in those regards (essentially, Thunderbird users at national laboratories and foundations, and also Richard Stallman of the FSF and Michel Bauwens of the P2P foundation). I suggest Mitchell Baker and Mark Surman (or others) could approach the top 35 funding foundations looking for (literally) a billion dollars to be put into peer-to-peer software, including maintaining Thunderbird and also developing migration paths to new systems. Part of the approach could be about dealing with "data smog" as well as ensuring privacy, FOSS, local data, and support for small groups of activists.

In general, the issue is that the current situation of Thunderbird support has not really grown organically over the last fifteen years or so, given the Mozilla background. Things changed a lot with the spinout, and this is all consequences of it. I had not really been paying attention myself much to it until Mitchell Baker's recent message. Thunderbird has just always worked well, although with a few bugs and awkwardnesses here and there I've managed to live with. But that message has brought what is essentially an ongoing (if slow moving) crisis into people's attention. Still, a crisis can be both a danger and and opportunity.

So, this is my own spin on: "What can be done to get some attention on this for that bug and many others?" I wrote this as a long email in Thunderbird, but as people often complain about long emails, I put the rest on my website at the end of the "ThunderbirdS Are Grow!" manifesto.
http://pdfernhout.net/thunderbirds-are-grow-manifesto.html

I can post it directly to the tb-plannning list if people wanted.

Back to coding... :-)

--Paul Fernhout

## Background on four types of exchange

Essentially, there are at least four major positive types of economic transactions in our society: subsistence, gift, exchange, and planned. A health economy needs all four of those. In the USA, over the past thirty years, the balance has shifted heavily to exchange. Now, in general, every software developer needs money to live in the USA. That does not mean software developers need to be "rewarded" for doing specific software development (that may even reduce output as Dan Pink talks about like in an RSA animate video on motivation, or Alfie Kohn talks about in "Punished by Rewards"). But it is hard to function in US society without some for of income (or a spouse or parent or relative who otherwise provides that, like Linus Torvalds starting Linux as a student). A "basic income" in the USA would help with that to acknowledge social equity and also the value of participation in non-exchange transactions, but the USA is not there socially yet, although some other countries are progressing.

Let's consider these four types of transactions in a Thunderbird context.

Subsistence: people fix bugs they care about or add new features they care about to their local copies.

Gift: People share their bug fixes, fixes for other people's bugs, and create and share new features other people want. People (not necessarily Thunderbird users) also give money to groups that maintain Thunderbird so they can continue to exist, and foundations also give money to Thunderbird maintainers.

Exchange: People fix bugs and add new features other people pay them to fix and add -- either in a fine-grained per-bug and per-feature bounty, or in a more coarse-grained way, like funding a collective of such developers who have some accountability somehow to the funders. That essentially seems to be what Kent is proposing here?

Planned: Government employees keep Thunderbird working as their day-job. The goverment says peer-to-peer is a priority and also funds it either within goverment labs, by contracts, or by grants.

Things get muddy when these streams get crossed, however they do get crossed all the time in practice, and that is unavoidable. When communities are a mix of motivations (not saying that is always bad), their can be friction between those who focus on sharing gifts and those who focus on exchanging service and code for money (especially as proprietary code tends to be proprietary and that creates other issues in an open source community). That friction may be in every community, and how it is managed is probably tied to the success or failure of such social groups.

Licenses can make a difference in that as well (like WordPress' choice of the GPL means all PHP-side plugins need to come with source and rights to redistribute it and change it).

There can be fuzzy lines in actions. People may make free software but also use it to promote a related consulting business (as with our NarraFirma project). To an extent, even donations to Mozilla can be seen as people exchanging money for supporting a general group they expect will deliver.

Since Mozilla has not been delivering much value recently for Firefox desktop or Thunderbird desktop users, it is natural such users might withdraw their contributions, even if they still believe in free software, democracy, privacy, and so on. Of course, Mozilla does other stuff like Firefox OS, and Webmaker, and more, so people can still find value in those things. And Mozilla talks about renewing support of Firefox desktop, so it's a complex topic of what people will fund with what expectations.

For more details on this general issue of different types of economic transactions, see this video I made on the topic or see the related PDF file of the presentation, which is summarized on the main page of my website.
"Five Interwoven Economies: Subsistence, Gift, Exchange, Planned, and Theft"
https://www.youtube.com/watch?v=4vK-M_e0JoY

Other people can no-doubt build a good case for funding Thunderbird in some exchange-based ways, and Kent has made such a suggestion. So let me talk about planned and gift ways here. To be clear, as above, in our society, this is not to dismiss Kent's suggestion. All these approaches can potentially co-exist depending on the specifics, the licenses, and the constraint of limited time to pursue any of them.

## Planned funding

My work on Twirlip / Thunderbird Server proof-of-concept and all those Slashdot comments (collected in a previous post to tb-planning) make me realize how I've had it so good for such a long time coasting on Thunderbird and all the hard work of people here. :-) The big innovation is to figure out how to deliver a free-as-in-freedom email/PIM tool while still having people support its development. And that is hard.

The US government should fund more open source software in this area, given it supposedly supports democracy and open source software can be distributed at little incremental cost. The German government with Kolab shows what is possible, as does Linagora and work within France.
http://kolab.org/
https://linagora.com/

After I get the Thunderbird Server / Twirlip POC working, I plan to apply to both of those companies in hopes they might be willing to support its evolution or integration with their offerings. :-)

The US government does fund some freedom-promoting technology in a little way through the Open Technology Fund (as part of Radio Free Asia) who for example recently funded the Briar Project for half-a-million dollars, and it's not clear to me much more it does yet than Thunderbird with Enigmail? https://www.opentech.fund/projects https://www.opentech.fund/project/briar

I suggest the Thunderbird Council could contact the Open Technology Fund for a few million dollars of interim development funds for Thunderbird as-it-is to ensure users in Asia have access to reliable encryption (as well as it works): https://www.opentech.fund/
"We love crazy new ideas that really change the Internet freedom landscape. That said, we support all kinds of projects at different stages of their life, new or established. Ideal projects fit within one or more of our main areas of focus below. If you have a project that you think OTF should support, please let us know and apply today!"

By the way, this is how I feel about encryption though, as a useful tool, but no panacea for ensuring accountable government, which probably does not endear me to cypherpunks: :-)
http://www.pdfernhout.net/why-encryption-use-is-problematical-when-advocating-for-social-change.html

I essentially make a point similar to here:
http://www.washingtonsblog.com/2015/04/mcaffee.html
“Encryption Doesn’t Matter In a World Where Anyone Can Plant Software On Your Phone and See What You’re Seeing”

One of the biggest difficulties with getting the US government to fund free software is that proprietary vendors are still so powerful they can lobby against it. That is probably one reason so much work is done for the government by contractors and universities that retain rights to what they develop as opposed to work done by US government employees that (generally, if non-secret) goes into the public domain right away. That is an implicit consequence of privatizing US government functions.

Still, if the Thunderbird council could locate Thunderbird users at major government labs, maybe there might be some connection there? Here are some of those labs as a starting point. https://en.wikipedia.org/wiki/United_States_Department_of_Energy_national_laboratories
http://www.dhs.gov/science-and-technology/national-federal-laboratories-research-centers

## Why the individual volunteer part of the gift economy is problematical for maintenance of Thunderbird as-it-is

Individual volunteers of course make the Thunderbird project go through their gifts of time. Whether that is enough depends on complex community dynamics. Free and open source is a terrific thing for the community; but in a society built more-and-more around exchange, funding open source can be problematical. Most of the "successful" business models around open source tend to be compromised in some way that development becomes incidental -- by selling installation support, training, manuals, customization, bug fixes, and so on, which all incentivize making software that is hard to install, hard to learn, undocumented, inflexible, and buggy. Even paying per new feature doesn't work that well as who maintains features or deals with conflicts between them?

Right now, as Andrew (a past Thunderbird maintainer) has repeatedly said, Thunderbird Desktop is suffering from huge technical debt. It seems to me the shift from funded development to community development that is problematical in the face of all that technical debt. Mozilla has already essentially kissed off Thunderbird Desktop, like any big corporation that divests itself of a subsidiary burdened with debt to improve its balance sheet. Basically, Mozilla abandoned the needs of ten million Mozilla users (Thunderbird users) because it realized it would be expensive to do something about the situation, and chose to do things like build Firefox OS and make Firefox look and work like Chrome instead (and some other smaller worthwhile initiatives like Webmaker). Mozilla still pays lip service to those users, but is not backing that as a priority with money for maintainers.

Yet, to do math like Kent has done differently elsewhere about Thunderbird fundraising, if there was ten dollars from somewhere for each Thunderbird users each year (US$100 million per year), we would not be having these kind of discussions -- we'd have other ones. :-) But, that is not completely unreasonable to expect. It really is not. All kinds of services get supported at the rate of US$10 per user per year and more. Consider, for example, taxes that support local libraries. And from one perspective, what is Thunderbird, in some ways, but a very local personalized library?

Still, in general, while Thunderbird does what it does well, technologies and expectations are changing out from under it. Thus my Chesterton's white posts must all be being painted white again just to maintain the status quo quote in the "Thunderbirds Are Grow!" manifesto. Examples of shifting expectations include the increasing preference for a web technology stack over conventional desktop GUI approaches, a preference for JavaScript over C++, a preference for accessing messages from multiple machines including phones, and a desire for integrated messaging (like the rise of a proprietary Slack demonstrates).

Based on what people here have been saying (or maybe I'm too much influenced by Kent's comments?), it sounds like the size of the current Thunderbird community of developers is below some critical mass needed to sustain the gigabyte-sized Thunderbird codebase for the long-term given all these challenges (especially when Mozilla cuts over to Servo at some point). That sounds like the kind of social issue that may just start to snowball, as bug after bug (like this one) then drives people to other solutions, and there are then less and less maintainers. And also, as other solutions get new features (like when the Kolab talk presenter in a video I linked to elsewhere talked glowingly about Kontact's ongoing innovation in comparison), then also their will be user attrition. Still, the reality has been that Thunderbird's user base has continued to grow -- which shows some kind of hunger for an alternative to centralized proprietary communication services.

That critical mass might be a lot lower if maintaining Thunderbird was a lot of fun. But it is the rare programmer who thinks it is fun to slog through literally a gigabyte of someone else's C++ (and some deprecated XUL) and fix other people's bugs and track random breakage from an upstream that plans to pitch the upstream codebase (95% of Thunderbird) as soon as possible.

It is hard to get programmers involved in projects that are no fun and also have a questionable future. I'm an example; I'm willing to put time into envisioning something new about communications with web technologies (or even adding to something like a WordPress plugin). However, even knowing C++, or especially knowing C++, I don't want to wade into a gigabyte of C++ developed by many other developers "for fun". I've done that kind of work for pay though like at NBCUniversal (even though it was indeed not that much fun, but the cash us make NarraFirma and now coast into starting Twirlip / Thunderbird Server).

Of course, some people are willing to support Thunderbird Desktop even if it is not that much fun in the same way others volunteer at nursing homes (for the good works and for interacting with other volunteers). And there are no doubt many wonderful people doing that for Thunderbird out of the goodness of their hearts. But, just as a social thing, it is going to be hard to recruit more people to do that, and I expect the burnout rate for current unpaid maintainers is going to be high. Even with volunteers, most nursing homes are going to need an income though and paid staff. And I picked that nursing home analogy, because it seems like that is, at best, what we are talking about for the current C++/XUL version of Thunderbird Desktop? We're talking about keeping it on life-support? Nobody so far seems to be talking about a Kontact-like resurgence of Thunderbird? Or do I have that wrong?

There way well be ways to get groups interested specifically in keeping Thunderbird on life-support even with the huge overhang of unpaid technical debt, where the interest on that debt is eating up any time volunteers have to do anything in new directions. It remains an important piece of software to ten million users. But it's a tough sell as a continued investment, given all that technical debt and those shifts in technology trends, and also some migration paths (like to Kontact for Linux users, or to various webmail systems like mailpile or Kollab and so on for the more technically inclined Mac and Windows users who are willing to run their own servers).

Essentially, Thunderbird was designed thinking it would be integrated with Firefox as part of Mozilla, and now that Mozilla has moved on, the codebase is in a problematical social and technical situation. Disentangling Thunderbird from Firefox is no doubt possible, but it will likely be a lot of work, and during the process there will probably be lots of C++ style bugs and security vulnerabilities. And who is going to audit all those new changes in C++? More volunteers we don't have?

## Support via the foundation part of the gift economy

Still, when you step back a bit, you can see Thunderbird as an example of essentially a peer-to-peer application. Yes, I know people often use that term differently, but in essence, ignoring email relay servers, Thunderbird is a peer-to-peer application, and one of the best and most reliable in the world. Of course, so are other desktop email clients like Kontact and so on.

So, I feel the best bet for Thunderbird (and the email space as a whole) may be to get a big foundation to literally pour a billion US dollars into the issue of re-imagining peer-to-peer. And then maintaining Thunderbird and migrating it forward in various ways would fit into that agenda, or at least, providing a clear and easy upward migration path for Thunderbird users? Just the other day, I saw a flock of geese going south for the winter -- birds migrate all the time, why not Thunderbird users? But hopefully to a better version of Thunderbird. :-)

I'm not kidding about that scale of funding either. :-) A billion dollars (even a billion dollars a year) is next-to-nothing when you consider how important communications are in the modern world. It might take the same amount of effort to get a foundation to invest a billion dollars as a million dollars. It may even be easier. :-)

The big challenge has been that people think that communications needs are being satisfied because those billions of dollars a year are being spent by proprietary companies like Facebook, Google, Yahoo, and now Slack. It's a complex case to make that a need is not being served when others can point to billions of (proprietary, centralized) dollars a year being supposedly spent to serve it. It is kind of like, in the same way, arguing that obese people who eat a lot are obese because they are actually malnourished and not eating enough of the right foods (whole plants, mostly). It's hard to tell sickly obese stressed out people that their problem is they don't eat enough. :-) Even when it is true. And the same thing is true for an infosphere that has become deeply polluted by commercialized "data smog". And it is less and less a percentage of the internet users who remember what the internet was like in the 1980s and early 1990s, or the web before mass commercialization.

See: https://en.wikipedia.org/wiki/Data_Smog
"It is argued that "Just as fat [and sugar / refined grains -- pdf] has replaced starvation as this nation’s number one dietary concern, information overload has replaced information scarcity as an important new emotional, social, and political problem." As per David Lewis, PhD in psychology, this attempt at consuming the majority of data, the result is what he calls "information fatigue syndrome." This term refers to the data smog that we encounter daily that ultimately interferes with our sleep, concentration, and even affecting our immune systems. According to clinical psychologist Michelle Weil "the problems stem from people’s overuse or misuse of technologies and from technology’s ineffective presentation of information, researchers are finding.""

Even Thunderbird contributes in its own way to that, but at least, with Thunderbird, you have ways to put in place filters and such to try to tame that somewhat. And we could hope for even better in years to come.

Yet, smog can be cleaned up with the right funding and right laws and right attitude. See, for example, Pittsburgh before and after:
http://digital.library.pitt.edu/images/pittsburgh/smokecontrol.html
http://www.theatlantic.com/technology/archive/2013/01/aghast-over-beijings-air-pollution-this-was-pittsburgh-not-that-long-ago/267237/
"Everyone knew that the smoke covering their homes and clothes and trees was bad. But it made a certain group of people a lot of money. And so they fought pollution controls. And those people had friends. So, while the American Academy of Arts and Sciences (granted, a less august institution back then) declared the health hazards of smoke and wondered aloud whether corporations should be allowed to produce what it called such "evil," a Pittsburgh doctor maintained that soot and smoke "only go throat-deep" and said that fire and smoke "correct atmospheric impurities." The politics of how this works are pretty simple. The smoke and the soot are something we recognize now as an externality. A cost of doing business that the business doesn't have to pay because they can dump it on society. Chinese citizens and activists and assorted air-breathers will have to get the polluting companies to internalize these costs. ..."

So, that is the moral and political case that surrounds the funding of Thunderbird (and related peer-to-peer software). How do we get funding for maintaining and improving software that deals with data smog, when a lot of very wealthy people out there have made a lot of money by creating data smog, whether spammers or advertisers or proprietary content creators or others? Even me with this overly long email (although I've been working towards having software to better handle such things). :-)

But the resources are there to deal with this data smog / proprietary / surveillance situation! See this discussion about an article Mark Surman wrote when he was a Shuttleworth Foundation (so, before Mozilla):
http://news.slashdot.org/story/08/04/20/1313223/is-open-source-the-answer-to-giving
"Mark Surman, Shuttleworth Foundation fellow, writes that open source is the answer to philanthropy's $55 trillion question: how to spend the money expected to flow into foundations over the next 25 years. While others have lashed out at 'Philanthro-Capitalism' — claiming that the charitable giving of Gates and others simply extends power in the market to power over society — Surman believes that open source shows the way to the harmonious yin-yang of business and not-for-profit. Sun, Microsoft, Cisco, IBM, Yahoo, and Facebook are big backers of Creative Commons; Mozilla has spawned two for-profits. Open source shows that philanthropy and business can cohabit and mutually thrive. Indeed, philanthropy might learn from open source to find new ways to organize itself for spending that $55 trillion."

Of course, someone like the Gates Foundation is probably not going to fund a lot of open source software given it's cultural origins it proprietary software. :-) But, maybe the Open Society Foundation or the Mellon Foundation or someplace like that might fund such a group?

Until then, I guess smaller amounts could suffice. But really, some foundation interested in open democracy should be funding open tools for open democracy. :-) I think such foundations have, like me, just taking it for granted tools like Thunderbird are always going to be around and ignoring how they get made and maintained.

As with US national labs, do people know any Thunderbird users at major foundations? If so, those people could be approached by the Thunderbird Council (or Mozilla) to get support for a tool the foundation is already depending on for its internal operations.

You might think Mozilla itself should have been that foundation, but sadly that does not seem to be the case. After making a related post to the Mozilla governance list replying to Mitchell Baker, I just keep thinking though about all the many many billions of dollars that go into building proprietary shackles (like Slack & WhatsApp) instead of open source keys (like Jabber and Thunderbird). That post: https://groups.google.com/d/msg/mozilla.governance/kAyVlhfEcXg/-NST0ZTeCQAJ

Why should billions of dollars not instead go into building new visions of Thunderbird plus maintaining what we have? Ten million people are benefiting every day from that work. It is not unreasonable to think that number might even grow substantially if Thunderbird itself grew in new ways (like Kent or I outlined with a web emphasis).

So, I wonder if there might be a foundation out there interested in open democracy that could literally throw a billion US dollars at this issue of peer-to-peer local systems as an alternative to centralized web apps? :-)

Mitch Kapor started that with Chandler, which did not work out, but that does not prove that idea of a great open source PIM tool was bad, even if the implementation and development team for Chandler did not deliver on the hopes. A successful Chandler might have helped with data smog in its own way. (I applied to the Chandler project too, btw, but as with Mozilla for that Thunderbird job in 2011, I don't recall hearing back.) As an article about Chandler says, "Software is Hard":
http://gamearchitect.net/Articles/SoftwareIsHard.html

Chandler's main mistake may have been not starting with the things Thunderbird does and then moving on from there? Once someone is using something for serious email, it's a serious app because it has serious stuff in it.

Whatever Mozilla's current trends to diminishing support for local data as with the Thunderbird spinoff, someone like Richard Stallman at the FSF gets the issue of liberating individuals through local information encouraging privacy. And it is what he has been talking about for years.

Related by Richard Stallman:
"Who does that server really serve?"
http://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
"Digital technology can give you freedom; it can also take your freedom away. ... If “cloud computing” has a meaning, it is not a way of doing computing, but rather a way of thinking about computing: a devil-may-care approach which says, “Don't ask questions. Don't worry about who controls your computing or who holds your data. Don't check for a hook hidden inside our service before you swallow it. Trust companies without hesitation.” In other words, “Be a sucker.” A cloud in the mind is an obstacle to clear thinking. For the sake of clear thinking about computing, let's avoid the term “cloud.” ... However, on a longer time scale, we can create alternatives to using servers. For instance, we can create a peer-to-peer program through which collaborators can share data encrypted. The free software community should develop distributed peer-to-peer replacements for important “web applications”. ..."

And also related to that theme on Facebook's CEO comments about contempt for his original users:
http://www.tomsguide.com/us/Facebook-Mark-Zuckerberg-Social-Networking-privacy-security,news-6794.html

In a previous email to tb-planning I suggested someone official contacting Richard Stallman, because he really appreciates the combination of Thunderbird as it is and GnuPG via the Thunderbird Enigmail plugin. If you could stress the urgency of the need to keep Thunderbird supported even with ongoing trends, maybe you could form a partnership with the FSF. But the FSF is not a "foundation" despite the name; it is an advocacy non-profit with no substantial assets (beyond goodwill). I'm just thinking that link may help somehow in building others.

There have been several other foundations mentioned on this list (e.g. Document Foundation) as well for homes for Thunderbird. I don't know if they actually have any assets to fund maintenance and development themselves though. So, the kind of "Foundation" I'm talking about is different in that sense. And the funding foundation does not have to be the same as the software's legal home, and may well not be for legal reasons related to limited-liability (in case the software developers get sued like over software patents or whatever).

## Building the moral case for broad support for peer-to-peer

Peer-to-peer has been vilified in the mainstream supposedly because it has been used to facilitate copyright infringement (or worse). In a way, that is like vilifying automobiles because people can use them in bank robberies as getaway cars. Peer-to-peer is at the heart of a democracy. Such tools should be broadly supported for political and moral reasons. The P2P Foundation (not a funding foundation) is an top of all that:
http://p2pfoundation.net/Main_Page
"The P2P Foundation is an international organization focused on studying, researching, documenting and promoting peer to peer practices in a very broad sense. This wiki is our knowledge commons. "

Michel Bauwens is another person to coordinate with on peer-to-peer support, and may have other funding ideas for Thunderbird and beyond:
http://p2pfoundation.net/Michel_Bauwens/Full_Bio

Beyond the issue of "data smog", there has always been a big doubt in the back of my mind about all of those centralized and proprietary services for social media and communications like MySpace, Facebook, gmail, Yahoo, LinkedIn, and now Slack, because they make it easy for someone to aggregate a lot of data about a person and also on the person's friends. For example, that's one reason I don't have a LinkedIn account even though it hurts me professionally given the current expectations these days. I consider something like LinkedIn to be morally wrong in a sense -- although, I guess that might be silly given Google or Duck Duck Go or whoever will still crawl email archives and such and put together social networks, so obviously it is not black and white. I refer to LinkedIn myself quite a bit -- although I would be happier to find personal/professional websites. Maybe I'll cave someday to peer pressure and get an account there, but that's how I feel about giving a third-party all my professional (or personal) contacts.

I has been saddening to see the rise over the past fifteen years or so of MySpace, Facebook, Yahoo mail, gmail, etc. versus personal websites and desktop email clients. I still remember the web of 1997-2000, and it was such a different place. It's also sad now to see Slack displacing IRC and a whole lot more -- without any substantial discussion of what it means for a company to put their entire corporate knowledge base offsite in someone else's hands. Working on RSS feed reading, which I've mostly ignored in the past when RSS was a big thing probably a decade or so ago, really drives that point home, as I poked around to find some contrasting RSS feeds, and yet also see stuff scrolling off of them quickly, like the one for the Whitehouse press releases. These are things to consider in creating a moral and political case for investing in better communication tools like better email clients etc..

WordPress and related software like Drupal though has been a ray of sunshine in all that (probably hosting more than 25% of websites together), and is what a lot of people turn to as an alternative to communicating through Facebook (or email). While it may make sense for a lot of people to host at a locked-down WordPress.com, the fact that there is an open-ended WordPress.org distribution that you can run locally if you want makes all the difference -- especially that you can fairly easily migrate from one to the other. So, even if the Thunderbird project itself does not go in the direction of this proof-of-concept Thunderbird Server experiment, I'm realizing such code could probably run in front of WordPress or Drupal as well (in a "decoupled" way). That's not my main expectation of how most users would deploy an email-focused client locally (Node.js is easier to manage than the current typical WordPress stack of Apache+MySQL) -- but considering other web deployment options does suggest a way to leverage interest in such a Thunderbird webapp project.

So, there is a need to find like-minded people, who care about such issues, and ask them to put a lot of money into the peer-to-peer space, of which Thunderbird is one example (perhaps the best) of software that works well and has broad adoption by ten million users.

## A TODO list for Mozilla that sadly may never get done

As I pointed out in my email on the Mozilla Governance list replying to Mitchell Baker, there is a fundamental conflict of interest between Firefox (funded by Google and then Yahoo and some others mostly because it provides access to social media and related advertisements via the search bar) and Thunderbird (which helps people avoid all that).

Mitchell Baker is obviously a persuasive person, and she is earning the big bucks no doubt in part of that. Perhaps she could persuade some big foundations (as in, US$ many billions of dollars assets) to put a lot of money into open source software for democracy, rather than relying on a funding approach that involves partnerships with proprietary messaging companies? With money that was less conflicted, then maybe Thunderbird would get a fairer share of it.

So, here is a TODO list for her of a total of around US$300 billion dollars just sitting there in 35 foundations and waiting to be spent on Thunderbird (and even Firefox) as a way to promote democracy: :-) https://en.wikipedia.org/wiki/List_of_wealthiest_charitable_foundations

Of course, if she and Mark Surman are too busy to do that, then maybe someone else could do that instead, like specifically for Thunderbird and peer-to-peer? I'm too busy coding to do it myself right now (or should be, back to it now), plus I would not have the credibility various socially connected high-profile people like them have.

--Paul Fernhout
http://www.pdfernhout.net/

The biggest challenge of the 21st century is the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.