Continued support for ESR

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Continued support for ESR

lsblakk
Hello,

When the ESR branch was initially created it was done so in a manner of intentional impermanence,  the thinking being that consumers of this channel would eventually establish a way to switch over onto our 6 week rapid release mainline builds.  With last week’s ESR31 we are pushing the limits of the original timeframe and it’s time to make a call on how to proceed with this population of users with an intent of creating permanence.  

In its present state, a strong community has built up around this channel and pacing of major version bumps.  The enterprise mailing list is active but not high-volume. There are two community contributors who took on the work of administrating the mailing list and they provide support as well on how to customize deployments.  Since this branch/channel was created with the intention of killing it off down the road, we do not do any external marketing of the ESR.  The user base can be generally distributed into three buckets: large organizations with over 100K instances, 2-10K organizations, and then ones under 1K. There are over 5500 members on the mailing list, and in order to get details about use a query was sent to the list in order to collect information on the value of continue providing this channel. About 80 responses were received in 2 weeks.

Given:

* we have a strong, self-supporting community
* building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks)
* Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/)
* there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions

The approach going forward is to:

* continue providing ESR builds as a permanent channel dedicated to the criteria we laid out in its creation
* plan a marketing push around the existence of ESR (update docs, revamp the org web page, promote the channel externally)
* commit to iterating on the processes built around of this channel and explore potential improvements to pacing, packaging, and other customizations
* make a project of getting FHR/Telemetry data from these deployments where permitted so that we have information on long-term usage that could be missing from mainline

For that last point, many of the respondents to the questions I raised on the list said they already could do, or would look into doing, Telemetry/FHR reports if they had more visibility into what the data collected was and also some expressed interest in having access to that collected data.  Data from long term support build users might unlock stability and security information that we do not currently discover in our rapid releases.

There is value to this channel both in loyalty of users, reaching people at work where they likely spend more of their online time, and maintaining a share of desktop browser usage.  Let’s take this already strong community, and look at how we can grow it for the benefit of the users and our products.

Cheers,
Lukas

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Kyle Huey-2
Can we at least adjust the ESR release length so that they fall on
even numbered Geckos?  Then they'll never end up on a version that is
not shared with a b2g branch.

- Kyle

On Thu, Jul 31, 2014 at 10:18 PM, Lukas Blakk <[hidden email]> wrote:

> Hello,
>
> When the ESR branch was initially created it was done so in a manner of intentional impermanence,  the thinking being that consumers of this channel would eventually establish a way to switch over onto our 6 week rapid release mainline builds.  With last week’s ESR31 we are pushing the limits of the original timeframe and it’s time to make a call on how to proceed with this population of users with an intent of creating permanence.
>
> In its present state, a strong community has built up around this channel and pacing of major version bumps.  The enterprise mailing list is active but not high-volume. There are two community contributors who took on the work of administrating the mailing list and they provide support as well on how to customize deployments.  Since this branch/channel was created with the intention of killing it off down the road, we do not do any external marketing of the ESR.  The user base can be generally distributed into three buckets: large organizations with over 100K instances, 2-10K organizations, and then ones under 1K. There are over 5500 members on the mailing list, and in order to get details about use a query was sent to the list in order to collect information on the value of continue providing this channel. About 80 responses were received in 2 weeks.
>
> Given:
>
> * we have a strong, self-supporting community
> * building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks)
> * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/)
> * there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions
>
> The approach going forward is to:
>
> * continue providing ESR builds as a permanent channel dedicated to the criteria we laid out in its creation
> * plan a marketing push around the existence of ESR (update docs, revamp the org web page, promote the channel externally)
> * commit to iterating on the processes built around of this channel and explore potential improvements to pacing, packaging, and other customizations
> * make a project of getting FHR/Telemetry data from these deployments where permitted so that we have information on long-term usage that could be missing from mainline
>
> For that last point, many of the respondents to the questions I raised on the list said they already could do, or would look into doing, Telemetry/FHR reports if they had more visibility into what the data collected was and also some expressed interest in having access to that collected data.  Data from long term support build users might unlock stability and security information that we do not currently discover in our rapid releases.
>
> There is value to this channel both in loyalty of users, reaching people at work where they likely spend more of their online time, and maintaining a share of desktop browser usage.  Let’s take this already strong community, and look at how we can grow it for the benefit of the users and our products.
>
> Cheers,
> Lukas
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Ben Hearsum-2
In reply to this post by lsblakk
What's the benefit of doing this? It won't reduce the number of backport
landings, because the repos will remain separate. I guess it might make
backporting the actual patches a bit less work?

