Thunderbird, the future, mozilla-central and comm-central

[Mitchell Baker]

This is a long-ish message. It covers general topics about Thunderbird
and the future, and also the topics of the Foundation involvement (point
9) and the question of merging repositories (point 11). Naturally, I
believe it’s worth the time to read through the end.

1. Firefox and Thunderbird have lived with competing demands for some
time now. Today Thunderbird developers spend much of their time
responding to changes made in core Mozilla systems and technologies. At
the same time, build, Firefox, and platform engineers continue to pay a
tax to support Thunderbird.

2. These competing demands are not good for either project. Engineers
working on Thunderbird must focus on keeping up and adapting Firefox’s
web-driven changes. Engineers working on Firefox and related projects
end up considering the competing demands of Thunderbird, and/or
wondering if and how much they should assist Thunderbird. Neither
project can focus wholeheartedly on what is best for it.

3. These competing demands will not get better soon. Instead, they are
very likely to get worse. Firefox and related projects are now speeding
up the rate of change, modernizing our development process and our
infrastructure. Indeed, this is required for Mozilla to have significant
impact in the current computing environment.

4. There is a belief among some that living with these competing demands
is good for the Mozilla project as a whole, because it gives us an
additional focus, assists Thunderbird as a dedicated open source
community, and also supports an open source standards based email
client. This sentiment is appealing, and I share it to some extent.
There is also a sense that caring for fellow open source developers is
good, which I also share. However, point 2 above — “Neither project can
focus wholeheartedly on what is best for it” -- is the most important
point. Having Thunderbird has an additional product and focus is *not*
good overall if it causes all of our products — Firefox, other
web-driven products and Thunderbird — to fall short of what we can
accomplish.

5. Many inside of Mozilla, including an overwhelming majority of our
leadership, feel the need to be laser-focused on activities like Firefox
that can have an industry-wide impact. With all due respect to
Thunderbird and the Thunderbird community, we have been clear for years
that we do not view Thunderbird as having this sort of potential.

6. Given this, it’s clear to me that sooner or later paying a tax to
support Thunderbird will not make sense as a policy for Mozilla. I
know many believe this time came a while back, and I’ve been slow to say
this clearly. And of course, some feel that this time should never
come. However, as I say, it’s clear to me today that continuing to live
with these competing demands given our focus on industry impact is
increasingly unstable. We’ve seen this already, in an unstructured way,
as various groups inside Mozilla stop supporting Thunderbird. The
accelerating speed of Firefox and infrastructure changes -- which I
welcome wholeheartedly -- will emphasize this.

7. Some Mozillians are eager to see Mozilla support community-managed
projects within our main development efforts. I am also sympathetic to
this view, with a key precondition. Community-managed projects that
make the main effort less nimble and likely to succeed don’t fit very
well into this category for me. They can still be great open source
projects -- this is a separate question from whether the fit in our main
development systems. I feel so strongly about this because I am so
concerned that “the Web” we love is at risk. If we want the traits of
the Web to live and prosper in the world of mobile, social and data then
we have to be laser-focused on this.

8. Therefore I believe Thunderbird should would thrive best by
separating itself from reliance on Mozilla development systems and in
some cases, Mozilla technology. The current setting isn’t stable, and we
should start actively looking into how we can transition in an orderly
way to a future where Thunderbird and Firefox are un-coupled. I don’t
know what this will look like, or how it will work yet. I do know that
it needs to happen, for both Firefox and Thunderbird’s sake. This is a
big job, and may require expertise that the Thunderbird team doesn’t yet
have. Mozilla can provide various forms of assistance to the
Thunderbird team via a set of the Mozilla Foundation’s capabilities.

9. Mark Surman of the Mozilla Foundation and I are both interested in
helping find a way for Thunderbird to separate from Mozilla
infrastructure. We also want to make sure that Thunderbird has the right
kind of legal and financial home, one that will help the community
thrive. Mark has been talking with the Thunderbird leadership about
this, and has offered some of his time and focus and resources to
assist. He will detail that offer in a separate message. We both
recognize that the Thunderbird community is dedicated to sustaining a
vibrant open source project, which is why we’re currently looking at how
best to assist with both technical separation and identifying the right
long-term home for Thunderbird. These discussions are very early, so
it’s easy to you can definitely think of a lot of questions for which
there are’s no answers yet.

10. The fact that the Foundation is facilitating these discussions does
not necessarily mean that the Foundation is or is not the best legal and
financial home for Thunderbird. The intent is not to make technical
decisions about support of Thunderbird by Mozilla employees, or merging
repositories, etc. Point 6 above is the shared organizing principle for
both of us.

11. I understand from recent discussions that merging mozilla-central
and comm-central would provide some reduction of effort required to ship
Thunderbird, at least in the short term. This would make sense if our
path was long term integration of the projects. As i noted above, I
believe our path has to be the long term separation of these projects,
so that each can move as fast as possible into new things. Given that,
I’m not sure that merging them makes sense. I have to learn a bit more
about the cost / benefit analysis of merging repositories given the need
to separate these project. I’m asking the platform and release folks to
comment on this.

12. This message is about the future and there’s a lot to work out.
It’s explicitly not to announce changes in daily activities at this
point. People using Thunderbird will not see any change in the product
they use. We have started this conversation early because Mozilla
works best when our community is engaged. This is how we gather the
people who are interested, and enable those folks to engage productively
within the process. It also of course allows those who prefer a
different course of action to be vocal. We’ve seen this before with
Thunderbird. Building a positive response and a positive conversation
will be a very useful first step in making a good future for Thunderbird.


Mitchell

[Mark Surman]

Hi all

As a follow on to Mitchell’s post, I want to outline more specifically
how the Foundation got involved and the ways in which I believe the
Foundation can assist in this situation.

Mitchell and I have had a number of discussions regarding Thunderbird.
The Thunderbird Council has also come to each of us at various times. We
agree it could be helpful for some of the Foundation's capabilities to
be part of this work. Specifically, I’ve put forward an offer of
Foundation staff time and resources to:

1. Advise and support the Council as they come up with a plan. Mitchell,
myself and many at the Foundation care about the long term health of
Thunderbird and feel some responsibility to help get it to a good spot.

2. Beyond time, we’ve offered the Council a modest amount of money to
pay for contractors who can help develop options for both the
organizational and technical future of Thunderbird.

2.1 As Mitchell said, this *does not* mean that MoFo is making technical
decisions about Thunderbird -- just that we want to make sure the
Council has access a technical architect, a business planner, etc. to
generate plans and options that the community can consider together.

2.2 As part of this, we’ve also (loosely) offered MoFo's meeting
facilitation team run by Allen Gunn to bring together a set of
Thunderbird stakeholders to discuss these options. I haven't fully
discussed this part with the Council yet.

3. Finally, we've offered to accept donations for Thunderbird and
disperse funds for contractors while we're figuring out this plan.

3.1 This makes MoFo, who already owns the Thunderbird IP, into a 'fiscal
home' for the Thunderbird community during this period. We also play
this role for Firebug.

3.2 We’re talking to at least one org who is considering supporting
Thunderbird. We are also looking at adding a user donation function to
support the Thunderbird community. We will likely also supplement this
funding with some of our own resources in a small way.

Some of the items above could be done via MoCo (items 2, 2.2) or MoFo,
and since I have a bit of energy to focus on this now, Mitchell and I
agreed we should take advantage of this energy. Other items make much
more sense to be handled from the Foundation (item 3).

I'm not sure where all this leads -- but I am certain that we need to
invest some time and resources in figuring out a good future for
Thunderbird. That's what I've offered to help with.

If people have questions or want to somehow help out themselves, I'd be
happy to discuss.

ms

[Mark Surman]

[Robert Accettura]

It's not immediately clear (and maybe that's because it's truly undecided),
but is this an effort to separate Thunderbird from Mozilla entirely
(perhaps live on under Apache, someone else, or stand alone)? Or would it
be an independent project under the Mozilla Foundation, but no
infrastructure/technical ties to MoCo/Firefox with it's own financial model?

-R

On Mon, Nov 30, 2015 at 7:43 PM, Mark Surman <ma...@mozillafoundation.org>
wrote:

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>



--
Robert Accettura
rob...@accettura.com

[Benjamin Kerensa]

I think this is rather disappointing and wish Mozilla would continue to
support Thunderbird as a Mozilla community-driven project. Thunderbird has
continued to grow[1] despite Mozilla removing paid staff from its
development and eliminating resources it had. (Actually has more users than
Firefox OS) I think there are alternatives to the current infrastructure
and build situations that are taxing that would allow Thunderbird to
continue on as a Mozilla community-led project but it seems like that is
not open for discussion.

That said, if Thunderbird is to become a separate project I do hope you and
Mark will consider giving Thunderbird a generous financial parting grant to
help it transition and continue to thrive, also ensure good protections are
in place to protect the Mozilla Thunderbird brand and trademark, and that a
good governance structure is proposed for any independent Thunderbird that
results.

[1]
https://blog.mozilla.org/thunderbird/2015/02/thunderbird-usage-continues-to-grow/

On Mon, Nov 30, 2015 at 1:11 PM, Mitchell Baker <mitc...@mozilla.com>

Benjamin Kerensa
http://benjaminkerensa.com/

[Mitchell Baker]

Hi Robert

Truly undecided.  Obviously there's both "mozilla-ness" and history with the Mozilla Foundation.  And there are some drawback about being part of something with the impact goals that we have.   It's possible that being associated with an organization that supports open source projects without the driving need to change the overall ecosystem could be better.  Either way, the legal and financial home can be separated and addressed as a separate topic.

thanks for asking.

Mitchell

On 11/30/15 7:01 PM, Robert Accettura wrote:

It's not immediately clear (and maybe that's because it's truly undecided), but is this an effort to separate Thunderbird from Mozilla entirely (perhaps live on under Apache, someone else, or stand alone)? Or would it be an independent project under the Mozilla Foundation, but no infrastructure/technical ties to MoCo/Firefox with it's own financial model?

-R

On Mon, Nov 30, 2015 at 7:43 PM, Mark Surman <ma...@mozillafoundation.org> wrote:

Hi all

As a follow on to Mitchell’s post, I want to outline more specifically how the Foundation got involved and the ways in which I believe the Foundation can assist in this situation.

Mitchell and I have had a number of discussions regarding Thunderbird. The Thunderbird Council has also come to each of us at various times. We agree it could be helpful for some of the Foundation's capabilities to be part of this work. Specifically, I’ve put forward an offer of Foundation staff time and resources to:

1. Advise and support the Council as they come up with a plan. Mitchell, myself and many at the Foundation care about the long term health of Thunderbird and feel some responsibility to help get it to a good spot.

2. Beyond time, we’ve offered the Council a modest amount of money to pay for contractors who can help develop options for both the organizational and technical future of Thunderbird.

2.1 As Mitchell said, this *does not* mean that MoFo is making technical decisions about Thunderbird -- just that we want to make sure the Council has access a technical architect, a business planner, etc. to generate plans and options that the community can consider together.

2.2 As part of this, we’ve also (loosely) offered MoFo's meeting facilitation team run by Allen Gunn to bring together a set of Thunderbird stakeholders to discuss these options. I haven't fully discussed this part with the Council yet.

3. Finally, we've offered to accept donations for Thunderbird and disperse funds for contractors while we're figuring out this plan.

3.1 This makes MoFo, who already owns the Thunderbird IP, into a 'fiscal home' for the Thunderbird community during this period. We also play this role for Firebug.

3.2 We’re talking to at least one org who is considering supporting Thunderbird. We are also looking at adding a user donation function to support the Thunderbird community. We will likely also supplement this funding with some of our own resources in a small way.

Some of the items above could be done via MoCo (items 2, 2.2) or MoFo, and since I have a bit of energy to focus on this now, Mitchell and I agreed we should take advantage of this energy. Other items make much more sense to be handled from the Foundation (item 3).

