Last week, Mozilla programmers and executives were jubilant when the release of Firefox 5 marked the successful transition to a more competitive rapid-release development cycle.
Now, with a backlash from corporations and others who aren’t equipped to handle that pace of change, things aren’t quite so sunny. The organization and its community of supporters have begun some soul-searching about how to reconcile the conflicting priorities–developing software quickly but not leaving users behind.
Mozilla has concluded that Firefox isn’t for corporations whose Web use doesn’t move at the speed of today’s Web, though. That decision frees Mozilla from catering to that audience, but it also means that audience is more likely to choose a rival browser–Microsoft’s Internet Explorer being the most obvious candidate.
The tension mirrors one in standardization circles between two groups overseeing Hypertext Markup Language, the programming language better known as HTML that’s used to describe Web pages. One group, the Web Hypertext Applications Technology Working Group (WHATWG), has moved to a “living” document whose HTML specification continually evolves. The other, the World Wide Web Consortium (W3C), standardizes a snapshot of this specification through a process that moves at a much more stately pace for those whose products and certifications also do: its HTML5 standard isn’t due to be officially complete until 2014.
Deliberations about the Firefox support issue have surged on a 220-plus message discussion on a Mozilla mailing list.
It began with a simple question from a Firefox 3.6 user who wants to keep that version as long as possible. The intensity picked up with two quotations on the blog of Mike Kaply, a consultant who specializes in browser matters:
I have 500,000 corporate users on Firefox 3.6. We just completing a test cycle of Firefox 4 on many thousands of internal business web applications. Many hundreds of application owners and their test teams have participated. We gave them several months to ready themselves. We worked with dozens of internal Add-On developers and product teams to prepare their add-ons for Firefox 4. We’re poised to deploy Firefox 4.01 in 3Q when the corporate change freeze lifts…The Firefox 4 EOL [end of life schedule] is a kick in the stomach. I’m now in the terrible position of choosing to deploy a Firefox 4 release with potentially unpatched vulnerabilities, reset the test cycle for thousands of internal apps to validate Firefox 5 or stay on a patched Firefox 3.6.x. By the time I validate Firefox 5, what guarantee would I have that Firefox 5 won’t go EOL when Firefox 6 is released?
Kaply concluded, “While the rapid release process sounds great, it’s an absolute fail for large deployments of Firefox.”
Mozilla’s response, in short: tough beans.
“We recognize that this shift may not be compatible with a large organization’s IT policy and understand that it is challenging to organizations that have effort-intensive certification polices. However, our development process is geared toward delivering products that support the Web as it is today, while innovating and building future Web capabilities,” said Kev Needham, channel manager at Mozilla, in a statement. “Tying Firefox product development to an organizational process we do not control would make it difficult for us to continue to innovate for our users and the betterment of the Web.”
And Firefox, fundamentally, is aimed at individuals, not corporations, Needham said.
With the rapid-release cycle, Firefox versions reach their end of life soon. “As part of the faster cadence, FF5.0 automatically EOL’s when FF6.0 is released with users getting silent updates,” the rapid-release documentation states. Firefox 4 uses the earlier policy, which offers support for up to six months after a major successor is released. New versions of Firefox initially were set to arrive every three months, but now they’re set to arrive sooner on a six-week schedule that should produce Firefox 6 on August 16 and Firefox 7 on Sept. 27. Version numbers no longer are promoted.
So how did we get here?
The rapid-release arrival
The rapid-release cycle, in which Firefox issues four new versions a year, is intended to bring new features to people sooner. That could be better performance, new Web programming technologies, or user interface improvements.
With the older style, a version number change was a rare event that signified major change. As a result, releases often were pushed back by months as programmers worked to include and debug their new features. With the rapid-release approach, new versions of Firefox ship quarterly with whatever new features are done. The consequences to missing the release train are lower, since another train will come around again soon.
“By releasing small, focused updates more often, we are able to deliver improved security and stability even as we introduce new features, which is better for our users, and for the Web,” Needham said.
The idea is based on how Google develops Chrome, a browser that in less than three years has won over one out of every eight people on the Web. Last year, Chrome switched from quarterly releases to an even faster six-week schedule.
Chrome has proven successful, and it’s no wonder Mozilla is paying attention. Chrome’s growth took off just as Mozilla’s share of browser usage peaked at just shy of one in four users. Although the two projects compete, they share some goals–making the Web a more powerful platform for software, for example–and Chrome engineers directly briefed Mozilla on how to quicken the pace.
But Chrome and Mozilla have one very big difference. From the outset, Chrome has automatically, silently updated itself when new versions arrive. Chrome users have no idea what version they’re using unless they explicitly check. Chrome version numbers increment rapidly–the stable version is Chrome 12, the beta version is Chrome 13, and the edgier developer version is Chrome 14. Those numbers are mere labels to keep track of branches on a tree, though.
In contrast, Mozilla is retrofitting the rapid-release schedule to a user base that’s not not used to it.
One of Firefox’s biggest assets has been its ability to run extensions that could customize what the browser could do with a programming foundation called XUL. But when it comes to change, extensions have a downside: new versions of Firefox can break compatibility.
“You can do nearly everything with an Add-on SDK and Add-on Builder based add-on that you can do with a XUL-based add-on,” said Justin Scott, Mozilla’s add-ons product manager.
Unfortunately, though, rewriting extensions is work for anyone relying on them.
“After shipping version 1.0 of the Add-on SDK and the Add-on Builder Beta, one of our top priorities is to help developers migrate from XUL-based add-ons to Builder/SDK based add-ons, so implementing advanced add-ons will become much easier,” Scott said.
The mailing-list discussion has captured some of the back-and-forth.
Jean-Marc Desperrier suggested Mozilla release Firefox the way Ubuntu releases its long-term support (LTS) versions of Linux: A version comes out every two years for customers that need stability not provided by the other twice-yearly releases.
“Normal users get updated to each new release, but people who need the stability and don’t care about frequent functionality update can stay on the LTS release for a whole year,” Desperrier said.
Mozilla’s Asa Dotzler countered that such a move would be expensive, though, and added, “Corporate deployments have never been a Firefox focus. Mike Beltzner, the former director of Firefox who’s still an active member of the Mozilla community, concurred.
“While I agree that longer intervals would be better for corporate deployments and embedders [who build a browser into a product], I’m not at all certain it’s the best thing for the Web or for Mozilla,” Beltzner said. “My instinct is to let corporate deployers catch up to a faster…We don’t have the resources–as a community–to focus on their problems and on moving the Web forward.
It’s no surprise to see a different view at Microsoft, much of whose revenue comes from corporate customers. “We’ve got a great solution for corporate customers with both IE8 and IE9,” said IE team member Ari Bixhorn in a blog post, offering these points:
1. Enterprises have always been, and will always be, an important focus of ours.
2 For corporate customers, we’ll support each version of Internet Explorer as long as the latest version of Windows that it runs on is supported. For example, Windows 7 Enterprise is supported through January 2020. Internet Explorer 9 will therefore also be supported through January 2020.
The rapid-release issue is complicated for slower-moving organizations by the fact that security risks of using a browser show no signs of abating. Sticking with an older and unsupported browser exposes browser users to malware on the Web.
Dotzler, in comments that mirror Google’s Chrome philosophy, made the argument that software running on a person’s computer is similar to the software people use as Web service. In the latter case, site operators frequently update their sites with no notice at all to those who use them.
“No one is complaining these days about Google Chrome 14, and not a soul I know (and I know a lot of sophisticated computer users) even knows what version of twitter.com or gmail.com they’re using,” Dotzler said.
Fundamentally, the conflict boils down to one often called the “consumerization of IT.” People increasingly expect their company computing equipment to behave like that they buy themselves. They want to recieve company e-mail alerts on their smartphones, to use the company’s intranet site with their iPad, and to be able to check their Web-based e-mail from any browser.
Ultimately, though, IT departments may just not be able to deliver all that, as the persistent use of decade-old IE6 shows. So don’t be surprised to see a wider gulf forming between the fast movers of the Web world and those who can’t keep up.
Originally posted at Deep Tech