Three months ago, Mozilla released the long-awaited Firefox 4. Last week, the organization shipped the follow-up release: Firefox 5. Firefox 5 was the first version of the browser to be released using Mozilla's new Firefox product lifecycle, which would see a new version of the browser shipping every three months or so. The new policy has been publicized for some months, and so the release of Firefox 5 was not itself a big surprise. What has caught many off-guard is the support, or lack thereof. With the release of Firefox 5, Firefox 4—though just three months old—has been end-of-lifed. It won't receive any more updates, patches, or security fixes. Ever. And corporate customers are complaining.
The major problem is testing. Many corporations have in-house Web applications—both custom and third-party—that they access through their Web browsers, and before any new browser upgrade can be deployed to users, it must be tested to verify that it works correctly and doesn't cause any trouble with business-critical applications. With Mozilla's new policy, this kind of testing and validation is essentially impossible: version 5 may contain critical security fixes not found in version 4, and with version 4 end-of-lifed, the only way to deploy those fixes is to upgrade to version 5. That may not be an issue this time around, but it's all but inevitable that the problem will crop up eventually.
Testing overhead
That makes things awkward for the companies who need to validate browser releases. Rolling out security updates with minimal testing is, in theory, generally pretty safe, because security updates are narrow in scope, and because the risk of the alternative—running a known-exploitable browser—is worse than the risk of something breaking. With those security updates now inextricably linked to other, nonsecurity updates, some enterprise users are expressing the fear that their task is now impossible. The other updates included with the security fixes mean that each release is so large that it must be tested thoroughly, but the rapid release schedule means there's no time to do so.
This has some corporate users of the browser feeling very unhappy. Though the release itself came as little surprise, the consequences it would have for version 4 were not generally understood until it was too late. They didn't realize that they would no longer have access to security fixes for Firefox 4, and now have to test all over again for Firefox 5. And to make matters worse, future updates will probably come out even more frequently; a six week cycle is the goal.
These enterprise customers are plainly unhappy, and some commentators are suggesting that Mozilla is alienating its enterprise customers and in effect signing its own death warrant.
Flawed assumptions
But is this really the right response to take? We're not so sure that it is.
Let's be clear: the enterprise has never been Mozilla's number one priority. If it were, this pair of bugs wouldn't still be open more than half a decade after they were first filed. For enterprises, deployment and patch management using MSIs and configuration control using GPOs, are bread-and-butter stuff. They're a hallmark of enterprise readiness. Internet Explorer—surely the king of enterprise browsers—has this kind of support in spades. Chrome, too has some amount of enterprise support.
I'm sure both of those bugs will be fixed eventually. The work will get done. But enterprise users should take note: they're not the priority, and never have been. This should not be regarded as surprising.
But what of those organizations that use Firefox anyway? How are they going to cope now that they will have to do all this extra testing?
The answer to that is: the same way they always have done. The reality is that Firefox minor updates have never been restricted to pure security fixes. If organizations thought that they could get away with performing only minor testing of the 18 minor updates that Firefox 3.6 has received in just 15 months, they were mistaken. Firefox minor releases have long contained stability and compatibility updates. Sometimes there are even feature changes: 3.6.4 introduced a new system whereby plugins were run in a separate process, and 3.6.9 introduced support for new countermeasures against a certain type of security flaw.
These kinds of changes could absolutely cause compatibility issues with business sites and applications. For businesses that needed to perform extensive validation of the browser before deploying it, then both of these updates would require new validation. And in both cases there was no way of avoiding the new features; there were few "pure security" updates made to 3.6. The implication that the new policy somehow changes something about the nature of Firefox updates—and hence the testing burden—just isn't true.
Combining security fixes with broader compatibility and stability fixes or new features is not unique to Firefox, either; Google does the same for Chrome, and even the latest security update to Internet Explorer 9 includes a minor nonsecurity update that resolves a bug with downloading files. The isolated pure security fix just isn't a feature of the Web browser landscape.
Meaningless numbers
Some have said that the testing problem is a result of Mozilla's decision to bump the major version number—with the implication that their company's testing procedures are driven not by an assessment of what's actually changed but by a mere version number, as if the major version increasing meant that there must be major changes.
Mozilla could have chosen a better mechanism to distinguish between versions than a major version number bump—for example, if they had used a date-based numbering scheme then it's likely that this (flawed) inference would no longer be made. But it didn't, and the result is that an increase of the major version number doesn't necessarily imply major changes under the hood.
Mozilla certainly isn't the first to do this. The next version of the Linux kernel will be version 3.0, from the current 2.6.39.2, but this major version update doesn't denote major changes. It might just as well have been version 2.6.40, or 2.8, or something else entirely; it was simply the preference of Linus Torvalds that the major version should, after many years, be increased.
Nor is Mozilla the first major open source project to use a time-based release model instead of a feature-driven one. The Ubuntu Linux distribution has made twice-annual releases, with major version numbers that increment accordingly, since its inception. The user community understands this and responds accordingly.
The corporate response to this change in numbering policy should be trivial: base testing on what has changed rather than what the number is. Any other policy has never been consistent with the way the browser is actually updated. At worst, the new update policy is simply highlighting flaws in existing corporate practices.
reader comments
346