or Why Government FLOSS Purchasing Policy is Misapplied
Summary
Misapplication of “value for money” requirements when purchasing software results in poor value for money – Government purchasing policies for software tend to support the creation of monopolies.
Government purchasing has effects on the price paid by citizens for the product purchased. In some cases purchasing produces volume which permits scale discounts and therefore a net benefit to citizens who also purchase the product. However, in the case of lock in software* Government purchasing can create a monopoly in the software which leads to increased costs for citizen purchasers and a net detriment for society as a whole. It is not appropriate for value for money policies to be assessed on a per acquisition basis when software is being acquired. Doing so will almost certainly create net costs for the community when considered in the aggregate.
A Tale of Two Widgets
Consider the case where the government must buy one of two types of widget (called Widgets A and B respectively). Assume also that both widgets are more or less equivalent. Not only do both widgets meet the government’s needs, but they would also both meet the needs of most general purchasers of widgets. Assume further that the government price for Widget A is about half that of Widget B. At this point take out your taxpayers hat and place it squarely on your head and think about which widget you’d like the government to buy. That is, would you prefer the government to take more of your money and spend it on Widget B or would you prefer it to spend your money on the cheaper Widget A?
It was the Best of Times
Did you choose Widget A? Surely, based on what I’ve told you, that must be right! You’d think government would need to be mad, bad or corrupt to purchase Widget B in those circumstances. Not surprisingly this purchasing preference is reflected in government procurement policies. For example:
Let’s assume now that the Government does purchase Widget A and take the scenario further to analyse some of the assumptions we made in arriving at the purchasing decision. What if Widget A is used to lay roads? What if Widget A is not interoperable?
What if Widget A has been specifically designed so that if it is used to lay a road, then to drive on the road a car must also be fitted with Widget A? (Assume, for the sake of fairness, that Widget B also requires a car to be fitted with Widget B). Would you still be happy for the government to buy Widget A? Maybe you would – Widget A costs half of Widget B. Presumably you’ll be no worse off. You will need to buy one of the two Widgets and you’ve already paid half** the price of Widget B when the government used your taxes to buy Widget A, if you have to pay half the price of Widget B again, you’re square with the price of buying Widget B – in fact you’re better than square because if the government had bought Widget B you’d pay the full price for it with your taxes and you’d have to pay the full price for it in order to drive your car.
It was the Worst of Times
There is a but – and it is unrelated to the characterstics of Widget A and Widget B, their functions, design and operation. That “but” is the availability of Widget A and how it can be priced. Assume that Widget B is made by lots of different people and there is fierce price competition in relation to it. Assume also that Widget A is only available from a single vendor. The vendor of Widget A (Vendor A) is able to set different prices for Widget A in different markets (the vendors of Widget B are not able to do so, because of the assumed competition in the market). Vendor A can choose to set a very low price for Widget A for Government purchasers, knowing that governments build a lot of roads. They can then choose to set a higher price for other purchasers – the prices given above were prices for government purchasers (not for chumps like you and me). Want to drive on a government road? Sorry, that’ll be 10 times the price of Widget B.*** Now, any way you cut it you are out of pocket. Assuming most roads are laid by the government, over time Widget B will be pushed out of the market or at very least relegated to small niches.
Intermediate Conclusion
We can conclude from the above that it is not possible to make a judgment as to value in isolation. Something which seems to be good value in a particular purchase scenario can lead to extremely poor value from public expenditure.
What’s the Problem
Government procurement can both create and reinforce a monopoly in goods and services which it is acquiring. Anecdotal evidence suggests that bureaucrats look at “value for money” type formulae and assess it against the cost to Government on a purchase-by-purchase basis. This approach is fine in respect of goods and services which are easily substitutable (such as hammers, screws, cars etc). In respect of goods which are specifically designed to prevent substitutability – eg devices which are not designed to be interoperable it is an extremely hazardous approach. If those goods also tend to be a natural monopoly (such as software in general, but particularly that which is designed not to be interoperable) this approach is absolutely the wrong one. The reasons should be obvious:
- the vendor of the product can almost always underprice competitive offerings – even when competitors are loss leading;
- the Government, bound by its bureaucrat’s incorrect understanding of the value for money policy is required to purchase the monopolist’s product;
- over time network effects enable the monopolist to crowd out competitive offerings;
- the vendor, now a monopolist, can charge what it likes to the rest of the community safe in the knowledge that, because of the preponderant use by Government others have no choice but to acquire the product;
- ironically, over time the monopolist will even be able to charge the Government more because of the its huge installed base and the previous elimination of competition.
The Tragedy of the Anti-Commons
A prospective monopolist has a period of vulnerability before it has established the monopoly product in the market in which this strategy is risky (because it must carry the costs of underpricing). However, the tragic (ie fatalistic) nature of the process, coupled with the huge rewards to be had from playing the game makes it inevitable that sooner or later a monopoly will be established – it only requires one prospective monopolist to succeed for a monopoly to become entrenched. No number of failed attempts will prevent the next attempt and the winner take all nature of the scenario will continually draw in new prospective monopolists.
What is a Better Approach?
Government may have many roles in the procurement of goods and services but supporting, establishing and maintaining unregulated monopolies is not one of them.
While the value for money requirement is fundamentally correct, to elevate it to the status of gospel or taking it out of context is not. Value for money must be determined by reference to the price paid in the aggregate by the community for the Government’s acquisition, not to the price paid by Government or authority for the acquisition. This value for money assessment is further complicated by the fact that the assessment must necessarily:
- be an ongoing one. A purchase today has no immediate cost impacts on the rest of the community – those impacts are all in the future and some of them may be in medium or long term;
- involve a review of pre-existing Government acquisitions (as a previous (acceptable) acquisition may be unacceptable when taken in combination with a proposed acquisition); and
- involve a review of things other than the software – in particular whether the vendor is likely to be in a position to manipulate the market.
Of course, the complexity of issues to be addressed by a value for money assessment make it difficult to apply with any consistency or certainty. In relation to lock in software it may only be a feel good term with little real substance. Any doubt should be resolved against the creation of monopolies.
If the licence terms permit perpetual use of each copy and permit the Government to onsell each copy of the software acquired and to do so independently of any hardware acquired in conjunction with the software that would reduce some of the monopolistic impact of the arrangement. Unfortunately the structure of copyright law usually forbids this arrangement in practice and, in any event, would not eliminate all monopolistic effects.
Particular Example – Whole of Government Purchasing
Whole of Government acquisitions of lock in software provide especially poor value for money on this analysis. Such acquisitions provide a vast installation of the software across government and effectively create an environment in which incremental improvements are net costs rather than net savings. For example, if the software has been purchased for the whole of Department X, then using a cheaper product for some users will not result in any cost savings – on the contrary since there is an effective doubling up on the licensing to the small group it costs more to use cheaper software! Further they create an entrenched installed base which increases the costs in the next round of acquisition (because this installed base effectively dictates purchasing requirements in that acquisition round).
Particular Example – Key Resources
Government acquisitions of software for key services or resources also provide especially poor value for money on this analysis as well. In these cases the importance of the relevant project (for example, the provision of public information by a health body, broadcaster or library) creates a lock in because of the general need of the public to interact with that body. That need for interaction will create in the public a need to acquire the software in order to access the resource, with the consequent establishment of a monopoly. It is a dangerous vanity for public resources to adopt lock in technologies in the provision of information or services through public facing interfaces.
Note on Formats, Standards and Protocols
This discussion has focussed on software primarily because it is more familiar and is conceptually easier to understand. However, the arguments presented apply equally to the adoption of products which require the use of a particular data format, standard or protocol if that format, standard or protocol has the lock in characteristic. Indeed, ultimately the issue is not so much in the software which manipulates data but in the manner in which data is stored and exchanged. In many instances software (and particularly lock in software) has a direct mapping against a specific data format and can therefore be identified with that format. If no lock in data format is used, the negative effects of the acquisition of lock in software is greatly reduced.
Notes
* For the purposes of this paper “lock in software” refers to software for which: the licence for that software ties the licensee to the licensor or to any third party either implicitly; or the software is designed to effect such a tying and there is no capacity either at all or in practice for the licensee to avoid or remove that tying. Lock in software includes software: which is not interoperable (eg doesn’t save to a standard format in its default configuration) or not interoperable outside the product set for a specific vendor or set of vendors, for which there is only one manufacturing source (multiple sales channels don’t count) and that source of the software has a substantial degree of market power in the relevant software market. By definition, lock in software does not include software which meets the open source definition.
** Technically probably less than half. It’s only half if the Government must buy one widget per car on the road.
*** The price will be determined by the demand for Widget A and may not be (but also might exceed) 10x. If, as in the case of software, the law prevents on sale, Vendor A will also be able to price discriminate, by charging each individual consumer as much as they are willing to pay.
Finally, a “widget” in this context is a placeholder term for some object the subject of discussion.
[Note initially made available for review on 7 January 2008]
Brendan Scott's Weblog 