Openstreetmap economics — maps for a lost Coase

As a way to support future debates on firm ground, let’s review the economic fundamentals of Openstreetmap, explain why Openstreetmap works and try to extrapolate a few axis from there. This article will be useful to those unfamiliar with free software.

We’ll lean on Yochai Benkler’s classic: “Coase’s Penguin, or, Linux and The Nature of the Firm” : “For decades our common understanding of the organization of economic production has been that individuals order their productive activities in one of two ways: either as employees in firms, following the directions of managers, or as individuals in markets, following price signals. This dichotomy was first identified in the early work of Ronald Coase and was developed most explicitly in the work of institutional economist Oliver Williamson. In this paper I explain why we are beginning to see the emergence of a new, third mode of production, in the digitally networked environment, a mode I call commons-based peer production”

“Commons-based peer production, the emerging third model of production I describe here, relies on decentralized information gathering and exchange to reduce the uncertainty of participants, and has particular advantages as an information process for identifying human creativity available to work on information and cultural resources in the pursuit of projects, and as an allocation process for allocating that creative effort. It depends on very large aggregations of individuals independently scouring their information environment in search of opportunities to be creative in small or large increments. These individuals then self-identify for tasks and perform them for complex motivational reasons”

To the Openstreetmap contributors, this sounds so familiar that the reader at this point considers whether to stop reading, in case the rest of this article is filled with such banality. But as economic concepts go, it is actually still quite novel. It occurs when cooperation (“peering” — as Benkler puts it) is more efficient than markets or hierarchies — a situation which is also familiar to whoever has ever tried to assemble a global geographical dataset or produce one in-house:

Nothing new so far: Openstreetmap is classic free software, native to the Internet and cooperation its core, with cooperation measured by contribution to the project. Even merely using a product rather than its competitor is contribution already, as it increases the product’s mindshare and marketshare — but let’s consider that the cooperation threshold is a bit above that. By relying on cooperation, free software characterized by the prisoner’s dilemma and specifically the iterated prisoner’s dilemma. But it also provides a solution to it’s own problem, as Liz Wang explains :

“Given a piece of Free Software, you can study the source code and make improvements. Then you can keep secret the improved version [..] Alternatively, you could share the improved version [..] (cooperate). If everyone defects, then many are probably making exactly the same improvements. For any software that is under the GPL, it is illegal to distribute only the unmodifiable form, including any changes made, thus forcing cooperation. Hence, rival parties can all work on it and know that none will defect, and all share in the improvements made by the others”.

Free software depends on cooperation, so forcing it through a license is the logical self-preservation step. No surprise here — that is why Openstreetmap data is under the Open Database license (ODbL).

In practice, a license does not quite ensure that free software thrives — its health is also the outcome of an equilibrium that reminds of host-parasite relationships, with particularly intelligent parasites seeking balance between overspending and collective suicide. In “Game Theory, Competition and Cooperation”, Alexandre Oliva explains such dynamics:

“Acting in a selfish and rational manner, it won’t set the cost to zero, but rather right below the price exercised by other vendors, that do incur actual costs to maintain the software. If multiple such vendors try this trick, they may actually succeed in driving the price down to zero, but this would tend to take the real software maintainers out of the market, leaving these entrants in a situation in which they have to do the actual work to satisfy their contractual obligations toward their customers. If they fail and go out of the market as well, the higher ­paid competitors get a chance of getting contracts again, if they haven’t completely moved on; worst case, customers might end up having to hire individuals or new companies to do the work, increasing the market value again. The bottom line is that bargaining theory will lead the market to an equilibrium in which vendors get for their work an amount they consider reasonable, and customers pay a reasonable amount for such work”

So, with inter-parasite diplomacy similar in structure to the challenge of cooperative challenge of managing anthropogenic climate change at a global scale, the license works in practice. As large corporations enter the game, I trust them to be the smart parasites that they are — to our benefit as long as the ODbL remains Openstreetmap’s keystone.

I my precedent article here (“Measuring data quality or why are we even Openstreetmapping anyway ?”), I talked about Openstreetmap’s indirect approach, inherent to its free software nature. It is indirect downstream, on the distribution side — but on the other side there is also the question of whether to act directly of let third party fill the role. Let’s dig into that, how it is relevant to the rise of corporate contributors, why it makes the license the capstone to the whole project and how it relates to the Openstreetmap Foundation’s finances.

So, we have the license as a core asset for Openstreetmap. What else must we do so that Openstreetmap abides in its role as global repository of human-curated consensual geographical facts ? More specifically, what where should the Openstreetmap Foundation draw the line between what it should do directly and what it should leave to third parties ? If we reduce that to a classic make or buy decision, then we are back to Coase — through Oliver Williamson’s “Markets and Hierarchies: Analysis and Antitrust Implications”, which identifies factors that raise transaction costs and combine to create “market failure” — which is synonymous with cases where in-house production is superior to external supply.

Among the factors of market failure are transaction-specific assets, which Geyskens, Steenkamp, and Kumar explain in “Make, buy, or ally: A transaction cost theory meta-analysis Make, buy, or ally: A transaction cost theory meta-analysis”, underlining that “The conceptual and empirical research launched in the shadow of Williamson’s book led to the proposition that asset specificity is the critical determinant of the choice between markets and hierarchies” :

“Transaction-specific assets are assets that are tailored to a particular transaction and cannot be easily redeployed outside the relationship of the par-ties to the transaction. Their idiosyncratic nature gives rise to a safeguarding problem, because market competition will not restrain opportunistic exploitation. The solution to the safeguarding problem identified in transaction cost theory is vertical integration. In contrast to markets, the authority relationships and hierarchical control procedures available through vertical integration are assumed to embody greater safeguarding capabilities”

The Openstreetmap Database and its API are intimately tied to the transactions — respectively consumption and contribution,that are the core of Openstreetmap. They are perfect examples of transaction-specific assets, so I would err into boring obviousness if I underlined that they are absolutely part of what the Openstreetmap Foundation must keep producing internally — or at the very least keep under strict control from its working groups.

So, to decide whether a production is essential, the key question is: what would happen if an hostile third party takes control ? If the outcome is strategic compromise, then it is essential. The rest will sometimes be nice to have but most often better be left for the rest of the world to enrich the Openstreetmap ecosystem.

Coase and Williamson were features of the industrial economics course I took in early 96, in the third year of my management studies — right at the time when I began trying to figure out why Slackware Linux had a “root” floppy and a “boot” floppy instead of just a boot floppy like DOS and Windows… Coincidence ? I’m not sure now…