I'm not sure where all this leads -- but I am certain that we need to invest some time and resources in figuring out a good future for Thunderbird. That's what I've offered to help with.

If people have questions or want to somehow help out themselves, I'd be happy to discuss.

ms

On 2015-11-30 4:11 PM, Mitchell Baker wrote:

_______________________________________________
governance mailing list
gover...@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance

--

Robert Accettura
rob...@accettura.com

[Mitchell Baker]

Hi Benjamin

And yes, we want to see a good setting.  Both Mark and i are among the dedicated Thunderbird user group, and I use Thunderbird to organize vast parts of my life.   When I say that Thunderbird and Firefox must disentangle, it's not because I don't value Thunderbird.  I value it both as an open source project and because i personally rely on Thunderbird to be productive.

There is currently a community driven governance structure, through the Thunderbird Council.   We'll be working with the Council.

Mitchell

On 11/30/15 7:45 PM, Benjamin Kerensa wrote:

I think this is rather disappointing and wish Mozilla would continue to support Thunderbird as a Mozilla community-driven project. Thunderbird has continued to grow[1] despite Mozilla removing paid staff from its development and eliminating resources it had. (Actually has more users than Firefox OS) I think there are alternatives to the current infrastructure and build situations that are taxing that would allow Thunderbird to continue on as a Mozilla community-led project but it seems like that is not open for discussion. That said, if Thunderbird is to become a separate project I do hope you and Mark will consider giving Thunderbird a generous financial parting grant to help it transition and continue to thrive, also ensure good protections are in place to protect the Mozilla Thunderbird brand and trademark, and that a good governance structure is proposed for any independent Thunderbird that results.

[1] https://blog.mozilla.org/thunderbird/2015/02/thunderbird-usage-continues-to-grow/

On Mon, Nov 30, 2015 at 1:11 PM, Mitchell Baker <mitc...@mozilla.com> wrote:

This is a long-ish message. It covers general topics about Thunderbird and the future, and also the topics of the Foundation involvement (point 9) and the question of merging repositories (point 11).   Naturally, I believe it’s worth the time to read through the end.

1. Firefox and Thunderbird have lived with competing demands for some time now. Today Thunderbird developers spend much of their time responding to changes made in core Mozilla systems and technologies. At the same time, build, Firefox, and platform engineers continue to pay a tax to support Thunderbird.

2. These competing demands are not good for either project. Engineers working on Thunderbird must focus on keeping up and adapting Firefox’s web-driven changes. Engineers working on Firefox and related projects end up considering the competing demands of Thunderbird, and/or wondering if and how much they should assist Thunderbird. Neither project can focus wholeheartedly on what is best for it.

3. These competing demands will not get better soon. Instead, they are very likely to get worse. Firefox and related projects are now speeding up the rate of change, modernizing our development process and our infrastructure. Indeed, this is required for Mozilla to have significant impact in the current computing environment.

4. There is a belief among some that living with these competing demands is good for the Mozilla project as a whole, because it gives us an additional focus, assists Thunderbird as a dedicated open source community, and also supports an open source standards based email client. This sentiment is appealing, and I share it to some extent. There is also a sense that caring for fellow open source developers is good, which I also share.  However, point 2 above — “Neither project can focus wholeheartedly on what is best for it” -- is the most important point. Having Thunderbird has an additional product and focus is *not* good overall if it causes all of our products — Firefox, other web-driven products and Thunderbird — to fall short of what we can accomplish.

5.  Many inside of Mozilla, including an overwhelming majority of our leadership, feel the need to be laser-focused on activities like Firefox that can have an industry-wide impact.    With all due respect to Thunderbird and the Thunderbird community, we have been clear for years that we do not view Thunderbird as having this sort of potential.

6.  Given this, it’s clear to me that sooner or later paying a tax to support Thunderbird will not make sense as a policy for Mozilla.    I know many believe this time came a while back, and I’ve been slow to say this clearly.  And of course, some feel that this time should never come.  However, as I say, it’s clear to me today that continuing to live with these competing demands given our focus on industry impact is increasingly unstable.  We’ve seen this already, in an unstructured way, as various groups inside Mozilla stop supporting Thunderbird.  The accelerating speed of Firefox and infrastructure changes -- which I welcome wholeheartedly -- will emphasize this.

7.  Some Mozillians are eager to see Mozilla support community-managed projects within our main development efforts.  I am also sympathetic to this view, with a key precondition.  Community-managed projects that make the main effort less nimble and likely to succeed don’t fit very well into this category for me.  They can still be great open source projects -- this is a separate question from whether the fit in our main development systems.  I feel so strongly about this because I am so concerned that “the Web” we  love is at risk.  If we want the traits of the Web to live and prosper in the world of mobile, social and data then we have to be laser-focused on this.

8.  Therefore I believe Thunderbird should would thrive best by separating itself from reliance on Mozilla development systems and in some cases, Mozilla technology. The current setting isn’t stable, and we should start actively looking into how we can transition in an orderly way to a future where Thunderbird and Firefox are un-coupled.   I don’t know what this will look like, or how it will work yet. I do know that it needs to happen, for both Firefox and Thunderbird’s sake.  This is a big job, and may require expertise that the Thunderbird team doesn’t yet have.    Mozilla can provide various forms of assistance to the Thunderbird team via a set of the Mozilla Foundation’s capabilities.

9. Mark Surman of the Mozilla Foundation and I are both interested in helping find a way for Thunderbird to separate from Mozilla infrastructure. We also want to make sure that Thunderbird has the right kind of legal and financial home, one that will help the community thrive. Mark has been talking with the Thunderbird leadership about this, and has offered some of his time and focus and resources to assist. He will detail that offer in a separate message. We both recognize that the Thunderbird community is dedicated to sustaining a vibrant open source project, which is why we’re currently looking at how best to assist with both technical separation and identifying the right long-term home for Thunderbird.  These discussions are very early, so it’s easy to you can definitely think of a lot of questions for which there are’s no answers yet.

10. The fact that the Foundation is facilitating these discussions does not necessarily mean that the Foundation is or is not the best legal and financial home for Thunderbird. The intent is not to make technical decisions about support of Thunderbird by Mozilla employees, or merging repositories, etc. Point 6 above is the shared organizing principle for both of us.

11. I understand from recent discussions that merging mozilla-central and comm-central would provide some reduction of effort required to ship Thunderbird, at least in the short term. This would make sense if our path was long term integration of the projects.  As i noted above, I believe our path has to be the long term separation of these projects, so that each can move as fast as possible into new things. Given that, I’m not sure that merging them makes sense. I have to learn a bit more about the cost / benefit analysis of merging repositories given the need to separate these project. I’m asking the platform and release folks to comment on this.

12.  This message is about the future and there’s a lot to work out. It’s explicitly not to announce changes in daily activities at this point.  People using Thunderbird will not see any change in the product they use.   We have started this conversation early because Mozilla works best when our community is engaged.  This is how we gather the people who are interested, and enable those folks to engage productively within the process.  It also of course allows those who prefer a different course of action to be vocal.  We’ve seen this before with Thunderbird.   Building a positive response and a positive conversation will be a very useful first step in making a good future for Thunderbird.


Mitchell

_______________________________________________
governance mailing list
gover...@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance

--

Benjamin Kerensa
http://benjaminkerensa.com/

[Dirkjan Ochtman]

On Mon, Nov 30, 2015 at 10:11 PM, Mitchell Baker <mitc...@mozilla.com> wrote:
> 7. Some Mozillians are eager to see Mozilla support community-managed
> projects within our main development efforts. I am also sympathetic to this
> view, with a key precondition. Community-managed projects that make the
> main effort less nimble and likely to succeed don’t fit very well into this
> category for me. They can still be great open source projects -- this is a
> separate question from whether the fit in our main development systems. I
> feel so strongly about this because I am so concerned that “the Web” we
> love is at risk. If we want the traits of the Web to live and prosper in
> the world of mobile, social and data then we have to be laser-focused on
> this.

Can you comment why you think Thunderbird (or maybe even email in
general) is not part of this Web that we love that is at risk? 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.

I think it makes sense to separate Thunderbird and Firefox more from a
technical perspective, just because loose coupling is a good thing. I
think this is the same promise XULRunner and the Firefox SDK were
going to fulfill, though, and it always looks to me like they were
never really a viable strategy, in part due to a lack of resources
available to make that really a good technical bet.

Also, this lack of focus on Gecko being a viable platform is kind of
weird when viewed through the lens of what's happening on the other
side of the fence with the Electron ecosystem, with Atom and Nylas N1
and whatever else is being built on top of that. If Mozilla had
invested more in XULRunner, would we have all of those developers as
part of our community now? There's a lot of noise being made about
participation, but this seems yet another instance where Mozilla takes
the stance that a sizable part of its community is not actually
welcome, and one might wonder whether actions speak louder than words.

Cheers,

Dirkjan

[Andrew Sutherland]

On Tue, Dec 1, 2015, at 03:21 AM, Dirkjan Ochtman wrote:
> On Mon, Nov 30, 2015 at 10:11 PM, Mitchell Baker <mitc...@mozilla.com>
> wrote:
> > 7. Some Mozillians are eager to see Mozilla support community-managed
> > projects within our main development efforts. I am also sympathetic to this
> > view, with a key precondition. Community-managed projects that make the
> > main effort less nimble and likely to succeed don’t fit very well into this
> > category for me. They can still be great open source projects -- this is a
> > separate question from whether the fit in our main development systems. I
> > feel so strongly about this because I am so concerned that “the Web” we
> > love is at risk. If we want the traits of the Web to live and prosper in
> > the world of mobile, social and data then we have to be laser-focused on
> > this.
>
> Can you comment why you think Thunderbird (or maybe even email in
> general) is not part of this Web that we love that is at risk?

A contextual digression before addressing your comment/question (way)
below:

Thunderbird is still, at its heart, a C++ mail client with a HTML/CSS/JS
UI grafted on top with JS logic slowly chipping-away-at and replacing
pieces of the C++ logic.

It is an email/newsgroup client (and sometimes RSS client) that is part
of the federated messaging system of email (and others). And this is
important. Mail User Agents are absolutely important. Just as Firefox
endeavors to put users in control of their web browsing, Thunderbird
endeavors to put users in control of their messaging in a way that
closed-source webmail UIs running on third-party server infrastructures
outside of the user's control inherently cannot.

The problem with Thunderbird is not that it is a mail user agent or that
user agency in messaging is unimportant. The problem is that
Thunderbird has had a serious technical debt problem since the day its
code-base transitioned from Netscape. Its low-level integration with
Gecko has been a maintenance burden for Thunderbird developers and
non-Thunderbird developers alike.

The Mozilla Foundation and Mozilla Corporation put serious financial
resources into trying to address both of these problems with the
creation of Mozilla Messaging. The idea, as I understand it, was to
attempt to alleviate the burden on Firefox development by separating
Thunderbird development while simultaneously providing Thunderbird with
people and resources to attempt to address this technical debt.

Probably the core takeaways from working on Thunderbird during that time
were:
1) There was and continues to be a lot of technical debt. (Despite
serious efforts to address it.)
2) When you have addressed the technical debt, you potentially are left
with something that is not the same product that Thunderbird was to
begin with[1]. (:rkent's post at
https://mail.mozilla.org/pipermail/tb-planning/2015-September/004066.html
"Future Planning: Thunderbird as a Web App" could be interpreted as a
variation on this.)


An important question that falls out from all of this is and your
original question is: which is more important? Mail user agency or
Thunderbird the product, especially if there are serious opportunity
costs related to Thunderbird?

