pep financing proposal

R. Kent James rkent at
Fri Dec 4 08:45:52 UTC 2015

On 12/3/2015 1:55 PM, Patrick Brunschwig wrote:
> Frankly speaking, I'm very disappointed by the decision the Council has
> taken. I fully agree with Ben that this would have been a dream solution
> for me, and I would indeed like to hear the main arguments from both
> sides. After all, this agreement could have secured the (financial)
> future of Thunderbird for the foreseeable time.
> I just hope that the Council has offer(s) from other partner(s) on the
> table to secure the future of Thunderbird, otherwise I'm starting to get
> slightly worried. The least thing I would want is a fork from Thunderbird.
> -Patrick

For the record, the Council has not taken any decision, the only vote we 
have had was to make certain points in our next response to p≡p. Not all 
of the picture is visible yet, nothing has been finally decided, we are 
continuing to talk to the p≡p Foundation, and it would be great if 
everyone could avoid rushing to judgement and give us some space to work 
through the complicated issues involved.

But I think it is worth at this point additional public debate about 
what the key issues are here, both technical and financial. Benjamin 
Kerensa rightly quoted me saying "Because we are a community project, we 
discuss our real issues openly." So let's discuss.

Let me start by saying that I am overall quite enthusiastic about the 
technology developments from p≡p. All we have seen is a demo, but as far 
as we understand it, p≡p does some really great stuff to make PGP 
encryption occur with minimal user interaction. The email client 
automatically generates a PGP key, that key is advertised automatically 
to people who receive messages from you, and then those other clients 
start to automatically send encrypted emails to you. Multiple clients 
have methods of syncing the automatically generated keys. If enough 
people are using p≡p, then pretty soon the whole world is sending emails 
encrypted. p≡p is right to push fairly hard for their technology to be 
enabled by default, as that allows it to spread virally.

But the specific issue on the table, as far as I understand it, is do we 
contractually agree to enable this by default for all of our users, with 
nothing more than a technology demo and promises, by a specific date, in 
exchange for six months worth of assistance from p≡p. There are several 
issues here.

First, in our normal software incorporation process there is detailed 
review of code and user interface, including what is enabled by default. 
Do we bypass that and pre-agree on defaults, and do we agree to accept 
and incorporate code received by a third party by a fixed date? 
Experience has shown that when we are under pressure due to some 
deadline, usually due to some pre-announcement of a feature, life gets 
very uncomfortable near the due date.

Second, there are serious side effects of having this enabled. From what 
we understand already, (which is precious little, and that is part of 
the problem) at the very least this will cause surprises to many 
unsuspecting users who use multiple devices to read email. You need to 
have this technology installed on all of your devices, else the 
encrypted emails that people start sending you will be unreadable on, 
say, your Android email client. Now p≡p understands this, they are 
bright people after all, and have done an amazing job of making sure 
there is at least one client available with their technology enabled on 
all platforms, and even within subcultures (with Thunderbird being the 
open-source subculture). But this will be a surprise to many of our 
unsuspecting users when they suddenly are getting emails that cannot be 
read on some of their devices. I really don't know what the best way 
will be to introduce this to our users, as they have to take concrete 
steps to mitigate these side effects by properly preparing all of their 
devices prior to enabling it. I am quite willing to push this quite hard 
on our users. But there is just not enough detail at the moment to know 
what p≡p means by "enabling by default", and what the negative downsides 
will be to the typical user's experience.

Third, some users will be unhappy with this, and if this deal is 
presented as a quid pro quo transaction, we will have to deal with 
negative fallout from pushing a technology on them against their wishes 
in exchange for money. Originally I thought that we would be able to 
deal with p≡p from a position of each mutually wanting the same things 
and agreeing to work together. If we want better encryption (which p≡p 
offers us), and they want a viable desktop email client (which we can 
offer them), we are just working on the same goals. I would be much more 
comfortable if we negotiated these issues separately.

So, what do you think, stakeholders in Thunderbird?

Let me reject one counter argument, at least personally. I've been 
contacted privately by one key contributor, who wondered if the events 
in Paris should make us question our commitment to encryption. We had a 
long discussion here about end-to-end encryption a couple of months ago, 
and I ended with a consensus statement:

1.    We should investigate including Enigmail as a shipped addon in 
future versions of Thunderbird.

