/* Filed under Web */
Under the proposal, Mozilla would issue a new Extended Support Release (ESR) version of Firefox every 30 weeks. That’s five times slower than the new rapid-release cycle for regular Firefox, which updates the browser every six weeks. And each version would be supported for 42 weeks under the proposal.
After Mozilla got an earful in June about how the rapid-release program outpaces some users’ needs to test the browser and in-house Web sites that use it, Mozilla set up an Enterprise Working Group to try to hammer out a compromise.
“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,” said Mozilla’s Kev Needham in a mailing list message yesterday.
The proposal is the result of that group’s work, said Stormy Peters, head of developer engagement at Mozilla. Now it’s time to see how well the proposal is received.
With the ESR proposal, Mozilla is trying to have it both ways, modernizing its development process without abandoning slower-moving customers. If it moves too slowly, it risks losing its edge with early adopters who already have found Google’s Chrome appealing. If it moves too fast, it risks driving slower-moving organizations into the arms of Microsoft’s Internet Explorer.
The company, while trying to accommodate the slower-moving customers without having to spin up a huge new support operation, is as convinced as ever that the rapid-release program is the best way forward.
Indeed, some at Mozilla are mulling an even faster cycle that would deliver new features to users faster And it seems likely that Firefox updates will become not merely frequent but “silent,” generally taking place without user intervention.
The rapid-release plan is designed to bring new features to Firefox users sooner and to smooth the development process. Instead of waiting a year or so for a large set of new features, Firefox users wait a few weeks for a small set. And no more can a single new feature hold up an entire release. Instead, it’s pushed back six weeks while the other changes are shipped. With a focus on a schedule rather than a version number, developers ideally can ship a new feature it’s done, not hastily push it into users’ hands before its ready.
“If we don’t do something like this the browser becomes a limiting factor in what the Internet can do,” Mozilla Chair Mitchell Baker said in a blog post in August.
Google pioneered the rapid-release schedule with Chrome, starting with a three-month process then spinning faster with a six-week cycle.
But Google had a couple advantages over Mozilla with the rapid-release mechanism.
First of all, it employed a silent update mechanism from the outset, with the browser downloading new versions of itself automatically, installing them when a person restarted the browser or the computer. Those who didn’t like the system enough steered clear of Chrome altogether.
Mozilla, in contrast, is trying to change an existing process that, while not always perfect, has certainly worked well enough to attract the second largest group of browser users on the Internet.
Firefox, though, while adding a similar extensions system, has an older one as well that’s much more susceptible to compatibility problems. Mozilla is working to ameliorate those problems–for example by automatically registering the add-ons it distributes as compatible with new versions of Firefox when possible.
Ideally, Web developers will adjust to the new era by skipping version numbers, too. Instead of tailoring Web sites and Web applications for this or that numeric version of a browser, they can use “feature detection” to see what technologies a browser supports and present an appropriately tuned Web site.
There are cultural issues with the rapid-release process. Huge numbers of people have been trained by the software industry that a major version number increase ought to be something of importance, an occasion to take note of big changes. The rapid-release process–which has largely hidden away version numbers as a mere tracking tool–does away with this big-bang style of change.
And there are practical issues. As Needham succinctly puts it, “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.”
To deal with the slower-moving users such as businesses and schools, for example, Mozilla offers the ESR version. Under the proposal, it would come with fixes for high-risk and critical security holes, would be tested and released through its own distribution channel alongside ordinary Firefox, and likely would start out based on Firefox 8 or 9.
A discussion on a Mozilla mailing list has raised the possibility of an even faster release cycle. Programmer Josh Aas asked whether a five-week cycle might be possible. A new feature developed this way would arrive in users’ browsers three weeks earlier, because it would spend one less week being tested in the nightly, Aurora, and beta channels of Firefox that precede a stable release.
There’s no plan to make the shift right now. But the general idea has allies–including Christian Legnitto, Firefox’s release manager.
“Yes, I absolutely think in the future we will shorten the cycle–but it won’t be soon. We have some work to do to make 6 weeks smooth from a process, tool, and product side. When we get six weeks down to a science we can shorten as needed. Note we will need to be very, very crisp on the messaging and announce the shift well in advance,” Legnitto said. However, he added later, “We are sticking with the 6 week cycle for the foreseeable future.”
Mozilla also is moving Firefox toward a silent update process in which people don’t have to take actions to move to new versions of the browser as they do today.
“We formed a team / had our first meeting last week to focus on silent updates, and it is definitely a top priority,” said Mozilla’s Robert Strong in a message. An update will require user action in cases where the new version isn’t compatible with an existing add-on, he said. One of the complications of the idea is bypassing operating system warnings such as Windows’ User Account Control that pop up asking if users really want to install software.
Firefox mutiny? Not so much
Despite the hue and cry over the rapid-release program, most Firefox users are on board.
Legnitto said people are moving to new versions of Firefox faster than before.
“The uptake curve got steeper between [Firefox versions] 5 and 6, which means more people are updating faster. This generally dismisses the concern that as we do more updates people are holding back,” he said. “These numbers are actually good to great. We are watching this closely though.”