The Pitfalls of Firefox’s Rapid Release Cycle [Editorial]
By on August 25th, 2011

If you have been following the recent Firefox releases, you are probably already aware that Mozilla is now following a rapid release cyclefor Firefox. Frustrated by the innumerable delays that plagued the release of Firefox 4, Mozilla decided to take a leaf out of Google’s book, and release a new version of Firefox every six weeks. Unfortunately, the new quick-fire release policy creates some major issues that Mozilla doesn’t seem to be willing to tackle.

Firefox-Rapid-Release

The first problem is that it makes version numbers redundant. A major version number bump normally indicates the introduction of major new features along with significant enhancements to existing features. However, the biggest new feature in Firefox 6 domain highlighting in the address bar, is something that wouldn’t excite even the most passionate Firefox user. Firefox 5 was even worse.

The biggest feature in Firefox 5 is that the Do Not Trackfeature, which we have discussed in a fair amount of detail in the past, is now more accessible. It is now available under the Privacytab, instead of being buried under Advancedoptions. Yep, the biggest user-perceivable change in Firefox 5 is a minor interface tweak.

Of course, this alone isn’t such a big problem. Undoubtedly, it’s annoying and stupid. However, Firefox’s auto-update does a good job at making the update process hassle free. Add-on compatibility was another issue that I was worried about. However, Mozilla seems to be doing something right in this area. All the add-ons I used were compatible with Firefox 6 at launch. At the time of writing, 99% of the top extensions, which constitute 95% of the total extension usage, are compatible with Firefox 6.

Unfortunately, there is one issue that Mozilla doesn’t seem to have a solution for. The rapid fire update policy means that every year we will be witnessing eight to nine major version trunks of Mozilla. However, Mozilla isn’t willing to support the older version trunks. If you are on version 4, which was released just a few months back, then tough luck. Mozilla won’t be providing any further updates to the 4.x trunk. Updating to newer versions might not be a big issue for home users, but it is a major undertaking for enterprises. Each major update has to be tested for regressions and other issues before it can be deployed. Mozilla’s reluctance to support older trunks mean that enterprises stand the risk of being left vulnerable to serious security vulnerabilities over extended periods.

Enterprises are notorious for their reluctance to switch to newer and better browsers. It’s only recently that some of them have begun to opt for Firefox. However, with the new rapid release cycle, Mozilla will almost certain succeed in making all of them revert to Microsoft Internet Explorer, since Google Chrome also follows the same quick-fire release cycle and Opera has too many website compatibility problems (often due to factors out of its control) to be considered seriously. In contrast to Mozilla, Microsoft will be supporting Internet Explorer 9 till January 2020.

So why is Mozilla using the rapid release cycle? It seems to offer very little benefit and is misleading, annoying, and counterproductive. This is what Asa Dotzler, product manager for Firefox, had to say:

I can give you an example that may help illustrate the value in faster release cycles. In June of 2010, Mozilla engineers added WebM support to Firefox’s HTML5 >video< tag. But users and the Web and Web developers did not see that in a shipping version of Firefox for more than 9 months when Firefox 4 finally shipped.

That delay was bad for the Web and bad for the users. When you only ship a feature when all other features scheduled for a release are complete, your schedule can grow, in the case of Firefox, to a year or two.

We’ve moved to a new cadence that allows us to ship a feature when it’s ready, even if dozens of other important features aren’t yet complete.

If we’d have been on this faster release cadence, we could have delivered WebM to the world 8 or 9 months earlier, but because we were waiting on a new JavaScript engine and a new toolbar design and a dozen other important features — all of which needed to be completed before we could ship Firefox 4, users and developers didn’t get WebM until then.

Dotzler certainly makes a very valid point. It’s better to push through a major new feature like WebM as soon as it is ready, rather than waiting for all of the other new features to be ready. However, Firefox’s current release cycle can’t really be called feature driven. Both Firefox 5 and Firefox 6 didn’t contain any feature that needed to be pushed through as soon as possible.

Mozilla is aware that their new rapid release system breaks the established version numbering system. Unfortunately, the solution that Mozilla is considering implementing is rather insincere. Mozilla will be dropping the version number information from the Help –> About dialogue box, where almost all applications are typically expected to house the version and build information. Here’s Dotzler’s Bugzilla submission on the impending change.

