> I'll be compiling, responding to, and evaluating the feedback received
> on the ESR proposal, and will provide updates here on the go-forward plan,
> including suggested changes. I hope to be able to provide the project with
> the information it needs to take a decision on the ESR within the next few
> weeks, and would ask for your feedback as soon as possible. If you're not
> comfortable posting to the dev.planning
> group, please also feel free to contact me directly.
Thanks for posting this Kev, I know a ton of work went into this proposal.
I raised this issue last week, but I think it's worthy of broader
My main concern with this is splitting our user base between the two
releases (other than this, I actually think it's a great proposal, but I'm
not sure how to get past this problem). Just as David Ross points out,
there are any number of reasons for individuals to be interested in the LTS
releases (addons that aren't compatible, locales that have dropped off the
train, websites that break when we finally hit Gecko 10 and their crappy UA
sniffing thinks they're talking to a browser from 2004 ...). People who
install Firefox on computers for their friends/families would be more likely
to install the LTS releases so that they don't have to deal with upgrade
issues every 6 weeks. If there is a way for people to slow down, some of
Given a choice between:
1) Old style: Major feature releases every 18 (or so) months, most users are
on the latest version or one version back
2) New style: Smaller releases every 6 weeks, with most users on the latest
version but some relatively small amount spread across the last N versions
(for some N > 1).
3) This proposal, with most of our users on the latest version, some small
amount spread across the last N versions, and a good chunk on the divergent
LTS release that is roughly 6 months old.
I'll let others debate #1 vs #2, but I think #3 is the definitely worst
situation for the Mozilla community. It causes the maximum fragmentation
across versions, slows down the pace at which we can move the web forward
(from delivering new stuff every 6 weeks (at least in theory, there's some
more time here for uptake/etc) to delivering stuff every 6 months),
complicates the testing matrix both for us and for third parties (web devs,
addon authors, etc), makes some trains more equal than others (potentially
leading to pressure to "get stuff in" for a given release since that will
become the LTS release), and doesn't fix any of the pain points of the rapid
In short, I think there's an inverse relationship between how well the LTS
branch aligns with our goals and how many people use it, and that's a really
perverse incentive to have.
In my ideal world, we'd wait on implementing an LTS branch until we've had a
chance to shake out the remaining pain points in the rapid release process,
but I expect the length of time necessary to do that, the need to EOL 3.6,
etc will force our hand before that can happen.
I'm not saying that users will find it if we hide it, more that users will WANT it. Sure, we can make this difficult for them, but is that really what we want?
I think the comparison you want is actually how many people are sticking with Firefox 3.6,4, 5? People who download most of these versions from FTP aren't even tracked in our download numbers but there are obviously people who are fighting our updates.
> 2. The UI and interaction changes should trickle out rather than be
> super in your face like 3.6 -> 4 was. This concern is only mildly
> related to the proposal here and even then only if #1 is unsuccessful
No, it's 100% this proposal. We're offering a way for people to avoid UI/UX/behavior churn; I'd be surprised if they didn't take it if given the choice. If we hide that choice, that's a different story -- but we should recognize that we're deliberately hiding that choice because we think users will want to switch to it and we don't want them to, not that somehow they're preferring the rapid release version because it's a better product.
> 3. Users get angry about updates. Period. We saw complaints about
> 6.0.1, which introduced no changes except a security fix. We saw
> complaints for 3.6 point releases. People complain about Mac and
> Windows updates. We're working on making it less painful, but I doubt
> it will drive people to an ESR, especially if we are successful with
Indeed. People hate updates and now they can avoid some of it. If we make that transition hard/painful, people won't go there but my only point is that if we give them the choice, people are going to take lack of updates over fancy new things (which is what Jonas was arguing).
> 4. Car analogies...yikes ;-)
Sorry. I don't even have a car, but I wanted something that people regard as essential. You're more likely to be upset if something you rely on breaks than something you don't.
Thanks for the work on this - it's a great proposal.
I have two concerns:-
1) Can you clarify what "Public (re)distribution of Mozilla-branded
versions of the ESR will not be permitted." - I assume this means I
can host it on a private FTP Server and install it on Friends & Family
machines from there but can't make it generally available.
2) I'm disappointed the commitment is only for a minimum of 2 ESR
releases, that's not a lot of time in the Corporate world.
Thanks again for bringing some sanity to this mess.
I guess I can WONTFIX or INVALID bug 555935, then.
> On 11-09-22 3:53 AM, Mike Hommey wrote:
> >Corollary question: are they expected to only ship the latest Firefox
> >version to get the trademark license for "Firefox"?
1) Won't this proposal fragment our user base?
Compared to a world where there is nothing but our mainline releases: yes, trivially. But much less so than we have historically when we supported multiple past releases, often for a year or more. This proposal makes clear the maximum extent of the lag (42 weeks ~ 9 months), and the maximum amount of concurrent maintenance (3 branches, for 12 weeks of overlap, about a quarter of the time).
2) Why these times (30 weeks, 12 weeks, &c)? Will they be enough?
Kev's been working with all of us here, as well as EWG members, to find a good balance. 30 and 12 are multiples of 6 weeks, for perhaps obvious reasons. Some ESR consumers will want much more. As an engineering manager looking at the cost of backports, I would like as little code divergence as possible. These timelines feel like a good middle ground to me, though I think Kev is quite open to discussion of the particulars.
3) Won't our users flock to ESR?
Some might. We won't market it, and our experience with old versions (like 3.6 today) shows that the vast majority of people won't, but some might. This largely goes back to question 1.
4) Won't add-on authors choose to focus only on ESR?
I'm not the add-on expert, but as an add-on author on this thread, I know I like having users, and most of the users, by a significant margin, will be on mainline releases. As in all things, I'm sure there will be some grey area, but our add-on compatibility story (through a great deal of hard work from the add-ons team and add-on authors) is getting better, so I don't foresee a tidal wave.
5) I hate updates.
Duly noted, but not really on-topic (except as it pertains to question 1 above, I guess).
On 2011-09-21, at 5:13 PM, Kev Needham wrote:
> Since moving to a faster release process, Mozilla understands that some
> organizations are facing challenges in deploying Mozilla products in a
> managed environment. The faster release cadence makes gives organizations a shorter period of time to certify and use new releases,
> and the lack of maintenance on older releases can expose organizations
> using them to security risks. Through the Enterprise Working Group (EWG)
> we're working with those organizations through to determine the best way
> Mozilla can help.
> To that end, representatives from the Product, Engagement, Engineering,
> and Release Engineering teams have taken the feedback received to date
> from the EWG and other sources to create an initial proposal for an Extended Support Release (ESR) of Mozilla Firefox and Thunderbird. These proposed releases would provide organizations with additional time to certify and deploy new versions of Firefox while mitigating some of the security risks of staying on an older release. They would be targeted specifically at those organizations that want to deploy Firefox and Thunderbird in a managed environment, and would not be recommended for individuals outside those organizations.
> The proposal can be viewed on the Mozilla Wiki at
> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. I
> think it balances the needs of organization(s) that want to continue to
> deploy Firefox, while allowing Mozilla to maintain a faster release
> process to better deliver new features, performance enhancements and
> security fixes to individual users.
> The proposed ESR will require effort to maintain, and we want to gather
> feedback in dev.planning from the broader Mozilla project on the
> proposal and its impacts. When submitting your feedback, please consider how it balances our need to give individuals the best experience possible through our regular release process while still meeting the needs of organizations that deploy Mozilla software; how it affects you and the people you work with; and what additional clarity we can provide on the ideas behind the proposal.
> We realize that Thunderbird in particular is a significant downstream consumer of the Gecko platform, which is itself influenced by Firefox's plans with respect to security & maintenance policies in particular. While sharing technology, Thunderbird is a distinct product which is exposed to different distinct security and market environments, and we don't want to assume that the discussions which have focused on Firefox necessarily apply as-is to Thunderbird. We will be starting a Thunderbird-specific discussion informed by the Firefox processes, please join that discussion on the tb-enterprise mailing list (https://wiki.mozilla.org/Thunderbird/tb-enterprise).
> I'll be compiling, responding to, and evaluating the feedback received
> on the ESR proposal, and will provide updates here on the go-forward plan, including suggested changes. I hope to be able to provide the project with the information it needs to take a decision on the ESR within the next few weeks, and would ask for your feedback as soon as possible. If you're not comfortable posting to the dev.planning
> group, please also feel free to contact me directly.
> I thank you in advance for your thoughts and feedback, and look forward
> to a constructive discussion.
> Kev Needham (also representing Stormy Peters and JP Rosevear)
Director of Firefox Engineering
What I don't understand is why ESR cannot be the ONLY timeline for
releases. It would be more frequent than what was happening before the
current rapid, frequent releases. At the same time, it would give more
time to unpaid volunteers to complete component developments, update
add-ons, and provide localizations. It would also give more time for
testing. From the standpoint of user satisfaction, it would end the
complaints about too frequent updates.
Building a solid user base should not require lemming-like following the
example of Chrome. Remember, individual users at home might also be
enterprise users at work. Individual users and enterprises should be
I agree, we would be accused of being closed and controlling if we
release an ESR version but don't make it easy for non-enterprise users
to get it, given the fact that there is definite user interest.
But taking this even further, wouldn't we potentially *want* to offer
it to normal users? If we do go to all the effort to make an ESR
version - and it is is a lot of effort - and we later do some user
surveys and see that users on the ESR version are happier (due to
fewer updates and so forth), would we have a legitimate reason for
*not* offering the ESR version to normal users? This is an honest
question: No matter how much we believe in the rapid release process,
if we have two products - ESR and rapid release - and we see that one
makes users happier, how can we not promote that one more?
There are some potential reasons, like that the rapid release versions
would be more secure (something users don't notice directly, so there
isn't an immediate impact on user happiness). But we would need to
balance that against user happiness, and I don't think we can know in
advance which considerations will end up winning.
Let Firefox be Firefox. Splitting the brand won't be noticed or understood
by the end user, nor protect the brand reputation. Perhaps add a LTE or
whatever so those looking to do support can differentiate.
> On Sep 21, 8:58 pm, Justin Lebar <justin.le...@gmail.com> wrote:
>>> 1. The proposal specifically says we will put barriers in place to make this
>>> not happen. You may think those wont be effective but how many people are
>>> downloading 3.6? Virtually none, as they can't find it...and we didn't even try
>>> to hide it.
>> Could you elaborate on these barriers?
>> Given that there have been approximately UINT32_MAX stories on Slashdot about how awful our rapid-release process is, I'm concerned that we may be underestimating how hard our community might look for these builds and how loudly they might cry if they can't get them.
Not responding directly to you azakai, but I can't resist: "No wireless. Less space than a nomad. Lame."
>> Suppose we had perfect barriers. Can you imagine the news stories? "Mozilla develops the Firefox LTS you've been asking for, but puts it behind a wall! Are they more closed than Android?"
>> If we have crummy barriers, then we fragment the user base. If we have good barriers, then people (perhaps rightly) accuse us of being closed. It's hard for me to see how we win here.
> I agree, we would be accused of being closed and controlling if we
> release an ESR version but don't make it easy for non-enterprise users
> to get it, given the fact that there is definite user interest.
Firefox 3.6 is out there, supported, on mozilla.org, and doesn't have the update rage or add-on pain. We don't see people opting into it. This is a non-issue if we get out in front of it, and likely a non-issue in general.
> But taking this even further, wouldn't we potentially *want* to offer
> it to normal users?
The proposal is explicitly saying no.
> If we do go to all the effort to make an ESR
> version - and it is is a lot of effort - and we later do some user
> surveys and see that users on the ESR version are happier (due to
> fewer updates and so forth), would we have a legitimate reason for
> *not* offering the ESR version to normal users? This is an honest
> question: No matter how much we believe in the rapid release process,
> if we have two products - ESR and rapid release - and we see that one
> makes users happier, how can we not promote that one more?
No. Again, users hate updates and change. If it was up to users they would have rejected Firefox 6.0.1 even though it kept them safe and secure and didn't change *anything* user-visible. Let users speak for themselves by moving to a different browser, complaining on Twitter, or filing bugs rather than offering them something that's "ok". We don't want the ESR to become IE6, dragging the web down due to tons of users and slow(er) progress.
> There are some potential reasons, like that the rapid release versions
> would be more secure (something users don't notice directly, so there
> isn't an immediate impact on user happiness). But we would need to
> balance that against user happiness, and I don't think we can know in
> advance which considerations will end up winning.
We think users will be happier in the new release process. When their HTML5 pandora works, when their browser suddenly starts using less memory, when they are protected from a new security threat due to hardening, when the fonts on their favorite webpage start displaying correctly, when their favorite site uses new HTML tech to make their experience better, when they can suddenly push their open tab to a mobile device, when some cool new demo works even though the developer says it "only works in webkit", etc. Yes, there is pain in the short term. We turned on a dime and some things need to catch up. This proposal is recognizing that enterprises likely *can't* catch up due to their unique needs and requirements.
I definitely appreciate your thoughtful emails so far, but I really want to be clear on this point to everyone in the thread:
This proposal is not a proxy for moving away from the new release process. Please, please stop treating it as such.
Oh, we do. Not in masses, but still I continue to read new messages
again and again from people who want to get back to 3.x or want to stay
there because they dislike the UI of 4 onwards or have problems with
add-ons being incompatible or some other aspects of some more recent
That still doesn't make me a friend of the ESR proposal, but tells me
there is a need for us to care about those people and find a way to
bring them along to newer trains.
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)