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

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.

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.

edit: Given how long mainframes have been around, is it really that much of a stretch to say that these kind of legacy web apps could still be around for a few years yet, if they're really integrated deep into an organization's processes?

Yep. Hence my comment "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"

IE6-only (and IE-only) exist in the enterprise. That doesn't really impact on the Firefox upgrade strategy, since people don't use Firefox to access them.

(Also, MS is slowly dropping support for operating systems supporting IE6. Enterprises are very reluctant to use unsupported operating systems.)

It would be pretty ironic, but thanks to HTML probably not that hard, to be screen scraping an IE only web app to make it available to other web browsers.

That's what makes them so hard to port - they aren't really webapps at all - just (old style, non .NET) client-server VB programs that happen to be deployed as ActiveX controls in a web page.

Instead of mandating everyone run IE6 from now to eternity, IT will provide a Citrix link to launch the crusty web app inside the controlled Citrix environment, and allow users to use more modern browsers by default.

Or so we can hope.

With that said though, except for high priority zero-days, we would actually roll ours up with our other patches so we can test them all together. There's only been a couple of times where we only did a smoke test and deploy def updates -- but we always do some testing on them. Always.

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.

Now that the pain point has been shifted it will soon become apparent to corporations that the current system is untenable, just as Chrome and Firefox discovered it was. The browsers couldn't change things except to pass the buck whereas the corporations can actually fix it, or be outcompeted by those that do (just as Firefox and IE were outcompeted by Chrome choosing this path).

The third option for big corps. is to bluster and try and frighten Firefox into acting more like IE than Chrome by claiming it will hurt adoption if they don't do what they want. You only have to look at the Chrome, IE and Firefox usage graphs over the last few years to see which way Firefox should be jumping.

If they are so brittle as to be this dependent upon browser versions, versus throw the new version on a machine and run it through your browser tests with say selenium, how can it be depended upon?

To me the root problem is internal web apps with atrocious testing, or more importantly lack thereof.

This probably applies as well.

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?

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

As more users adopt auto-updating browsers like Chrome (and hopefully soon, Firefox) and as browser market share spreads out, there may not be a single browser that is both terrible and widely-used. So there may be no economic reason for supporting the worst browsers.

And there will be much rejoicing.

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

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.

As an example. Run something like Test 262(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.

Your problem there is really with the standard...

But more importantly, intranet apps are not coded to standards to start with, so the whole discussion is moot.

Your argument about Intranet apps not coded to standards seems circular. If browsers (like Firefox) don't implement the standards properly, then how can Intranet apps code to standards? It has to start with browsers.

Yep. Support for all the new ES5 features... Doesn't guarantee that it's all bug-free, sadly. That said, you may be interested in the graph shown in http://blogs.msdn.com/b/ie/archive/2011/06/30/test262-indust... (ignoring for the moment the "start at 50%" inanity).

You may also be interested to note that changes continue to be made to the ES5 specification; the most recent ones happened just a few months ago. The whole moving target thing makes it hard to comply with all the edge cases at all times, obviously. I would not be surprised if there are now test262 tests that are testing the old language, and will need to be fixed just like browsers will need to be fixed.

> Your argument about Intranet apps not coded to standards > seems circular.

I wasn't making an argument; just stating a fact.

But note that the non-standard assumptions that intranet apps make are not even in the sort of things that 262test shows as broken in browsers: the latter tend to be somewhat esoteric due to the obvious fact that browsers sort of agree on the JS used on the web. But intranet apps tend to be coded to particular DOM quirks (in areas where the standard often doesn't define behavior to start with), particular HTML parsing quirks (until recently there was no standard for parsing HTML), and so forth.

Or put another way, intranet apps have a tendency to find situations where there is no behavior defined by a standard and depend on behavior in those situations, when the smart thing to do would be to avoid those situations entirely.

It's worse in most cases as there aren't fully built out tests, so it's even more difficult to converge implementations to the specifications.

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.

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.

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.

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.

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.

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

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.

My point is that it's not inherent in the notion of a browser that enterprises have to upgrade. IE is simply the existence proof.

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.

While most in the tech industry will not agree with me on this, but the inability to browse the general web would not be that grave of a detriment on the productivity of the enterprise.

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.

This is necessary, but not sufficient. Another big thing they need to do is to not break code, even if intentional. Probably the bigget thing they can do here is to not introduce "experimental" features, and then tweak them over time. The way a lot of devs work, whether you like it or not, is to find a feature from the web that solves their problem, put it in their code and test it on their current browser. If it works then they're happy. Three months later when that feature changes, because the feature isn't finalized anyways, you now have a bunch of apps this guy wrote that just broke.

It's not a matter of whether I like it, it's a matter of whether those people remain employed. It would be ridiculous to hold off on new features until they're fully supported just because of the unprofessionalism of some enterprise web devs.

> Probably the bigget thing they can do here is to not introduce "experimental" features, and then tweak them over time.

See, what we're talking about here in practice is the web standards development process. Currently it is collaborative and driven by experimentation, dialogue and feedback from the field. It has proven to be immensely successful in assuring cross-browser compatibility. What you're suggesting instead is a traditional software development approach where any relevant standards are either already nailed down, proprietary or made irrelevant by monopoly. This may have worked for Microsoft in the past. It's not going to work now.

Of course they remain employed. Why? Because these browsers simply won't be used. It'a easier to fix the problem by not changing browsers than trying to hire the all-star enterprise dev team.

What you're suggesting instead is a traditional software development approach where any relevant standards are either already nailed down, proprietary or made irrelevant by monopoly.

Indeed I am. The enterprise isn't concerned with Mozilla doing something interesting with the web. That's not their business. That's up to Mozilla to figure out how to get it done right. GE could careless about Mozilla. If Mozilla ships a browser that works best for GE then they'll use it. If not, they won't. I think the answer is for the vast majority of enterprises now and in the future, they'll simply not use FF. Mozilla appears to actually want it that way. Everyone seems to be happy.

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.

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.

I figure if I'm going to do a rewrite I might as well go down the NPAPI path (via http://www.firebreath.org/) as then I can pick up Chrome.

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 fail to see why it is offensive to suggest that extension developers use this time.

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.

(This is especially a bummer for those using Linux desktops.)

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.

Neither of those claims have proved true in the past.

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.

The problem here is poorly written web apps, and not mozilla.

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.

Then you can keep the main desktop browsers up to date without worrying about frequent regression testing.

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"! :)

Mozilla developers needs to be thinking about more than what is convenient for Mozilla developers. There's a whole of eco-system of add-ons, themes, etc that other people provide that makes for Mozilla you are going to be breaking every couple of months now.

I think of any software an OS would benefit the most from a timed release schedule. Ref: Linux/*BSD, don't ref: Hurd.