I’ve been meaning to move this blog off a sub-domain affixed to the Dojo Project for some time, but I finally got all the pieces lined up last night. This blog will continue to be technical in nature and I’ll set up another location here on infrequently.org for political stuff. Thanks for being patient with any latent brokenness.

The concepts of negative externality and moral hazard describe situations where one person can impose costs on another without paying for it, often resulting in less-than optimal outcomes for everyone. That sounds a lot like what’s going on with organizations that won’t upgrade from IE6 to me. Lets quickly consider both sides of the browser equation and then sketch out some possible solutions, keeping in mind that the assumed goal is a better, less frustrating web experience for users and developers. We’ll also look to see how this stacks up with the fairness goal of buyers paying full-freight for the costs of production.

Firms have incentive to maximize returns on existing investments in browsers. That usually means not switching immediately when better versions are available, even if the nominal price is zero, since the real price may be much higher. Retraining, support, validation, and rework of existing systems that won’t work with a new browser all add up to create a large disincentive to any change. A new browser — or even a new version of an existing browser — has to overcome not just compatibility and feature hurdles, but also has to be worth enough in the view of the upgrading firm to outweigh those other potential costs. Once an organization gets large enough, it may cost real money just to figure out if upgrading to a new browser will cost a lot of money. That outlay itself may be hard to justify, so lets assume that big organizations are making decisions about browsers under uncertainty.

Web developers and the folks who employ them would like their customers — the aforementioned firms — to pay at least what it costs to produce an app. As we’ll see, this may be hard to estimate. They’d also like to deliver competitive, compelling apps at as low a cost as possible. But they’re also operating under uncertainty. Developers want to maximize the size of their potential market, which means supporting the broadest swath of browsers as possible. They also wish to avoid rework, or building features twice. They could build a feature once for old browsers and again (perhaps better) for new browsers, but that’s expensive. Only the largest sites and firms can even contemplate such a strategy. This means that developers have incentive to build to the least common denominator since that will ensure an app works for the largest market.

So what browsers to include? There’s historical on how browser usage is evolving, but things move slowly enough in the modern browser era to suggest that the future is going to look a lot like the present, particularly related to average sales and development cycles. Public, widely available statistics about market share might also bear scant resemblance to the audience for a potential app. Developers for enterprises can often count on even more legacy browser users than the numbers from the public web would suggest. App development may be speculative and therefore hard to gauge the eventual profile of user’s browser. It’s unlikely that a firm knows all of its future customers when you starting development, particularly for new applications. It pays to be conservative about what browsers to support, then.

What if a developer builds an app, pays all of the costs related to increased complexity and reduced feature set for supporting old browsers, but does not sell many units to firms using old browsers? There’s potential deadweight loss to the developer of that app in supporting old browsers, but that might be OK from the perspective of the developer; they reduced their uncertainty. They’ll likely never know if the cost/benefit would have worked out the other way, but it’s a moot question for them.

The cumulative effects of this dynamic over time are not additive; they compound. Lets consider the environment that these developers are selling into. Remember that a developer’s customers are also the market for browsers, but on different time scales. The costs of an IT upgrade project for browser replacement may not be known and may dwarf the cost of the app, making it unlikely that the cost savings to the organization for an app targeted at newer browsers (thanks to browser features which reduce development time and therefore cost) will win the day. More likely the customer will lean on their supplier to support their old browser or simply exclude vendors from the bid process all together. Mismatches in size and clout between vendors and clients amplify this dynamic: large clients simply dictate terms, forcing suppliers to bear costs that they might not otherwise. If those suppliers have (or would like to have) other clients, they may pursue a strategy for browser support that includes more than just the supported browsers at their large firm client, again potentially taking deadweight losses. The cumulative effects of large, slow moving organizations aren’t just to reduce the features or increase the cost of a single app; over time the inability of developers to use and stress new features robs the entire market of growth thanks to the third linkage: that of browser makers to application developers.

It might come as a surprise, but browser vendors care very much what web developers do. This shows up clearly in the standards process (a forum historically populated with browser vendors) where a lack of use is cause for removing features from specs. After all, standards are insurance policies that developers and customers take out on their investment in browsers and the features they support, and it doesn’t make sense to insure features that nobody is using. Developers who include slow-moving firms as clients may shy away from using new features, depriving both their app of marginal capabilities but crucially also robbing the process of browser improvement from the feedback that’s critical in cementing progress in place. With this feedback loop weakened, browser makers may assume that web developers simply don’t want new features or perhaps don’t want the ones they’ve clamored for. Worse, they may wrongly think that developers just want better/faster versions of existing features, not new features that open up new markets (assuming wide distribution).

I’ve glossed over lots of details at every step here, but by now we can see how the dynamic caused by legacy content in organizations that demand continuity robs us all of forward momentum. More frustratingly, we can also see how everyone in the process is behaving rationally(ish) and without obvious malice. That doesn’t mean the outcomes are good. If firms could make new web features available for their suppliers to target faster, they would strengthen the feedback loop between developers and browser makers and also reduce their own procurement costs for applications, assuming they could continue to use their old applications. The key to enabling this transition to a better equilibrium lies in reducing those potential costs of change. In many ways, that comes down to reducing the uncertainty. If new features could work along side legacy content without retraining, added support costs, and without the need for exploratory work to understand the potential impacts, organizations should be more willing to accept modern applications. We need to make free cheaper.