On 14-08-01 04:14 AM, Kyle Huey wrote:

> Can we at least adjust the ESR release length so that they fall on
> even numbered Geckos?  Then they'll never end up on a version that is
> not shared with a b2g branch.
>
> - Kyle
>
> On Thu, Jul 31, 2014 at 10:18 PM, Lukas Blakk <[hidden email]> wrote:
>> Hello,
>>
>> When the ESR branch was initially created it was done so in a manner of intentional impermanence,  the thinking being that consumers of this channel would eventually establish a way to switch over onto our 6 week rapid release mainline builds.  With last week’s ESR31 we are pushing the limits of the original timeframe and it’s time to make a call on how to proceed with this population of users with an intent of creating permanence.
>>
>> In its present state, a strong community has built up around this channel and pacing of major version bumps.  The enterprise mailing list is active but not high-volume. There are two community contributors who took on the work of administrating the mailing list and they provide support as well on how to customize deployments.  Since this branch/channel was created with the intention of killing it off down the road, we do not do any external marketing of the ESR.  The user base can be generally distributed into three buckets: large organizations with over 100K instances, 2-10K organizations, and then ones under 1K. There are over 5500 members on the mailing list, and in order to get details about use a query was sent to the list in order to collect information on the value of continue providing this channel. About 80 responses were received in 2 weeks.
>>
>> Given:
>>
>> * we have a strong, self-supporting community
>> * building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks)
>> * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/)
>> * there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions
>>
>> The approach going forward is to:
>>
>> * continue providing ESR builds as a permanent channel dedicated to the criteria we laid out in its creation
>> * plan a marketing push around the existence of ESR (update docs, revamp the org web page, promote the channel externally)
>> * commit to iterating on the processes built around of this channel and explore potential improvements to pacing, packaging, and other customizations
>> * make a project of getting FHR/Telemetry data from these deployments where permitted so that we have information on long-term usage that could be missing from mainline
>>
>> For that last point, many of the respondents to the questions I raised on the list said they already could do, or would look into doing, Telemetry/FHR reports if they had more visibility into what the data collected was and also some expressed interest in having access to that collected data.  Data from long term support build users might unlock stability and security information that we do not currently discover in our rapid releases.
>>
>> There is value to this channel both in loyalty of users, reaching people at work where they likely spend more of their online time, and maintaining a share of desktop browser usage.  Let’s take this already strong community, and look at how we can grow it for the benefit of the users and our products.
>>
>> Cheers,
>> Lukas
>>
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Ludovic Hirlimann-2
In reply to this post by lsblakk
On 01/08/2014 07:18, Lukas Blakk wrote:

> Hello,
>
> When the ESR branch was initially created it was done so in a manner of intentional impermanence,  the thinking being that consumers of this channel would eventually establish a way to switch over onto our 6 week rapid release mainline builds.  With last week’s ESR31 we are pushing the limits of the original timeframe and it’s time to make a call on how to proceed with this population of users with an intent of creating permanence.  
>
> In its present state, a strong community has built up around this channel and pacing of major version bumps.  The enterprise mailing list is active but not high-volume. There are two community contributors who took on the work of administrating the mailing list and they provide support as well on how to customize deployments.  Since this branch/channel was created with the intention of killing it off down the road, we do not do any external marketing of the ESR.  The user base can be generally distributed into three buckets: large organizations with over 100K instances, 2-10K organizations, and then ones under 1K. There are over 5500 members on the mailing list, and in order to get details about use a query was sent to the list in order to collect information on the value of continue providing this channel. About 80 responses were received in 2 weeks.
>
> Given:
>
> * we have a strong, self-supporting community
> * building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks)
> * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/)
> * there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions
>

