

Firefox update policy: the enterprise is wrong, not Mozilla - abraham
http://arstechnica.com/business/news/2011/06/firefox-update-policy-the-enterprise-is-wrong-not-mozilla.ars

======
nl
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-
upd...](http://arstechnica.com/software/news/2010/03/bitdefender-update-
breaks-64-bit-windows-pcs.ars)

[2] [http://www.techgeekandmore.com/tag/ca-anti-virus-update-
brea...](http://www.techgeekandmore.com/tag/ca-anti-virus-update-breaks-
windows/)

[3] [http://simonedwards.blogspot.com/2010/04/mcafee-anti-
virus-u...](http://simonedwards.blogspot.com/2010/04/mcafee-anti-virus-update-
breaks-pcs.html)

~~~
barrkel
What if a business on the edge goes bankrupt because their internal web apps
stop working?

~~~
zcid
It's hard to blame the straw when the camel's back breaks.

~~~
william42
I read that as "It's hard to blame the straw man when the camel's back
breaks."

This probably applies as well.

------
mindcrime
_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?

~~~
SoftwareMaven
I really, REALLY hope this does not happen. We don't need FF4 to be the next
IE6!

~~~
mindcrime
Something's gotta be "the next IE6"!

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

~~~
ZoFreX
It's obviously going to be IE8. Anyone can upgrade from 7 to 8, but to upgrade
to 9 you have to be running something more modern than XP, which isn't going
away anytime soon.

~~~
T-hawk
Indeed. XP itself is a major reason IE6 hangs around so much. XP installation
discs and images only ever came with IE6, never anything newer. And with the
frequency that most corporate workstations get reassigned and recreated and
reinstalled, IE6 comes out of its casket all the time. It's not that these
corps are scared or ignorant of upgrading past IE6, it's that doing so across
100 or 10,000 machines is a huge task and not worthwhile from a cost-benefit
standpoint.

~~~
ZoFreX
Have you ever worked in that sort of environment? "doing so across 100 or
10,000 machines is a huge task and not worthwhile from a cost-benefit
standpoint" contradicts my own experiences.

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

~~~
zeddez
I am not sure that is true any more.

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.

~~~
bzbarsky
And how many of those are things where ES5 changed behavior from ES3 and
Firefox still implements the ES3 behavior?

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.

~~~
zeddez
On the Mozilla technology page <http://www.mozilla.com/en-
US/firefox/technology/> it specifically calls out ES5 support. There is no
qualifier, so I am assuming that they believe they are fully supporting it.

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.

~~~
bzbarsky
> it specifically calls out ES5 support.

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...](http://blogs.msdn.com/b/ie/archive/2011/06/30/test262-industry-
javascript-standards-test-available.aspx) (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.

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

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

~~~
kenjackson
_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._

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.

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

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.

~~~
kenjackson
_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._

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.

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

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

~~~
potch
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
Is it safe to assume that every release is going to require binary XPCOM
components to be rebuilt?

~~~
joedrew
Yes. We make no guarantees _whatsoever_ on binary compatibility between
versions.

~~~
cbf
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.)

~~~
dochtman
Curious what you want to do... Maybe extend js-ctypes so that it'll do what
you want?

~~~
cbf
I use an API that you pass a callback into and get an fd in response. You then
monitor the fd and invoke a process function when there's something to read
which results in your callback being fired with results. I haven't checked js-
ctypes for some time so I could be wrong about this type of thing not being
possible with it.

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.

------
Adam503
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
Evernote will hopefully learn to adapt to upcoming changes in advance.

~~~
aristidb
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
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).

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

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

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

------
justinph
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
If you coded the App correctly as per the HTML Spec would a browser upgrade
cause such problems?

~~~
Mavrik
Assuming the HTML spec doesn't change and browser isn't buggy.

Neither of those claims have proved true in the past.

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

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

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

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

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

~~~
Adam503
How are Mozilla developers like you going to keep my Evernote add-on working
in Mozilla now? You guys will be breaking all the add-ons every 3 months, too.

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.

~~~
robin_reala
It’s 6 weeks, not 3 months. Still, addons that are hosted on
addons.mozilla.org are now automatically tested. Ones that don’t touch code
that changed in that release timeframe have their max version automatically
increased.

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

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

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

