Firefox rapid-release scheme vs. enterprise processes

I know it’s a cheesy title for a post, but I couldn’t find better. In this article I try to explain the possible outcome of the new rapid-release scheme regarding the integration of Firefox in bigger enterprises.

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!

Footnotes

[1I’ve gotten old along the way: I do sleep now and consider myself a semi-retired geek...

Comments

  • Jibou (8 September 2011)

    Hi Stephane,

    Interesting article on an indeed complex subject !

    I worked as an engineer for the automotive industry before realizing a geek like me needed a geek job ;)

    The company I worked for is building cars (not surprising...) and all the business is done in one place. Everyone (and I mean everyone!) is working in one location. The cars are being designed, engineered, manufactured, marketed and sold there. More than 3000 people work on a lot of complicated pieces of software that uses complicated pieces of servers.

    In that environment, I think another issue concerning web browsers emerge. It’s the "who gives a fuck about web browser" issue ? If I recall correctly all the software I used had nothing to do with web browsers. Those were software like Catia V5 (Dassault System) or softwares developed internally.

    Needless to say that the IT department had other stuff to do than migrating the web browsers of every computer in the company. And I’m sure that if someone had asked the IT departement to migrate the answer would have been : "Does it goes on the internet ? Are you able to do a search on google ? Yes ? So IE6 is good enough".

    Jibou

    Reply to Jibou

  • karl (8 September 2011)

    @jibou in this case it doesn’t break your process, and then it is not an issue.

    I think stephane is talking about companies who are working with the Web. For example Boeing has a few hundred thousand employees and many Web servers in the world for working (not only public). They participate to W3C because when something is done wrong on the Web front, they have issues in their companies.

    I sympathize with the two sides of the argument. It might be a bit hard to really have a clear discussion without separating the issues people are facing.

    There are issues related to

    * Web technologies themselves (the CORE engine)
    * the Chrome (user interface of the browser)
    * Browser components (extensions)

    These doesn’t have exactly the same impact and doesn’t create the same set of issues.

    For the Web technologies side, a rapid release process is cool by avoiding bugs to solidify. People start to use hacks when they know it will be supported for ever.

    ISSUE? The legacy code already deployed and the crap existing here and there that some systems might depen on.

    So the rapid release process encourages being conservative about what you should do on the Web. It’s kind of funny because we encourage people to use the new shiny feature, but a rapid release process can in fact create the opposite of not trying the new features, because any ways in two versions from now, it will be dropped.

    Another issue with rapid release process which is not really mentioned is the resources cost. EVEN if it would not break anything, just deploying on thousands of computers is very costly. Think about bookmarks, little configurations here and there that people use on their browsers. Imagine that every 12 weeks, someone comes to your office and change your entire desk at work.

    Reply to karl

  • Stéphane (8 September 2011, in reply to karl )

    Karl,

    I sympathize with the two sides of the argument.

    Me too. Which is why I shared here. I’m on both sides.

    Another issue with rapid release process which is not really mentioned is the resources cost. [...] Imagine that every 12 weeks, someone comes to your office and change your entire desk at work.

    Exactly. I was thinking that this is a ’blank’ operation as bigger companies already have committed resources to evolving the environment according to updates etc., because they already do it for a lot of stuff, like OS updates, Microsoft Office updates, email servers going from POP to Exchange etc. Which is why I didn’t mention it, as processes are already put in place. But in fact you’re right, there is a cost to every new software added to the process.

    The good news is that Mozilla knows the rapid-release is an issue.

    Reply to Stéphane

  • Jibou (8 September 2011)

    @karl:

    I understood Stephane’s point.

    What I’m saying is there is more to his side. Sometime, IT just doesn’t have time for web browser’s improvement because they have more important stuff to do.

    Reply to Jibou

  • Jorge (8 September 2011)

    Nitpick: the quick succession of 6.0 to 6.0.1 to 6.0.2 was due to the Diginotar certificate compromise. So, this wasn’t really related to a bug in Firefox code, but a response to a compromise in an external component. The rapid release process is designed so that no patches come into release versions unless they are truly critical, and the expectation is that all of these problems are caught during the 12 week Aurora and Beta window.

    Of course, security patches will continue to happen every now and then, but they should be much more rare than they were before.

    Reply to Jorge

  • Stéphane (8 September 2011, in reply to Jorge)

    Jorge,

    So, this wasn’t really related to a bug in Firefox code, but a response to a compromise in an external component.

    Yeah, but some thing can always happen that calls for minor updates, which was what I was trying to say there. Minor updates are here to stay whatever the major-release scheme is. Case in point.

    Reply to Stéphane

  • @moutonrebelle (8 September 2011)

    I think the rapid-release process is mainly hurting individuals, not entreprise. IT service in big companies disable auto-update, and having a quick or a slow release process does not change the fact that no update will be done until the IT guys decide it’s safe and worth it to do so. And my guess is it won’t be more often than before.

    Individual - let’s say my mum - have auto-update enabled, and for the most part they don’t want it, and it’s just hurting Firefox and Mozilla’s image :

    - Update process is not as transparent as it is in Google Chrome : it require user confirmation, compatibility check, etc...
    - It can break extensions, which are in my opinion the only advantage Firefox has over Chrome, Safari and Opera.
    - Most important : they are useless. They fix/implement geeky new web tech that won’t be used until widely adopted, which is not until IE drop another 10% ; Web dev can use nightly to test those new features, and users can wait a few month to get them.

    Reply to @moutonrebelle

  • anonymous (15 March 2012)

    1) I concur that individuals like myself are affected, both at work and at home,
    because Firefox and Chrome are forcing updates on me by auto-updating the next
    time the browser is restarted...at which time it tells me all the "incompatible"
    extensions and plugins that it has deleted/deactivated. D’oh!!

    2) This is just a particular case of the general problem of "rapid releases".
    People who have to guarantee the quality of a system, need to know that the
    components they have built with, and tested with, have not changed.
    If for no other reason than to let them figure out if changes to THEIR code has
    broken something (rather than having to wonder if it was the fault of a new
    version of some component that was involuntarily/secretly "updated").

    3) The problem of rapid releases snowballs because the more rapid, the less
    tested and stable each new release is. The more it makes the users involuntary
    beta testers.

    4) The notion of rapid releases makes sense only if:
    (a) one can specify a particular release such that is never changes underneath you
    (b) some releases are "blessed" as extra stable and extra well tested therefore
    worth the bother/expense of bumping up to that new version/release.

    Reply to anonymous

  • polyglot (15 March 2012)

    im not really anonymous

    Reply to polyglot

  • Stéphane (16 March 2012)

    polyglot : Hi,

    Actually since this article was written, the firefox crew came up with an enterprise release cycle.

    Have a look at the Mozilla Enterprise User Working Group.

    Reply to Stéphane

Who are you?
Your post

This form accepts SPIP shortcuts [->url] {{bold}} {italic} <quote> <code> and the HTML code <q> <del> <ins>. To create paragraphs, simply leave blank lines.

Hypertext link

(If your message refers to an article published on the web or to a page providing further information, please enter the title of the page and its URL below).