This article is right.<p>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.<p>[1] <a href="http://arstechnica.com/software/news/2010/03/bitdefender-update-breaks-64-bit-windows-pcs.ars" rel="nofollow">http://arstechnica.com/software/news/2010/03/bitdefender-upd...</a><p>[2] <a href="http://www.techgeekandmore.com/tag/ca-anti-virus-update-breaks-windows/" rel="nofollow">http://www.techgeekandmore.com/tag/ca-anti-virus-update-brea...</a><p>[3] <a href="http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-update-breaks-pcs.html" rel="nofollow">http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-u...</a>
<i>the enterprise is wrong, not Mozilla</i><p>This isn't necessarily an either/or thing. They can both be right... it's all a matter of perspective.<p><i>So what can enterprises do?</i><p>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.<p>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?
<i>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.</i><p>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?)
There seems to be a consensus that enterprise wants one kind of browser and <i>everyone else</i> wants another kind of browser.<p>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.<p>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.
Money quote:<p>"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."
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.<p>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.<p>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.<p>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?<p>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.
Firefox isn't just killing their Enterprise customers. This is going to hurt all the users who like to use add-ons with Firefox.<p>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.
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.
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.<p>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.<p>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...
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.<p>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.<p>Then you can keep the main desktop browsers up to date without worrying about frequent regression testing.
It's a fuss about <i>a number</i>. 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.<p>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).<p>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.
Firefox and Ubuntu: making sure that no-one ever again is confused whether or not FOSS might be usable for people who have other things to do than updating their software.