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