Firefox (and Chrome) updates should be seen in the same way as virus definition updates - something that can indeed cause chaos [1][2][3], but is too useful and sensible to do any other way. Similarly to virus definition updates, typically these updates don't get tested before being rolled out.
There are a few big differences between virus def updates and browser updates:
1) virus def updates rarely cause any problems whatsoever. Whereas browser updates are actually just the opposite. At enterprises its not uncommon that even dot releases break some apps. So those apps need to get fixed, before wide rollout.
2) Virus def updates, when they do break people, break a LOT of people very visibly. That is, if you wait a day on a virus def update, you can pretty quickly see if it broke ppl just by doing an online search. Whereas with browser updates, its a lot more difficult to tell if any of your apps will be broken with a given update.
3) Virus def updates are often fixing issues that have the potential to directly effect your business. Whereas, except for security fixes in browsers, browser updates won't have any effect on the business. It's rare that you have an app waiting to be deployed, but you're waiting on the next version of FF for a new feature or bug fix. IOW, you're taking risk, with no upside.
The issue here is the mixing of new features and security updates. As a sysadmin, I would happily (and do!) roll out periodic security updates without significant testing, for the reasons that you outline.
But when the software is deliberately adding/removing features, I have a number of reasons why I would be wary. You might remove a feature I was using, change the way that your features behave, or change the interface and cause confusion for users.
I've seen cases of all of these, and if I wasn't actively managing the upgrade then we'd have had real-world problems that cost us time and (potentially) money.
This isn't necessarily an either/or thing. They can both be right... it's all a matter of perspective.
So what can enterprises do?
One option is to wait and see if some enterprising (no pun intended) young startup emerges, that offers long-term support for older versions of Firefox. If EnterpriseBrowser Inc. existed today, and sold a guaranteed support program (including backports of security fixes) for, say, Firefox 4, for, say, 5 years, they could probably make some nice coin from the corporate customers.
It doesn't even have to be a for-profit startup as far as that goes... a few $BIGCORPs might pool some resources and create a new open-source project to maintain older releases. Who knows?
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.
Is this really necessary with Firefox or any WebKit browser? If your app is running in Firefox, presumably it's actually written properly to standards (as opposed to being written against whatever Microsoft shipped 10 years ago). Firefox 5 doesn't change that much, just like Chrome releases. (err, what version am I on? Who cares?)
If your app is running in Firefox, presumably it's actually written properly to standards
Unfortunately, as I learned in 10 years of corporate consulting work, that presumption isn't entirely true. The typical corporate webapp I've encountered was written to the corporate browser standard du jour, with very little attention paid to standards. It likely has poor unit test coverage and absolutely no automated testing of client-side markup or code. High profile apps are likely to be an exception - I recently worked on software that delivers market data to the people making billion-dollar trades. It's top notch and awe-inspiring in every respect. But for every one of these, there are 100 apps that let you change your insurance plan, submit new automated deposit instructions, request vacation time, check inventory levels, etc. All done on the absolute cheap by developers whose true skill set is usually integration with legacy ERP software.
The devops folks are right to be wary of a new browser deploys in such an environment.
Exactly. This "new browser version will break everything" argument applies very much to Internet Explorer, but IMO not so much to better browsers like Firefox and Chrome. There might be minor quirks here and there, but those are never going to be serious enough to require more than a couple of days of testing if the app is standards-compliant to begin with.
There seems to be a consensus that enterprise wants one kind of browser and everyone else wants another kind of browser.
Put another way, what does Firefox have to gain from catering to enterprise needs? Funding? They have plenty at the moment. Code contribution? I doubt they really want code from companies who seem dependent on crudware internal apps.
So, let them continue to write cruddy web apps that only work in IE. Perhaps their users will complain, and the IT guy will install Chrome, or Firefox. Then their employees will have to switch between browsers when they log into their HR portal or accounts billing or whatever. That doesn't seem so terrible a thing.
Although I'm not involved with enterprise software, I am worried by the direction Firefox and Chrome are taking: in addition to being a platform for deploying applications, the web is the most important way for readers and writers to share text on the internet, and I worry that rapidly improving the web's ability to deploy applications will make it less suitable for reading and writing. For example, if the web would have been used only for reading and writing, browsers would probably be a lot more stable than they actually are (since an application-delivery platform is a more complicated and consequently less stable thing than a text-delivery platform). And browsers probably wouldn't require half a gig of RAM like Firefox 5 does.
Note that it is not worth a writer's time to use an alternative to the web to deliver text over the net until a sufficiently large fraction of his potential audience is set up to use the alternative. Similarly, a reader cannot use the alternative to download or read a particular text unless a writer (well, owner of the text's copyright, to be more exact) chooses to publish in that alternative. And the existence of the web makes it hard for any such alternative to gain traction. So, readers and writers are stuck with the web for a number of years, until some alternative reaches critical mass.
So when I read about how the pursuit of the HTML 5 vision is causing pain for enterprise users, my first reaction is not to conclude that enterprise users are holding back the web, but rather to see the enterprise as a potential ally in the important project of preventing the HTML 5 program or the enhanced-web-app program from making reading and writing online a lot more difficult than it needs to be.
"If a company really does need to perform extensive validation and verification of its software, perhaps using a browser to deliver that software just isn't appropriate."
If a company really does need to perform extensive validation and verification of its software, perhaps using a browser to deliver that software just isn't appropriate.
First, any time you have software that is a key part of your line of business you have to do extensive validation and verification.
Second, rapidly upgrading browsers isn't something inherent in browsers. As enterprises have shown, you can stick with the same major version of a browser for years w/o any degredation in the core business.
At the end of the day for a lot businesses its just a runtime for deploying CRUD apps. The browser is a fine mechanism for that.
A note: I'm 10 years removed from the enterprise. It seems to me, organizations who respond to change are the ones best staffed, skilled and tooled to weather change.
The FF fighters are in a tough place. It seems the momentum shifted and is on the side of rapid and responsible products closer to what is a SaaS offering, but desktop software is beginning to deliver updates near SaaS pace. Yet a major version number isn't reflective of features/functionality these days. It's a schedule. Perhaps that's the most unnerving aspect -- shifting rev numbers. It's not difficult, but takes a leap of faith and sales to your manager.
I'm guessing the organizations will have to make a major IT expenditure to meet the One True Path -- not buying into a vendor's plan, but making your own. A vendor should get you closer to your vision, but not dictate it. Ten years ago, enterprises got burned on web apps. You bought into a vision. Now, you can pick the best of the best and relatively cheaply, integrate them. I remember a multi-year, multi-million dollar project to get Siebel and JD Edwards to play well. I dearly hope it's not the case. There are young billion dollar companies running on commodity hardware and software with profit margin inbetween.
I haven't seen any commentary on the fact that Firefox's plugin system is completely based on browser version number when specifying compatibility in install.rdf.
Do they expect all developers to release a new version of their extensions every 6 weeks, or do they expect us to effectively say "my extension is compatible with every future version of firefox" which is impossible to guarantee?
There are very good reasons for the "major" version number to exist. Why would they ditch that? Just bump a minor number instead... I see no benefit to this approach.
Hello! I work for Mozilla. To address the problems with our extension versioning system, we've begun running an automated suite of tests against addons that will automatically make them as compatible with the next version of Firefox. The system performed well for the 4 -> 5 update, and we expect to tune it better. Additionally, if developers use the new set of extension APIs as opposed to the older ones, compatibility is a much simpler affair.
I'd be really curious to know the frequency of IT departments reaching the conclusion that nope, FireFox x.y should NOT be installed. I have a suspicion that this is some ridiculously lengthy process that always gets a thumbs up at the end. However, I have zero experience in this so I am more than willing to believe that that's not the case.
Some years ago I asked one of the IT guys at a company I worked at about this. They had a laborious checklist to go through to make sure that no internal or external web apps broke.
This sounds like a small job, but the number of things to check when dealing with apps built internally and externally over the course of a decade or more is not insignificant. Factor in the failure case being potentially hundreds of staff answering phone calls with "Sorry, our system is broken" and you can understand the conservatism towards upgrades.
In the time he'd been at the company (18 months) two upgrades had been held back, one due to a bad stylesheet in an internal app and a second due to an incompatibility with a third-party site that used client SSL certificates.
It took a long time for Firefox to get the thumbs up as a supported browser for internal apps where I work. Like FF 3.5 maybe? Before that, if you reported issues, they told you to use the standard shipped IE on our laptop images. I imagine that the result of this kind of thing will be that FF goes back to the unsupported list.
(This is especially a bummer for those using Linux desktops.)
The basic idea is that if you do something lengthy and laborious and generate documentation that no-one will ever read then if/when it all goes wrong, you cannot be blamed, no matter how spurious your work is. It's like making sure you do all the right steps in a raindance, or ceremony for warding-off evil demons.
Basically when one of their low level "packaging" people screws up the install script. It took me 3 months for an IT department to give me an updated Java VM, as they had marked it "incompatible."
Can't help but compare to Apple's recent Final Cut Pro update: screw one segment over (hard core niche users) for greater riches in others (larger prosumer market). Whether it turns out to be genius or the death of a great product, only time will tell for both FF and Final Cut Pro.
But when I considers how Ubuntu and Red Hat approach life cycle, I can't help but wonder why FF, also open source, couldn't find folks willing to support an enterprise long-life version. Perhaps that tells us something about how much the enterprises really value a stand-alone and open source browser vs. IE, Chrome, and Opera, all their whining aside.
Isn't there a pretty obvious business here? Neatly package (MSI) and test Firefox + every single update to it, and offer to certify webapps (run a cucumber/selenium test suite against each patch level) as guaranteed to run on "Enterprise Firefox". Plus support. Then corporate IT has their backs free (they're not installing cowboy open source weirdness), and the business gets to use a sane browser.
If enterprise web-app developers were to test capabilities rather than browser versions, this would be a moot point. This has been the advice from most browser vendors and js library builders for years.
The problem here is poorly written web apps, and not mozilla.
EOL'ing Firefox 4 after just three months does seem pretty abrupt. Many commercial products will support security fixes for the current and previous versions. Of course, Firefox 5 will presumably EOL'd in three months when Firefox 6 is released...
I think it's just the flip from doing N.X.Y updates for so long to making a major increment every 3 months. If you were running 4.2.1 and three months later they were running 4.5.2, would you necessarily say "Hey, you're EOLing 4.2.1 too soon!", or just click the "Update" button without thinking about it?
The core issue is this - enterprises can reduce testing and maintenance costs for their internal apps because they can control and standardize their browser enviroment. Sites that cater to users at large (like a yahoo) have no control over what browsers their users choose. So, they have to bear significantly higher testing costs.
I haven't heard a persuasive argument for enterprises to change their web development practice and bear significantly higher testing costs. So my expectation is that they will continue on the path that they have been on traditionally.
For mission critical enterprise web apps you can always use the Citrix option. Run an obsolete, tested browser on an intranet server and let employees access it from their desktops (looks just like a local browser but runs remotely). Lock down the network access from that Citrix server to only authorized web apps to eliminate the security risk from unpatched security holes.
Then you can keep the main desktop browsers up to date without worrying about frequent regression testing.
It's a fuss about a number. Ars has a good point – there was no backlash about EOLing 3.6.3 when 3.6.4 came out, but the actual changes in this version were probably just as risky as changes between 4.0 and 5.0.
This new release policy just doesn't make any sense. Sure Chrome is flashy and their release cycle is fast but they're also consistent (also young). OSX and Ubuntu release like clockwork. People appreciate consistency.
Also, when 5 was announced the state of extensions support was uncertain (I finally got the Delicious add-on back working again without compatibility fiddling and definitely didn't want to mess with it).
Having said that, the unrealistic and bureaucratic IT policies of backwards companies are their problem and not for open source to solve (are they donating?). If they're so concerned maybe they should hire someone to contribute to the project full-time so they can stay abreast of changes and maybe have a say in the direction of development.
This new release policy just doesn't make any sense.
Speaking as a Mozilla developer - sure it does! We release every 6 weeks, and don't hold new releases for features. In the past, we ran into far too many cases where new feature X that wasn't ready held up a release for all the other features that were ready. Now, we'll just remove or disable that new feature and ship.
OSX and Ubuntu release like clockwork. People appreciate consistency.
Two things: 1) OS X releases at the whim of Apple, not "like clockwork." 2) Every 6 weeks is "like clockwork"! :)
[+] [-] nl|14 years ago|reply
Firefox (and Chrome) updates should be seen in the same way as virus definition updates - something that can indeed cause chaos [1][2][3], but is too useful and sensible to do any other way. Similarly to virus definition updates, typically these updates don't get tested before being rolled out.
[1] http://arstechnica.com/software/news/2010/03/bitdefender-upd...
[2] http://www.techgeekandmore.com/tag/ca-anti-virus-update-brea...
[3] http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-u...
[+] [-] kenjackson|14 years ago|reply
1) virus def updates rarely cause any problems whatsoever. Whereas browser updates are actually just the opposite. At enterprises its not uncommon that even dot releases break some apps. So those apps need to get fixed, before wide rollout.
2) Virus def updates, when they do break people, break a LOT of people very visibly. That is, if you wait a day on a virus def update, you can pretty quickly see if it broke ppl just by doing an online search. Whereas with browser updates, its a lot more difficult to tell if any of your apps will be broken with a given update.
3) Virus def updates are often fixing issues that have the potential to directly effect your business. Whereas, except for security fixes in browsers, browser updates won't have any effect on the business. It's rare that you have an app waiting to be deployed, but you're waiting on the next version of FF for a new feature or bug fix. IOW, you're taking risk, with no upside.
It's really just not the same thing at all.
[+] [-] omh|14 years ago|reply
But when the software is deliberately adding/removing features, I have a number of reasons why I would be wary. You might remove a feature I was using, change the way that your features behave, or change the interface and cause confusion for users. I've seen cases of all of these, and if I wasn't actively managing the upgrade then we'd have had real-world problems that cost us time and (potentially) money.
[+] [-] barrkel|14 years ago|reply
[+] [-] mindcrime|14 years ago|reply
This isn't necessarily an either/or thing. They can both be right... it's all a matter of perspective.
So what can enterprises do?
One option is to wait and see if some enterprising (no pun intended) young startup emerges, that offers long-term support for older versions of Firefox. If EnterpriseBrowser Inc. existed today, and sold a guaranteed support program (including backports of security fixes) for, say, Firefox 4, for, say, 5 years, they could probably make some nice coin from the corporate customers.
It doesn't even have to be a for-profit startup as far as that goes... a few $BIGCORPs might pool some resources and create a new open-source project to maintain older releases. Who knows?
[+] [-] SoftwareMaven|14 years ago|reply
[+] [-] thedeuce|14 years ago|reply
[deleted]
[+] [-] natesm|14 years ago|reply
Is this really necessary with Firefox or any WebKit browser? If your app is running in Firefox, presumably it's actually written properly to standards (as opposed to being written against whatever Microsoft shipped 10 years ago). Firefox 5 doesn't change that much, just like Chrome releases. (err, what version am I on? Who cares?)
[+] [-] spanktheuser|14 years ago|reply
Unfortunately, as I learned in 10 years of corporate consulting work, that presumption isn't entirely true. The typical corporate webapp I've encountered was written to the corporate browser standard du jour, with very little attention paid to standards. It likely has poor unit test coverage and absolutely no automated testing of client-side markup or code. High profile apps are likely to be an exception - I recently worked on software that delivers market data to the people making billion-dollar trades. It's top notch and awe-inspiring in every respect. But for every one of these, there are 100 apps that let you change your insurance plan, submit new automated deposit instructions, request vacation time, check inventory levels, etc. All done on the absolute cheap by developers whose true skill set is usually integration with legacy ERP software.
The devops folks are right to be wary of a new browser deploys in such an environment.
[+] [-] kijinbear|14 years ago|reply
[+] [-] ender7|14 years ago|reply
Put another way, what does Firefox have to gain from catering to enterprise needs? Funding? They have plenty at the moment. Code contribution? I doubt they really want code from companies who seem dependent on crudware internal apps.
So, let them continue to write cruddy web apps that only work in IE. Perhaps their users will complain, and the IT guy will install Chrome, or Firefox. Then their employees will have to switch between browsers when they log into their HR portal or accounts billing or whatever. That doesn't seem so terrible a thing.
[+] [-] hollerith|14 years ago|reply
Note that it is not worth a writer's time to use an alternative to the web to deliver text over the net until a sufficiently large fraction of his potential audience is set up to use the alternative. Similarly, a reader cannot use the alternative to download or read a particular text unless a writer (well, owner of the text's copyright, to be more exact) chooses to publish in that alternative. And the existence of the web makes it hard for any such alternative to gain traction. So, readers and writers are stuck with the web for a number of years, until some alternative reaches critical mass.
So when I read about how the pursuit of the HTML 5 vision is causing pain for enterprise users, my first reaction is not to conclude that enterprise users are holding back the web, but rather to see the enterprise as a potential ally in the important project of preventing the HTML 5 program or the enhanced-web-app program from making reading and writing online a lot more difficult than it needs to be.
[+] [-] muyyatin|14 years ago|reply
"If a company really does need to perform extensive validation and verification of its software, perhaps using a browser to deliver that software just isn't appropriate."
[+] [-] kenjackson|14 years ago|reply
First, any time you have software that is a key part of your line of business you have to do extensive validation and verification.
Second, rapidly upgrading browsers isn't something inherent in browsers. As enterprises have shown, you can stick with the same major version of a browser for years w/o any degredation in the core business.
At the end of the day for a lot businesses its just a runtime for deploying CRUD apps. The browser is a fine mechanism for that.
[+] [-] gry|14 years ago|reply
The FF fighters are in a tough place. It seems the momentum shifted and is on the side of rapid and responsible products closer to what is a SaaS offering, but desktop software is beginning to deliver updates near SaaS pace. Yet a major version number isn't reflective of features/functionality these days. It's a schedule. Perhaps that's the most unnerving aspect -- shifting rev numbers. It's not difficult, but takes a leap of faith and sales to your manager.
I'm guessing the organizations will have to make a major IT expenditure to meet the One True Path -- not buying into a vendor's plan, but making your own. A vendor should get you closer to your vision, but not dictate it. Ten years ago, enterprises got burned on web apps. You bought into a vision. Now, you can pick the best of the best and relatively cheaply, integrate them. I remember a multi-year, multi-million dollar project to get Siebel and JD Edwards to play well. I dearly hope it's not the case. There are young billion dollar companies running on commodity hardware and software with profit margin inbetween.
[+] [-] tlianza|14 years ago|reply
Do they expect all developers to release a new version of their extensions every 6 weeks, or do they expect us to effectively say "my extension is compatible with every future version of firefox" which is impossible to guarantee?
There are very good reasons for the "major" version number to exist. Why would they ditch that? Just bump a minor number instead... I see no benefit to this approach.
[+] [-] potch|14 years ago|reply
[+] [-] sid0|14 years ago|reply
[+] [-] Adam503|14 years ago|reply
I'm an Evernote premium user. New versions every 3 months means the Evernote add-on gets broken for a month every 3 months. That's not gonna work.
[+] [-] aristidb|14 years ago|reply
[+] [-] tolmasky|14 years ago|reply
[+] [-] cbf|14 years ago|reply
This sounds like a small job, but the number of things to check when dealing with apps built internally and externally over the course of a decade or more is not insignificant. Factor in the failure case being potentially hundreds of staff answering phone calls with "Sorry, our system is broken" and you can understand the conservatism towards upgrades.
In the time he'd been at the company (18 months) two upgrades had been held back, one due to a bad stylesheet in an internal app and a second due to an incompatibility with a third-party site that used client SSL certificates.
[+] [-] smackfu|14 years ago|reply
(This is especially a bummer for those using Linux desktops.)
[+] [-] ZeroGravitas|14 years ago|reply
[+] [-] Bo102010|14 years ago|reply
[+] [-] mwexler|14 years ago|reply
But when I considers how Ubuntu and Red Hat approach life cycle, I can't help but wonder why FF, also open source, couldn't find folks willing to support an enterprise long-life version. Perhaps that tells us something about how much the enterprises really value a stand-alone and open source browser vs. IE, Chrome, and Opera, all their whining aside.
[+] [-] mseebach|14 years ago|reply
[+] [-] justinph|14 years ago|reply
The problem here is poorly written web apps, and not mozilla.
[+] [-] suprgeek|14 years ago|reply
[+] [-] Mavrik|14 years ago|reply
Neither of those claims have proved true in the past.
[+] [-] cpeterso|14 years ago|reply
[+] [-] cpeterso|14 years ago|reply
[+] [-] pseudonym|14 years ago|reply
[+] [-] zeddez|14 years ago|reply
If there had been something subtantial in 5, it might have worked. But it seemed more like an update for the sake of versioning.
They could probably have gotten away with this later, but first turn of the crank just opens them up for complaints.
[+] [-] bzbarsky|14 years ago|reply
[+] [-] zeddez|14 years ago|reply
I haven't heard a persuasive argument for enterprises to change their web development practice and bear significantly higher testing costs. So my expectation is that they will continue on the path that they have been on traditionally.
[+] [-] nradov|14 years ago|reply
Then you can keep the main desktop browsers up to date without worrying about frequent regression testing.
[+] [-] pornel|14 years ago|reply
[+] [-] flocial|14 years ago|reply
Also, when 5 was announced the state of extensions support was uncertain (I finally got the Delicious add-on back working again without compatibility fiddling and definitely didn't want to mess with it).
Having said that, the unrealistic and bureaucratic IT policies of backwards companies are their problem and not for open source to solve (are they donating?). If they're so concerned maybe they should hire someone to contribute to the project full-time so they can stay abreast of changes and maybe have a say in the direction of development.
[+] [-] joedrew|14 years ago|reply
Speaking as a Mozilla developer - sure it does! We release every 6 weeks, and don't hold new releases for features. In the past, we ran into far too many cases where new feature X that wasn't ready held up a release for all the other features that were ready. Now, we'll just remove or disable that new feature and ship.
OSX and Ubuntu release like clockwork. People appreciate consistency.
Two things: 1) OS X releases at the whim of Apple, not "like clockwork." 2) Every 6 weeks is "like clockwork"! :)
[+] [-] yuhong|14 years ago|reply
[+] [-] alxeder|14 years ago|reply
[+] [-] aristidb|14 years ago|reply