pep financing proposal
R. Kent James
rkent at caspia.com
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.
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
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
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
R. Kent James
Chair, Thunderbird Council
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3701 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning