When Free Isn’t Cheap Enough

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 return on investments, meaning not switching immediately when better browsers 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 be worth enough to outweigh those potential costs. It may cost real money just to figure out if upgrading will cost a lot. Lets assume that organizations are deciding under uncertainty.

Web developers want their customers to pay at least what it costs to produce an app. This may be hard to estimate. They’d also like to deliver competitive apps at as low a cost as possible and often want to maximize the size of their addressable market, which means supporting the broadest swath of browsers as possible. They could build features once for old browsers and again (perhaps better) for new browsers, but that’s expensive. Only the largest sites and firms can contemplate such a strategy, and usually as a way of mopping up marginal market share once they’ve “won” the primary market battle. Developers of new apps have strong incentives to build to the least common denominator and address the largest potential market.

So what browsers to include? There’s historical data on browser share but things move slowly enough that the future is going to look a lot like the present, particularly related to development cycles. Public statistics on browser share may not even resemble the market for a vertically focused product. Enterprise software developers can count on more legacy browser users than consumer sites. In any case, it’s unlikely that a firm knows all of its future customers. It pays to be conservative about what browsers to support.

What if a developer builds an app, bears the pain of supporting old browsers, but does not sell many units to users of old browsers? There’s potential deadweight loss in this case, but it might be OK; the developer reduced their uncertainty and that’s worth something.

What’s good for a single firm may be bad for the ecosystem, though. The cumulative effects of this dynamic compound. Application buyers are also the market for browsers, but on different time scales. The costs of a browser upgrade may not be known and may dwarf the cost of any individual app, making it unlikely that cost savings for an app targeted at newer browsers will win the day. More likely the customer will lean on their supplier to support their old browser. Mismatches in size and clout between vendors and clients amplify this dynamic. What small consulting firm can tell a Fortune 500 firm who may be their largest customer to go stuff it if they don’t upgrade from IE 6? Small vendors may be able to target more than just the supported browsers at their largest client, but again potentially taking deadweight losses. Large, slow moving organizations may hurt individual apps but cumulatively they can also rob the market of growth thanks to the third linkage: the connection between browser makers and application developers.

It might come as a surprise, but browser vendors care very much what web developers do. We see this in the standards process where a lack of use is cause for removing features from specs. After all, standards are insurance policies that developers and customers take out against their investment in technologies — in this case browsers and the features they support. It doesn’t make sense to insure features that nobody is using. Developers whose clients are slow-moving may shy away from using new features, robbing the process of the feedback that’s critical in cementing progress. With the feedback loop weakened, browser makers may assume that developers don’t want new features or don’t want the ones they’ve built. Worse, they may wrongly think that developers just want better/faster versions of existing features, not new features that open up new markets.

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.

6 Comments

  1. Posted August 10, 2010 at 3:11 pm | Permalink

    I’m not sure that this is really describable as a negative externality in the classic sense. No one is being actively harmed and being forced to take on these support costs. If you’d have argued that those running older browsers are more likely to have malware on their machine, and then causing direct harm to others, you’d possibly have a case.

    Additionally, there isn’t moral hazard here unless you want to make the argument that IE6 users are more likely to have a security problem, but aren’t being forced to cover the full costs of that. In the existing case if users are running IE6, a developer is perfectly at rights to charge them more to use their application if they’d like to, or not service them.

  2. Posted August 10, 2010 at 4:57 pm | Permalink

    Hey Andy,

    Web developers and users of better browsers take on the costs that organizations who run older browsers don’t bear (but should). Developers bear direct economic losses in the form of higher costs for the production of “lumpy” goods (based on the lowest-common-denominator effect noted) and pass those costs on to *all* of their clients, not just the ones using bad browsers. Obviously, I support differential pricing based on browser quality, but for many web apps that’s not really workable…or at least it hasn’t been historically. The costs are suffused throughout the development process: libraries are bigger and slower than they otherwise would be since they assume lowest-common-denominator. CSS techniques are stilted because of assumptions about browser support. Performance and features are capped at every turn, driving costs up for everyone.

    Regards

  3. Posted August 11, 2010 at 10:48 am | Permalink

    And web developers also have costs to support a multitude of browsers. Desktop software vendors incur costs to sell software for both Windows and the Mac, much less Linux. I don’t think you could describe the Mac user as causing a negative externality to Windows software developers because they aren’t running Windows. Does this reduce the market for that developer, yes.

    How are older browsers any different?

  4. Posted August 11, 2010 at 11:43 am | Permalink

    Andy: browsers are assumed to be substitute goods. OSes aren’t (usually). Given that web sites today are “lumpy” in that they are often built to assume multiple client browsers and not just a single client, the analogy just doesn’t hold. The dynamics and expectations of market participants are totally different.

  5. Justin Meyer
    Posted August 11, 2010 at 11:06 pm | Permalink

    Have you guys field tested CF? I’m not sure what kind of budget google gives you, but I’d be interested in knowing what happens when someone tries to use CF at a big company.

  6. Bron
    Posted August 12, 2010 at 10:38 am | Permalink

    Developing for down-level browsers isn’t as hard as it is made out to be in my honest opinion. Monolithic, overly complex pages are usually to blame and a little carefully crafted server-side code can make delivering appropriate HTML, CSS and Javascript for the browser in use quite simple.

3 Trackbacks

  1. By links for 2010-08-11 « burningCat on August 11, 2010 at 7:07 am

    […] When Free Isn’t Cheap Enough 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. […]

  2. By We are why IE6 lingers on | Marc Drummond on August 15, 2010 at 9:00 pm

    […] recent article, When Free Isn’t Cheap Enough, goes into more detail on some of these […]

  3. By Story Time! | Infrequently Noted on October 12, 2010 at 12:03 pm

    […] don’t have to do it” — ignores upgrade costs. I’ve written about this at eye watering length. This perspective has two common sources: looking at a small sliver of the browser market (e.g., […]