Part of the problem is how enterprise-y companies do things. Taking 3 months to roll out a new browser is ridiculous. But then, so is designing your website to only work on the most popular browser, and they do that, too.
Fix the latter and you can probably fix the former at the same time.
"Taking 3 months to roll out a new browser is ridiculous."
Unless you have pretty poor infrastructure, actually rolling out a new version should be trivial, it's the testing to confirm that the new version doesn't break anything vital that will take the time.
In my experience, there are few departments that have automated tests that could assist in shortening the testing cycle. If there is a bug with a new version of firefox then it will take 3 months to fix it because of the long development and deployment cycles exacerbated by a heavy bureaucracy.
Yeah, in an ideal world.... This is a really ignorant statement, though. Just one of my teams has a tracking spreadsheet for >100 web apps they support. A fair number of those are "legacy" -- created by folks who are no longer with the company, or which are no longer the standard way of performing a task -- but are unkillable for one reason or another. Besides homegrown stuff, certain versions of expensive commercial software only support specific browsers and versions of browsers. If you have to test, AND you have to setup GPOs for users at the app-level because of browser incompatibilities, it is completely understandable why the internal upgrade cycle can take longer than the vendor's upgrade cycle.
You should spend some time in enterprise IT and see what it's like on the other side of the fence.
That problem could be easily solved by having multiple browsers installed so that a user could chose one that works with a broken, legacy web app. IT departments could roll out two different browsers in a tick-tock manner.
If you think it's easy to teach users to intelligently choose among several different browsers for each of several web apps you've never worked in corporate IT before.
Users have already been taught to choose among different desktop apps. How? By clicking on installed shortcut links on their desktop. The same can be done with internal web apps.
Treat these legacy web apps just like desktop apps in that launching them requires clicking an icon specifically for that web app somewhere on their machine that opens the web app in the appropriate browser. Those browsers (like IE6) could be locked down to only work for certain URLs. For everything else, the user would then just need to use a more modern web browser such as Firefox 5.0.
An ambitious startup could find many other (and probably better) ways to solve this problem. The issue with legacy web apps that run only on IE6 always struck me as a potential business opportunity for any startup interested in targeting the enterprise space. With Firefox's recent shift to an accelerated release cycle, it has made this problem even more pronounce.
Can someone more knowledgeable describe why each new FF version breaks existing extensions? Can't FF have a more stable extension architecture?
Edit: though the idea that enterprise is useless may be dangerous. Each new FF user is worth maybe pennies or nothing at all in revenue to Mozilla, while enterprise 'seats' can get a nice premium.
In my experience, most extensions work just fine after an update without modifications even if they are marked as incompatible. The addon authors simply tend to set the version compatibility rather conservatively.
The issue is usually the extension creator's fault. It's left up the developer to say what versions your extension is compatible with - and usually that's left to just the current version.
For add-ons hosted by Mozilla, this is no longer left up to the developer. Mozilla will automatically scan add-ons for compatibility with new versions and update their metadata:
A few thoughts. First, Fx extensions are required to expose the versions that they work for. In many cases after a release extensions will work pretty well and just need to have the "working versions" updated.
The past Fx development model focused on cramming a ton of features in to the browser, then bumping the version number. This could be a pain because there were huge changes, extensions broke and were slow to be updated, users were nagged...
The new approach is to ship on a schedule: if a change is good, it goes into the RC; if it isn't ready, it stays out.
But this likely means that every "new version" won't contain nearly as many massive and possibly breaking changes. I think this should let extension developers keep up with development better.
It's very similar to Chrome's restricted extension APIs, which are the reason that Chrome extensions are not tied to a specific version. If you offer a restricted API, you just have to ensure that that API doesn't break between releases.
The problem is with existing Firefox extensions, which are able to use any API in the Mozilla platform, and touch every bit of the Firefox UI. They are essentially executed as if they were part of the browser itself. This approach offers near-unlimited power (you can do anything the browser code can do!) but makes compatibility difficult, since any change to any API can potentially break extensions. Thus extensions have to specify a maximum version of Firefox that they are compatible with.
This is both good and bad: it's good in that Firefox extensions are much more powerful than Chrome extensions, but it's bad in that the versioning and compatibility issues are a problem.
For Firefox 5, all extensions hosted on addons.mozilla.org were run through a compatibility checker, and if they didn't use any APIs that were impacted in the 4.0 -> 5.0 update, they were marked as compatible with Firefox 5 without any action on the author's part. This helped a lot, but unfortunately there are also a lot of extensions out there that are not hosted on addons.mozilla.org (such as Google Toolbar and other toolbars installed by third-party software, as well as corporate addons).
The entire notion of 'certifying' a browser is ridiculous anyway. This is how IT organization get 'stuck' still having IE 6 as the approved browser.
With all of the work going into web standards, agile processes, and automated testing, why is certification such a huge labor-intensive ordeal anymore?
I sympathize with both sides of the argument. Large organizations really do need a longer support and deployment cycle. If they adopt version ___ of a product, they need some assurance that it will be supported for a certain window of time. On the other hand, if you let "The Enterprise" dictate your development strategy, you will find yourself making faster horses rather than electric roadsters.
This might be a good opportunity for a business to sell support contracts with guaranteed life cycles for EOL'd versions of Firefox. That way, an enterprise shop could pick a version knowing that it will be supported for a year or two years or whatever they negotiate.
It isn't just large organizations that may be inconvenienced by rapid releases of major versions -- when I adopted FF5, a bunch of plugins stopped working. If that happens every 3-6 months, I'll probably stop using FF for daily work (Chrome is arguably better anyway). Of course, I'd still have to test in FF -- but that's a minor issue.
Maybe a system like Ubuntu's is needed here? Every two years or so designate a version as "LTS" and continue to support that branch with bugfixes for several years. I suppose that's not quite as Agile...
One the one hand, you can't really blame FF. Chrome is killing them with their quick release cycles, so they felt they needed to respond.
On the other hand, what options do enterprises have? Assuming they're currently using FF, they probably don't want to go back to IE. Chrome is out of the question for the same reason we're having this discussion, frequent releases. So, what's left? Safari on Windows? And too much is broken on Opera. So, I don't really think FF has much to fear in terms of losing existing enterprise customers.
It may stall adoption on the enterprise market, but if it brings them back in the consumer market, and it's a net gain, then it was a good move. After all, Mozilla's customers like Google are buying eyeballs wholesale, irrespective of them being enterprise or consumer users.
Just let Firefox freaking update itself, after all, Mozilla is more trustworthy than an IT department of debatable competency.
And what on earth are they doing in those internal apps that makes them incompatible between Firefox 3 and Firefox 5 ?
I do have an intranet app of reasonable complexity that was created using IExplorer 6 and the original Mozilla browser. It still works today, the same as it was working when I made it. That's what standards are for.
what though, if by total accident, that one webapp worked on FF 3.6 due to a bug in that borwser version?
That one webapp that some guy once created to make his life easier, that's not documented anywhere any more and that's now being used to do all accounting over even though nobody knows about it.
Now imagine you as the IT guy update Firefox from 3.6 to 4 and now that app breaks and with it the accounting department stops working.
Nobody will appreciate your "but... I didn't know that app was there" which is totally not the correct answer to "why the hell did you just break the accounting department?"
I have seen this happen. Maybe not at this scale, but it definitely did happen. No wonder IT people are scared of updating: If you don't do anything, everything will keep working, but you might piss off some web developers who you don't know. If you DO update, you may risk breaking some home-grown solution you didn't know about and you will be held responsible for all the damage caused.
Yes. That app shouldn't exist. Yes, it should be documented, yes it should not have bugs.
But it might exist, it might not be documented and it might have bugs. You. Just. Don't. Know.
Now don't get me wrong: I'm not one of these guys, mainly because I have not been burnt by this yet (and probably never will - 10 people company and I still know about everything that's going on), but I can certainly understand them.
Those are the tradeoffs of webapps. They're relatively portable and don't require manual deployment for every update but web tech moves fast. The good news is that today standards support is good enough across browsers that you should be able to write fairly durable apps if you don't push niche functionality too hard.
What you've described is where a company allows technical debt to crawl up their leg and bite them in the ass. Probably in the name of cost-cutting. They are free to:
* never upgrade
* do things The Right Way
I really don't understand this mentality where we have to bend over backwards for organizations that simply aren't interested in listening to the fucking professionals about how things should be done. Where after a decade of horsing around and allowing high turnover and changing direction every quarter suddenly Mozilla has to drop everything to accommodate some packet of assholes who don't like the direction their free tool is taking.
We've made entirely too big a deal out of getting everybody off old browsers. Don't like Firefox? Chrome? IE6 still exists. Feel free to use it for the next 50 years.
what though, if by total accident, that one
webapp worked on FF 3.6 due to a bug in that
borwser version?
It's not the browser's fault, it's the fault of the people who made that app.
Mozilla's responsibility is indeed to provide reasonable backwards compatibility, but as long as that behavior is specified in the standard or as long as it benefits lots and lots of people.
But it is also Mozilla's responsibility to advance the state of the art, to implement new emerging standards and to fix their broken implementation, if needed of course. And let me tell you - Mozilla almost lost me to Chrome.
I also think your argument doesn't hold water as I've never seen Firefox behave badly on upgrades, ever since version 2. Sure, there might have been an incompatibility here and there, but I never ran into one and if it was, it was easily detectable if you just executed your app in Opera, or Chrome, or Safari, or another non-Gecko browser.
However, I suspect that this fear-mongering is from "consultants" and IT staff that are paid for support contracts and testing new versions of Firefox was part of their billable hours. And now they'll have to do more work supposedly testing Firefox.
In a recent HN thread, someone correctly stated that Mozilla and Google are working the browser market like a tag team, not like competitors. In accordance with that view, I think it would have been more sensible for Mozilla to stay with their previous versioning scheme, and not call something 5.0 which really should have been 4.1, thus making a complementary offer to the user base, instead of doing it exactly like Chrome.
To my mind, this is mostly a culture clash. In no way is it "Enterprise Users" that FF is worried about; it's Enterprise IT guys.
Spoken as a startup executive who also wears the IT hat at times -- those guys can be fascist bastards. I don't really want to help them either. Well, I guess I'll erase this post when I do my next Group Policy-based startup. Until then, I stand by my statement.
Long ago, IT was there to help users work with something they couldn't understand. Now IT has sort of turned into that abusive controlling parent who too often says "you can't do this, because I don't like it."
Standard disclaimers apply: you are not like this, you are a great IT person.
That said, I think there is absolutely no chance that the Firefox team will, after significant internal effort to speed up and become more agile, slow down to please IT groups.
Organizations that are also learning to speed up will get benefits from FF or Chrome, others won't.
I do agree that plugin development issues are a serious pain point. I anticipate that they'll work out some better system (maybe a version API contract that tells a plugin what they can consume?).
I think this new development process will actually be a benefit for plugin authors. Each new version will come with fewer big changes, meaning that plugins may just keep working across different versions.
Of course, that benefit can only be realized if plugins are no longer tied to a version. A good solution is definitely needed here.
If you move a product from A to B where A is compatible with a plug-in and B isn't, it doesn't matter whether you do it in one step or 10 steps, it's still going to break at some point.
The positive for developers is that the smaller number of changes might make it easier to identify what's caused the problem and means that any particular release is less likely to cause a problem, the downside is that you have to retest it far more often and you have far more releases that might break something.
Overall it feels slightly (though not massively) worse for developers as the total overhead of basic test, release and so on increases.
Too many at one time for me. I'd much rather be able to follow the 5->6 release cycle and test my extension over a much smaller set of changes. Other devs may disagree, that's fine and worth discussion.
The key point IMO is that extension authors must be provided a way to indicate extension compatibility that isn't tied to the browser version number. The version is going to start iterating much faster, and popping up a "these extensions are broken!" box every few months will completely kill user confidence in extensions.
"I have 500,000 corporate users on Firefox 3.6. We just completing a test cycle of Firefox 4 on many thousands of internal business web applications"
I don't really get the problem? Firefox 4 is a browser that honours web standards. So if your web apps work on version 4, why shouldn't they on 5? Firefox won't drop JavaScript or the <table> element!?
This manager is not talking about extensions, he's talking about web apps.
I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. Even if so, the accelerated release cycle will ensure that it'll be fixed right away.
It's interesting -- when I have my software company that builds web apps hat on, I assume that if there's a rendering problem with a new browser, it's our problem: these guys lead the standards groups, so we fix our app as best we can, and remember that people are used to seeing occasionally broken stuff on the internet. Not the end of the world.
That's contrary to this point of view, and maybe just speaks to how IT and internal corporate application mindsets are different.
> when I have my software company that builds web apps hat on, I assume that if there's a rendering problem with a new browser, it's our problem
I used to assume that, but I've spent so much time in the past few months fixing silly bugs that really were regressions in mainstream browsers that my default is now to assume that if something works in two or three browsers but not another then they really have broken something. This is why I have been so critical of the rapid updates policy in various recent discussions.
For no browser in particular, or in some cases for several of them:
- Typography (text rendering that is actually illegible on some platforms, due to basic kerning issues, poor antialiasing when CSS3 effects are applied, misapplication of OpenType features, and so on)
- Java applets (outright crashing, or more annoying things like not quite passing keyboard/mouse events through properly)
- HTML5 video (which encoding shall we use this week?)
- CSS3 rounded corners and gradients (assorted rendering bugs that made these look awful if you'd relied on the new features)
All of these have been pushed in minor/point releases, with the exception of Google dropping H.264 video support, where they appear to have quietly done a U-turn at some point having made a big announcement that they were going to push it.
Well, neither of us know exactly what he's talking about, but clearly his organization does think testing on a new version is worthwhile enough to pay people to do it, which suggests they have been burnt by it in the past.
People who fiddle with their computers at home for fun really have no experience that carries over to supporting non-technical users who absolutely rely on in-house developed apps to do their work, and no-one gets paid if they can't.
>I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation.
You're giving the Firefox guys too much credit. Bugs do happen even in web browsers and not all corporate websites are made by people that don't know about programming or standards.
The thing is: somebody pays (sometimes a whole lot) to use an webapp and you have to guarantee that your site will work for him on a given browser version. This means you actually test the product in various ways. You can't just put blind trust into Firefox that is will just be perfect from now on.
>Even if so, the accelerated release cycle will ensure that it'll be fixed right away.
Yeah, and who pays for the downtime, losses, etc. in the mean time?
As an user I like Chrome and I see the value of having it autoupdate on my parent's computer so I don't have to manage that myself.
But in a corporation some pretty big money are starting to depend on browsers so you can't just believe new updates won't subtly break something.
While I don't dispute the honest good intentions here, I do, strongly, dispute the cost benefit analysis.
They're testing every last security fix, every last point release, every last sneeze from the platform vendors against everything in their entire app pool. That might've been viable Way Back When; now, I doubt it. There's just too much changing at too many levels. What about if the user combines this service pack with these security fixes but not that one, this particular browser release, running over a remote link with either a 3G modem or a home firewall and a particular model of router?
Bugs happen, both in the platform and in the app. I've had my code suddenly fail due to a new version before, too. Once, in ten years, and a dev team of two had a fix up and running in a few hours.
What's the cost to the business to run all this checking? What's the cost to the business to be running older, less secure, less featureful versions of the software?
What would be the cost of the likely scale of failure if they were broken by a new release (factoring in the very, very low likelihood of that happening)? What would be the business interruption cost of having the app down? What would be the opportunity cost of having to pull developers off their other projects and push them quickly onto fixing this internal app?
If it's an internal app, you've likely got a small enough, contained enough userbase that it's manageable for you to have a short period of downtime occasionally - I've never known such a service that didn't, frankly. If it's a public app, good luck to you trying to tell your customers they can't use this new version. If it's a third-party app, that's their problem. If Oracle want to tell me their latest, greatest, very expensive CRM dashboard isn't compatible with a new browser point release, exactly what am I paying them all that money for?
Stop being officious. Stop being risk averse beyond reason. Look at the actual numbers and just let it run.
I don't get your assertion. Is it that you don't really need to do testing the way your quoted manager did?
Have you any idea what you're talking about?
Have you any notion of the cost of downtime -- whether your company is big or small?
"pretty sure" and "rather unlikely" are absurd in this context.
I don't even understand what your point is? That Mozilla shouldn't do anything to cater to these scenarios because people should just deploy new versions on trust?
A lot of those internal apps hang by a thread with regard to cross-compatibility. Many large companies still live in IE6 land where change occurs on a geologic scale, and what's more that's sort of the way they want it.
As much as businesses like to bitch about IT costs the fact is that, for what they pay, most of them get a quite a lot of utility out of their poorly-budgeted and mismanaged IT departments. Even their talented developers are so overworked and underpaid and mismanaged that they churn out mostly garbage, but it's usually garbage that gets the job done right then. Anything more than that is always viewed as a luxury anyway, until you can't upgrade anymore because 10% of the internal apps misperform running under a newer JS implementation. Nevertheless, the business sees something better and thinks they might need it but they first have to wake up to the fact that OSS != free shit, and they don't like that at all. "What happens if they EOL FF5?" Well, you have the source, fix the problem yourself, that's how it works. You're a big organization, you got this amazing tool for absolutely nothing, give something back. If you can't accept those terms, fuck off back to IE land.
So Dotzler is absolutely right. There is no way his organization can please enterprise as they have impossible demands, so fuck them.
I really dislike this strawman and how it goes unchallenged. From my experience, its the IT guy who wants to move to Firefox, but finds no official MSI installer and no official group policy extensions difficult to work with on a day to day basis.
Mozilla is purposely shooting itself it the foot because it doesn't want to strain its OSS cred by appealing to MS environments and IT departments. Now compare this awful shortsighted attitude to Google's Chrome. Official MSI installer - check. Auto updating - Check. Auto updating of flash - Check. Group Policy - check. Secure sandboxing - check.
The narrative of Firefox isn't "the nerds vs the assholes in IT" its "OSS pigheadedness & zealotry vs basic convenience" and its amusing to see a more liberal project like Chrome eat its lunch.
I did read the original article. I still don't see any good reason why Mozilla is abandoning major releases in 3 months. Heaven forbid those 'assholes' in IT be allowed to do testing on any schedule other than the whims of Asa Dotzler.
The suggestion from Asa about someone starting a business version of FF is ridiculous on its face. Why bother dealing with FF and paying when IE9 is good enough? Especially with Chrome as an alternate browser? The dismissive neckbeard attitude doesn't win friends or marketshare. I wish more people understood this.
I also wish people would stop it with the double-standard. Imagine if MS pulled shit like this and responded like Asa did. Or if the Mysql guys did this and said 'update it every 3 months, if you dont like it then pay for Oracle.' Just incredible how much leeway we give Mozilla for some bizarre reason. Fanboys die hard, I guess.
That said, I think there is absolutely no chance that the Firefox team will, after significant internal effort to speed up and become more agile, slow down to please IT groups.
It's not the speed of development that's the problem; it's the speed of obsolescence. If they supported older versions for longer there wouldn't be a problem.
Nothing is free. You have so many hours of development time available. The more old versions you support, the less time you have available for new development.
The very fastest thing to do is to only suport the latest version. I'm not saying this is the best or right thing to do, just that there is a natural trade-off between supporting old versions and developing new functionality.
But if the release schedule is faster, and there is less in each release, then surely they can support more releases.
I'm assuming that the amount of code change relative to the latest release has more impact than the incremental burden of supporting each additional release.
I think this is functionally why the Chrome team hides the version number. They wanted it to be more like a utility, or web app. What version is your version of Hacker News running?
In order to get that kind of instant deployment for a distributable executable, you have to really solve distribution down the chain to (especially) the windows desktop. The Chrome guys did that, it rocks, and it works.
Versions probably originally existed to allow marketing teams to sell more. I wouldn't be surprised if FF eventually drops the version number thing and just has a 'stable' and 'exciting' branch type system for their users.
True, I'm vaguely aware that I run Chrome 13 (Stable) and Chrome 14 (Canary) for testing -- but I'm surprisingly vague on that awareness -- in fact I got it wrong (I thought it was 12 that was stable)
> I wouldn't be surprised if FF eventually drops the version number thing and just has a 'stable' and 'exciting' branch type system for their users.
That's pretty much what we're going for. The version number is still there, but we're phasing numbers out of the discussion when we talk about Firefox. There's the release channel, the beta channel, and the Aurora channel. There's also the Nightly channel and some projects builds (these sets are targeted at developers). Check out https://www.mozilla.com/en-US/firefox/channel/
And yes, we were definitely influenced by what Chrome is doing, though we've adjusted to what's going to work better for us.
The consumerization of IT goes both ways: people get the latest & greatest at home and want to bring it to work, but they often are trained to use interesting tech at work -- and become comfortable with it -- so they tend to use the same at home. If Mozilla doesn't change their tune, Google & Apple will eat their lunch.
Glad to see this. If Mozilla started chasing corporate then it would be necessary for me to switch browser. I've stuck with them through the misconceptions about memory from people who don't understand how memory management works. I've put up with slightly worse performance and standards support for enabling features I actually use like ad block.
However I would never tolerate kowtowing to the mishmash of nonsense that is corporate IT. I don't use IE for exactly this reason.
The simple truth is that if corporations need consistent behaviour they should not be using web apps to begin with.
Enterprises don't have time to be modern or forward thinking, they're too busy wrapped up in management process and business bullshit to concern themselves with upgrading the software on their corporate network.
I know this because I work as an enterprise developer in a large enterprise company. I can't wait until I die :)
The exec is right. Why should mozilla "slow down" to accommodate enterprises who churn out absurdly brittle applications and who change them literally only when a crisis forces them to do so.
It is the internal enterprise apps that need to "get with the program."
This article made me realize that to enterprises, what SaaS really sells is not the ease of (or lack of) deployment, but the disability for IT departments like these to control deployment at all.
I saw an interesting point in a scientific paper recently which I, admittedly, only got to read the abstract of (scientific journals are littered with paywalls). It basically stated that the corporation is a form of social technology which has failed society. When looking at the reality of the situation, in particular, how slowly they move and how much they tend to halt progress, I tend to agree with the sentiment. Just look at IE6 - the web would be a very different place if certain people weren't so obsessed with making money (by always taking the path of least risk) and making everyone else pay for the fact.
The question is not whether Mozilla should cater to enterprise users. The question is should Mozilla cater to internal enterprise applications which don't get updated very often and are easy to break.
now is the time for a third party organisation to step up and support designated firefox 3.6 or 4.0 releases. it might not be feasible for a company to do just this, but someone already in the business of supporting open source software could conceivably add firefox on to their product list.
You know, enterprise software is a funny thing. Every time a new version of say Firefox comes out, I get a bunch of emails at work saying that whatever version of SAP doesn't support it so please don't upgrade or face great peril.
Then there are older legacy products like Lotus Notes Domino web access that is the biggest pile of garbage when run outside of IE that I've ever seen. Heck, inside of IE it's still terrible.
Web software was supposed to make large scale software updates better, but thanks to "enterprise software" the whole thing is actually worse inside of enterprises. Go figure.
So I work for an "enterprise company", and if you install Firefox on your computer, it will be automatically removed within an hour, and an email will be sent to your manager. (Unfortunately, the same thing happens if you try to install IE 7 or later).
I'm not sure this is a market that they want to be in.
Or some legacy app requires admin rights just to work, so instead of locking down they scan for badness every hour. Of course, that won't help against something really bad.
The faster release cycles didn't bother me until I realized that with Google's new support announcement [1], that Firefox versions would officially only get about six months of support on Google Apps. And that I have no idea how Ubuntu's handling quicker releases.
Canonical's Jason Warner said Ubuntu will move to the latest stable version of Firefox if security updates for whatever version they are currently shipping stop [1].
The real problem here isn't the release cycle, it's the support cycle. Many open source apps that are used in enterprise settings (servers, mostly) get this right, and mark dedicated supported versions, for customers who can't or won't yet upgrade.
Mozilla could start doing this, and all of a sudden they'd be both accessible, but still able to do their release cycle as planned.
82 comments
[ 3.3 ms ] story [ 113 ms ] threadFix the latter and you can probably fix the former at the same time.
Unless you have pretty poor infrastructure, actually rolling out a new version should be trivial, it's the testing to confirm that the new version doesn't break anything vital that will take the time.
You should spend some time in enterprise IT and see what it's like on the other side of the fence.
Treat these legacy web apps just like desktop apps in that launching them requires clicking an icon specifically for that web app somewhere on their machine that opens the web app in the appropriate browser. Those browsers (like IE6) could be locked down to only work for certain URLs. For everything else, the user would then just need to use a more modern web browser such as Firefox 5.0.
An ambitious startup could find many other (and probably better) ways to solve this problem. The issue with legacy web apps that run only on IE6 always struck me as a potential business opportunity for any startup interested in targeting the enterprise space. With Firefox's recent shift to an accelerated release cycle, it has made this problem even more pronounce.
Edit: though the idea that enterprise is useless may be dangerous. Each new FF user is worth maybe pennies or nothing at all in revenue to Mozilla, while enterprise 'seats' can get a nice premium.
http://blog.mozilla.com/addons/2011/04/19/add-on-compatibili...
Apart from that, I think the new development process (http://mozilla.github.com/process-releases/draft/development...) makes it less likely that new versions will break extensions.
The past Fx development model focused on cramming a ton of features in to the browser, then bumping the version number. This could be a pain because there were huge changes, extensions broke and were slow to be updated, users were nagged...
The new approach is to ship on a schedule: if a change is good, it goes into the RC; if it isn't ready, it stays out.
But this likely means that every "new version" won't contain nearly as many massive and possibly breaking changes. I think this should let extension developers keep up with development better.
It's very similar to Chrome's restricted extension APIs, which are the reason that Chrome extensions are not tied to a specific version. If you offer a restricted API, you just have to ensure that that API doesn't break between releases.
The problem is with existing Firefox extensions, which are able to use any API in the Mozilla platform, and touch every bit of the Firefox UI. They are essentially executed as if they were part of the browser itself. This approach offers near-unlimited power (you can do anything the browser code can do!) but makes compatibility difficult, since any change to any API can potentially break extensions. Thus extensions have to specify a maximum version of Firefox that they are compatible with.
This is both good and bad: it's good in that Firefox extensions are much more powerful than Chrome extensions, but it's bad in that the versioning and compatibility issues are a problem.
For Firefox 5, all extensions hosted on addons.mozilla.org were run through a compatibility checker, and if they didn't use any APIs that were impacted in the 4.0 -> 5.0 update, they were marked as compatible with Firefox 5 without any action on the author's part. This helped a lot, but unfortunately there are also a lot of extensions out there that are not hosted on addons.mozilla.org (such as Google Toolbar and other toolbars installed by third-party software, as well as corporate addons).
With all of the work going into web standards, agile processes, and automated testing, why is certification such a huge labor-intensive ordeal anymore?
This might be a good opportunity for a business to sell support contracts with guaranteed life cycles for EOL'd versions of Firefox. That way, an enterprise shop could pick a version knowing that it will be supported for a year or two years or whatever they negotiate.
On the other hand, what options do enterprises have? Assuming they're currently using FF, they probably don't want to go back to IE. Chrome is out of the question for the same reason we're having this discussion, frequent releases. So, what's left? Safari on Windows? And too much is broken on Opera. So, I don't really think FF has much to fear in terms of losing existing enterprise customers.
It may stall adoption on the enterprise market, but if it brings them back in the consumer market, and it's a net gain, then it was a good move. After all, Mozilla's customers like Google are buying eyeballs wholesale, irrespective of them being enterprise or consumer users.
Just let Firefox freaking update itself, after all, Mozilla is more trustworthy than an IT department of debatable competency.
And what on earth are they doing in those internal apps that makes them incompatible between Firefox 3 and Firefox 5 ?
I do have an intranet app of reasonable complexity that was created using IExplorer 6 and the original Mozilla browser. It still works today, the same as it was working when I made it. That's what standards are for.
That one webapp that some guy once created to make his life easier, that's not documented anywhere any more and that's now being used to do all accounting over even though nobody knows about it.
Now imagine you as the IT guy update Firefox from 3.6 to 4 and now that app breaks and with it the accounting department stops working.
Nobody will appreciate your "but... I didn't know that app was there" which is totally not the correct answer to "why the hell did you just break the accounting department?"
I have seen this happen. Maybe not at this scale, but it definitely did happen. No wonder IT people are scared of updating: If you don't do anything, everything will keep working, but you might piss off some web developers who you don't know. If you DO update, you may risk breaking some home-grown solution you didn't know about and you will be held responsible for all the damage caused.
Yes. That app shouldn't exist. Yes, it should be documented, yes it should not have bugs.
But it might exist, it might not be documented and it might have bugs. You. Just. Don't. Know.
Now don't get me wrong: I'm not one of these guys, mainly because I have not been burnt by this yet (and probably never will - 10 people company and I still know about everything that's going on), but I can certainly understand them.
* never upgrade
* do things The Right Way
I really don't understand this mentality where we have to bend over backwards for organizations that simply aren't interested in listening to the fucking professionals about how things should be done. Where after a decade of horsing around and allowing high turnover and changing direction every quarter suddenly Mozilla has to drop everything to accommodate some packet of assholes who don't like the direction their free tool is taking.
We've made entirely too big a deal out of getting everybody off old browsers. Don't like Firefox? Chrome? IE6 still exists. Feel free to use it for the next 50 years.
Mozilla's responsibility is indeed to provide reasonable backwards compatibility, but as long as that behavior is specified in the standard or as long as it benefits lots and lots of people.
But it is also Mozilla's responsibility to advance the state of the art, to implement new emerging standards and to fix their broken implementation, if needed of course. And let me tell you - Mozilla almost lost me to Chrome.
I also think your argument doesn't hold water as I've never seen Firefox behave badly on upgrades, ever since version 2. Sure, there might have been an incompatibility here and there, but I never ran into one and if it was, it was easily detectable if you just executed your app in Opera, or Chrome, or Safari, or another non-Gecko browser.
However, I suspect that this fear-mongering is from "consultants" and IT staff that are paid for support contracts and testing new versions of Firefox was part of their billable hours. And now they'll have to do more work supposedly testing Firefox.
Spoken as a startup executive who also wears the IT hat at times -- those guys can be fascist bastards. I don't really want to help them either. Well, I guess I'll erase this post when I do my next Group Policy-based startup. Until then, I stand by my statement.
Long ago, IT was there to help users work with something they couldn't understand. Now IT has sort of turned into that abusive controlling parent who too often says "you can't do this, because I don't like it."
Standard disclaimers apply: you are not like this, you are a great IT person.
That said, I think there is absolutely no chance that the Firefox team will, after significant internal effort to speed up and become more agile, slow down to please IT groups.
Organizations that are also learning to speed up will get benefits from FF or Chrome, others won't.
I do agree that plugin development issues are a serious pain point. I anticipate that they'll work out some better system (maybe a version API contract that tells a plugin what they can consume?).
Of course, that benefit can only be realized if plugins are no longer tied to a version. A good solution is definitely needed here.
If you move a product from A to B where A is compatible with a plug-in and B isn't, it doesn't matter whether you do it in one step or 10 steps, it's still going to break at some point.
The positive for developers is that the smaller number of changes might make it easier to identify what's caused the problem and means that any particular release is less likely to cause a problem, the downside is that you have to retest it far more often and you have far more releases that might break something.
Overall it feels slightly (though not massively) worse for developers as the total overhead of basic test, release and so on increases.
Too many at one time for me. I'd much rather be able to follow the 5->6 release cycle and test my extension over a much smaller set of changes. Other devs may disagree, that's fine and worth discussion.
The key point IMO is that extension authors must be provided a way to indicate extension compatibility that isn't tied to the browser version number. The version is going to start iterating much faster, and popping up a "these extensions are broken!" box every few months will completely kill user confidence in extensions.
http://weblog.raganwald.com/2007/09/we-have-lost-control-of-...
I don't really get the problem? Firefox 4 is a browser that honours web standards. So if your web apps work on version 4, why shouldn't they on 5? Firefox won't drop JavaScript or the <table> element!?
As many others have said, extensions that work in 4 do not work in 5...
I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. Even if so, the accelerated release cycle will ensure that it'll be fixed right away.
That's contrary to this point of view, and maybe just speaks to how IT and internal corporate application mindsets are different.
I used to assume that, but I've spent so much time in the past few months fixing silly bugs that really were regressions in mainstream browsers that my default is now to assume that if something works in two or three browsers but not another then they really have broken something. This is why I have been so critical of the rapid updates policy in various recent discussions.
- Typography (text rendering that is actually illegible on some platforms, due to basic kerning issues, poor antialiasing when CSS3 effects are applied, misapplication of OpenType features, and so on)
- Java applets (outright crashing, or more annoying things like not quite passing keyboard/mouse events through properly)
- HTML5 video (which encoding shall we use this week?)
- CSS3 rounded corners and gradients (assorted rendering bugs that made these look awful if you'd relied on the new features)
All of these have been pushed in minor/point releases, with the exception of Google dropping H.264 video support, where they appear to have quietly done a U-turn at some point having made a big announcement that they were going to push it.
People who fiddle with their computers at home for fun really have no experience that carries over to supporting non-technical users who absolutely rely on in-house developed apps to do their work, and no-one gets paid if they can't.
You're giving the Firefox guys too much credit. Bugs do happen even in web browsers and not all corporate websites are made by people that don't know about programming or standards.
The thing is: somebody pays (sometimes a whole lot) to use an webapp and you have to guarantee that your site will work for him on a given browser version. This means you actually test the product in various ways. You can't just put blind trust into Firefox that is will just be perfect from now on.
>Even if so, the accelerated release cycle will ensure that it'll be fixed right away.
Yeah, and who pays for the downtime, losses, etc. in the mean time?
As an user I like Chrome and I see the value of having it autoupdate on my parent's computer so I don't have to manage that myself.
But in a corporation some pretty big money are starting to depend on browsers so you can't just believe new updates won't subtly break something.
They're testing every last security fix, every last point release, every last sneeze from the platform vendors against everything in their entire app pool. That might've been viable Way Back When; now, I doubt it. There's just too much changing at too many levels. What about if the user combines this service pack with these security fixes but not that one, this particular browser release, running over a remote link with either a 3G modem or a home firewall and a particular model of router?
Bugs happen, both in the platform and in the app. I've had my code suddenly fail due to a new version before, too. Once, in ten years, and a dev team of two had a fix up and running in a few hours.
What's the cost to the business to run all this checking? What's the cost to the business to be running older, less secure, less featureful versions of the software?
What would be the cost of the likely scale of failure if they were broken by a new release (factoring in the very, very low likelihood of that happening)? What would be the business interruption cost of having the app down? What would be the opportunity cost of having to pull developers off their other projects and push them quickly onto fixing this internal app?
If it's an internal app, you've likely got a small enough, contained enough userbase that it's manageable for you to have a short period of downtime occasionally - I've never known such a service that didn't, frankly. If it's a public app, good luck to you trying to tell your customers they can't use this new version. If it's a third-party app, that's their problem. If Oracle want to tell me their latest, greatest, very expensive CRM dashboard isn't compatible with a new browser point release, exactly what am I paying them all that money for?
Stop being officious. Stop being risk averse beyond reason. Look at the actual numbers and just let it run.
I don't get your assertion. Is it that you don't really need to do testing the way your quoted manager did?
Have you any idea what you're talking about?
Have you any notion of the cost of downtime -- whether your company is big or small?
"pretty sure" and "rather unlikely" are absurd in this context.
I don't even understand what your point is? That Mozilla shouldn't do anything to cater to these scenarios because people should just deploy new versions on trust?
As much as businesses like to bitch about IT costs the fact is that, for what they pay, most of them get a quite a lot of utility out of their poorly-budgeted and mismanaged IT departments. Even their talented developers are so overworked and underpaid and mismanaged that they churn out mostly garbage, but it's usually garbage that gets the job done right then. Anything more than that is always viewed as a luxury anyway, until you can't upgrade anymore because 10% of the internal apps misperform running under a newer JS implementation. Nevertheless, the business sees something better and thinks they might need it but they first have to wake up to the fact that OSS != free shit, and they don't like that at all. "What happens if they EOL FF5?" Well, you have the source, fix the problem yourself, that's how it works. You're a big organization, you got this amazing tool for absolutely nothing, give something back. If you can't accept those terms, fuck off back to IE land.
So Dotzler is absolutely right. There is no way his organization can please enterprise as they have impossible demands, so fuck them.
Mozilla is purposely shooting itself it the foot because it doesn't want to strain its OSS cred by appealing to MS environments and IT departments. Now compare this awful shortsighted attitude to Google's Chrome. Official MSI installer - check. Auto updating - Check. Auto updating of flash - Check. Group Policy - check. Secure sandboxing - check.
The narrative of Firefox isn't "the nerds vs the assholes in IT" its "OSS pigheadedness & zealotry vs basic convenience" and its amusing to see a more liberal project like Chrome eat its lunch.
That said, did you read the original article? Thousands of web apps need to be 're-certified'. This guy isn't installing Chrome in his office.
Full disclosure: I typed this in Chrome.
The suggestion from Asa about someone starting a business version of FF is ridiculous on its face. Why bother dealing with FF and paying when IE9 is good enough? Especially with Chrome as an alternate browser? The dismissive neckbeard attitude doesn't win friends or marketshare. I wish more people understood this.
I also wish people would stop it with the double-standard. Imagine if MS pulled shit like this and responded like Asa did. Or if the Mysql guys did this and said 'update it every 3 months, if you dont like it then pay for Oracle.' Just incredible how much leeway we give Mozilla for some bizarre reason. Fanboys die hard, I guess.
It's not the speed of development that's the problem; it's the speed of obsolescence. If they supported older versions for longer there wouldn't be a problem.
The very fastest thing to do is to only suport the latest version. I'm not saying this is the best or right thing to do, just that there is a natural trade-off between supporting old versions and developing new functionality.
I'm assuming that the amount of code change relative to the latest release has more impact than the incremental burden of supporting each additional release.
In order to get that kind of instant deployment for a distributable executable, you have to really solve distribution down the chain to (especially) the windows desktop. The Chrome guys did that, it rocks, and it works.
Versions probably originally existed to allow marketing teams to sell more. I wouldn't be surprised if FF eventually drops the version number thing and just has a 'stable' and 'exciting' branch type system for their users.
That's pretty much what we're going for. The version number is still there, but we're phasing numbers out of the discussion when we talk about Firefox. There's the release channel, the beta channel, and the Aurora channel. There's also the Nightly channel and some projects builds (these sets are targeted at developers). Check out https://www.mozilla.com/en-US/firefox/channel/
And yes, we were definitely influenced by what Chrome is doing, though we've adjusted to what's going to work better for us.
However I would never tolerate kowtowing to the mishmash of nonsense that is corporate IT. I don't use IE for exactly this reason.
The simple truth is that if corporations need consistent behaviour they should not be using web apps to begin with.
I know this because I work as an enterprise developer in a large enterprise company. I can't wait until I die :)
It is the internal enterprise apps that need to "get with the program."
EDIT: This paper - http://sts.sagepub.com/content/15/1/1.abstract
Then there are older legacy products like Lotus Notes Domino web access that is the biggest pile of garbage when run outside of IE that I've ever seen. Heck, inside of IE it's still terrible.
Web software was supposed to make large scale software updates better, but thanks to "enterprise software" the whole thing is actually worse inside of enterprises. Go figure.
I'm not sure this is a market that they want to be in.
[1] http://googleenterprise.blogspot.com/2011/06/our-plans-to-su...
[1] http://lwn.net/Articles/432360/
Mozilla could start doing this, and all of a sudden they'd be both accessible, but still able to do their release cycle as planned.