Showing posts with label computing. Show all posts
Showing posts with label computing. Show all posts

Friday, March 12, 2010

Peer Production and Transaction Costs

The concept of peer production is hardly new to me. Wikipedia and Linux, the most visible examples of peer production, long ago convinced me that intellectual products can be produced by means of a distributed network of individuals working largely without supervision or central control.

But until a couple of weeks ago, when I finally listened to Clay Shirky’s interview on EconTalk (recorded over a year ago), I had a difficult time fitting peer production into my mental models. It’s not that I didn’t understand peer production; it’s that I couldn’t quite integrate it with what I already knew about typical modes of production. Shirky, by invoking the work of Ronald Coase, finally let me put it together.

(Disclaimer: The following doesn’t necessarily represent Shirky’s view; it’s just my take on what he said. Also, I have not read Yochai Benkler's work on this subject. Finally, my conclusions will probably be obvious to some readers -- but to compensate, I promise an example drawn from my work on Fringe!)

The first step is to uncover an assumption hidden in most models of labor supply. The “typical” labor supply curve looks something like Figure 1. This curve represents an individual’s willingness to supply labor. As the figure shows, the individual won’t supply any labor until offered a wage that exceeds some minimum, denoted wo and dubbed the “reservation wage.” This reflects the notion that exerting effort is inherently unpleasant.

But what if labor is not inherently unpleasant? Then the labor supply could look something like Figure 2. Here, we see that even at a wage of zero, the individual willingly supplies some amount of labor. This is obviously true for a variety of activities; I blog for free, for instance. Denote this minimum Lo and dub it the “free labor supply.”

But that’s not the end of the story. Most worthwhile projects will require more labor than any one individual will provide for free. To complete these projects without paying wages, you need to assemble the free supply of many, many individuals. Prior to the modern information age, this certainly happened; think barn-raisings and charity projects. To do it, however, you usually had to get people together in the same place, requiring both transportation and physical space. Information technology has dramatically reduced these transaction costs -- specifically, the costs of coordinating team production. It’s now possible to assemble the free labor supply of thousands of people at much lower cost than before.

Thinking of peer production in this way helps to understand its limits. What kind of projects can be done by this method, and which can’t? First, we need to have the kind of project for which people have labor supply curves like Figure 2 -- that is, for which people willingly supply free labor.

Second, the project’s other transaction costs must be sufficiently low. Coordination costs include not just drawing laborers together (physically or virtually), but also making sure their separate efforts mesh properly. The pieces have to fit, so to speak. And this puts a premium on modularity -- the capacity of a task to be broken up into pieces that can function, at least to some degree, on their own. Wikipedia is a nice example: an error or conflict within a single entry (say, Walmart) does not inhibit ongoing work on another entry (say, Target or quantum field theory). I don’t know enough about software programming to give examples there, but my understanding is that it has similarly modular features.

Not every project is of this nature. To take an example from my current livelihood: it’s awfully difficult to write a script in a distributed fashion. Anyone who’s read the results of a tandem writing assignment knows this. Every now and then, time constraints in the Fringe writing office will require us to “gang-bang” a script (yes, that’s actually what we call it): acts and scenes must be divvied up among all the writers to get the script written faster. But this only works because a detailed overall outline has already been written, either by an individual or by a group working in concert.

Moreover, once the individual pieces have been stitched together, the combined script is typically a hairy mess. The tone is inconsistent; some bits of necessary information have been duplicated across scenes; other necessary components have fallen through the cracks. To make the script coherent, a single writer or pair of writers (usually the writer(s) of record on the episode) must go through the script revising, reworking, and rewriting substantially. As Warren Buffett wryly notes, you can’t make a baby in one month by getting nine women pregnant; the same is true of a script. In some cases, I’ve seen a gang-banged script take longer to write than a regular script.

To summarize, peer production works because information technology has reduced the transaction costs that previously had prevented the coordination of large amounts of free labor provided by many individuals. Thus, low transaction costs are the key to peer production. But some kinds of transaction costs remain high, especially for projects that cannot easily be made modular; for those projects, peer production is still not a viable option.

Read More...