Software Transaction Costs

08 September 2013

Nobel prize winner Ronald Coase died this week.

His brilliant work explained why firms exist.

At the time, it wasn’t clear why the economy didn’t just consist of independent, self-employed people contracting with one another. He showed that there are transaction costs associated with procuring from the market. For instance there are costs involved in searching and selecting a supplier and for enforcing contracts. Sometimes these costs are so high that it makes more sense for a firm to internalise the production of the service themselves.

Reading about Coase’s work reminded me of the parallel effect that is so prevalent in software: the market doesn’t just consist of small, independent, tightly-focussed pieces of software interacting with each other. Instead, the landscape is dominated by monolithic all-in-one ‘solutions’ and closed-wall ecosystems.

Software buyers benefit from lower immediate transaction costs when they buy packaged software. There’s no need to search a wide market, ensure solutions will interoperate, check suppliers are reliable and so on.

But they potentially become vulnerable to higher medium and long-term costs in the form of switching costs as they become further ‘locked-in’ to particular solutions, be they particular products, ecosystems or programming languages.

One consequence of framing the problem like this is that it explains certain features of the market in economic terms. App stores reduce searching costs. Interoperability is ensured by conforming to open standards. Supplier reliability is judged through rating systems.

People concerned about software lock-in effects should support mechanisms which reduce perceived future transaction costs associated with buying small, independent pieces of software.

It would also help buyers if they could readily calculate potential future switching costs, which may be significantly higher than the transaction costs.

In concrete terms, what would it cost a business (in capital or time) to switch, at a future date, from Microsoft Office to Google Docs, iOS to Android or .NET to PHP? Such a calculation would be an estimate, but even ball-park figures would help buyers to make informed judgements about the benefits and costs involved in complex software decisions.