Within the funded efforts of the Mozilla Corporation[2], mail user
agency has not been abandoned and continues to be advanced as part of an
open development process. For Firefox OS, a mail app was developed with
a back-end based on experience from working on Thunderbird and other
messaging projects. There was some time lost due to the initial product
targets and related engineering complications, but we now have a branch
which does many things that were out of reach and continue to be out of
reach for Thunderbird:
* Conversation-centric[3] but also capable of supporting message-centric
UI's. Specific sync support for gmail's conversation model in addition
to "vanilla" IMAP and POP3 and ActiveSync.
* The offline-first back-end is entirely implemented in JS, which means
that it can run in content space in Firefox or any JS engine as long as
appropriate (web) API's are exposed to it, mainly a
(priviliged/permission based for security reasons) TCP implementation.
There is no C++ or deep integration into Gecko that slows down Gecko.
* The back end runs in a worker thread modulo some proxied web APIs so
it does not interfere with the responsiveness of the UI.
* Back-end designed to support desired Thunderbird UI features like
multi-line thread pane support while also allowing a virtual list
implementation that does not require the entire message store being
displayed to be loaded into memory.
* Back-end is decoupled from the UI, allowing multiple different UIs.
For example:
** Screenshot of the conversations branch of FxOS gaia mail UI showing
its conversations list running in b2g-desktop:
https://clicky.visophyte.org/files/screenshots/20151201-064354.png
** Screenshot of the (ugly) lazy-developer react.js desktop UI running
in Firefox nightly:
https://clicky.visophyte.org/files/screenshots/20151201-061945.png


And now back to your original point/question (responding only for
myself; I speak for no one else!):

> Can you comment why you think Thunderbird (or maybe even email in
> general) is not part of this Web that we love that is at risk?

As I read this question, the first implication I see is that Thunderbird
is important to the web/internet. And it is. But I think what is
really important is user agency. User agency on the web, user agency in
messaging.

The second implication I see is that Thunderbird is important in a way
that no other product can be and a choice to prioritize Firefox over
Thunderbird is a choice to ignore user agency in messaging. I don't
think that's the case, and as I hopefully indicated above, I do not
believe the Mozilla Corporation is ignoring user agency in messaging.

Andrew

1: Of course, with enough effort, it may be possible to create a UI that
mimics Thunderbird's existing interface with a high degree of fidelity.
But "enough effort" can be very high. For example, Thunderbird's global
faceted search UI came into existence because the performance of feeding
the global search results directly into the thread pane was very poor
because of Thunderbird's main-thread I/O and need to load entire folders
at a time entirely into memory using an append-only custom database
where compaction was frequently risky/scary (pre-rkent doing a fantastic
job of fixing the compaction!) Feeding the thread pane synthetic
headers backed by JS resulted in massively reduced scrolling performance
due to the treeview's draw model in addition to losses of fidelity and
consistency.
2: Note that I'm explicitly saying Mozilla Corporation/Foundation etc.
just to be clear about the entities involved. A lot of times the bare
term "Mozilla" is used to mean any of the corporation, foundation,
project/community, etc. and it can get very confusing and potentially
even seem exclusionary. I'm trying to avoid that.
3: Noting that Thunderbird's global database provides a best-effort
conversation overlay data model on top of the underlying folder and
message-centric view of things. Unfortunately there were many
compromises inherent in this approach, including that the whole layer is
entirely optional, so most core functionality can't depend on gloda at
all.

[Kurt Roeckx]

On 2015-11-30 22:11, Mitchell Baker wrote:
> 5. Many inside of Mozilla, including an overwhelming majority of our
> leadership, feel the need to be laser-focused on activities like Firefox
> that can have an industry-wide impact. With all due respect to
> Thunderbird and the Thunderbird community, we have been clear for years
> that we do not view Thunderbird as having this sort of potential.

I currently don't see Mozilla having a focus or having an industry-wide
impact. I do see both Firefox and Thunderbird as having that potential.


Kurt

[Dirkjan Ochtman]

On Tue, Dec 1, 2015 at 1:47 PM, Andrew Sutherland
<asuth...@asutherland.org> wrote:
> An important question that falls out from all of this is and your
> original question is: which is more important? Mail user agency or
> Thunderbird the product, especially if there are serious opportunity
> costs related to Thunderbird?

Thanks for your context. Yes, I was sort of conflating these two
concepts, though I hope the context about ecosystems might have
indicated that I was more talking about mail user agency. I do believe
mail (or rather messaging -- including trying to pry loose
iMessage/Telegram/Hangouts/FB messenger from their respective
corporate headmasters -- and maybe working with the Signal folks) is
an important user agency battle.

The problem with a Firefox OS app, as I see it, is that Fx OS was
always a risky bet, is not available in markets where rapid adoption
is even a feasible option, and even now with the b2g-droid stuff, is a
pretty crappy experience on relatively common devices. Any app which
is built for that environment therefore has extremely low chances of
making a sizable impact. I thought Raindrop was actually an
interesting approach to the problem... but at this point Thunderbird
is making a relatively large impact on messaging user agency, and it
seems like bad thing to cut that loose.

Cheers,

Dirkjan

[Paul]

Here's my two cents on the matter. In Mozilla's failing to create the platform that Firefox should run atop it quickly became an uphill struggle to compartmentalise code. As a result, where Thunderbird should've been a module that plugs into a platform and should've got a free ride with the Android and desktop releases, it instead required a whole bunch of work. It's not impossible to take Firefox in that direction and in fact would actually be beneficial as it would allow for Firefox to run on a much wider array of devices in the long run.

The fact of the matter is, Mozilla lacks an ecosystem and even while there's no truly good third-party mail app available for Android, because of the laser-focused approach to Firefox, Mozilla lacks the agility to capitalise on such needs. All this while Google faffs about with Inbox and Gmail attempts to be the portal to everyone's mail.

This isn't even a new concern:
1. https://someotheropines.wordpress.com/2011/10/13/soo-is-it-possible-to-arrive-at-any-other-conclusion-than-thunderbird-is-doomed/
2. https://someotheropines.wordpress.com/2011/11/15/soo-is-it-time-for-a-more-modular-approach-to-browsing/
3. https://someotheropines.wordpress.com/2011/11/24/soo-musings-on-mozillas-mobile-meddlings/
4. https://someotheropines.wordpress.com/2012/07/24/soo-just-why-doesnt-mozilla-seem-to-get-it/

[Daniel Glazman]

Hello Mitchell,

So I'd like to discuss some of the technical details in that
"separation" because I don't completely understand them, it's
probably only my fault. A few facts first:

1. Thunderbird is a standalone application embedding Gecko and deeply
relying on XPCOM, XUL (and XBL), XUL-based add-ons and XULrunner.
I need to mention that Postbox, a successful commercial MUA, is
precisely in the same case.

2. Thunderbird's code is quite well isolated, and comm-central that
hosts its core still needs to check mozilla-central out to build.
Most of the work I'm doing for Postbox these days sits inside /mail
and /mailnews, never /mozilla

So here are my questions:

a. all the underlying technologies of Thunderbird's world (XPCOM, XUL,
XBL, XUL-based add-ons) are on the verge of being deprecated. Is the
announced move a way to decouple faster, as it seems reading your
bullet point 8? What other areas of Gecko will be "cleaned up" if
that decoupling happens? This question is an absolutely major one
because it will deeply impact the rendering engine's choice.

b. Thunderbird will still need to embed a browser, even if it does not
use any more XUL or XPCOM in the future. Embeddability of Gecko has
always been a poor parent of the project. Will it change or should
Thunderbird look for rendering engine alternatives?
Technically speaking, I hope you will believe me when I say that
despite of all existing issues, the editor living inside Gecko is
still superior to all other editing engines on the market. Moving
to another rendering engine will imply, for TB and any other
application embedding a wysiwyg editor, a rather deep downgrade.
Again here, embeddability is crucial.

c. if a is true, then a very long list of third-party apps, like my own
(BlueGriffon line) or Seamonkey, will be very deeply impacted. What
about them/us?

d. do you have any ETA or deadline? I suspect that a rewriting of TB
w/o Mozilla technologies is a >=2 years effort for a team of 2 to 3.

e. last but not least, and this is not a question but more a comment,
Thunderbird is used by many governmental and non-governmental
organizations around the globe even if they're less visible than
Firefox's users. As a local example, many areas of the french
government rely on it. Planning a future for TB will be crucial
to them, but also crucial to Mozilla's image among these people.

Best,

</Daniel>

[Mitchell Baker]

On 12/1/15 12:21 AM, Dirkjan Ochtman wrote:
> On Mon, Nov 30, 2015 at 10:11 PM, Mitchell Baker <mitc...@mozilla.com> wrote:
>> 7. Some Mozillians are eager to see Mozilla support community-managed
>> projects within our main development efforts. I am also sympathetic to this
>> view, with a key precondition. Community-managed projects that make the
>> main effort less nimble and likely to succeed don’t fit very well into this
>> category for me. They can still be great open source projects -- this is a
>> separate question from whether the fit in our main development systems. I
>> feel so strongly about this because I am so concerned that “the Web” we
>> love is at risk. If we want the traits of the Web to live and prosper in
>> the world of mobile, social and data then we have to be laser-focused on
>> this.
> Can you comment why you think Thunderbird (or maybe even email in

> general) is not part of this Web that we love that is at risk? 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.

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

>
> I think it makes sense to separate Thunderbird and Firefox more from a
> technical perspective, just because loose coupling is a good thing. I
> think this is the same promise XULRunner and the Firefox SDK were
> going to fulfill, though, and it always looks to me like they were
> never really a viable strategy, in part due to a lack of resources
> available to make that really a good technical bet.

And because XUL never caught on as an industry standard and became a
mozilla-specific technology. Open source, but not an interoperable
industry standard.

> Also, this lack of focus on Gecko being a viable platform is kind of
> weird when viewed through the lens of what's happening on the other
> side of the fence with the Electron ecosystem, with Atom and Nylas N1
> and whatever else is being built on top of that. If Mozilla had
> invested more in XULRunner, would we have all of those developers as
> part of our community now? There's a lot of noise being made about
> participation, but this seems yet another instance where Mozilla takes
> the stance that a sizable part of its community is not actually
> welcome, and one might wonder whether actions speak louder than words.

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.

Mitchell




>
> Cheers,
>
> Dirkjan

[Myk Melez]

Dirkjan Ochtman wrote:
> The problem with a Firefox OS app, as I see it, is that Fx OS was
> always a risky bet, is not available in markets where rapid adoption
> is even a feasible option, and even now with the b2g-droid stuff, is a
> pretty crappy experience on relatively common devices. Any app which
> is built for that environment therefore has extremely low chances of
> making a sizable impact.

Andrew noted that the FxOS app's backend can run in any JS engine that
exposes the appropriate APIs. That makes it generalizable to the web,
given standardization and cross-browser implementation of those APIs (or
a server-side proxy).

Andrew doesn't come out and say it, but I read his message to imply that
the work required to address Thunderbird's technical debt remains
daunting, and it would be more promising (in terms of the work required,
but also because of a greater potential for impact) to generalize the
FxOS app to the web.

-myk

[Mitchell Baker]

This is indeed the same discussion, and we continue to share the same
difference in viewpoints and appropriate action.

Also, I note that the point of my post is that relying on shared
infrastructure -- by which I meant build and release, etc -- doesn't
make sense. The question of whether Mozilla Foundation is the right
infrastructure for a home for Thunderbird is a different question, and
currently much more open.

mitchell

[martin...@gmail.com]

PLEASE don't do this. I and many of my colleagues depend on Thunderbird; there's no decent comparable alternative on Linux. Firefox is my browser of choice, but I could get by without it; I can't get by without Thunderbird.

Cheers,
A happy user for YEARS.

> good, which I also share. However, point 2 above -- "Neither project can

> focus wholeheartedly on what is best for it" -- is the most important
> point. Having Thunderbird has an additional product and focus is *not*

> good overall if it causes all of our products -- Firefox, other
> web-driven products and Thunderbird -- to fall short of what we can

[niklas.o...@gmail.com]

