When Mozilla adopted its six-week rapid development cycle in early 2011, backlash came from a number of angles — but the heaviest was from enterprise IT departments. In October, the browser maker formed a working group in order to sit down with corporate users and hash out a suitable support plan. The result is the Mozilla Extended Support Release (ESR) program, which is now up and running for Firefox, and is due to debut shortly for Thunderbird a well.
Rapid is Bad?
If the backlash comes as a surprises to you, you may simply work in a computing environment that does fall into the problematic territory that Mozilla ESR is intended to serve. One of the most important ways that enterprises manage the task of supporting hundreds or thousands of users is by locking down updates, and putting all new releases through a rigorous security and compatibility testing process before deploying them across the company — which ensures both stability and uniformity. Being asked to push out eight Firefox updates a year is bad enough, but along with the new release schedule Mozilla announced it was also discontinuing security updates for “older” releases.
To many in the industry, that pace made it virtually impossible for corporate IT departments to keep up with Firefox — a situation exacerbated when Mozilla’s Aza Dotzler publicly opined that the enterprise “has never been (and I’ll argue, shouldn’t be)” Mozilla’s focus. The Mozilla Enterprise User Working Group was formed a month later to help Mozilla and enterprise customers and come up with a solution together.
The working group holds monthly phone meetings — the minutes of which are publicly available on the Mozilla wiki — and has a Bugzilla category for issue tracking and a moderated mailing list to which interested parties must send a request in order to join. The meetings were evidently fruitful, resulting in a number of bugs and blueprints for Firefox deployment tools (including the Windows MSI installer used by most IT departments and the group policy objects (GPOs) used to manage security) and in proposals for creating a manageable security fix “support tail.”
Eventually the group wrote a comprehensive extended-support proposal for Firefox, which was published on the wiki in early December. On January 10, 2012, Mozilla announced that the proposal had been officially approved as an action plan.
Firefox ESR
The plan establishes Firefox ESR as a separate product tailored for use by enterprises, universities, public institutions, and other large-scale deployments that rely on centrally-managed IT.
ESR releases will be supported for 54 weeks (or nine releases of Firefox’s rapid-development cycle), a schedule that provides a balanced lifespan between the new rapid-release schedule of Firefox and the long-term support expectations of enterprise users. During the 54-week time-frame, high-impact security fixes will be provided, but updates that alter browser functionality or change add-on compatibility will not be pushed out.
ESR releases will be scheduled so that the new release is delivered 12 weeks before the end-of-lifetime date of its predecessor, to allow for enterprise testing and qualification. Mozilla will also continue to support all platforms and locales included in the ESR release for the ESR’s lifetime, even if platform or locale support is dropped from rapid-release Firefox in the interim. That means that even if Firefox deprecates an older platform (say, Mac OS X 10.4) halfway through the 54-week lifespan of the ESR, Mozilla will continue to provide security fixes for 10.4 up until the end of the 54th week.
The first ESR release will be Firefox 10, scheduled for January 31. Subsequent releases over the 54-week lifetime will be numbered as Firefox ESR 10.0.1, 10.0.2, and so forth. In order to avert any potential end-user confusion, however, the ESR releases will only be announced and marketed through the Enterprise wiki page, although the packages themselves will be delivered through the usual Mozilla staging servers. When Firefox ESR 10 reaches end-of-life, it will be replaced by the then-current build of upstream Firefox, Firefox 17.
Finally, it is important to note that the ESR plan does not cover Firefox Mobile, and that organizations that choose to deploy Firefox ESR are warned that they may experience compatibility problems as the releases age, and that only urgent security fixes are guaranteed. The risk profile of ESR compared to normal rapid-release Firefox must be determined by the organization.
Thunderbird ESR
The original Firefox ESR plan made a point of noting that Thunderbird was not covered by the proposal. Shortly after the Firefox plan was publicized, however, the project began drafting a Thunderbird ESR plan to accompany it. On January 12, the official Thunderbird blog carried the announcement that Thunderbird would be adopting the same schedule.
Because Thunderbird’s plan is to keep in step with Firefox ESR, is does not yet have a separate incarnation of the plan on the wiki. However, as the announcement and mailing list thread make clear, the details are the same: Thunderbird ESR releases will be made once every 54 weeks, and will receive critical security updates, but no changes that alter the functionality of the application or affect the compatibility of add-ons.
When Mozilla adopted the rapid-development cycle, it intentionally synchronized the version numbers used by Firefox, Thunderbird, and the Gecko layout engine common to both applications — thus keeping all three on the same footing, making updates easier to manage. As a result, Thunderbird 10 will also be the first Thunderbird ESR release, and will receive security updates for one year. As with Firefox, the next scheduled ESR release will be version 17, in early 2013.
Like Firefox, Thunderbird is covered by the Enterprise User Working Group, but the project maintains a separate presence on the Mozilla wiki.
The wiki provides several other resources of use to enterprises deploying Thunderbird ESR, most notably a guide to managing upgrades with large-volume IMAP servers and a guide to keeping enterprise-related preferences synchronized. In both instances, the amount of email that accumulates in a modern mailbox between upgrades is the problematic factor, a concern Firefox ESR does not share.
T-Minus-Zero
The Firefox ESR and Thunderbird ESR plans have been in discussion for more than six months, and Mozilla has assembled the engineering resources to implement both. However, this is only the first round, and 54 weeks is a long time in software terms; it is always possible that there will be adjustments to the plan between now and the first ESR end-of-life.
Nevertheless, the important fact is that the project was able to successfully sit down with enterprise IT users and arrange a schedule beneficial to both. The shift to a six-week development cycle has not been an easy one, and there are still other concerns (from other groups, such as extension authors and Linux distributions) that have yet to be completely resolved, but the ESR action plans offer hope that all will be well in the long run.
