Ersatz pragmatism and the lock-in problem.

Bob Plankers believes that OpenStack exhibits lock-in behavior, and is therefore equivalent to proprietary technology like VMware and Hyper-V.

This kind of argument sounds, on the surface, perfectly reasonable. Unfortunately, it ignores some important characteristics of both proprietary and open software in order to make good on a black-or-white argument in service of middle-ground ersatz pragmatism.

A man who knows something of lock-in. Image courtesy the Bedford Falls Sentinel.
A man who knows something of lock-in. Image courtesy the Bedford Falls Sentinel.

I should mention that while I work for an open source software company, I don’t think that open source is magic. Blindly going all-open source in your shop will not solve any meaningful problems. I do think, though, that if you dismiss the advantages of open source, as I believe Bob does here, you’re putting some very valuable tools out of reach.

So: yes, all technology will have switching costs and so exhibit some aspects of lock-in. But switching costs are not the same, and lock-in is composed of many more factors than a maintenance burden or the immediate switching costs1. Let’s take them in turn:

Sunk costs

Proprietary software charges a licensing fee to use their tool. Open source software does not. Everyone agrees on this, I think, but it’s not the whole story.

It’s important to account for the secondary sunk costs. You may have to acquire new infrastructure to use the tool: hardware, third-party tools, and so on. You may have to train your staff. To make the product useful, you may have to update or change existing tools and procedures. These are costs you will never recover, and while open source may not charge you a licensing fee, it is just as subject to these sunk costs as proprietary tools.

Maintenance costs

All tools have some kind of maintenance cost, whether they’re formally paid to a vendor (ex ante) or incurred by the organization informally (ex post). The ex ante costs are pretty simple to account for: it’s what the vendor demands every year for support, updates, and so forth. Open source often has an advantage here.

As Bob suggests, the ex post costs can be a killer. There’s the acquisition cost of new talent that knows how to use the tool. There’s the operational debt you might assume through customization of a proprietary tool or maintaining your own fork of an open source project.

These ex post costs are why companies like Red Hat are useful: they mitigate some of this risk by assuming some of this maintenance burden on your behalf. We backport patches, add features, manage the security vulnerabilities, create and sign packages, and so on, reducing the need to hire new talent for those tasks. In other words, we can turn ex post costs into ex ante costs, and simultaneously reduce those costs through economies of scale.

Bob’s rigged his maintenance argument so he can compare a proprietary tool like VMware against a DIY OpenStack implementation or a proprietary wrapper around OpenStack like Piston, which has the same economics as a proprietary tool. Ignoring the value of a commercial vendor supporting a truly open source tool, rather than a proprietary wrapper, is a pretty serious omission.

Exit costs

I’ve been thinking a lot about exit costs lately, because they’re the least-understood part of this problem. If you look at your average procurement rules, they spend nearly all their time on acquisition, and almost no time talking about relinquishment. It’s a pity, because that’s where the pain of lock-in is most deeply felt. I firmly believe that a full and honest accounting of exit costs during acquisition is the best way to combat the problem. Open Forum Europe in the EU has started thinking about this. They advocate including exit costs into the EU procurement rules.

The exit costs from a particular technology include ex ante fees associated with canceling contracts, but also the cost of acquiring a new system and any transition costs. Everyone knows that if you’re using a widely-implemented open standard, you can reduce these transition costs. That’s the obvious stuff. If you’re not accounting for your use of proprietary standards, you’re inviting predatory rent-seeking by the vendor2. In Bob’s discussion of lock-in, I notice that he didn’t touch on the consequences of VMware’s proprietary vmdk or VMFS formats.

Even an open standard, though, doesn’t reduce the cost of switching implementations of that standard. You may be using IMAP for your email servers, but moving from the Microsoft Exchange IMAP implementation to the Zimbra implementation is non-trivial. Switching from one Zimbra vendor to another, on the other hand, will probably be much less painful. This is where open source has a unique advantage against exit costs: the prospect of switching providers without assuming an expensive and complex migration effort.

Friction is not lock-in

Obviously, this is a rough survey of the lock-in problem. There’s much more written on the subject by people much smarter than I am. Returning to Bob’s article: just because there’s friction in a switch from one technology to another does not mean all lock-in is equivalent. It’s a complex problem with any number of mitigation strategies, and if you ignore the very real effects of open source on this problem, you’re missing a big piece of the puzzle.

  1. See Paul Klemperer‘s work in 1989 and 1995 (which I’ve only skimmed) for much more about this. 
  2. If you’ve been forced to purchase £30 charging cables for your mobile phone, you know what I’m talking about. 

One thought on “Ersatz pragmatism and the lock-in problem.

Comments are closed.