Re-write Thunderbird in AngularJS and make it a first-class html5-citizen.

As Thunderbird is a pretty complex piece of software it would also make a great base-line for Firefox ability to run apps in the browser.

[jlphill...@gmail.com]

> good, which I also share. However, point 2 above -- "Neither project can

> focus wholeheartedly on what is best for it" -- is the most important
> point. Having Thunderbird has an additional product and focus is *not*

> good overall if it causes all of our products -- Firefox, other
> web-driven products and Thunderbird -- to fall short of what we can

I find it very disheartening to hear this. I have been using Thunderbird for many years. I don't even know how many. Over the years I have introduced Thunderbird to several others. If Thunderbird disappears there is no viable alternative. While many have gone to web based email, there is definitely a need for stable email clients like Thunderbird. Ever web based email system I have tested were really miserable. Recently I researched the possibility of another email client and found NONE that came close to the capability of Thunderbird. I would even be willing to pay a reasonable amount for Thunderbird to continue.

[Henri Sivonen]

On Tue, Dec 1, 2015 at 2:47 PM, Andrew Sutherland
<asuth...@asutherland.org> wrote:
> 2) When you have addressed the technical debt, you potentially are left
> with something that is not the same product that Thunderbird was to
> begin with[1]. (:rkent's post at
> https://mail.mozilla.org/pipermail/tb-planning/2015-September/004066.html
> "Future Planning: Thunderbird as a Web App" could be interpreted as a
> variation on this.)

Is that the plan of record that the Thunderbird devs agree on
executing given resources?

> An important question that falls out from all of this is and your
> original question is: which is more important? Mail user agency or
> Thunderbird the product, especially if there are serious opportunity
> costs related to Thunderbird?

In the tb-planning thread Mailpile was mentioned, but when looking at
the archives, I failed to see the point addressed. How do Thunderbird
devs see the benefits of Thunderbird rewritten as a local HTML + Web
API JS app compared to Mailpile running locally with a general-purpose
browser (or, hypothetically, Mailpile running locally with a
special-purpose bundled browser engine or system WebView)?

On Tue, Dec 1, 2015 at 5:01 AM, Robert Accettura <rob...@accettura.com> wrote:
> It's not immediately clear (and maybe that's because it's truly undecided),
> but is this an effort to separate Thunderbird from Mozilla entirely
> (perhaps live on under Apache, someone else, or stand alone)?

If you look at the contexts where Thunderbird has been recommended by
someone over the last couple of years, the context often seems to have
been privacy and end-to-end encryption in general and Enigmail+GPG in
particular.

Even though there is a lot to criticize about OpenPGP in general and
GPG in particular, it seems to me that making OpenPGP a feature that
is easy to use (to the extent the OpenPGP paradigm allows) and
available by default is the angle that allows a locally-run MUA to
make the most impact in a world where Gmail is otherwise winning on
user experience.

In that sense, I think Mozilla's GPL-avoiding license policy has hurt
Thunderbird and it would have been better for Thunderbird to have
bundled GPG and to have designed the UI for it right into the main
product itself ages ago instead of leaving it to an extension.
Mozilla's license policy seems to cater to the use case that a
Netscape engine can be embedded into proprietary software such as an
AOL client. Since Thunderbird doesn't exist in that context, I think
the license policy hasn't been serving Thunderbird well. How has
Thunderbird's mission benefited from Postbox being able to take the
code with only a legal compliance dump coming back? If the choices are
bundling GPG or enabling Postbox, I'd bundle GPG.

When finding a new fiscal sponsor, I'd recommend finding one that
doesn't impose a license policy that blocks Thunderbird from bundling
GPG. Obviously, this means that I think that Apache's policies
wouldn't be a good match for Thunderbird.

(If Thunderbird developers are serious about eradicating non-JS code
100%, then bundling GPG will become moot eventually as OpenGPG
functionality would have to be written in JS to comply with a "nothing
but JS" stance. However, it's unlikely that Web Crypto will cater to
the idiosyncrasies of OpenGPG and it's unlikely that you could
implement the algorithms that OpenGPG requires but Web Crypto doesn't
provide in JS without side channel problems. OTOH, compiling GPG to
asm.js, ignoring the side-channel issues, would still be
licensing-relevant.)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[mka...@gmail.com]

Mitchell,

Daniel has some really great questions.

Can they be answered as well?

Thanks

Mike

[R Kent James]

On 12/3/2015 4:01 AM, Henri Sivonen wrote:
> On Tue, Dec 1, 2015 at 2:47 PM, Andrew Sutherland
> <asuth...@asutherland.org> wrote:
>> 2) When you have addressed the technical debt, you potentially are left
>> with something that is not the same product that Thunderbird was to
>> begin with[1]. (:rkent's post at
>> https://mail.mozilla.org/pipermail/tb-planning/2015-September/004066.html
>> "Future Planning: Thunderbird as a Web App" could be interpreted as a
>> variation on this.)
>
> Is that the plan of record that the Thunderbird devs agree on
> executing given resources?

No, this was just some thoughts for discussion. The question of the
long-term technical platform for Thunderbird is still very much a topic
of discussion. In my dreams though, 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.

>
> If you look at the contexts where Thunderbird has been recommended by
> someone over the last couple of years, the context often seems to have
> been privacy and end-to-end encryption in general and Enigmail+GPG in
> particular.
>

The Enigmail community is certainly important, but represents a small
fraction of our users, less than 5% certainly. Yet Thunderbird is a
vital part of the overall GPG community, as I frequently hear that
Enigmail users at meetups typically are more than all of other GPG users
combined. Since privacy and security are important to Mozilla and the
Thunderbird, we are committed to continuing to support and encourage
Enigmail. We are actively investigating what it would take to have
Enigmail more integrated into Thunderbird, perhaps as a shipped addon.
But we have to keep that in context, as there are other important issues
as well that Thunderbird needs to address.

:rkent

[Thomas Zimmermann]

I understand that Thunderbird's future is currently under discussion and
pretty much open.

If it is decided to move Thunderbird out of Mozilla, I'd like to suggest
to reach out to The Document Foundation and ask if they are interested.
It seems to me that Thunderbird might be a good addition to their
LibreOffice productivity suite.

> good, which I also share. However, point 2 above — “Neither project

> can focus wholeheartedly on what is best for it” -- is the most
> important point. Having Thunderbird has an additional product and

> focus is *not* good overall if it causes all of our products —
> Firefox, other web-driven products and Thunderbird — to fall short of

[Benjamin Kerensa]

I'm just going to add that Mitchell's email while we u see stand what she
said I think the messaging could have been different. I'm unsure if PR was
consulted but the end result has been very negative media for Thunderbird
as a project and Mozilla across media in all countries.

I don't even know why it was necessary to email Mozilla Governance since
nothing is being proposed yet technically. Why not reach out to Thunderbird
Council and other stakeholders? It seems like this message created the
perfect recipe for FUD when nothing is changing today or likely in the near
future.

It is great to finally hear what's going on or what Mozilla leadership
thinks but I don't think the world needed to know all this until more
things were certain and there was a game plan in place.


On Thu, Dec 3, 2015 at 7:58 AM Thomas Zimmermann <tzimm...@mozilla.com>
wrote:

[Mitchell Baker]

There is always a back-and-forth between how much the leadership announces a plan and how much there is a community-based process, with early statements of what's in the air and the ability  for those who are interested and can get involved in a productive way to do so.

This time I did the latter.  Some time when I do the former I expect to get the opposite concern -- that I decided who gets to participate, worked on a plan and have no presented a "done deal." 

I opted for the former this time because in general I think Mozilla has moved towards the part of the spectrum where our operating model is affected quite a bit by what might happen in the press.  Doing this makes for a much more polished public presentation.  The loss of community-based engagement in the creative stages seems quite real to me.  I'd like to find ways to avoid that.

mitchell

[Gijs Kruitbosch]

On 03/12/2015 16:09, Benjamin Kerensa wrote:
> I'm just going to add that Mitchell's email while we u see stand what she
> said I think the messaging could have been different. I'm unsure if PR was
> consulted

Did you consult PR before you posted your response?

> but the end result has been very negative media for Thunderbird
> as a project and Mozilla across media in all countries.
>
> I don't even know why it was necessary to email Mozilla Governance

Whoa. We're an open project. This is what we do. It is fundamentally
impossible to have open and honest conversation in public for a
high-profile project like Mozilla, and not have the media cover it.

There is also literally no way to communicate "we're going to do a
little less of X" (for pretty much any subtle meaning of "do a little
less") in a way that makes users of X happy and/or avoids media coverage
that doesn't just say "stop", "wind down", "eliminate", "kill" etc. even
if all 4 of those are hyperbole. It happened last time we reduced
investment in Thunderbird. Of course it happened again.

Unless we want Mozilla to stop being an open project where things like
this can be discussed by everyone in an open fashion, there is no way
around this.

TBH, if this hadn't been discussed publicly before finalizing plans,
people would have complained because it was a "decision made in secret"
and "why wasn't I consulted". Now people are being consulted and instead
those doing the consulting get told "but you didn't come out with a
finished plan and so the media spreads FUD and people are upset, don't
do that".

I'm sorry, we can't have it both ways, and blaming Mitchell (or PR, or
anyone else) for that is not a productive thing to do.

~ Gijs

(who has spent the last month or so becoming intimately familiar with
reactions to "we're stopping X" because tab groups / panorama.)

[R Kent James]

On 12/3/2015 8:09 AM, Benjamin Kerensa wrote:
> I'm just going to add that Mitchell's email while we u see stand what she
> said I think the messaging could have been different. I'm unsure if PR was
> consulted but the end result has been very negative media for Thunderbird
> as a project and Mozilla across media in all countries.
>
> I don't even know why it was necessary to email Mozilla Governance since
> nothing is being proposed yet technically. Why not reach out to Thunderbird
> Council and other stakeholders? It seems like this message created the
> perfect recipe for FUD when nothing is changing today or likely in the near
> future.
>
> It is great to finally hear what's going on or what Mozilla leadership
> thinks but I don't think the world needed to know all this until more
> things were certain and there was a game plan in place.

I read a response to one of those negative press reports that said,
"Isn't this at least the third time I've heard that Thunderbird is
dead?" When I go to open-source gatherings, frequently people are
surprised that I work with Thunderbird, because they thought Thunderbird
died years ago.

Yet a couple of weeks ago we hit our highest ADI ever, 9.8 million
users. We expect a major celebration next year as we pass 10 million
ADI, which using standard ADI->actual user multipliers, should represent
about 25,000,000 total users. Meanwhile we are all busy getting ready
for our next major release.

So I don't really have much concern about what the press is saying. I
understand that Mozilla does given their mission, and we will work with
them as necessary to clarify the message for Mozilla's sake, but our
mission as Thunderbird is simply to best serve whatever users we have,
full stop.

Because we are a community project, we discuss our real issues openly.
If the press decides to grab onto some topic and run with it, we cannot
control that, and we won't try. I will not promote more closed
discussions out of fear for FUD from the press.

:rkent
Chair, Thunderbird Council

[Henri Sivonen]

On Thu, Dec 3, 2015 at 5:37 PM, R Kent James <ke...@caspia.com> wrote:
> In my dreams though, 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.

N1 is GPLv3 like GPG, so my licensing comment applies to using code
from N1 in addition to applying to bundling GPG.

> The Enigmail community is certainly important, but represents a small
> fraction of our users, less than 5% certainly.

Well, it could be larger if Thunderbird included the GPG and Enigmail
functionality in the product itself.

[Mitchell Baker]

Thanks for the suggestion! We'll follow up.

mitchell

[Douglas Turner]

Hey Daniel,

Lots of questions; let me try. Keep in mind that there are plenty of
points of views at Mozilla. These are my opinions which are influenced by
the gecko developers I work with and the Firefox teams that I support.
Some of this will feel like tit for tat, my intent is only to address each
of your questions.