You also forgot to mention that Thunderbird releases were based on ESR
that's a bunch more users.


Ludo

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Ryan VanderMeulen
In reply to this post by Ben Hearsum-2
On 8/1/2014 7:35 AM, Ben Hearsum wrote:
> What's the benefit of doing this? It won't reduce the number of backport
> landings, because the repos will remain separate. I guess it might make
> backporting the actual patches a bit less work?

A common Gecko would probably make backports less work most of the time,
but it's not guaranteed given that any B2G release branch is going to
have a bunch of cherry-picked patches on top of it that the ESR branch
won't have.

-Ryan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

lsblakk
In reply to this post by Ben Hearsum-2
It's been suggested to push to 8 cycles and we'll look into the risks/rewards. The last 10 & 17 esrs had troubles with a couple of backports by 7 cycles but the last 24 esr has not had such issues so far.  According to many ESR users, 7 cycles is still too quick so I don't expect objections if we were to extend by one.

-Lukas

On Aug 1, 2014 4:40 AM, Ben Hearsum <[hidden email]> wrote:
>
> What's the benefit of doing this? It won't reduce the number of backport
> landings,What's the benefit of doing this? It won't reduce the number of backport
landings, because the repos will remain separate. I guess it might make
backporting the actual patches a bit less work?

On 14-08-01 04:14 AM, Kyle Huey wrote:

> Can we at least adjust the ESR release length so that they fall on
> even numbered Geckos?  Then they'll never end up on a version that is
> not shared with a b2g branch.
>
> - Kyle
>
> On Thu, Jul 31, 2014 at 10:18 PM, Lukas Blakk <[hidden email]> wrote:
>> Hello,
>>
>> When the ESR branch was initially created it was done so in a manner of intentional impermanence,  the thinking being that consumers of this channel would eventually establish a way to switch over onto our 6 week rapid release mainline builds.  With last week’s ESR31 we are pushing the limits of the original timeframe and it’s time to make a call on how to proceed with this population of users with an intent of creating permanence.
>>
>> In its present state, a strong community has built up around this channel and pacing of major version bumps.  The enterprise mailing list is active but not high-volume. There are two community contributors who took on the work of administrating the mailing list and they provide support as well on how to customize deployments.  Since this branch/channel was created with the intention of killing it off down the road, we do not do any external marketing of the ESR.  The user base can be generally distributed into three buckets: large organizations with over 100K instances, 2-10K organizations, and then ones under 1K. There are over 5500 members on the mailing list, and in order to get details about use a query was sent to the list in order to collect information on the value of continue providing this channel. About 80 responses were received in 2 weeks.
>>
>> Given:
>>
>> * we have a strong, self-supporting community
>> * building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks)
>> * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/)
>> * there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions
>>
>> The approach going forward is to:
>>
>> * continue providing ESR builds as a permanent channel dedicated to the criteria we laid out in its creation
>> * plan a marketing push around the existence of ESR (update docs, revamp the org web page, promote the channel externally)
>> * commit to iterating on the processes built around of this channel and explore potential improvements to pacing, packaging, and other customizations
>> * make a project of getting FHR/Telemetry data from these deployments where permitted so that we have information on long-term usage that could be missing from mainline
>>
>> For that last point, many of the respondents to the questions I raised on the list said they already could do, or would look into doing, Telemetry/FHR reports if they had more visibility into what the data collected was and also some expressed interest in having access to that collected data.  Data from long term support build users might unlock stability and security information that we do not currently discover in our rapid releases.
>>
>> There is value to this channel both in loyalty of users, reaching people at work where they likely spend more of their online time, and maintaining a share of desktop browser usage.  Let’s take this already strong community, and look at how we can grow it for the benefit of the users and our products.
>>
>> Cheers,
>> Lukas
>>
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Kyle Huey-2
On Fri, Aug 1, 2014 at 8:06 AM, Lukas Blakk <[hidden email]> wrote:
> It's been suggested to push to 8 cycles and we'll look into the risks/rewards. The last 10 & 17 esrs had troubles with a couple of backports by 7 cycles but the last 24 esr has not had such issues so far.  According to many ESR users, 7 cycles is still too quick so I don't expect objections if we were to extend by one.