When a user opens the About window for Firefox, the window should say something like “Firefox checked for updates 20 minutes ago, you are running the latest release.”
It is important to say when the last check happened and ideally to do the check when the dialog is launched so that time is very near and to drop the version and simply tell them they’re on the latest or not.
If a user needs the full version information they can get it from about:support.

Firefox-Release-Channels

In Mozilla’s bizzaro world, the best way to solve a problem seems to be by brushing the symptoms under the carpet rather than dealing with the root cause of the problem. Dave Garret explained the folly of hiding version numbers from the “About” dialogue box succinctly.

The about dialog is essentially a box designed for the sole purpose of housing the application developer and version. I am sorry to break it to you, though, even if having the version in the about dialog is a UX problem in any way, virtually all other applications out there beg to differ. Even my mother knows this is where you look up what version of a program you’re using. You’re going up against established UX that spans much time and across OSes.
The greater point here is that any gain that could be made trying to hide the version is not worth the expected confusion of people no (sic) being able to find it in the same place every other application has it, and not worth the eventual flame storm this will create.

Mozilla’s problem is not that its version number is soon going to be insanely high. Its problem is that it is confusing users by labeling minor releases as major ones, and it is alienating enterprise users by refusing to provide long term support. If delivering features is the ultimate aim of the faster release cycle, then the release cycle needs to be flexible enough to be determined by the completion of new features rather than being strictly time bound. At the very least, there is no reason why they can’t have four minor releases and two major releases per year, instead of the current eight to nine annual major releases. If Mozilla wants to address the real problem then they will have to get the balance between release speed and features right.

Tags: , , ,
Author: Pallab De Google Profile for Pallab De
Pallab De is a blogger from India who has a soft spot for anything techie. He loves trying out new software and spends most of his day breaking and fixing his PC. Pallab loves participating in the social web; he has been active in technology forums since he was a teenager and is an active user of both twitter (@indyan) and facebook .

