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-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