I would really like to push it to 6.  I think I would rather stay at 7
and be out of sync with b2g releases than move to 8 and be in sync.

- Kyle
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Jonathan Kew
On 1/8/14 18:35, Kyle Huey wrote:
> On Fri, Aug 1, 2014 at 8:06 AM, Lukas Blakk <[hidden email]> wrote:
>> It's been suggested to push to 8 cycles and we'll look into the risks/rewards. The last 10 & 17 esrs had troubles with a couple of backports by 7 cycles but the last 24 esr has not had such issues so far.  According to many ESR users, 7 cycles is still too quick so I don't expect objections if we were to extend by one.
>
> I would really like to push it to 6.  I think I would rather stay at 7
> and be out of sync with b2g releases than move to 8 and be in sync.

Why choose shorter rather than longer? If we're going to do an ESR at
all (which I do think is a good thing, btw), surely we should listen to
what the target community wants, which seems to be a slower cycle rather
than a faster one.

There'll presumably be a little more backporting to do if the sync-up
with mozilla-central is less frequent, but I doubt the difference
between 6 and 8 cycles would make much difference to the overall burden
of supporting ESR. The difference between a 36-week and 48-week cadence
for customers seems more significant, and IMO argues for the 8-cycle option.

JK


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Justin Dolske-2
In reply to this post by Kyle Huey-2
On 8/1/14 10:58 AM, Jonathan Kew wrote:

>> I would really like to push it to 6.  I think I would rather stay at 7
>> and be out of sync with b2g releases than move to 8 and be in sync.
>
> Why choose shorter rather than longer? If we're going to do an ESR at
> all (which I do think is a good thing, btw), surely we should listen to
> what the target community wants, which seems to be a slower cycle rather
> than a faster one.

I would ask if there are specific schedule needs, and how sizable a
portion of the community that represents (e.g., requirements driven by
financial or academic quarters accounting for X end-users).

If some are grumbling for a return to the multi-year stability of IE6, a
+1 cycle isn't going to help, nor can I imagine us ever meeting that
kind of schedule. Similarly, if the requests are just vague "slower
please", it's unclear how much longer we would have to make ESR cycles
to have an impact on that concern.

I'd also note that ESR was created to fill an imminent need -- people
discovering Mozilla was about to desupport Firefox 4 faster than their
processes could adapt. At this point, people have adapted to the ESR
schedule or have switched browsers. So I would expect ESR schedule
tweaks to have a rationale for either (A) improving specific pain points
for entities currently using ESR per the above or (B) estimates on how
many new ESR users we gain from places who do not currently use ESR but
would switch back.

There's nothing magically perfect about 6 weeks, but extending it
definitely has costs, and so we should understand the benefit and
tradeoffs from doing so.

Justin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Justin Dolske-2
In reply to this post by lsblakk
On 7/31/14 10:18 PM, Lukas Blakk wrote:

> * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/)

Does Chrome actually provide extended support for older Chrome releases?
It's not really clear from a quick skim of the page, and my
understanding was that it's just the usual Chrome schedule (i.e., not
like our ESR at all).

I note this because "enterprise support" and "extended support" are
different things (albeit with some overlap). [Which is probably obvious
to people on this thread, but may not be to someone newly seeing it.]

Justin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Chris Peterson-12
In reply to this post by lsblakk
On 7/31/14 10:18 PM, Lukas Blakk wrote:
> Given:
>
> * we have a strong, self-supporting community
> * building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks)
> * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/)

Would Mozilla also provide (or subcontract) enterprise support for ESR?
Companies might be more likely adopt to ESR if they knew Mozilla (or a
group endorsed by Mozilla) was available for enterprise support. It
could also be an opportunity to generate non-search revenue. :)


> * there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions
>
> The approach going forward is to:
>
> * continue providing ESR builds as a permanent channel dedicated to the criteria we laid out in its creation
> * plan a marketing push around the existence of ESR (update docs, revamp the org web page, promote the channel externally)

Who is the target audience for this external promotion? Do there exist
large enterprises that would actually switch their existing desktop
environment (presumably IE or Chrome) to ESR? Or would we target small
to medium enterprises that are standardizing their desktop environments
for the first time?