Pallab De has written and can be contacted at pallab@techie-buzz.com.
  • Caitlin

    You’ve made quite a few assumptions here, and clearly haven’t done any background research.

    Compatibility: Mozilla is very aware of this problem. That’s why, starting in Firefox 9 (currently in the “nightly” stage, and set to be released December 20th), add-ons will always be compatible unless there’s a good reason for it not to be.
    Proposal: https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
    Reactions: http://forums.mozillazine.org/viewtopic.php?f=23&t=2272397 and http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/f68e4b67c18f037d?pli=1

    Support for older trunks: first of all, there’s a big difference between not supporting a version and not providing minor releases for it. But even if we use your definition of support, given that no new features are implemented after a version has reached the Aurora channel, and given just how stable the Beta versions already are, IT departments can begin running their own tests several weeks in advance. Furthermore, since Firefox is completely open-source and Mozilla provides a very detailed list of every change, IT can implement any relevant bug fixes themselves while still using the same “version”.

    Firefox 5 and 6 features: you and other detractors really need to rethink your definition of “feature”. Something that works in the background and doesn’t change the GUI is still a feature. Furthermore, quite a few of the new features (about:memory revamp, domain highlighting, site-specific permissions, web console changes, etc. ) are partially aimed at the enterprises you’ve been talking about. Firefox 6 has significantly improved performance for anyone who uses Panorama. Lastly, the next 3 releases will have huge end-user-pleasing changes — Firefox 7′s MemShrink, 8′s 3rd-party add-on blocking and confirmation, and 9′s add-on performance info and new tab page, to name a few.

    I’ll conclude by re-stating a very important point: just because you can’t instantly see a change doesn’t mean it’s not there. Plenty of new features have been implemented in Firefox 5 and 6, and waiting for GUI-specific features before a release unnecessarily delays non-GUI features that are more than just bugfixes.

    • http://www.pallab.net Pallab De

      Before claiming that I haven’t done any background research, you should probably at least read what I have written.
      Regarding add-on compatibility, this is what I had to say:

      However, Mozilla seems to be doing something right in this area. All the add-ons I used were compatible with Firefox 6 at launch. At the time of writing, 99% of the top extensions, which constitute 95% of the total extension usage, are compatible with Firefox 6.

      In other words, I praised Mozilla for fixing the add-on compatibility issue. The automatic compatibility checker is certainly doing a pretty good job.

      Regarding the support for older trunks: I don’t want Mozilla to go back and fix performance issues, or add new features to older trunks. However, they should offer security updates to the older trunks. Without that its very difficult for enterprises to go use Firefox.

      But even if we use your definition of support, given that no new features are implemented after a version has reached the Aurora channel, and given just how stable the Beta versions already are, IT departments can begin running their own tests several weeks in advance.

      Even if IT departments begin running their tests early, they will have to run these tests every 6 weeks. In other words, they will end up spending a considerable amount of resources on simply supporting Firefox. Almost no enterprise will be willing to invest this much on just a browser, when IE 8/9 is reasonably good enough. And enterprises almost certainly aren’t going to take the effort of manually porting patches to older versions. None of your suggestions are practical.

      Firefox 5 and 6 features: you and other detractors really need to rethink your definition of “feature”. Something that works in the background and doesn’t change the GUI is still a feature.

      Firefox is a essentially a consumer software. As such, my definition of feature is perfectly valid and acceptable. In order for something to qualify as a feature it must be perceivable to a large segment of users. Under the hood changes that don’t have any impact (yet) on users can’t qualify as features. Even more crucially, it is not sufficient for a major release to have new features. It must have significant new features. Otherwise, its simply doesn’t qualify as a major release.

      • Caitlin

        The section about compatibility was aimed more at those looking at the comments. Admittedly, using it as the first example didn’t make that at all clear.

        Even if IT departments begin running their tests early, they will have to run these tests every 6 weeks. In other words, they will end up spending a considerable amount of resources on simply supporting Firefox. Almost no enterprise will be willing to invest this much on just a browser, when IE 8/9 is reasonably good enough.

        If you look at the hotfixes for IE8, the largest interval was 11 weeks, and on average they occurred every 7-8 weeks. In other words, IT departments are frequently running tests anyway. With Firefox, they’ll have a couple of extra testing periods per year, with the added benefit of new features.

        Firefox is a essentially a consumer software.

        Yet you’ve spent quite a bit of time outlining the problems of the rapid release cycles for enterprises….

        … my definition of feature is perfectly valid and acceptable. In order for something to qualify as a feature it must be perceivable to a large segment of users. Under the hood changes that don’t have any impact (yet) on users can’t qualify as features.

        First off, 5 & 6 did have some features that were “perceivable to a large segment of users”. Secondly, note that Microsoft never released web standards compliance features without incrementing the major version number — a problem that has always hindered site development and cross-browser compatibility. Considering that Firefox is by design reliant on its extensions, providing the technology for developers to improve those add-ons does in turn affect the end-user. Finally, at least 1 major end-user-visible feature is scheduled for each of the next 4 releases. Maybe we should think of 5 & 6 as a period of adaptation instead of a sign of things to come.

        Even more crucially, it is not sufficient for a major release to have new features. It must have significant new features. Otherwise, its simply doesn’t qualify as a major release.

        I partly addressed this above. But your colloquial use of the word “significant” is ambiguous. Is 1 humongous change “significant”? What about 10 smaller changes? And significant to whom?

  • http://www.abhishekpathak.net Abhishek Pathak

    I guess this was one decision Mozilla made with the trade-offs in mind.While a lot of people do not agree with the bumping up of version numbers ever-so-frequently,it generally makes sense to have shorter releases with background updates.The common user never really has to “know” the version,or remember to update.While this certainly causes headaches for developers,fx is taking a step in the right direction with better compatibility among releases.As far as the enterprise-friendliness goes,you can’t please everyone perfectly.There do exist 3 channels(Aurora,nightly,beta) for better regression(considering rapid releases are not major overhauls).Moreover,IE pretty much reigns supreme in enterprise environments not due to better support,but better integration with the MS suite of enterprise products.Half the world’s computers,and a major chunk of the enterprise world still runs XP,even though it not supported any more by Microsoft.IMHO its a much better strategy by fx and chrome to try becoming more consumer-friendly excellent products.If that risks going down a notch in the enterprise world,it matters less because – 1.they dont really care about new features as much 2.the share is already dominated by MS/IE/Apple,and for a much bigger reason than browser compatibility.

  • http://www.yahoo.com/ Deena

    This is a neat summary. Thanks for sahirng!

  • Cornelius

    Hiding the version number in this case is hardly a UX folly. Removing complexity from people’s view is a good thing. In this case, I wonder how much value there is to display version numbers to people given the ability of the program to auto-update itself. Do people care about the actual number? Most of the time, people just want the latest thing.

 
Copyright 2006-2012 Techie Buzz. All Rights Reserved. Our content may not be reproduced on other websites. Content Delivery by MaxCDN