What's interesting is that in the past the approach corporations have taken to browsers is that they wait for the browser to be released, then test it in their environment to see whether it broke anything.

This is as opposed to testing the beta to see whether it's breaking anything and if so report a bug to the browser vendor so the final release _won't_ break anything.

Just making that one change to their rollout process would significantly reduce the breakage potential of updates....

Exactly, companies want a lot of stuff, but that doesn't mean they should get it.

> My point is that it's not black and white unless Mozilla chooses to make it that way. Right now, it's white. For Mozilla to say: "Infinite incremental release is the way forward" is to say, "We don't care about your ability to plan releases in any way shape or form." That's pretty black & white. Any commitment to a release schedule would, at least, give them the ability to plan.

Asking for a release timeline and asking for 3 years of support on a dead branch are entirely separate things. It's not unreasonable to ask the Mozilla keep users informed of the release schedule (don't they already do this?), but asking them to support an old version for 3 years seems silly. It takes a lot of manpower and there's no value in it for probably 95% of their customers.

> I agree that web browsers are not synonymous with word processing software, but the expectation that large corporations will simultaneously adopt web based technologies while throwing out decades of change-management process is just naivety at it's finest.

I would say it's practical, not naive. If you want a browser that allows you to stagnate while enjoying long-term support, then either start paying someone for support, or start using IE. You agree that web browsers and word processors are different, so why should Mozilla bend over backwards to allow corporations to try to treat them the same?

> Large organizations benefit from economies of scale. This means reduced costs. This means one IT manager per five hundred PCs. This means you can't roll out software willy-nilly and expect your organization to stand. Any in-roads Mozilla gained with corporations will be quickly squandered if they stick to this strategy.

Sure, so don't roll out willy-nilly. Test and then roll out, just as they do now. But instead of rolling out 4.1, roll out 5.0. I don't understand what the big issue is. I'm sure it's a bit more work if there's a breaking change, but frankly you're going to have to deal with those breaking changes eventually unless you're going to stick with the same browser for years (let's call this the IE6 model). You just deal with them incrementally rather than in one massive painful push. Frankly the incremental approach sounds less painful for everyone involved.

We're talking about corporations demanding that a free product meet their antiquated needs. There's no grounds for the demand. It reflects their broken rollout policies, not a deficiency on the part of Mozilla. Maybe if it takes you several months to approve a browser rollout, that's your real problem. And let's be honest, a lot of this is just baseless fear. We're talking about a change in the way version numbers are incremented. People are worrying because it's called 5.0 instead of 4.1. The number attached doesn't really matter.

> Again, I agree that the old pattern is not what we need, but this is upheaval, and that's not what works at corporations.

What else would work? For Mozilla to dedicate a lot of extra resources to maintaining dead branches for years? Not only does this not help move corporations forward, it doesn't help Mozilla, and it doesn't help the web.

If the current change management models are not working, then they need to be fixed. Test and rollout faster and more frequently. Roll out in stages, rather than with the "big bang" model. Have a roll-back plan and system in place. Really, the way people talk, it's as if every week the browser is going to break half the web. I hardly think that's the case, and I frankly think Mozilla's testing is probably more thorough than most any corporate IT department.

I don't entirely disagree with most of what you said, but I think you underestimate the challenges. I own a small start-up, so I know how nice it is to operate at a small scale. I let my employees chose their own browser, but I require that they keep it up to date. I can do that because I don't have to worry about supporting 500 people.

I've also consulted for very large corporations. The same disruptive ideology that applies to start-ups falls flat with large corporations. The biggest mistake is to take a unilateral position with them. They will fall back to IE. They will stagnate on old versions if we don't work with them. Is that what you want?

Maybe your product can avoid the corporate space altogether, but there are a lot of us who rely on them. I don't want to re-live IE6. I want browser makers to acknowledge that changing the corporate world isn't the same as creating Google or Facebook. It's far less glamorous and usually means doing shit in a way that you don't like for longer than you like. Change is coming, but it's coming slowly.

I hate line-item rebuttals, because they just turn in to pissing matches, but I did want to offer some clarification on these two points.

> Asking for a release timeline and asking for 3 years of support on a dead branch are entirely separate things. It's not unreasonable to ask the Mozilla keep users informed of the release schedule (don't they already do this?), but asking them to support an old version for 3 years seems silly. It takes a lot of manpower and there's no value in it for probably 95% of their customers.

Let me clarify: I don't think 3 years is a viable LTS schedule for browsers. I don't know what the time frame is, but I'm sure it's not 3 years, and I'm sure it's not "We release continuously." I should have been more clear about what "similar" means when referencing Ubuntu. By similar, I mean that they should continue their march forward, but that there should be an occasional LTS release that is maintained for a longer, more planned interval.

> I would say it's practical, not naive. If you want a browser that allows you to stagnate while enjoying long-term support, then either start paying someone for support, or start using IE. You agree that web browsers and word processors are different, so why should Mozilla bend over backwards to allow corporations to try to treat them the same?

I'm saying it's naive (showing a lack of experience, wisdom, or judgment) to expect that this new development cycle won't have ramifications. Mozilla is free to do what they wish with their product. What I'm claiming is that it will come at the cost of market share in the corporate world. If they don't care about the market share, then go ahead and walk on it.

> I've also consulted for very large corporations. The same disruptive ideology that applies to start-ups falls flat with large corporations. The biggest mistake is to take a unilateral position with them. They will fall back to IE. They will stagnate on old versions if we don't work with them. Is that what you want?

What I want is for corp IT departments to not pretend as if this is somehow an insurmountable change. Yeah, corporations are slow and risk-averse. How risky is it to upgrade the browser once per quarter? Are they not testing and upgrading now for the sake of security fixes?

> Let me clarify: I don't think 3 years is a viable LTS schedule for browsers. I don't know what the time frame is, but I'm sure it's not 3 years, and I'm sure it's not "We release continuously." I should have been more clear about what "similar" means when referencing Ubuntu. By similar, I mean that they should continue their march forward, but that there should be an occasional LTS release that is maintained for a longer, more planned interval.

Okay, I can understand that. I can see the value in dropping a version every 9 months with a guarantee of 1 year of security fixes. Or maybe drops every 6 months that get 9 months of support.

I think if Mozilla is committed to backwards-compatibility moving forward, though, this shouldn't be necessary. If they can't avoid breaking changes for some reason, then it is an issue. (One exception would be breaking changes in beta/bleeding-edge features. If you build your product on unstable CSS or whatever, that's your burden. And if you built your product on features that were only around for 3 months, then you should be able to fix your product quickly.)

> I'm saying it's naive (showing a lack of experience, wisdom, or judgment) to expect that this new development cycle won't have ramifications. Mozilla is free to do what they wish with their product. What I'm claiming is that it will come at the cost of market share in the corporate world. If they don't care about the market share, then go ahead and walk on it.

Thanks for the definition of naive. :) I never said it wouldn't have ramifications. I actually said the opposite. Corporate IT shops need to find a way to move more quickly. They need to change. Running everything on a multi-year upgrade cycle is ridiculous, and borderline incompetent (though the incompetence might be coming from higher up than the IT guys).

> Corporate IT shops need to find a way to move more quickly. They need to change.

That is easy to say, and difficult to do.

The simplest way I can think of to explain why is that every single move, or change, comes with a nonzero cost-per-employee. While it may be possible to reduce that cost, nobody has yet invented a way to eliminate it.

When you have 5 employees, a small change that costs X-per-employee is not a big deal.

When you have a few thousand...

> That is easy to say, and difficult to do.

No doubt. That doesn't mean it shouldn't happen.