9 ms·

Firefox update policy: the enterprise is wrong, not Mozilla

134 points by abraham 15y ago

ender7 15y ago
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.
- hollerith 15y ago
  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.
  - billybob 15y ago
    I don't see how the web is getting worse at sharing text. If anything, HTML5 makes it possible to mark up text in a more semantic way, improving access for screen readers for the blind, for example. The fact that people CAN embed movies and audio does not prevent them from posting text. Nor are increasing RAM requirements a problem if you consider the market. I just checked Dell's site, and you can't even buy a laptop with less than 1GB of RAM right now, but you can get more than 16GB.
    - hollerith 15y ago
      >I don't see how the web is getting worse at sharing text. I already gave some reasons, and here is one more: if the web had stayed a means of sharing text and images, it would not be one of the most popular ways for attackers to get control of a desktop computer.
  - bxr 15y ago
    >I worry that rapidly improving the web's ability to deploy applications will make it less suitable for reading and writing. Will make it? It already has. The web as we know it is a fucking unfettered mess. We've just been jamming applications into a document format so hard for so long we're used to it. You are right though, its going to get a lot worse. We need a new platform. We're probably not going to get one, the "web" is just going to expand to engulf every bit of functionality a new platform would have, but bring along over two decades worth of evolutionary cruft. I've resolved to just stay out of the way, not fight the inevitable.
  - bzbarsky 15y ago
    As a counterpoint, the next version of Firefox has support for automatic hyphenation, at least if the author asks for it. It could ship in August of this year (as currently planned), or it could ship a year and a half from now (the old schedule). Which do you prefer? Which do enterprises prefer?
nradov 15y ago
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.
gry 15y ago
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.
zeddez 15y ago
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.
mindcrime 15y ago
the enterprise is wrong, not Mozilla 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?
- thedeuce 15y ago
  Why should enterprises pay someone else for support when they can get that in IE(x) with the version of windows they paid to have on said workstation? Honestly it seems like mozilla is pulling out the carpet from enterprises, even tho it was those same enterprises mozilla at one time hoped would bring them market share. This is why so many people have a hard time trusting open source, a perfect example of hidden costs.
- SoftwareMaven 15y ago
  I really, REALLY hope this does not happen. We don't need FF4 to be the next IE6!
  - mindcrime 15y ago
    Something's gotta be "the next IE6"!
    - threepointone 15y ago
      From my experience, the next IE6 is IE7/IE8. They both have the strangest quirks. (as a random example, in IE7, try setting the hash of an iframe, from an iframe inside of that, and if they're on different domains. It... opens up a new window?! And the fix for this is to have another iframe inside that inner iframe which is the same domain as the iframe you want to set the hash on, and from that, do parent.parent.location='#whatever'; %^$^&$#@$&) (and in IE8, WHY does postMessage not work properly across popups opened up from iframes? WHY.) Bah.
cpeterso 15y ago
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...
- pseudonym 15y ago
  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?
- zeddez 15y ago
  This was not the best way to ease users into the new Firefox versioning and the associated benefits. 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 15y ago
  8 weeks, not three months. But yes, Firefox 5 is EOL once Firefox 6 is released.
nl 15y ago
This article is right. 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-update-breaks-64-bit-windows-pcs.ars http://arstechnica.com/software/news/2010/03/bitdefender-upd... [2] http://www.techgeekandmore.com/tag/ca-anti-virus-update-breaks-windows/ http://www.techgeekandmore.com/tag/ca-anti-virus-update-brea... [3] http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-update-breaks-pcs.html http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-u...
- kenjackson 15y ago
  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. It's really just not the same thing at all.
  - nl 15y ago
    At enterprises its not uncommon that even dot releases break some apps. In my experience (nearly 15 years in enterprise development) this isn't the case at all. It used to be the case, especially with apps that used plugins or Java (both of which were common in the early 2000s), but for the most part these apps have gone now. I think it is very, very unlikely that any non-client-Java webapp that runs in Firefox 3.x will break in any significant way in any future release.
natesm 15y ago
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?)
- kijinbear 15y ago
  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.
  - deleted 15y ago
    [deleted]
  - zeddez 15y ago
    I am not sure that is true any more. As an example. Run something like Test 262(http://test262.ecmascript.org/ http://test262.ecmascript.org/) which is the official test suite for JavaScript 5 and you'll see how many compatibilitiy issues there are just for this single spec in Firefox. It's in the hundreds. Anyone of these could potentially break an app. And that is just for one of the many specs in Firefox.
    - kijinbear 15y ago
      Theoretically, you're right. But how many "enterprise" intranet apps actually make use of cutting-edge HTML5 and JS5 features?
      - 15y ago
muyyatin 15y ago
Money quote: "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 15y ago
  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.
  - noibl 15y ago
    > As enterprises have shown, you can stick with the same major version of a browser for years As the article points out, it is only really true of IE -- the 'enterprise-friendly' browser -- that feature updates are accompanied by major version change. It's somewhat disingenuous to generalise that to 'a browser' when most browser makers have found that release model to be inadequate and their growing market share bears them out. > w/o any degredation in the core business. There's a conflation here, by enterprise, between browser-as-client for in-house apps and browser-as-web-browser. If your test for degradation is that the in-house apps continue to work then sure, that's verifiable. But if you acknowledge that the same program is used for both purposes then you would find it much harder to show that no degradation of user experience and productivity have occurred. --- I personally think the success or failure of the rolling release model with separate streams for early adopters depends entirely on the QA standards of the vendor. Google has shown that with stringent QA, this model can help greatly in catching bugs before the mainstream user is exposed to them. This is what inspires the confidence that allows people to accept silent push updates. If Mozilla can be as effective in quarantining bugs before general release then they will earn the same level of trust. But if they're not able to keep major bugs out of the limelight using this process, it's going to be extremely counterproductive. I worry that they're just not militant enough about QA to make this work.
tolmasky 15y ago
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.
- cbf 15y ago
  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.
- Bo102010 15y ago
  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."
- ZeroGravitas 15y ago
  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.
- smackfu 15y ago
  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.)