> a. all the underlying technologies of Thunderbird's world (XPCOM, XUL,
> XBL, XUL-based add-ons) are on the verge of being deprecated. Is the
> announced move a way to decouple faster, as it seems reading your
> bullet point 8? What other areas of Gecko will be "cleaned up" if
> that decoupling happens? This question is an absolutely major one
> because it will deeply impact the rendering engine's choice.
>

It's unclear at this point what would be deprecated or what time frame
we're talking about.

The bigger picture is that I want the web to win. I want it to be
more-awesome than Android, iOS, Win32, and xul-gecko. I want people to be
able to build products like Thunderbird and BlueGriffon directly on the
web. This is where we're heading.

> b. Thunderbird will still need to embed a browser, even if it does not
> use any more XUL or XPCOM in the future. Embeddability of Gecko has
> always been a poor parent of the project.

Very familiar with that problem... Fifteen years ago I was embedding Gecko
into the AOL/Gateway Crusoe!

> Will it change or should
> Thunderbird look for rendering engine alternatives?
>

This is something the TB team should figure out -- I am in no position to
talk for them.

>
> c. if a is true, then a very long list of third-party apps, like my own
> (BlueGriffon line) or Seamonkey, will be very deeply impacted. What
> about them/us?
>

This is speculation. Maybe someone would carry a branch with XUL support.
Or maybe someone would build a transcompiler. Or maybe the authors of these
programs would rewrite to the web.

Keep in mind, there is no plan to remove XUL or stop supporting XUL.
Firefox depends on XUL and it's unlikely that will change anytime soon.

>
> d. do you have any ETA or deadline? I suspect that a rewriting of TB
> w/o Mozilla technologies is a >=2 years effort for a team of 2 to 3.
>

This is a conversation that the Thunderbird owners will have to have. I do
think that it is way premature to even think about removing XUL from Gecko.



One more thing:

We plan on supporting Thunderbird at Mozilla until there is a proper
transition. Thunderbird users will continue to get releases and security
fixes.


Thanks for the questions!

Doug

[Daniel Glazman]

On 04/12/2015 06:32, Douglas Turner wrote:

> Hey Daniel,

Hi my friend!

> a. all the underlying technologies of Thunderbird's world (XPCOM, XUL,
> XBL, XUL-based add-ons) are on the verge of being deprecated. Is the
> announced move a way to decouple faster, as it seems reading your
> bullet point 8? What other areas of Gecko will be "cleaned up" if
> that decoupling happens? This question is an absolutely major one
> because it will deeply impact the rendering engine's choice.
>
>
>
> It's unclear at this point what would be deprecated or what time frame
> we're talking about.
>
> The bigger picture is that I want the web to win. I want it to be
> more-awesome than Android, iOS, Win32, and xul-gecko. I want people to
> be able to build products like Thunderbird and BlueGriffon directly on
> the web. This is where we're heading.

Then we need to drastically increase the pace of submission to Standard
bodies like W3C to fill the gaps. The dismissal of the File API a while
ago is one of the crucial holes in the platform. We also need html-based
UI to go far beyond what Gaia currently allows to reach all what all
plaforms allow. Let's think Qt. And we need that to become a Standard.
There are other crucial Gecko interfaces available to chrome code
that have strictly no equivalent in the Open Web Platform.
This will also help a lot FirefoxOS and Firefox, of course.

Earlier in this thread was mentioned XUL that "never gained traction".
It never gained traction not only because of the market, but also
because there was reluctance at some point in the past to submit it
to W3C and have a WG reach a Standard. Because of that, XAML became
a competitor, while my high-level contacts at Microsoft were all in
favor of a standard and interoperable solution. Qt also got a
competitor UI language. This was a strategic mistake we should probably
not make again.

> b. Thunderbird will still need to embed a browser, even if it does not
> use any more XUL or XPCOM in the future. Embeddability of Gecko has
> always been a poor parent of the project.
>
>
> Very familiar with that problem... Fifteen years ago I was embedding
> Gecko into the AOL/Gateway Crusoe!

I had the same issue with AOL/Anvil if you recall correctly.

> This is speculation. Maybe someone would carry a branch with XUL
> support. Or maybe someone would build a transcompiler. Or maybe the
> authors of these programs would rewrite to the web.
>
> Keep in mind, there is no plan to remove XUL or stop supporting XUL.
> Firefox depends on XUL and it's unlikely that will change anytime soon.

I have been asking for that for years, and this is the very first time
I get such an answer, thank you. Now, I only need to have a sense of
what "anytime soon" means. I should also note I heard quite different
messages from some Moz employees. That's normal, but you have to
understand this is a direct and immediate threat to the business of
several companies and these companies cannot remain in such darkness.
The cost of decoupling Postbox or BlueGriffon from Gecko would be
tremendous.

</Daniel>

[akerb...@gmail.com]

Mostly a philosophical point from a long-term Tb user and localizer. 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.

I'm not that technical and can't comment on issues of this code vs that code though the argument of separating Fx more from Tb seems to be persuasive. 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.

[Benjamin Smedberg]

On 12/4/2015 12:32 AM, Douglas Turner wrote:
> Keep in mind, there is no plan to remove XUL or stop supporting XUL.
> Firefox depends on XUL and it's unlikely that will change anytime soon.

Doug, I'm surprised to hear you say that. There is definitely a desire
within the Firefox org to stop using XUL in its current form, and I've
heard a distinct desire within the DOM and layout team to stop
supporting the -moz-box layout paths in particular, the non-standard XUL
parser, and XBL.

--BDS

[Douglas Turner]

If there is a plan, please reference it! I guess what I am thinking here
is that there is a difference between writing new stuff using html5 and
rewriting all of Firefox to remove XUL.




On Fri, Dec 4, 2015 at 7:50 AM, Benjamin Smedberg <benj...@smedbergs.us>
wrote:

[Gijs Kruitbosch]

I don't think we have a concrete 100% worked-out *plan* at this point on
exactly how to remove all of XUL, but Benjamin said that there is a
*desire* to remove it. I can't speak for platform, but IME certainly
large portions of the Firefox frontend team do feel that way.

And realistically we *are* slowly but surely moving away from it, even
for existing XUL things. For instance, the new tab page moved to HTML
somewhat recently (yes, it was XUL before). I believe devtools are also
working on moving (further) away from XUL. The feed reader subscription
UI is moving to HTML. I was talking to Dave the other day about writing
an HTML-based treeview implementation so we can stop using XUL <tree>,
which will help moving things like about:sessionrestore and the
in-content prefs and so on away from XUL and XBL as well.

IMO, the only way to find out exactly how this is going to work for all
instances of "X is easy with XUL/XBL and hard(er)/impossible with HTML"
is to start doing it - there's no way to plan our way out of this before
we start, XUL and XBL's surface area is simply too big. When the surface
area is smaller (e.g. just outer windows and similar OS integration
left) then we can plan more easily. Right now it is too big a problem to
create a "from 0-100%" plan. But we're chopping away at it.

In the same way, it would be wise for things like bluegriffon,
Thunderbird, and other projects that rely on Gecko, to "write new stuff
using html5", and where they're redoing things anyway, to rewrite them
in HTML.

Ultimately though, I don't know that any of this is all that relevant to
this thread. We won't have a XUL-less Firefox "for a while", and the
conversation about Thunderbird's future is more immediately coupled to
build system issues, mozilla-central, discussions at a high level
between MoFo/MoCo/TB-council, etc. Less so "but what about XUL", AIUI.

~ Gijs

[Gijs Kruitbosch]

[Gijs Kruitbosch]

[R Kent James]

On 12/4/2015 8:48 AM, Douglas Turner wrote:
> If there is a plan, please reference it! I guess what I am thinking here
> is that there is a difference between writing new stuff using html5 and
> rewriting all of Firefox to remove XUL.

I think that you are seeing what is the common experience of people who
are trying to work with Mozilla technologies. That is, there are rumors
and statements about plans to deprecate some feature or technology, but
rarely any concrete schedule. Often these things take years between
rumor and implementation, and the rumor starts before there is any
concrete replacement. But the rumor is enough for us to be on notice, or
so the expectation goes, so someone can get the urge to really make it
happen, and quite quickly the rumor becomes reality. If you are trying
to rely on Mozilla technologies, there is this constant threat of a
sudden technology change that will leave you and your major application
unusable.

What this does is leave people with the solid understanding that Mozilla
is not a reliable technology partner.

As far as I understand the official Mozilla position, the only
application that is encouraged to use the Mozilla platform is Firefox.
Anybody else is on notice that their needs will not be considered in
future technology planning, and "Go Fast" initiatives mean that
technology deprecation will go faster than anybody can reasonably keep
up with. In that environment it would be great if there were "no earlier
than" schedules for deprecation of key technologies like XUL, XPCOM, and
XBL, hopefully with years of warning.

I think it is fair to say that those of us who have major investments in
Mozilla technology do not think this is the right approach for Mozilla.
Of course we are terribly inconvenienced by it, to the point of
existential threats to our existence as viable products and communities.
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".

Another restatement of my current understanding of the Mozilla position
is, "We will try to be nice about it, but please everybody but Firefox
stop using the Mozilla platform as rapidly as possible". As loyal
Mozillians, we'll fall on our swords and strongly consider migrating to
NodeJS-based platforms. Is that really what Mozilla wants?

:rkent (representing his own viewpoints and not the Thunderbird Council).

[Daniel Glazman]

On 04/12/2015 18:09, Gijs Kruitbosch wrote:

> Ultimately though, I don't know that any of this is all that relevant to
> this thread. We won't have a XUL-less Firefox "for a while", and the
> conversation about Thunderbird's future is more immediately coupled to
> build system issues, mozilla-central, discussions at a high level
> between MoFo/MoCo/TB-council, etc. Less so "but what about XUL", AIUI.

Mitchell's original message was bot technical enough for me to
understand this was only about infrastructure hence my followup.
And this is the governance mailing-list after all, and my followup
IS about governance.

</Daniel>

[Daniel Glazman]

On 04/12/2015 20:43, R Kent James wrote:

> I think that you are seeing what is the common experience of people who
> are trying to work with Mozilla technologies. That is, there are rumors
> and statements about plans to deprecate some feature or technology, but
> rarely any concrete schedule. Often these things take years between
> rumor and implementation, and the rumor starts before there is any
> concrete replacement. But the rumor is enough for us to be on notice, or
> so the expectation goes, so someone can get the urge to really make it
> happen, and quite quickly the rumor becomes reality. If you are trying
> to rely on Mozilla technologies, there is this constant threat of a
> sudden technology change that will leave you and your major application
> unusable.

This has always been one of the major issues of the community:
"everything is in bug ###" is not enough as a message for us embedders
and users. And there were no blog post about any plan. There are
"desires", "opinions" but where's the plan? When was it discussed or at
least presented to us embedders? When was the impact on us evaluated and
how since we were never pinged about it? This does not feel like the
normal behaviour of a community, and it costs me an arm to write it, as
we say in french.

I am therefore asking for a "council" or "committee" gathering the main
embedders/users of the Mozilla platform where we could, together, have
a better vision of the future of the platform - even if we have to sign
a confidentiality agreement - and discuss what it means to everyone.
This does not exist today. Or maybe we don't count at all - and I can
live with it - but we have to officially know it _now_.

Unfortunately, I have to agree totally with the above. As I already
said, companies very deeply relying on the Mozilla platform are left
in the dark and it's supposed we can cope with any transformation of
that platform, whatever the depth. It's not going to happen that way
for multiple reasons: cost, strategy, and more. I should also mention
trust, yes trust. But overall, there are technical reasons why a
Mozilla platform moving to the OWP won't be suitable any more to our
projects: we will not be able to express all we do or use because
html-based apps are just not at that level yet.
I have gathered a list of all the interfaces BlueGriffon uses in its
JS code. Since it's quite long, please ping me to get it, I don't want
to paste it here. A rewriting of BlueGriffon based on html would require
a replacement for all of them. In terms of cost, BlueGriffon is a 2.5
years project from scratch to v1. Let's be clear, we won't have the
finances to rewrite it. I am then asking for a real strategy for a
smoother transition plan, and I consider it as only fair.

