Joining forces vs. starting from scratch (was Re: Proposal to start a new implementation...)

Paul D. Fernhout pdfernhout at
Sun Apr 9 02:44:26 UTC 2017

On 2017-04-08 1:23 PM, neandr wrote:
> We see projects and contributions to support such a project, just to
> name a few:
> -- Kent is working with a special group of people and I understood his
> goal is to contribute with building box for the TB-next
> -- Ben's tested with tables coded with html/css to demonstrate fast
> display / performance is possible with html/css
> -- mconley's project for a new address book
> -- it sounds a long year contributor and friend with TB can help to
> define the right approach -- THANKS to Mark
> -- Cardbook also very close to the current mature TB could contribute at
> least with expertise
> -- the New Zealand 'contacts' project show a first proof of concept
> Not to repeat Joshua's arguments here, but it's important to start! Now!

Personally, I feel making a new email client from scratch would be a lot
of fun -- especially if it went in new directions with new features for
knowledge exchange. But, to try to be practical, below I try to make the
case for considering joining forces with another existing
communications-oriented community that is already going in similar
directions rather than starting from scratch.

--Paul Fernhout

=== What Thunderbird still has going for it

Most people posting recently seem to agree that the Thunderbird codebase
is rapidly becoming obsolete given Mozilla's recent choices -- even as
that codebase may still provide a great reference for building better
email clients. So, something needs to change.

Given that, what Thunderbird has going for it most of all right now is
the community, the trademark and related good will, and the collective
knowledge about email within the community.

So, a broader question is, what does it make sense for the Thunderbird
community to do with its current resources of time, attention, and
knowledge to support current and future Thunderbird users who share
whatever values lead people to choose Thunderbird?

Starting from scratch to make a new Thunderbird is certainly possible.
But, imagine it was completely impossible to do a new version from
scratch for whatever reason and all Thunderbird users had to migrate
their email out of Thunderbird-as-is by the end of 2017. Imagine if the
Thunderbird Council set an End-of-Life date on Thunderbird support, like
a prize-fighter deciding to retire as a champion instead of fighting
until a final defeat. What would the community consider doing for
alternative options in that case?

=== Some alternatives

I liked the idea Mark Banner mentioned of experimenting to gather more
information if we were to start from scratch. Such experiments could
also include determining whether it was feasible to leverage all that
community email knowledge to make other email systems better with a lot
less work than starting from scratch (including perhaps tools to make
migrating Thunderbird plugins and email archives easier).

If we are seriously considering "burning the disk packs" as Alan Kay
calls a full rewrite in new conceptual directions based on previous
learning, there are other codebases that could be leveraged for future

For example, Ben already mentioned N1 as something he might consider if
it were somewhat different than it is, writing: "I would probably be
using Nylon N1 today, if it wasn't tied with a server component. I don't
need that many features, mostly UI speed, tree views, filters, and
multiple identities." Is it really easier to redo Thunderbird from
scratch than to change N1 either from within the community or via a fork?

So, another possibility is for this group to pick an existing FLOSS mail
system (Nylas N1, Mailpile, KMail, Mutt, Claws Mail, Zimbra, or whatever
especially it used web technologies) and make that into a new blessed
"Thunderbird" either as a fork or by joining that community.

Another broader possibility is joining forces with non-email systems
like or MatterMost (or perhaps even NEPOMUK or some other
Semantic Desktop project) and then integrating email into those projects
in some fantastic way. That might entail rethinking email and how it
interacts with many other communication, archiving, and indexing services.

Could the same amount of effort going into redoing Thunderbird from
scratch instead be able to make, say, Mailpile into something even better?

Or could that same effort perhaps create a robust email gateway for as well as a related UI?
"Development of Matrix is led by, a non-for-profit initiative
based in the United Kingdom, which hopes to make it an open standard for
decentralised, persistent and interoperable communications over the
Internet. Matrix targets use cases like Voice over IP, Internet of
Things and instant messaging, including group communication, along with
a longer-term goal to be a generic messaging and data synchronization
system for the web. The protocol supports security and replication,
maintaining full conversation history, with no single points of control
or failure. Existing communication services can integrate with the
Matrix ecosystem."

=== Social difficulties in considering alternatives

Communities and community members are not fungible, of course. Socially,
long-term Thunderbird users might feel uncomfortably strange becoming,
say, KMail advocates. And the dynamics of power sharing by the current
leadership if moving to some other community with an existing leadership
may be problematical.

But, if Thunderbird does not soon have a compelling story about what is
going to happen with a radically new version, it seems to me that some
sort of splintering from Thunderbird and joining other communities is
quite likely.

So, why not at least consider that option now as a fallback to manage
the risk of some new from scratch effort not coming together quickly?
Granted, a good reason "why not" is that such a hypothetical discussion
might become a self-fulfilling prophecy. So, exploring such options is
not without social risk to the community. And of course, wading through
someone else's email client code may seem less fun than starting from

=== Making objections to alternatives into technical requirements

If the option of joining forces with other communities is completely
unthinkable for *technical* reasons, then outlining why it is
unthinkable might at least help in coming up with requirements for a new
Thunderbird. For example, perhaps we might want to use JMAP as a great
new standard to talk between a local email store and various web-tech
clients and we all think it would be hard to integrate such an approach
into existing codebase?

--Paul Fernhout (
"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."

More information about the tb-planning mailing list