mwexler 15y ago
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.
tlianza 15y ago
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.
- sid0 15y ago
  AMO auto-bumps versions for addons that pass through automated checks.
- potch 15y ago
  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.
  - cbf 15y ago
    Is it safe to assume that every release is going to require binary XPCOM components to be rebuilt?
    - joedrew 15y ago
      Yes. We make no guarantees whatsoever on binary compatibility between versions.
      - cbf 15y ago
        Okay, thanks - has bundling an NPAPI plugin with an extension got a future? (js-ctypes can't do what I want so it seems like the next best thing.)
flocial 15y ago
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.
- yuhong 15y ago
  There is the Firefox x for developer documents which Mozilla publishes in advance: https://developer.mozilla.org/en/Firefox_6_for_developers https://developer.mozilla.org/en/Firefox_6_for_developers
- joedrew 15y ago
  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"! :)
  - mitchty 15y ago
    Weeeeel, osx was on an 18 month cycle of releases up until about 10.5ish. Then they toned it down, mainly I think due to there not being much to do oswise. (COUGH, memory dedup in the vm subsystem COUGH). I think of any software an OS would benefit the most from a timed release schedule. Ref: Linux/*BSD, don't ref: Hurd.
  - Adam503 15y ago
justinph 15y ago
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.
suprgeek 15y ago
If you coded the App correctly as per the HTML Spec would a browser upgrade cause such problems?
- cpeterso 15y ago
  Assuming browsers correctly implement the HTML spec.
- Mavrik 15y ago
  Assuming the HTML spec doesn't change and browser isn't buggy. Neither of those claims have proved true in the past.
Adam503 15y ago
Firefox isn't just killing their Enterprise customers. This is going to hurt all the users who like to use add-ons with Firefox. 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 15y ago
  Evernote will hopefully learn to adapt to upcoming changes in advance.
  - danssig 15y ago
    Or they can see how many of their users are using FF and decide if it's worth hiring a "upgrade response" team just for chasing Mozilla's tail. Personally, if I wasn't getting enough money from FF users I would just drop the whole platform and stick with something more stable.
  - aristidb 15y ago
    Firefox is not developed in secret. It is possible to see which breaking changes will probably be included before it is actually released. Mozilla is probably also willing to discuss changes with extension developers. I fail to see why it is offensive to suggest that extension developers use this time.
    - tlianza 15y ago
      It's because it's a colossal waste of time. Instead of Mozilla using a rational versioning policy, whereby major versions mean major changes, you're wasting everyone in the ecosystem's time instead (thousands of people's time, as opposed to a handful).
  - adamc 15y ago
    Or they will learn that supporting Firefox is expensive and that they should steer users to another browser.
aristidb 15y ago
Testing can be done on pre-release browsers, which would also allow problems to be fixed before the release.
mseebach 15y ago
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.
jpr 15y ago
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.
alxeder 15y ago
isn't the main benefit for deployment over browser a fast update process? So when you don't want to update often you miss the point
pornel 15y ago
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.

134 points by abraham 15y ago

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.

hollerith 15y ago
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.
- billybob 15y ago
  I don't see how the web is getting worse at sharing text. If anything, HTML5 makes it possible to mark up text in a more semantic way, improving access for screen readers for the blind, for example. The fact that people CAN embed movies and audio does not prevent them from posting text. Nor are increasing RAM requirements a problem if you consider the market. I just checked Dell's site, and you can't even buy a laptop with less than 1GB of RAM right now, but you can get more than 16GB.
  - hollerith 15y ago
    >I don't see how the web is getting worse at sharing text. I already gave some reasons, and here is one more: if the web had stayed a means of sharing text and images, it would not be one of the most popular ways for attackers to get control of a desktop computer.
- bxr 15y ago
  >I worry that rapidly improving the web's ability to deploy applications will make it less suitable for reading and writing. Will make it? It already has. The web as we know it is a fucking unfettered mess. We've just been jamming applications into a document format so hard for so long we're used to it. You are right though, its going to get a lot worse. We need a new platform. We're probably not going to get one, the "web" is just going to expand to engulf every bit of functionality a new platform would have, but bring along over two decades worth of evolutionary cruft. I've resolved to just stay out of the way, not fight the inevitable.
- bzbarsky 15y ago
  As a counterpoint, the next version of Firefox has support for automatic hyphenation, at least if the author asks for it. It could ship in August of this year (as currently planned), or it could ship a year and a half from now (the old schedule). Which do you prefer? Which do enterprises prefer?

nradov 15y ago

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.

gry 15y ago

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.

zeddez 15y ago

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.

mindcrime 15y ago

the enterprise is wrong, not Mozilla 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?

thedeuce 15y ago
Why should enterprises pay someone else for support when they can get that in IE(x) with the version of windows they paid to have on said workstation? Honestly it seems like mozilla is pulling out the carpet from enterprises, even tho it was those same enterprises mozilla at one time hoped would bring them market share. This is why so many people have a hard time trusting open source, a perfect example of hidden costs.
SoftwareMaven 15y ago
I really, REALLY hope this does not happen. We don't need FF4 to be the next IE6!
- mindcrime 15y ago
  Something's gotta be "the next IE6"!
  - threepointone 15y ago
    From my experience, the next IE6 is IE7/IE8. They both have the strangest quirks. (as a random example, in IE7, try setting the hash of an iframe, from an iframe inside of that, and if they're on different domains. It... opens up a new window?! And the fix for this is to have another iframe inside that inner iframe which is the same domain as the iframe you want to set the hash on, and from that, do parent.parent.location='#whatever'; %^$^&$#@$&) (and in IE8, WHY does postMessage not work properly across popups opened up from iframes? WHY.) Bah.

cpeterso 15y ago

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...

pseudonym 15y ago
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?
zeddez 15y ago
This was not the best way to ease users into the new Firefox versioning and the associated benefits. 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 15y ago
8 weeks, not three months. But yes, Firefox 5 is EOL once Firefox 6 is released.

nl 15y ago

This article is right. 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-update-breaks-64-bit-windows-pcs.ars http://arstechnica.com/software/news/2010/03/bitdefender-upd... [2] http://www.techgeekandmore.com/tag/ca-anti-virus-update-breaks-windows/ http://www.techgeekandmore.com/tag/ca-anti-virus-update-brea... [3] http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-update-breaks-pcs.html http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-u...

kenjackson 15y ago
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. It's really just not the same thing at all.
- nl 15y ago
  At enterprises its not uncommon that even dot releases break some apps. In my experience (nearly 15 years in enterprise development) this isn't the case at all. It used to be the case, especially with apps that used plugins or Java (both of which were common in the early 2000s), but for the most part these apps have gone now. I think it is very, very unlikely that any non-client-Java webapp that runs in Firefox 3.x will break in any significant way in any future release.

natesm 15y ago

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?)

kijinbear 15y ago
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.
- deleted 15y ago
  [deleted]
- zeddez 15y ago
  I am not sure that is true any more. As an example. Run something like Test 262(http://test262.ecmascript.org/ http://test262.ecmascript.org/) which is the official test suite for JavaScript 5 and you'll see how many compatibilitiy issues there are just for this single spec in Firefox. It's in the hundreds. Anyone of these could potentially break an app. And that is just for one of the many specs in Firefox.
  - kijinbear 15y ago
    Theoretically, you're right. But how many "enterprise" intranet apps actually make use of cutting-edge HTML5 and JS5 features?
    - 15y ago

muyyatin 15y ago

Money quote: "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 15y ago
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.
- noibl 15y ago
  > As enterprises have shown, you can stick with the same major version of a browser for years As the article points out, it is only really true of IE -- the 'enterprise-friendly' browser -- that feature updates are accompanied by major version change. It's somewhat disingenuous to generalise that to 'a browser' when most browser makers have found that release model to be inadequate and their growing market share bears them out. > w/o any degredation in the core business. There's a conflation here, by enterprise, between browser-as-client for in-house apps and browser-as-web-browser. If your test for degradation is that the in-house apps continue to work then sure, that's verifiable. But if you acknowledge that the same program is used for both purposes then you would find it much harder to show that no degradation of user experience and productivity have occurred. --- I personally think the success or failure of the rolling release model with separate streams for early adopters depends entirely on the QA standards of the vendor. Google has shown that with stringent QA, this model can help greatly in catching bugs before the mainstream user is exposed to them. This is what inspires the confidence that allows people to accept silent push updates. If Mozilla can be as effective in quarantining bugs before general release then they will earn the same level of trust. But if they're not able to keep major bugs out of the limelight using this process, it's going to be extremely counterproductive. I worry that they're just not militant enough about QA to make this work.

tolmasky 15y ago

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.

cbf 15y ago
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.
Bo102010 15y ago
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."
ZeroGravitas 15y ago
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.
smackfu 15y ago
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.)

mwexler 15y ago

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.

tlianza 15y ago

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.

sid0 15y ago
AMO auto-bumps versions for addons that pass through automated checks.
potch 15y ago
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.
- cbf 15y ago
  Is it safe to assume that every release is going to require binary XPCOM components to be rebuilt?
  - joedrew 15y ago
    Yes. We make no guarantees whatsoever on binary compatibility between versions.
    - cbf 15y ago
      Okay, thanks - has bundling an NPAPI plugin with an extension got a future? (js-ctypes can't do what I want so it seems like the next best thing.)

flocial 15y ago

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.

yuhong 15y ago
There is the Firefox x for developer documents which Mozilla publishes in advance: https://developer.mozilla.org/en/Firefox_6_for_developers https://developer.mozilla.org/en/Firefox_6_for_developers
joedrew 15y ago
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"! :)
- mitchty 15y ago
  Weeeeel, osx was on an 18 month cycle of releases up until about 10.5ish. Then they toned it down, mainly I think due to there not being much to do oswise. (COUGH, memory dedup in the vm subsystem COUGH). I think of any software an OS would benefit the most from a timed release schedule. Ref: Linux/*BSD, don't ref: Hurd.
- Adam503 15y ago

justinph 15y ago

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.

suprgeek 15y ago

If you coded the App correctly as per the HTML Spec would a browser upgrade cause such problems?

cpeterso 15y ago
Assuming browsers correctly implement the HTML spec.
Mavrik 15y ago
Assuming the HTML spec doesn't change and browser isn't buggy. Neither of those claims have proved true in the past.

Adam503 15y ago

Firefox isn't just killing their Enterprise customers. This is going to hurt all the users who like to use add-ons with Firefox. 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 15y ago
Evernote will hopefully learn to adapt to upcoming changes in advance.
- danssig 15y ago
  Or they can see how many of their users are using FF and decide if it's worth hiring a "upgrade response" team just for chasing Mozilla's tail. Personally, if I wasn't getting enough money from FF users I would just drop the whole platform and stick with something more stable.
- aristidb 15y ago
  Firefox is not developed in secret. It is possible to see which breaking changes will probably be included before it is actually released. Mozilla is probably also willing to discuss changes with extension developers. I fail to see why it is offensive to suggest that extension developers use this time.
  - tlianza 15y ago
    It's because it's a colossal waste of time. Instead of Mozilla using a rational versioning policy, whereby major versions mean major changes, you're wasting everyone in the ecosystem's time instead (thousands of people's time, as opposed to a handful).
- adamc 15y ago
  Or they will learn that supporting Firefox is expensive and that they should steer users to another browser.

aristidb 15y ago

Testing can be done on pre-release browsers, which would also allow problems to be fixed before the release.

mseebach 15y ago

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.

jpr 15y ago

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.

alxeder 15y ago

isn't the main benefit for deployment over browser a fast update process? So when you don't want to update often you miss the point

pornel 15y ago

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.