Again, I feel VERY sad writing all of that. I have a been a faithful
and loyal member of the community for fifteen years - and even more
if you consider my years of faithful supporter of Netscape (ask Vidur
Apparao...). I pushed Gecko to countless organizations in Europe, US
and Asia. Seeing that Mozilla gives us so little information about moves
that put whole businesses (including mine) at risk is heart-breaking.
I am discussing here a death knell on my company and some of my
customers, and the reply is just "follow us at our speed" w/o really
caring about our capacity to do it. This feels so totally wrong.

</Daniel>

[Mark Banner]

On 05/12/2015 09:02, Daniel Glazman wrote:
> On 04/12/2015 20:43, R Kent James wrote:
>
>> I think that you are seeing what is the common experience of people who
>> are trying to work with Mozilla technologies. That is, there are rumors
>> and statements about plans to deprecate some feature or technology, but
>> rarely any concrete schedule. Often these things take years between
>> rumor and implementation, and the rumor starts before there is any
>> concrete replacement. But the rumor is enough for us to be on notice, or
>> so the expectation goes, so someone can get the urge to really make it
>> happen, and quite quickly the rumor becomes reality. If you are trying
>> to rely on Mozilla technologies, there is this constant threat of a
>> sudden technology change that will leave you and your major application
>> unusable.
>
> This has always been one of the major issues of the community:
> "everything is in bug ###" is not enough as a message for us embedders
> and users. And there were no blog post about any plan. There are
> "desires", "opinions" but where's the plan? When was it discussed or at
> least presented to us embedders? When was the impact on us evaluated and
> how since we were never pinged about it? This does not feel like the
> normal behaviour of a community, and it costs me an arm to write it, as
> we say in french.

There was a discussion started on this at the last work week. As part of
that discussion, there was then at least a couple of follow-up
discussions on the Firefox-dev mailing list:

https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html
https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003119.html

I don't think it made it to any blog posts, but I could be wrong. Given
there's no firm plans on timescales or how things would be
removed/replaced, I think that's reasonable.

Note that for add-ons dropping xul etc has been already communicated as
part of other plans:

https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

>> As far as I understand the official Mozilla position, the only
>> application that is encouraged to use the Mozilla platform is Firefox.
>> Anybody else is on notice that their needs will not be considered in
>> future technology planning, and "Go Fast" initiatives mean that
>> technology deprecation will go faster than anybody can reasonably keep
>> up with. In that environment it would be great if there were "no earlier
>> than" schedules for deprecation of key technologies like XUL, XPCOM, and
>> XBL, hopefully with years of warning.

One of the things that stuck out for me from the discussions we had, was
that we don't really know how hard moving away from XUL will be -
there's various performance concerns, if things can be done in HTML or
not, and many other things. We'll need to work to resolve these, but
there's currently too many unknowns to be able to scope/estimate the
project. The initial idea, as Gijs commented, was to try and start
moving various parts of Firefox and see what the real issues actually were.

Mark.

[Daniel Glazman]

On 05/12/2015 16:44, Mark Banner wrote:

> Note that for add-ons dropping xul etc has been already communicated as
> part of other plans:
>
> https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

And this is another huge threat to our businesses that was not discussed
with us first. In the case of BlueGriffon, the editor is OSS and free
to download and use. We sell XUL-based add-ons.

> One of the things that stuck out for me from the discussions we had, was
> that we don't really know how hard moving away from XUL will be -
> there's various performance concerns, if things can be done in HTML or
> not, and many other things. We'll need to work to resolve these, but
> there's currently too many unknowns to be able to scope/estimate the
> project. The initial idea, as Gijs commented, was to try and start
> moving various parts of Firefox and see what the real issues actually were.

Performance is one thing. I still remember hyatt's tests to make the
XUL tree handle 30,000 rows... But reaching native UI completeness or at
least at the level of XUL and XBL is another thing and it's going to be
quite tricky.
Did I ever mention that WebComponents are not simpler than XBL, far from
it even?-)

</Daniel>

[Majken Connor]

This is great to read.

One thing I have noticed is that the public attention span is very short. I
think we do better to figure out how to weather some of the storms than
trying to avoid them. The people who will have a long term impact on the
impression of and future of Thunderbird will almost all definitely
understand the real message here. The people jumping to conclusions will
almost all forget about this announcement in a couple weeks and not have
further impact.

On Thu, Dec 3, 2015 at 12:09 PM, Mitchell Baker <mitc...@mozilla.com>
wrote:

> There is always a back-and-forth between how much the leadership announces
> a plan and how much there is a community-based process, with early
> statements of what's in the air and the ability for those who are
> interested and can get involved in a productive way to do so.
>
> This time I did the latter. Some time when I do the former I expect to
> get the opposite concern -- that I decided who gets to participate, worked
> on a plan and have no presented a "done deal."
>
> I opted for the former this time because in general I think Mozilla has
> moved towards the part of the spectrum where our operating model is
> affected quite a bit by what might happen in the press. Doing this makes
> for a much more polished public presentation. The loss of community-based
> engagement in the creative stages seems quite real to me. I'd like to find
> ways to avoid that.
>
> mitchell
>
>

> On 12/3/15 8:09 AM, Benjamin Kerensa wrote:
>
> I'm just going to add that Mitchell's email while we u see stand what she
> said I think the messaging could have been different. I'm unsure if PR was
> consulted but the end result has been very negative media for Thunderbird
> as a project and Mozilla across media in all countries.
>
> I don't even know why it was necessary to email Mozilla Governance since
> nothing is being proposed yet technically. Why not reach out to Thunderbird
> Council and other stakeholders? It seems like this message created the
> perfect recipe for FUD when nothing is changing today or likely in the near
> future.
>
> It is great to finally hear what's going on or what Mozilla leadership
> thinks but I don't think the world needed to know all this until more
> things were certain and there was a game plan in place.
>
>

> On Thu, Dec 3, 2015 at 7:58 AM Thomas Zimmermann <tzimm...@mozilla.com>

[Panos Astithas]

On Sat, Dec 5, 2015 at 11:02 AM, Daniel Glazman <dan...@glazman.org> wrote:

> On 04/12/2015 20:43, R Kent James wrote:
>
> > I think that you are seeing what is the common experience of people who
> > are trying to work with Mozilla technologies. That is, there are rumors
> > and statements about plans to deprecate some feature or technology, but
> > rarely any concrete schedule. Often these things take years between
> > rumor and implementation, and the rumor starts before there is any
> > concrete replacement. But the rumor is enough for us to be on notice, or
> > so the expectation goes, so someone can get the urge to really make it
> > happen, and quite quickly the rumor becomes reality. If you are trying
> > to rely on Mozilla technologies, there is this constant threat of a
> > sudden technology change that will leave you and your major application
> > unusable.
>

I honestly can't understand how one can come to this conclusion from the
points above.

Giant corporations in our industry make plans in secret, announce them once
they are done and everyone is left scrambling to follow along (unless they
were participating in their NDA-bound developer programs), and yet most
people consider that business as usual.

Mozilla starts talking in public about future directions long before there
is even a concrete plan in place and some feel like there will be a "sudden
technology change". It can only be "sudden" if we are talking in geological
terms.

This has always been one of the major issues of the community:
> "everything is in bug ###" is not enough as a message for us embedders
> and users. And there were no blog post about any plan. There are
> "desires", "opinions" but where's the plan?
>

Your frustration along with your long-time commitment to the project makes
it clear that you care deeply about this, but could you perhaps try to tell
us what it is we should do:

a) a blog post about a specific plan with a timeline, decided and delivered
from above, or
b) an honest discussion in public about our "desires" and "opinions" that
will culminate in a specific plan.

Both are reasonable requests and it's fine for different people to want
either, but I can't understand how someone could want both at the same time.

In case folks in this thread missed our previous discussions:

- firefox-dev thread from July 2015, titled "Revisiting how we build
Firefox":
https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html

- dev-platform thread from October 2014, titled "Moratorium on new XUL
features":
https://groups.google.com/d/msg/mozilla.dev.platform/HDJl1iBifB8/1TG876POw8cJ

That's how things usually happen at Mozilla, we discuss in public mailing
lists, come up with a detailed plan and then present it in a blog post. As
Gijs explained earlier, we don't have a detailed plan yet.

The rationale has been laid down in both threads by various people, but
it's fine to disagree with the finer points or with the entire plan. What
is not cool is to insinuate that there has been no public discussion about
this plan, which is still in its infancy.

Cheers,
Panos

[David Bruant]

Le 05/12/2015 18:08, Daniel Glazman a écrit :
> On 05/12/2015 16:44, Mark Banner wrote:
>
>> Note that for add-ons dropping xul etc has been already communicated as
>> part of other plans:
>>
>> https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
> And this is another huge threat to our businesses that was not discussed
> with us first. In the case of BlueGriffon, the editor is OSS and free
> to download and use. We sell XUL-based add-ons.

Have you signed a contract with Mozilla in which you made sure Mozilla
could not make moves that would threaten your business? (I assume you
haven't as I assume Mozilla would not sign such a contract, maybe I'm
wrong, but you would probably be enforcing the contract instead of
coming here to discuss)
Has Mozilla made general commitments about XUL or other Mozilla-specific
technologies suggesting it was a reasonable business decision for you ro
rely so profoundly on Mozilla's decisions? (I don't believe they have)

My point of view is obviously subjective, but from where I stand, it
looks like it's been many years that Mozilla has chosen to not focus on
embedability.
Node has chosen to use V8, MongoDB moved away from SpiderMonkey to use
V8, lots of embedded browsers are WebKit or Blink-based (not
Gecko-based). To the point where I believe I've read somewhere Servo may
try to have the necessary APIs/ABIs to be a drop-in replacement for
Webkit for embedders. And Node-webkit and Electron, etc.
I'm sensing a trend here and it does not contain a lot of XUL.

As a consequence, it looks like a very dangerous business decision to
depend on Mozilla's embeddability and support for some proprietary
technologies. For sure I would not have made it, but we may come from a
different perspective on this.

It may have been the choice you've made, but you should consider it may
be a bad choice and you should consider shifting your own strategy
instead of expecting/hoping Mozilla will change theirs.
It may result in much less pain on your side.

David

[Daniel Glazman]

On 06/12/2015 12:11, Panos Astithas wrote:

> a) a blog post about a specific plan with a timeline, decided and delivered
> from above, or
> b) an honest discussion in public about our "desires" and "opinions" that
> will culminate in a specific plan.
>
> Both are reasonable requests and it's fine for different people to want
> either, but I can't understand how someone could want both at the same time.

A or B is fine, but there are still many companies out there relying on
the Mozilla platform and I think they should be in the loop.

</Daniel>

[Daniel Glazman]

On 06/12/2015 15:11, David Bruant wrote:

> Have you signed a contract with Mozilla in which you made sure Mozilla
> could not make moves that would threaten your business? (I assume you
> haven't as I assume Mozilla would not sign such a contract, maybe I'm
> wrong, but you would probably be enforcing the contract instead of
> coming here to discuss)

Hrmpf.

My company - contracting for Lindows/Linspire at that time - started Nvu
at a time XULRunner was must better supported by Mozilla than today.
There were dozens of companies building apps above it. Do you mean they
were all wrong to do it? Do you mean Mozilla never intended to create
an ecosystem? That would be a drastic rewriting of what really happened,
at a time you were not around IIRC.
When I started BlueGriffon, the successor to Nvu, XULRunner was still
_the_ way to embed Gecko into a native app, up to the point it had its
own tinderbox.

