Comment by noibl | Hacker News Reader

Comment by noibl | Hacker News Reader

Parent Full thread

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

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.

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

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.

Reply on news.ycombinator.com