When I first heard about the Rapid Release plan for Firefox, I liked the idea, first and foremost marketing-wise, to “exist” in the professional communication and to stay abreast of other rapid-release browsers (namely Opera and Chrome). This is what I said on Daniel’s blog a while ago.
Taking a step back, here is what worries me so far, as seen from someone in a big enterprise (Precaution: I work at Orange, but I speak here on my own behalf and the company does not endorse anything I can say here; this is my own opinion forged from experience in big companies and this is my own web site, please bear this in mind):
1. Higher load for extension developers
Extension developers will now have to follow rhythm and update as fast as every sixth week. This is not directly linked to bigger enterprises but I think this endangers the extension ecosystem.
At work I don’t have the time to run after extension update, and/or hack install.rdf files and/or am willing to take the risk for a crucial extension to stop working, considering a few of them are important to my work.
So I’ve stuck to 3.6 for a long time, and had just jumped the bandwagon to 5.0.1 the day before 6 was out. By the way, I’m usually running around 50 extensions.
2. Rapid EOL (end of life)
This is a big trap. I read somewhere someone proposing that Firefox could have LTS (long-term support, like Ubuntu) in parallel to current version, this is an interesting train of thought.
In our company we switched from Internet Explorer 6 to 7 massively in 2010, and not before 2010, for a number of reasons: some applications used Microsoft’s JVM, some applications written with legacy code and did not necessarily have a budget devoted to evolution, for instance.
You can cringe and say that things were not developed correctly from the start like you-and-me geeks-who-don’t-sleep-at-night do [1], but the truth is this: most teams, most companies above a certain size will produce a legacy code that is not trivial to take into account when the environment evolves.
3. Industrial cycle
This is my biggest gripe. I read somewhere that some people in the community claim that companies “just have to adapt” to this major-version rapid-release philosophy, but for the sake of education this is how major versions are integrated in an industrial deployment cycle (and by “industrial” I mean thens of thousands of computers):
1. You let some time pass to see if no security patches will be added. This is exactly what we’ve gotten used to with Windows and a lot of other major software used in enterprise: most of the time it is not considered stable or safe until the SP2 is out. (between the time I wrote the beginning of this article and today, Firefox went through all the 5 cycle plus 6 to 6.0.2, by the way — this shows that this cautious approach is also pertinent here).
2. Once this “reasonable time” has passed (at the discretion of the IS Director), you do a test drive, itself divided in a few phases: first you distribute ISOs of prepackaged systems in which the browser has been updated, then ask for feedback by every team that is concerned in order to know if any regression will occur (freezes, incompatibilities, bugs of all kinds). Then if need be ask project owners to evolve and patch their applications, once again in a “reasonable time”, for instance by integrating correction patches in a bigger evolution of the application. Then do a pilot deployment on a test group to see if the package is OK and up to be deployed in the whole company.
3. You wait for a few months just in case new compatibility alerts are issued. Back to step 2 for a few interested parties that did not realise the stakes when you first asked for feedback. Rinse and repeat.
4. When no alerts are issued anymore and when all applications deemed strategic have been tested, then launch a thorough deployment. By the way, strategic applications are of course not the same according to the professional perimeter of the user: I’m into web and IT, others are into sales and CRM, others into accountancy, etc. This deployment has to be scheduled on several months, even in a structured teledeployment process: for reasons of network load, support, user mentoring with newer versions (“hey, where did Feature X go?”), you have to schedule the deployment in waves, week after week.
Wrap-up
If Firefox does not feature long-term support, and considering the long lag a company will add between major version changes — please bear in mind that this has some very good reasons for being when you manage tens of thousands of workstations and cannot afford to break something, especially now that many applications are web-based —, this new rapid-release model is going to hamper the adoption of Firefox in bigger companies.
I’m not saying I have a solution, and I’m not grumping for the pleasure of grumping : I love Firefox and would love to see it more widely adopted in the enterprise world. Maybe LTS is the solution, maybe it is not. Maybe the major-version rapid-release plan is not good and this is what has to be fixed, this is not for me to say as I am not working at Mozilla, but this has to be considered, enterprise-wise.
Please excuse the dry tone of this article, I just felt it would be useful to share the experience for the sake of improvement. Oh, and in case you’re wondering (and you’ve read this far), I’m still enthusiastic about Firefox!