> Has Mozilla made general commitments about XUL or other Mozilla-specific
> technologies suggesting it was a reasonable business decision for you ro
> rely so profoundly on Mozilla's decisions? (I don't believe they have)

Ok, this goes far beyond the rational discussion. I was raising an issue
about a clear threat to several businesses of the Mozilla ecosystem,
businesses that have been long-time partners and spread the Mozilla word
all around the world and your words above are inducing clear doubts
about the way these businesses were and are still managed, successfully
for more than a decade. Maybe you should consider a word of apology,
because this is clearly offending.

> As a consequence, it looks like a very dangerous business decision to
> depend on Mozilla's embeddability and support for some proprietary
> technologies.

What I said above.

</Daniel>

[Paul]

Does Thunderbird have a role in the future of Mozilla? Not taking the current approach. But neither does Firefox.

Thunderbird's primary existence should be to showcase the versatility of the Mozilla Platform. It should be to show that with a different module setup, you get an application that can run on all modern day open devices without compromise.

Obviously that means you also enable users to get access to their mail without some of the pitfalls which come with modern day clients.

Our current approach to software isn't modular and so things like this aren't happening. Instead we fail our users by not even having EME in testing on Linux.

The Mozilla platform secures the future of Firefox and Mozilla. If we create a platform where developers can plug and play components to create cross-platform software, we get more contributors to the platform itself. We grow the Mozilla ecosystem. That is our fundamental goal at this point.

Of course Thunderbird is a tax on Firefox as things stand. But as we continue to shave features and suggest that the developers of our biggest plugins throw away their flagship tailored versions for cut-down versions made for Chrome, aren't we essentially telling ourselves that we aren't confident in Firefox anyway? We're already compromising on what is Firefox, take a look at our iOS release. I'd much rather see Mozilla grow and have a future.

The reality is that the Firefox ecosystem doesn't exist, but we can create the Mozilla Platform ecosystem and have a low-maintainence Thunderbird flourish. With the growth of the platform, Firefox is enabled a new path to growth and experiments like Qt Firefox and WebOS Firefox become viable again due to the smaller requirements to get them working thanks to a truly unified modular codebase.

On Tuesday, 1 December 2015 18:57:24 UTC, Mitchell Baker wrote:
> This is indeed the same discussion, and we continue to share the same
> difference in viewpoints and appropriate action.
>
> Also, I note that the point of my post is that relying on shared
> infrastructure -- by which I meant build and release, etc -- doesn't
> make sense. The question of whether Mozilla Foundation is the right
> infrastructure for a home for Thunderbird is a different question, and
> currently much more open.
>
> mitchell
>
>
> On 12/1/15 7:24 AM, Paul wrote:
> > Here's my two cents on the matter. In Mozilla's failing to create the platform that Firefox should run atop it quickly became an uphill struggle to compartmentalise code. As a result, where Thunderbird should've been a module that plugs into a platform and should've got a free ride with the Android and desktop releases, it instead required a whole bunch of work. It's not impossible to take Firefox in that direction and in fact would actually be beneficial as it would allow for Firefox to run on a much wider array of devices in the long run.
> >
> > The fact of the matter is, Mozilla lacks an ecosystem and even while there's no truly good third-party mail app available for Android, because of the laser-focused approach to Firefox, Mozilla lacks the agility to capitalise on such needs. All this while Google faffs about with Inbox and Gmail attempts to be the portal to everyone's mail.
> >
> > This isn't even a new concern:
> > 1. https://someotheropines.wordpress.com/2011/10/13/soo-is-it-possible-to-arrive-at-any-other-conclusion-than-thunderbird-is-doomed/
> > 2. https://someotheropines.wordpress.com/2011/11/15/soo-is-it-time-for-a-more-modular-approach-to-browsing/
> > 3. https://someotheropines.wordpress.com/2011/11/24/soo-musings-on-mozillas-mobile-meddlings/
> > 4. https://someotheropines.wordpress.com/2012/07/24/soo-just-why-doesnt-mozilla-seem-to-get-it/
> >

[Kyle Huey]

On Mon, Dec 7, 2015 at 6:45 AM, Paul <sabre...@yahoo.co.uk> wrote:
> The Mozilla platform secures the future of Firefox and Mozilla. If we create a platform where developers can plug and play components to create cross-platform software, we get more contributors to the platform itself. We grow the Mozilla ecosystem. That is our fundamental goal at this point.

I don't think Gecko developers agree with this. By and large, the web
is the platform. Not Mozilla-proprietary extensions (e.g. XUL).

- Kyle

[Paul]

But haven't we already began to replace Mozilla-proprietary extensions with their native counterparts? Come what may, users will need free software to be able to access an open Internet. Firefox remains a means to doing that without some of the concerns which other browsers give way too.

[R Kent James]

On 12/7/2015 6:45 AM, Paul wrote:
> Does Thunderbird have a role in the future of Mozilla?
>

I think that the Mozilla powers-that-be have made it fairly clear that
they do not believe Thunderbird is an important piece of the Mozilla
web-focused strategy, which is the primary mission of at least MoCo.
Whether Thunderbird has a role within Mozilla more broadly, as an entity
focused on internet freedom and privacy, is still an open question.

> Thunderbird's primary existence should be to showcase the versatility of the Mozilla Platform.

Representing Thunderbird, we would not agree that is an important part
of why Thunderbird exists.

>
> Of course Thunderbird is a tax on Firefox as things stand. ... but we can create the Mozilla Platform ecosystem and have a low-maintainence Thunderbird flourish.

What I hear Mozilla saying is no, we cannot continue to support the
Mozilla platform, and applications such as Thunderbird that use the
Mozilla platform are strongly encouraged to stop.

But maybe I am hearing the wrong message. Another possible message from
Firefox would be "We're really busy with our own issues now, so please
don't expect much from us, but it is cool if you guys hang around and
try to do things with our platform."

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. I am not asking for
any change in path (though I suspect much of our community would
probably ask that), I am just asking for as much clarity as can be
offered about what the decisions are. Without clarity, it is very
difficult to achieve the unity of direction that we need within the
Thunderbird community to make some very difficult decisions on our own
direction.

--
R. Kent James
Chair, Thunderbird Council
@rkentjames

[Paul Fernhout]

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

To deal with this technical debt, I propose Mozilla fund a "skunkworks" team of seven people for a year to create a new server version of Thunderbird (called "Thunderbird Server") that runs initially as a Node.js app providing a single-page JavaScript/TypeScript webapp for email handling and other peer-to-peer communications using local storage. Thunderbird Server would assume Firefox 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). This Thunderbird Server platform would, through plugins, eventually become a social semantic desktop that would change the nature of the web as we know it.

This is a feasible way to deal with the technical debt Andrew talks about while still being true to the idea of distributed data and peer-to-peer communications which is at the core of the Thunderbird vision. Sadly, Thunderbird Desktop itself would then be left to technical bankruptcy (or self-serve fixes) once the Thunderbird Server version proved stable and popular and the migration path was clear and easy. However, 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.

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. At the link below is a manifesto I just wrote today 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 FOSS system I've already written called NarraFirma, I'm confident could produce a proof of concept of this Thunderbird Server idea even just working by myself.

You can find the "ThunderbirdS are Grow!" manifesto here:
http://pdfernhout.net/thunderbirds-are-grow-manifesto.html

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

[davix...@gmail.com]

Hi everyone,
I thinkg Thunderbird development should be continued. If Mozilla can't develop it I can organise a team to develop Thunderbird.

[Benjamin Kerensa]

I'm confident that Mozilla is not going to invest to expand Thunderbird by
making any kind of server edition.


On Thu, Dec 10, 2015 at 2:54 AM Paul Fernhout <pdfer...@kurtz-fernhout.com>
wrote:

[Benjamin Kerensa]

It's not that Mozilla cannot but that it does not see Thunderbird as having
the level potential at impacting the open web that Mozilla believes Firefox
and its other investments will.

There is already a team of community contributors that develop it.

[Ben Bucksch]

Hey Doug,

Douglas Turner wrote on 04.12.2015 06:32:
> Lots of questions; let me try. Keep in mind that there are plenty of
> points of views at Mozilla. These are my opinions which are influenced by
> the gecko developers I work with and the Firefox teams that I support.
> Some of this will feel like tit for tat, my intent is only to address each
> of your questions.

Thank you for your kind attitude. It's help for a battered soul.

> I want people to be able to build products like Thunderbird and BlueGriffon directly on the web. This is where we're heading.

Do you mean Web technologies, or really websites?

If you mean Web technologies, yeah, why not. In fact, I'm currently
concretely trying to help with that, but I have nothing to show yet.

Typically, web means websites, and that's not always progress.
Thunderbird users use Thunderbird specifically because it's a desktop
application under their own control, not run by a third party. I've
personally been supporting the German Ministry of State including the
embassies. This is highly security sensitive, and they must have
absolute control over their data. The same is true for individual users
with privacy concerns. Thunderbird has a large userbase with this sort
of needs.

The same is true for many other applications.

>> b. Thunderbird will still need to embed a browser, even if it does not
>> use any more XUL or XPCOM in the future. Embeddability of Gecko has
>> always been a poor parent of the project.
>
> Very familiar with that problem... Fifteen years ago I was embedding Gecko
> into the AOL/Gateway Crusoe!

Doug! I actually remember that. You were a true hero for me. I remember
being amazed and in awe how you massaged Gecko to be embeddable, all by
yourself, a lonely quest. It wasn't easy back then, your first had to
dis-entangle the browser APIs. If I remember correctly, nsIWebShell (and
good parts of nsIDocShell?) are your brain children.

Every time I think of Gecko's embedding story, I get sad when thinking
of all the efforts you put in there, and how little care was taken later
to keep the APIs stable, which is crucial for embedding. And how much
mind-share we lost because of that. Gecko could have been the fabric for
many products, the computing world. (And is, more below)

>> Will it change or should Thunderbird look for rendering engine alternatives?
>>
> This is something the TB team should figure out -- I am in no position to
> talk for them.

I don't think you were intentionally avoiding the question, but Daniel
was asking whether this is going to *change*, whether the embedding
story will get tangibly better from Gecko's side, not from Thunderbird's.

>> c. if a is true, then a very long list of third-party apps, like my own
>> (BlueGriffon line) or Seamonkey, will be very deeply impacted. What
>> about them/us?

>>
>
> This is speculation. Maybe someone would carry a branch with XUL support.
> Or maybe someone would build a transcompiler. Or maybe the authors of these
> programs would rewrite to the web.

This is my cue, why I post here.

As a Mozilla consultant, it is my day job to support companies that use
Mozilla technology in their own software products. You don't see them,
but there are lots. You have the whole range from Firefox extensions
written to support their own business, all the way to products using
Gecko to inspect webpages to make automated security audits of websites,
and in some cases even entire applications based on Mozilla, like
Thunderbird.

In some cases, the company's flagship product is based on Mozilla
technology, and it's so engrained that removing XPCOM and XUL would mean
simply a complete rewrite of the whole product. Just the attempts in
recent years to "clean up" XPCOM has caused them *major* pain (and that
pain was sometimes the very reason why I was hired, because they were
hopeless), again and again. Many of them have actually given up on
Mozilla already, because it was so much pain. Some are so deeply rooted
in Mozilla that they don't have much of an option.

Killing XPCOM and XUL will simply kill their product. Flat and simple.

Thunderbird is not the only one. You probably have no idea how many
there are. You get an idea when you look at AMO. There's more happening
outside AMO, because it's internal or proprietary.

> Keep in mind, there is no plan to remove XUL or stop supporting XUL.
> Firefox depends on XUL and it's unlikely that will change anytime soon.