2.    We would welcome partnering with individual developers, or 
organizations, who have a focus on security and privacy, and can provide 
some of the missing expertise and effort to allow us to better support 
communication security, privacy, and end-to-end encryption (e2e3) in our 
product. As a corollary, we don't reasonably expect the existing core 
team to begin to emphasize e2e3 at the expense of other product priorities.

3.    We are open to proposals to incorporate within our core product 
improvements that would ease some of the user experience problems with 
e2e3 as long as they do not significantly detract from the user 
experience of those to whom e2e3 is not a priority.

I still stand by those statements. and p≡p is that partner organization. 
There are arguments on both sides of supporting or not encryption, but 
we stand on the side of encryption. We welcome partnering with p≡p on 
issues of encryption and privacy, independent of any offer from them to 
support Thunderbird. I'm really looking forward to seeing their 
technology usable by us in Thunderbird.

But on to the issue of offers of support. In the long run, Thunderbird 
is going to live or die by whether we can develop ways to be supported 
by our users. One of the most exciting developments in Toronto last 
month was that Mark Surman offered the expertise of their donor team to 
work with us early next year to develop a donation campaign for 
Thunderbird. Whether that generates $10,000 or $500,000 will go a long 
way toward answering whether Thunderbird can be viable long-term or not. 
I do not believe long-term that we can rely on any outside organization, 
be it Mozilla or p≡p, to be our primary method of support. If we provide 
value to our users, they need to finance us. When people ask where we 
need help, user relations is always a key area, as that has to be our 

A common method of support of open source projects is staff who are 
seconded to the project by outside firms. Currently that is done for 
Thunderbird by both Linagora supporting Lightning, and Mesquilla 
supporting yours truly. We of course would welcome other firms, 
including p≡p, who would want to provide that support. We of course 
would also welcome direct financial support, if and when we can ever get 
the financial home setup.

Concerning p≡p, there has been some confusion on our side on exactly 
what they are offering. It appears now that the concrete offer is to 
hire some people themselves who will help with Thunderbird for a period 
of six months, with a declared value of $100,000. They have already 
started doing that, and one person has already started contributing 
patches. They have also offered to work with several European NGOs they 
are close to that could help us with some other needs. All of this help 
is greatly appreciated. There are also informal statements that this 
support or even more would continue for the indefinite future. All of 
which is great.

The rub seems to be that this offer is contingent on us accepting their 
technology, enabled by default, ASAP in Thunderbird. And they believe 
that we verbally agreed to this in Toronto, so that any attempt to 
deviate from that is viewed as rejection of their assistance. As Volker 
stated publicly on #maildev, "I must say I'm frustrated that you're 
rejecting what we have negotiated in Toronto" and "the worst is that you 
made that deal with us in Toronto, and now it does not count any more" 
On our side, we did not believe we were negotiating specific details of 
how p≡p would be enabled, as we did not know enough about their 
technology to do so (and still do not know enough). This has all been 
inflamed by the current situation with the press, where p≡p is getting 
ready to make their own public introduction, and Mozilla is dealing with 
the negative fallout of Mitchell's comments on Thunderbird use of 
Mozilla infrastructure.

We have also been glacially slow in responding to proposals from p≡p, 
which has not helped and for which I apologize, though we had of course 
many great excuses (such as the raging ear infection I have had for 8 
days, and still have, that makes me functionally deaf). I suspect that 
p≡p was under some time pressure to organize a public statement, and we 
did not realize that pressure or respond in a timely fashion, hence 
their enormous frustration.

What I am hoping is that we can rebuild trust based on what we all agree 
on, which is the importance of privacy in communication. Perhaps we can 
leverage this #maildev conversation into a way forward (fdik here is 
Volker of p≡p):

3:33:47 PM - fdik: rkent: the deal breaker is that you don't want to 
agree any more (which you did before), that when Enigmail/p≡p is ready, 
working, stable, reviewed and mature, to put it in
3:34:21 PM - rkent: fdik: I (and we) could agree to that statement.
3:34:34 PM - fdik: rkent: then why don't you just do it?!
3:34:52 PM - fdik: rkent: because the point of time you're doing that, 
we have a deal

We just have to agree on what "put it in" means, or else trust each 
other enough that we can work it out later and accept that wording 
today. Then let's get on with incorporating this exciting technology 
into Thunderbird.

R. Kent James
Chair, Thunderbird Council

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3701 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the tb-planning mailing list