cp

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Benjamin Kerensa
>> * we have a strong, self-supporting community
>> * building and maintaining ESR has become a smooth process which uses very
>> few resources (one channel, minimal builds on checkins, single QA sign off
>> every 6 weeks)
>> * Chrome is now providing enterprise support
>> (http://www.google.com/intl/en/chrome/business/browser/)
>
>
> Would Mozilla also provide (or subcontract) enterprise support for ESR?
> Companies might be more likely adopt to ESR if they knew Mozilla (or a group
> endorsed by Mozilla) was available for enterprise support. It could also be
> an opportunity to generate non-search revenue. :)

Sounds like a real opportunity

>
>
>
>> * there are at least 2M users on this channel and we estimate there to be
>> more if we factor in Linux distributions
>>
>> The approach going forward is to:
>>
>> * continue providing ESR builds as a permanent channel dedicated to the
>> criteria we laid out in its creation
>> * plan a marketing push around the existence of ESR (update docs, revamp
>> the org web page, promote the channel externally)
>
>
> Who is the target audience for this external promotion? Do there exist large
> enterprises that would actually switch their existing desktop environment
> (presumably IE or Chrome) to ESR? Or would we target small to medium
> enterprises that are standardizing their desktop environments for the first
> time?

So we just had a big Dev Rel presence at OSCON and quite a handful of
decision makers at major companies said they were using Chrome for
Business. They said small upcoming changes would help them make the
case for switching. One manager outright said he was planning on
making the switch when WebIDE makes it down the train and that he
would be looking towards deploying ESR.