There are other ways of addressing market imbalances like this, of course. One traditional answer is for governments to tax those who externalize their costs onto others, bringing the actual price of goods back into line. Regulation to prevent externalization in the first place can also be effective (e.g., the Clean Water Act). The use of the courts to find and provide remedies sometimes works but looks implausible here — you’d need a court to accept a theory of “browser pollution” in order to show harm. Derivative contracts may allow first parties (developers) to spread their potential costs, assuming they can find buyers who can judge the risks, but this looks to be a long way out for web development. Building basic schedules for relatively differentiated goods is hard enough. Asking others to trade on one small-ish aspect of a development process feels far-fetched.

Reasonable people disagree about how we should attack the problem. My own thinking on the topic has certainly evolved.

For a long time I viewed standards as a solution, and once my faith waned — based on a lack of evidence that standards could do what was being asked of them — I turned to JavaScript to help fill the gaps. It was only when I came to realize how the rate of progress determines our prospects for a better future that I started looking for other solutions. The dynamics I’ve outlined here are roughly how I came to view what I did for a living in 2008, when I began to look into building a swappable renderer for IE based on WebKit. Chrome Frame is an attempt to drive the price of free closer to zero and in the prcoess improve the rate of progress. That’s the reason that Chrome Frame is opt-in for every page and doesn’t render everything with the Chrome engine. That’s the reason we’ve created MSI packages that keep IT administrators in control and continue to do all our work in public. Rendering everything via Chrome or giving admins any reason to distrust the plugin wouldn’t reduce the uncertainty and therefore wouldn’t do anything to address the part of the process of progress that has been broken for so long.

Next time you hear someone say “if only I could use X“, remember that the way we’ll get to a better future is by bringing everyone else along for the ride. We won’t get there by telling them what to do or by implying with moral overtones that their locally optimal decision is “wrong”. Instead we can bring them along by understanding their interests and working to reduce the very real friction that robs us all of a better future. You can do your part by opting your pages into the future and working with your users to help them understand how cheap free has truly become.

Side-by-side versions of different browsers are critical for us webdevs. On some browsers, it’s because multi-year-old versions are still prevalent (luckily, you can start ignoring them). In the case of Chrome, nearly all users are up-to-date with the very latest Stable release. Being the forward thinking chap/gal you are you want to try out new stuff like WebGL that’s only available in the Dev channel. But you don’t want to mistakenly build something that uses features users don’t have yet. What to do? Side-by-side installs, a.k.a. the Canary channel! Now you can test with Stable while plotting world domination on Dev. Awesome.

This new version will auto-update with the new hotness at roughly the same rate as today’s Dev channel but will allow you to install and run it alongside a Stable channel version of Chrome. This new channel is Windows-only for now, but you have VMs for testing anyway, right? Happy testing!

You can get yours here. Note that these are Dev Channel builds, so they contain the new hotness. Also, the new bugs. Caveat emptor.

Huge props to Robert Shield who has been working through the endless details of this effort for months.

So you’re making the new shiny — ’cause that’s how you roll — and you’re thinking to yourself “hrm, I’ve told users of legacy browsers to get Chrome Frame or upgrade, but there’s this new awesome feature in the Chrome Developer Channel…but it’s not in the version of Chrome Frame I’m testing with. I thought I was on the Dev channel?”

Indeed, if you installed GCF prior to the Beta release, you would have been on the Dev version, but when the Beta was pushed, all existing GCF users were moved to it as a one-time transition. That means you might not be getting the new shiny features we’re pouring into Dev as quickly as you anticipated…but fear not! There’s a new Dev Channel Release available. If you’re developing sites with GCF and you want to see what’s coming, I highly recommend getting and testing against this version. You won’t be moved to Beta again, so this uninstall/reinstall is a one-time change.

As folks begin to use and test with GCF, one of the first many try is to use the OptInUrls registry key to over-ride a site’s preference about which renderer to use. This tends to cause confusion and spurious bug reports because many sites employ server-side User-Agent detection to send different content to different browsers. Since GCF uses IE’s network stack and reports a slightly modified IE User-Agent instead of Chrome’s UA, server-side detection may send IE-specialized content instead of Chrome-friendly content. This includes many large sites like Yahoo, GMail, and most sites built with GWT’s server-side detection.

These are not bugs.

Those sites are working as intended and GCF is operating correctly. What’s happening, instead, is that by adding sites to the OptInUrls list that do not understand GCF, you’re breaking the contract at the core of how GCF works: existing content works the way it always has. It’s only when you’re sure that a site is sending browser-neutral content (usually when it’s your site) that you should ever add a site to the OptInUrls list for your system or organization. As usual, if you’ve got questions about GCF that aren’t answered in the FAQs or docs, you can ask them on the Google Group for the project. The whole team is subscribed to the list and we’re focused on helping you make awesome apps, so stop by, say howdy, and let us know how it’s going.