Click here to see all articles in this series.

Welcome to the second installment in a multi-part series where I look at how IT departments may inadvertently cause more problems than they avoid in their approaches to deploying web browsers in their organization.

In part 1 I talked a little bit about why I have an interest in this topic.

Today we will look at the release cycles and support provided by the major browser vendors. We then look at two very tempting but ultimately destructive strategies many organizations have tried to attempt to cope with the challenges of a web-based infrastructure.

Browsers with rapid release calendars: Chrome and Firefox

Unfortunately, many of today's browsers make it difficult to successfully employ a locked-down approach to technology deployments. Both Google Chrome and Mozilla Firefox have adopted rapid release cycle strategies whereby major new versions are introduced every 6 to 8 weeks. When a new release is introduced, a very short period of overlap exists before the vendor drops support for previous versions. Now web sites and web-based tools and applications must adapt to this reality if they are to use supported versions of Firefox or Chrome.
Mozilla and Google aren't doing this to destabilize your delicate software balance. They are instead trying to focus effort around a single browser release. When Firefox 12 debuts (scheduled April 24), you will have a few weeks to enjoy continued support on Firefox 11, during which time you should have plans well underway to support the new version. And you should make every effort to move on, if for no other reason than in the interest of security. Google's Chrome quietly updates their browser without user intervention. And note that this is categorized as a security feature. If Google Chrome is a used to access your web-based environments you better know when those updates are scheduled to occur and proactively test your applications. Firefox is moving in a similar direction.

While this makes it necessary to update more often, developers building around Firefox and Chrome can focus the vast majority of their effort around a single version of each for the Macintosh, Windows and Linux platforms.

IT departments should have the release schedule on their calendars and proactively plan to support the new releases as soon as possible. The new releases will have security updates and active support from the browser's developer.

Internet Explorer: Versions That Never Die

Microsoft often appears reluctant to cut off support for aging software, due in large part to the size of the install base and the fear of losing customers with aging hardware platforms. 

This is reflected in Internet Explorer. Internet Explorer 6 will be finally interred in April, 2014. This is for a product they are aggressively recommending customers discontinue using, a product that had been eulogized in a funeral ceremony in 2010. Allowing aging versions to continue well beyond their prime, Microsoft has created the browser that wouldn't die.

Even when IE6 is finally gone we still have to contend with Internet Explorer 7, 8 and 9, and soon 10. We can only hope that Microsoft musters up some courage to discontinue their aging releases or they'll all be around into the next decade.

Safari: Something old and something new

Apple mixes a bit of the old with the new in their approach to Safari. They have longer release cycles often tied to major OS/X operating system updates, and tend to aggressively discontinue support for all previous releases. So at any given time developers using web-based technologies can largely focus on a single version of Safari for the Mac, for Windows, and for iOS.

The B-Movie Scientist Policy

So your organization will no doubt have to decide how to adapt to life once your supported browser is dead and buried. You could join many of Microsoft's large customers and use threats, bribes, begging, and tears to cajol them into keeping whatever version you use on official life support well past their prime. Of course, companies like Apple and Microsoft (and open source communities in the Linux world) are unlikely to respond unless you have an enormous IT budget. Even if you do manage to succeed, your victory will only be short-term. Like an ill-fated b-movie scientist, your monstrous creations may be doomed to roam the earth indefinitely.

I read an interesting case study of a startup who estimated the cost of providing Internet Explorer support for their tool at $100K. They chose not to support the world's #1 browser and claim it as a competitive advantage! Writing web applications and tools that can cope with the idiosyncrasies of years of browser releases is a challenge. Building code to deal with all the subtle variances means increased complexity. Hiring staff members who understand all these variations can be difficult. Even keeping around working versions of these dinosaurs is a challenge. Ultimately, the time you may have saved by avoiding a browser upgrade is probably lost many times over in long-run expenses.

The "Monkey's Paw" Policy

I am even more stunned by the approach taken by organizations who don't have the clout to officially keep their chosen browser alive indefinitely. Even after the vendor pulls the plug on the software, many organizations refuse to let go. They continue to support software that the software's creator has given up on. They continue to allow their users to rely on unsupported, unpatched browsers. While this may be sustainable in the short-term, it is a dangerous strategy in the long term. Like a wish on a monkey's paw, unintended consequences may be serious.

As I vendor, I have seen this phenomenon first-hand. Customers will ask for assurances that our software will support "dead" releases, even though such assurances are in reality impossible to guarantee when the browser itself is unsupported.

When a customer tries taking this approach I politely decline. Ultimately most customers realize that supporting dead browsers is an unsustainable strategy only to be used for short-term, emergency situations. Putting systems and users at risk by forcing them to use browsers that do not receive security updates should not be a standard operating procedure. 

Well before the browser developer ceases support for the version of a browser you use, you should already be planning your upgrade.

So that's a quick summary of how the browser vendors handle the lifecycle of their browsers and a few suboptimal responses.

The third installment in this series explores positive steps to a proactive web browser strategy.

Click here to see all articles in this series.

Welcome to the first installment in a multi-part series where I look at how well-intentioned IT departments may be causing more problems than they prevent in their approach to deploying web browsers in their organization.

This installment provides some of the context that lead me to explore this topic.

The Web Browser: Mission Critical Infrastructure
RSI Content Solutions fields two product lines reliant on the web browser as client software: RSuite CMS and DocZone. Managing products that operate in the browser presents challenges when trying to balance functionality against the need to support a wide range of browsers and their versions. Browser developers have been under increasing pressure to provide rapid updates to remain competitive and deal with ongoing security concerns. Users have become more reliant on a range of browser-based tools and applications. Almost every category of traditional desktop applications now have browser-based alternatives available. It can become a real challenge to find that magical browser release that supports the range of platforms and technologies in use today.

I've worked as a vendor in the browser-based application space for more than five years. In that time, I have encountered a range of responses from IT departments dealing with browser deployments. Some exert little or no control, often providing guidance but ultimately letting the users decide what browser to employ and when to upgrade it. Some IT departments have locked things down so tight they only give their users access to a single approved browser. While this may be sufficient for a fairly narrow use case over some finite period of time, the inflexibility is often stifling their ability to take advantage of the latest tools and technologies.

It's ironic that the mission critical role of the web browser has lead to defensive policies in many organizations in seeming ignorance of the rich variety of available tools. In the interest of ensuring a "perfect" technology deployment, it is tempting to lock the organization to a functional set of tools. Just don't blink lest your heavenly solution suddenly show its shortcomings and leaves you mired down.

Over the next several days I will be inviting you to consider your approach to supporting the web browser in your organization. In the next installment, we will look at the various approaches browser developers have adopted regarding updates and support. I'll also tell you about two strategies that have seduced many an IT department astray only to find they're worse off than before. 

Installment number two discusses how browsers are updated today and why acting like a B-movie scientest or wishing on a monkey's paw is not the right response.