And yeah I think the target audiences would be Corporations,
Libraries, Non-Profit's and Schools. I think if we polished our
message and did some promotion even small dollar that we could attract
more desktop user share by arguing the values of using Firefox over
other browsers.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Javaun Moradi
Excellent points. The strategy group also has data that suggests (as you'd expect) that what you use at work influences what you choose to use at home. I worked for a few big enterprises where Firefox was such a bright spot. Having a terrific browser alternative was like the IT folks giving us all a big hug. We talk a lot about giving users choice and that extends to the work place.

Vive la ESR

On Aug 1, 2014 7:16 PM, Benjamin Kerensa <[hidden email]> wrote:

>
> >> * we have a strong, self-supporting community
> >> * building and mainta>> * we have a strong, self-supporting community
>> * building and maintaining ESR has become a smooth process which uses very
>> few resources (one channel, minimal builds on checkins, single QA sign off
>> every 6 weeks)
>> * Chrome is now providing enterprise support
>> (http://www.google.com/intl/en/chrome/business/browser/)
>
>
> Would Mozilla also provide (or subcontract) enterprise support for ESR?
> Companies might be more likely adopt to ESR if they knew Mozilla (or a group
> endorsed by Mozilla) was available for enterprise support. It could also be
> an opportunity to generate non-search revenue. :)

Sounds like a real opportunity

>
>
>
>> * there are at least 2M users on this channel and we estimate there to be
>> more if we factor in Linux distributions
>>
>> The approach going forward is to:
>>
>> * continue providing ESR builds as a permanent channel dedicated to the
>> criteria we laid out in its creation
>> * plan a marketing push around the existence of ESR (update docs, revamp
>> the org web page, promote the channel externally)
>
>
> Who is the target audience for this external promotion? Do there exist large
> enterprises that would actually switch their existing desktop environment
> (presumably IE or Chrome) to ESR? Or would we target small to medium
> enterprises that are standardizing their desktop environments for the first
> time?

So we just had a big Dev Rel presence at OSCON and quite a handful of
decision makers at major companies said they were using Chrome for
Business. They said small upcoming changes would help them make the
case for switching. One manager outright said he was planning on
making the switch when WebIDE makes it down the train and that he
would be looking towards deploying ESR.

And yeah I think the target audiences would be Corporations,
Libraries, Non-Profit's and Schools. I think if we polished our
message and did some promotion even small dollar that we could attract
more desktop user share by arguing the values of using Firefox over
other browsers.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Gervase Markham
In reply to this post by lsblakk
On 01/08/14 06:18, Lukas Blakk wrote:
> * plan a marketing push
> around the existence of ESR (update docs, revamp the org web page,
> promote the channel externally)

All the rest of the plan sounds awesome, but this is a little worrying -
perhaps only through lack of detail.

Our non-ESR release is not a preview; we moved to rapid releases to push
the web forward at a faster pace. The more people use ESR, the harder
that is. Now, there are people who would either use ESR or another
browser, and so we do have and need ESR. But if we start promoting it
more actively, is there a risk that people who would and could otherwise
use our standard release start using ESR, and that starts to restrict
our ability to drive change?

Gerv


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Benjamin Kerensa
> Our non-ESR release is not a preview; we moved to rapid releases to push
> the web forward at a faster pace. The more people use ESR, the harder
> that is. Now, there are people who would either use ESR or another
> browser, and so we do have and need ESR. But if we start promoting it
> more actively, is there a risk that people who would and could otherwise
> use our standard release start using ESR, and that starts to restrict
> our ability to drive change?

I think those organizations that use our ESR release do so for the
slower release cycle when talking enterprise a rapid release is not
generally easy to sell. I do not think promoting ESR we would be in a
situation where we would attract users who would otherwise choose our
rapid release.

In fact I think by promoting ESR we might get more desktop users in
the normal channel as we expose more users in orgs to Firefox who may
not have been previously exposed and decide to download and install at
home.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Leman Bennett (Omega X)
In reply to this post by Chris Peterson-12
On 8/1/2014 6:15 PM, Benjamin Kerensa wrote:

>>> * we have a strong, self-supporting community
>>> * building and maintaining ESR has become a smooth process which uses very
>>> few resources (one channel, minimal builds on checkins, single QA sign off
>>> every 6 weeks)
>>> * Chrome is now providing enterprise support
>>> (http://www.google.com/intl/en/chrome/business/browser/)
>>
>>
>> Would Mozilla also provide (or subcontract) enterprise support for ESR?
>> Companies might be more likely adopt to ESR if they knew Mozilla (or a group
>> endorsed by Mozilla) was available for enterprise support. It could also be
>> an opportunity to generate non-search revenue. :)
>
> Sounds like a real opportunity
>
>>
>>
>>
>>> * there are at least 2M users on this channel and we estimate there to be
>>> more if we factor in Linux distributions
>>>
>>> The approach going forward is to:
>>>
>>> * continue providing ESR builds as a permanent channel dedicated to the
>>> criteria we laid out in its creation
>>> * plan a marketing push around the existence of ESR (update docs, revamp
>>> the org web page, promote the channel externally)
>>
>>
>> Who is the target audience for this external promotion? Do there exist large
>> enterprises that would actually switch their existing desktop environment
>> (presumably IE or Chrome) to ESR? Or would we target small to medium
>> enterprises that are standardizing their desktop environments for the first
>> time?
>
> So we just had a big Dev Rel presence at OSCON and quite a handful of
> decision makers at major companies said they were using Chrome for
> Business. They said small upcoming changes would help them make the
> case for switching. One manager outright said he was planning on
> making the switch when WebIDE makes it down the train and that he
> would be looking towards deploying ESR.
>
> And yeah I think the target audiences would be Corporations,
> Libraries, Non-Profit's and Schools. I think if we polished our
> message and did some promotion even small dollar that we could attract
> more desktop user share by arguing the values of using Firefox over
> other browsers.
>

There are very many waiting for MSI and GPO support in the shadows.
Google Chrome at the very least has a MSI wrapper.


--
==================================
~Omega X
MozillaZine Nightly Tester
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

mhoye

On 2014-08-04 1:25 PM, Leman Bennett (Omega X) wrote:
>
> There are very many waiting for MSI and GPO support in the shadows.
> Google Chrome at the very least has a MSI wrapper.
>
"Waiting in the shadows for something they can take for free" may be a
less flattering image than you intended, but it's probably more accurate
than you realize.

For what it's worth, I've tried to build a modest business out of a
highly functional Firefox .MSI creation and customization service for
enterprise environments, and was unable to find a single company willing
to pay for that service. If any of these presumed-to-exist organizations
"waiting in the shadows" had so much as offered to throw a few dollars
at me, they'd have had what they wanted three years ago. They did not,
and here we are.

I'm sure a lot of people would find .MSI deployment and GPO support
quite convenient if it were offered at no cost to them, but the idea
that this will become a revenue driver is, I think, fanciful.

- mhoye
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

R Kent James
In reply to this post by Gervase Markham
On 8/4/2014 2:35 AM, Gervase Markham wrote:
> we moved to rapid releases to push
> the web forward at a faster pace

That is Mozilla's agenda, but is not the primary agenda of many Firefox
users. They just want something that is not constantly breaking or
changing on them that they have to adapt to.

"Give the users what they want, and not what we wish they would want"
whenever possible. It is way too easy for disruptive changes to be
pushed too rapidly on unwilling users with the rapid release cycle, at
least for mission-critical company uses.

:rkent
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Leman Bennett (Omega X)
In reply to this post by Leman Bennett (Omega X)
On 8/4/2014 1:58 PM, mhoye wrote:
>
> On 2014-08-04 1:25 PM, Leman Bennett (Omega X) wrote:
>>
>> There are very many waiting for MSI and GPO support in the shadows.
>> Google Chrome at the very least has a MSI wrapper.
>>
> "Waiting in the shadows for something they can take for free" may be a
> less flattering image than you intended, but it's probably more accurate
> than you realize.

Looks like a misquote.

>
> For what it's worth, I've tried to build a modest business out of a
> highly functional Firefox .MSI creation and customization service for
> enterprise environments, and was unable to find a single company willing
> to pay for that service. If any of these presumed-to-exist organizations
> "waiting in the shadows" had so much as offered to throw a few dollars
> at me, they'd have had what they wanted three years ago. They did not,
> and here we are.
>
> I'm sure a lot of people would find .MSI deployment and GPO support
> quite convenient if it were offered at no cost to them, but the idea
> that this will become a revenue driver is, I think, fanciful.
>
> - mhoye

Maybe because they get it from Microsoft and Google for free and don't
see the incentive for buying it from a 3rd party they don't know and
don't trust.

The same can easily be said by mobile app stores and the majority of
people that only gravitate toward free apps and games. Why buy something
when its free elsewhere.

Mind you, this is Mozilla(Firefox) aiming to convince others that its
the better solution over the included "Free" solution and other 3rd
Parties who compete in the same space. According to a recent measurement
of marketshare, Mozilla is losing that fight.
http://www.computerworld.com/s/article/9250123/Chrome_passes_20_share_milestone_locks_up_2nd_place

This is about Mozilla looking for more Enterprise interest in ESR.
Enterprise related features is a good way to get a second look.




--
==================================
~Omega X
MozillaZine Nightly Tester
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Continued support for ESR

Ehsan Akhgari
In reply to this post by Gervase Markham
On Mon, Aug 4, 2014 at 5:35 AM, Gervase Markham <[hidden email]> wrote:

> On 01/08/14 06:18, Lukas Blakk wrote:
> > * plan a marketing push
> > around the existence of ESR (update docs, revamp the org web page,
> > promote the channel externally)
>
> All the rest of the plan sounds awesome, but this is a little worrying -
> perhaps only through lack of detail.
>
> Our non-ESR release is not a preview; we moved to rapid releases to push
> the web forward at a faster pace. The more people use ESR, the harder
> that is. Now, there are people who would either use ESR or another
> browser, and so we do have and need ESR. But if we start promoting it
> more actively, is there a risk that people who would and could otherwise
> use our standard release start using ESR, and that starts to restrict
> our ability to drive change?


Do we have evidence to suggest that the ESR user base has been continually
growing though since the short little while after ESR first came out?  My
understanding is that the number of ESR users is not growing very fast, so
I find the argument about ESR preventing us from pushing the web forward
faster particularly convincing any more...

With my developer hat on, I *hate* having to maintain old branches, and
believe that it will always have a non-0 cost for us.  But all things
considered, I think we should continue to do ESR releases for now.  They
serve an important and sizable group of our users, and ultimately I think
it's more important to do what's good for our users.

Cheers,
Ehsan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12