Mozilla Executive: We're Not Interested In Enterprise Level Users
pcmag.com
pcmag.com
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?).
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.
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.
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.
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.
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.
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.
http://weblog.raganwald.com/2007/09/we-have-lost-control-of-...
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.
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.
It is the internal enterprise apps that need to "get with the program."
I know this because I work as an enterprise developer in a large enterprise company. I can't wait until I die :)
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.
Fix the latter and you can probably fix the former at the same 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.
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.
EDIT: This paper - http://sts.sagepub.com/content/15/1/1.abstract
With all of the work going into web standards, agile processes, and automated testing, why is certification such a huge labor-intensive ordeal anymore?
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.
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.
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).
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.
http://blog.mozilla.com/addons/2011/04/19/add-on-compatibili...
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.
I'm not sure this is a market that they want to be in.
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.
what options do enterprises have?
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.
what though, if by total accident, that one
webapp worked on FF 3.6 due to a bug in that
borwser version?
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.
* 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.
[1] http://googleenterprise.blogspot.com/2011/06/our-plans-to-su...
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.