Doug, you can't believe how relieved I am to hear that. That's what I
had always understood.
HTML5 is the future, we'll slowly migrate to there. I hope that Servo
will be our renderer in the not too distant future, and I'd be happy to
see XBL eventually die. Some change is necessary, the question is how
the change happens. First have a replacement that's better and more
powerful, then let it pick up, see how people like it, wait a few years,
then kill the old tech.

Now I hear 18 months until death of XUL extensions, which would
effectively eradicate the majority of AMO and internal projects, and
that's an entirely different story. This is the point where projects are
at immediate risk, projects get canned. Very concretely, one employee of
mine resigned.

I would like to have *more* of this kind of discussion out in the open,
and most importantly to have this open discussion determine the decision
that's made.

All in all, thank you, Doug. Your post was speaking reasonableness.

Ben

[Daniel Glazman]

On 11/12/2015 21:26, Ben Bucksch wrote:

> Doug, you can't believe how relieved I am to hear that. That's what I
> had always understood.
> HTML5 is the future, we'll slowly migrate to there. I hope that Servo
> will be our renderer in the not too distant future, and I'd be happy to
> see XBL eventually die. Some change is necessary, the question is how
> the change happens. First have a replacement that's better and more
> powerful, then let it pick up, see how people like it, wait a few years,
> then kill the old tech.
>
> Now I hear 18 months until death of XUL extensions, which would
> effectively eradicate the majority of AMO and internal projects, and
> that's an entirely different story. This is the point where projects are
> at immediate risk, projects get canned. Very concretely, one employee of
> mine resigned.
>
> I would like to have *more* of this kind of discussion out in the open,
> and most importantly to have this open discussion determine the decision
> that's made.
>
> All in all, thank you, Doug. Your post was speaking reasonableness.

I concur entirely. A large Japan-based company pinged me a few weeks
ago, they wanted me to write an extension to Thunderbird adding UI
for writing-modes in HTML emails so they could author vertical-writing
messages. They are already users of BlueGriffon EPUB. The extension was
supposed to become OSS, free of charge, announced by PR, all of Japan
and China could have used it. Of course precisely in my favorite scope.

Mitchell's announcement, relayed by ComputerWorld 3 days ago at the end
of the FirefoxOS change announcement (they specifically quoted that
article), made them stop abruptly the discussions yesterday so I lost a
customer, and Thunderbird lost a market. A better - and more
discussed with us - process is badly needed. This is killing our
companies, and harming not only the future of Thunderbird but of a whole
ecosystem. Users are fleeing because of this.

</Daniel>

[Paul Fernhout]

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 (pdfer...@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 and 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. Firefox 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 commonalties 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.

[faz...@gmail.com]

[Henri Sivonen]

On Tue, Dec 1, 2015 at 7:27 PM, Daniel Glazman <dan...@glazman.org> wrote:
> 1. Thunderbird is a standalone application embedding Gecko

I think it's obscures the issues to characterize Thunderbird as
embedding. Embedding usually means putting a Web engine inside a
native app. Using Gecko as the platform for the desktop app itself is
something different.

On Mon, Dec 7, 2015 at 4:45 PM, Paul <sabre...@yahoo.co.uk> wrote:
> Thunderbird's primary existence should be to showcase the versatility of the Mozilla Platform.

On Fri, Dec 11, 2015 at 10:26 PM, Ben Bucksch
<ben.buck...@beonex.com> wrote:
> Thunderbird is not the only one. You probably have no idea how many there
> are. You get an idea when you look at AMO. There's more happening outside
> AMO, because it's internal or proprietary.

Let's look at some non-Firefox scenarios (some still possible, some no longer):

1) Embedding
a) Creating another Web browser with native chrome (Camino, K-meleon)
b) Previewing pages in a Web authoring tool that uses a non-Web
toolkit for its UI
c) Showing content from a particular Web site in a seemingly native
app affiliated with that site (common with WebKit on mobile)
d) Showing local Web tech content like help files in a native-toolkit app.
e) Showing content that's neither app-local like help files nor a
Web site: e.g. HTML email.

2) Gecko as installed app platform
a) Creating another Web browser with XUL chrome (SeaMonkey)
b) Creating an authoring tool that not only previews content using
Gecko but is itself running on Gecko (BlueGriffon)
c) Letting an app written in HTML+JS+CSS+SVG be locally installed
and do native-like things that the security model of the Web usually
blocks (some Firefox OS apps)
d) The XUL platform serving as an alternative to Qt for writing
cross-platform non-Web-focused Internet-connected desktop apps that
need to render some non-Web HTML (Thunderbird).
e) The XUL platform serving as an alternative to Qt for writing
cross-platform desktop apps that don't have much of a need to show
HTML content (Flickr Uploadr maybe?).

Which ones of these support any of the following?
* Make the Web (not the Internet, the *Web*) better in general.
* Drive usage of Gecko for *Web* usage thereby helping keep Gecko
relevant to the Web thereby allowing Gecko to serve as a vehicle for
Mozilla to make the Web better.
* Drive the creation of Web apps/sites that work great in Gecko
thereby helping keep Gecko relevant to the Web thereby allowing Gecko
to serve as a vehicle for Mozilla to make the Web better.
* Drive contribution to the Gecko features that make Gecko better for the Web.

In theory, mere usage of the Gecko platform for whatever purpose
regardless of XUL or HTML could drive contribution, but it seems that
in practice Gecko gets little Web-relevant contribution benefit from
any of the above-listed uses. Clearly, having a better embedding story
for WebKit and CEF has mindshare benefits for WebKit and Blink that
Gecko loses out on. But even if you look at WebKit, you'll find that
(apart from the time when Chrome used WebKit) WebKit has gotten very
little core Web feature contribution from all the non-Apple ports of
WebKit--most of the activity goes into taking WebKit to different
environments, which grows mindshare, but not to making the core of
WebKit better for the Web. (The effort to push WebRTC into WebKit
despite Apple may be an exception. And, like Gecko, WebKit has the
MathML exception.)

In theory, 1a and 2a could drive Gecko usage for Web usage, but in
practice the Gecko market share added by non-Firefox browsers has been
very small after Firefox on Mac got good enough to make Camino
irrelevant in terms of the Mac experience. (This aspect used to be
relevant when Firefox on Mac felt really un-Mac-like and Camino
addressed that problem. K-meleon never had a significant impact and
SeaMonkey has always been backward looking instead of taking Gecko to
new markets.)

In theory, 1b and 2b could be a big deal, but to have an big impact,
significantly more investment in this area would be required. With
Mozilla Corporation not investing in this area, e.g. Dreamweaver,
which has the big usage numbers, embeds Blink.

If 1c is an alternative to Web sites experienced in Firefox (or
another browser), the use case isn't really in favor of the Web but is
instead about trying to move users off the Web paradigm, which seems
like a negative from the point of view of advancing the Web.

The impact of 2c could be good for the Web or could be tangential.

1d, 1e, 2d and 2e aren't really that Web-relevant. In my experience
from meetings (which I don't get to experience often, since I work
remotely), trying to justify Mozilla Corporation's investment in them
by arguing from a Web-oriented mission doesn't work. Of course, for
people who have bought into using XULRunner as an alternative to Qt,
Mozilla losing interest in supporting XULRunner is a serious problem
and one that may be getting insufficient empathy. Still, appealing to
showcasing the versatility of the XULRunner platform (which is
off-Web) or appealing to internal or proprietary apps that are not
seen (which suggests there hasn't been notable Web-relevant
contribution to Gecko to make the sources of contribution known) is
unlikely to be persuasive in the light of the Web-oriented mission.

On Sat, Dec 12, 2015 at 12:35 PM, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:
> 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."

Note that the second sentence you quote changed from "the Internet" to
"the Web" in early September 2012.
August 31 2012:
https://web.archive.org/web/20120831102626/http://www.mozilla.org/en-US/mission/
September 10 2012:
https://web.archive.org/web/20120910100207/http://www.mozilla.org/en-US/mission/

(The way I found out was that in the past I was making a point about
email with an appeal to the Mission, looked up the Mission to be sure
I didn't misremember how it was phrased and was surprised to find that
it had changed.)

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

Indeed.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Dirkjan Ochtman]

On Tue, Dec 15, 2015 at 11:59 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
> On Sat, Dec 12, 2015 at 12:35 PM, Paul Fernhout
> <pdfer...@kurtz-fernhout.com> wrote:
>> 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."
>
> Note that the second sentence you quote changed from "the Internet" to
> "the Web" in early September 2012.
> August 31 2012:
> https://web.archive.org/web/20120831102626/http://www.mozilla.org/en-US/mission/
> September 10 2012:
> https://web.archive.org/web/20120910100207/http://www.mozilla.org/en-US/mission/

We discussed this on Twitter a bit already, but this is still very
weird me. Maybe someone from the leadership can comment?

Cheers,

Dirkjan

[Majken Connor]

This sounds like you've put some thought into this and are committed to
putting your money where your mouth is. I hope you get a thoughtful
response back!

[droid...@gmail.com]

> good, which I also share. However, point 2 above -- "Neither project can

> focus wholeheartedly on what is best for it" -- is the most important
> point. Having Thunderbird has an additional product and focus is *not*

> good overall if it causes all of our products -- Firefox, other
> web-driven products and Thunderbird -- to fall short of what we can

> accomplish.
>
> 5. Many inside of Mozilla, including an overwhelming majority of our
> leadership, feel the need to be laser-focused on activities like Firefox
> that can have an industry-wide impact. With all due respect to
> Thunderbird and the Thunderbird community, we have been clear for years
> that we do not view Thunderbird as having this sort of potential.
>
> 6. Given this, it's clear to me that sooner or later paying a tax to
> support Thunderbird will not make sense as a policy for Mozilla. I
> know many believe this time came a while back, and I've been slow to say
> this clearly. And of course, some feel that this time should never
> come. However, as I say, it's clear to me today that continuing to live
> with these competing demands given our focus on industry impact is
> increasingly unstable. We've seen this already, in an unstructured way,
> as various groups inside Mozilla stop supporting Thunderbird. The
> accelerating speed of Firefox and infrastructure changes -- which I
> welcome wholeheartedly -- will emphasize this.
>
> 7. Some Mozillians are eager to see Mozilla support community-managed
> projects within our main development efforts. I am also sympathetic to
> this view, with a key precondition. Community-managed projects that

> make the main effort less nimble and likely to succeed don't fit very

> well into this category for me. They can still be great open source
> projects -- this is a separate question from whether the fit in our main
> development systems. I feel so strongly about this because I am so
> concerned that "the Web" we love is at risk. If we want the traits of
> the Web to live and prosper in the world of mobile, social and data then
> we have to be laser-focused on this.
>
> 8. Therefore I believe Thunderbird should would thrive best by
> separating itself from reliance on Mozilla development systems and in
> some cases, Mozilla technology. The current setting isn't stable, and we
> should start actively looking into how we can transition in an orderly
> way to a future where Thunderbird and Firefox are un-coupled. I don't
> know what this will look like, or how it will work yet. I do know that
> it needs to happen, for both Firefox and Thunderbird's sake. This is a

> big job, and may require expertise that the Thunderbird team doesn't yet

This sounds nice, still have family members and grandparents using Thunderbird, glad its not dying off completely :)

[mozilla...@gmail.com]

On Tuesday, December 1, 2015 at 5:08:18 AM UTC+8, Mitchell Baker wrote:
> This is a long-ish message. It covers general topics about Thunderbird
> and the future

Hi Mitchell Baker and Mark Surman,

It has been a year since this post was posted.

Has Mozilla come to any decisions on the future of Thunderbird?

Thanks.

[Gervase Markham]

On 03/12/16 09:44, mozilla...@gmail.com wrote:
> Hi Mitchell Baker and Mark Surman,
>
> It has been a year since this post was posted.
>
> Has Mozilla come to any decisions on the future of Thunderbird?

Decisions about the future of Thunderbird are mostly being taken by the
Thunderbird Council. They have posted various updates on their thinking
to the tb-planning mailing list.

Gerv