Stephen Weber Exzerpte (OSP)
Ausschnitte aus: Stephen Weber: The political Economy of Open Source Software.
"Coca-Cola sells bottles of soda to consumers. Consumers drink the soda (or use it in any other way they like). Some consumers, out of morbid curiosity, may read the list of ingredients on the bottle. But that list of ingredients is generic. Coca-Cola has a proprietary 'formula' that it does not and will not release. The formula is the knowledge that makes it possible for Coke to combine sugar, water, and a few other readily available ingredients in particular proportions and produce something of great value. The bubbly stuff in your glass cannot be reverse-engineered into its constituent parts. You can buy it and you can drink it, but you can't understand it in a way that would empower you to reproduce it or improve upon it and distribute your improved cola drink to the rest of the world.
The economics of intellectual property rights provides a straightforward rationalization of why the CocaCola production 'regime' is organized in this way. The problem of intellectual property rights is about creating incentives for innovators. Patents, copyrights, licensing schemes and other means of 'protecting' knowledge assure that economic rents are created and that some proportion of those rents can be appropriated by the innovator. If that were not the case, a new and improved formula would immediately be available for free to anyone who chose to look at it. The person who invented that formula would have no claim on the knowledge or any part of the profits that might be made from selling drinks engineered from it. The system unravels, because that person no longer has any 'rational' incentive to innovate in the first place."
...
"Collaborative Open Source software projects such as Linux and Apache have demonstrated, empirically, that a large, complex system of code can be built, maintained, developed, and extended in a nonproprietary setting where many developers work in a highly parallel, relatively unstructured way and without direct monetary compensation."
...
"Mark Smith and Peter Kollock have called Linux 'the impossible public good'. Linux is non-rival and non-excludable. Anyone can download a copy of Linux, along with its source code, for free, which means it is truly non-excludable. And because it is a digital product that can be replicated infinitely at no cost, it is truly non-rival. For well known reasons public goods tend to be underprovided in social settings.6 The situation with Linux ought to be at the worse end of the spectrum of public goods since it is subject additionally to 'collective provision' -- the production of this particular collective good depends on contributions from a large number of developers. Stark economic logic seems to undermine the microfoundations for Linux. Why would any particular person choose to contribute -- voluntarily -- to a public good that he or she can partake of unchecked as a free-rider? Since every individual can see that not only her own incentives but the incentives of other individuals are thus aligned, the system ought to unravel backwards so that no one makes substantial contributions.
Linux also is an 'impossibly' complex good. An operating system is a huge, highly complicated and intricate piece of code that controls the basic, critical functions of a computer. It is the platform or the foundation upon which applications -- word processors, spread sheets, databases and so on -- sit and run. To design a robust operating system and to implement that design in code is a gargantuan task. Testing, debugging, and maintenance are frequently even harder. Computer users will run an operating system in a nearly infinite number of settings, with functionally infinite permutations leading to infinite possible paths through the lines of code. Complex software is less like a book and more like a living organism that must continually adapt and adjust to the different environments and tasks that the world confronts it with.
There was a time when a single determined individual could write a reasonable operating system, but given the demands of computer applications at present that is no longer possible. The task needs to be divided, which immediately becomes a problem of coordination within a division of labor. The standard answer to this question has been to organize labor within a centralized, hierarchical structure -- i.e. a firm. An authority makes decisions about the division of labor and sets up systems that transfer needed information back and forth between the individuals or teams that are working on particular chunks of the project. The system manages complexity through formal organization and explicit decisional authority. While transaction costs (particularly of moving information and tacit knowledge around) reduce the efficiency of hierarchical coordination in a complex task like software development, the job gets done and an operating system -- imperfect and buggy, but functional -- is produced."
...
"If altruism were the primary driving force behind open source software, no one would care very much about who was credited for particular contributions or who was able to license what code under what conditions. If Linux were simply the collective creation of 'like-minded' individuals who cooperate easily because they are bound together by semi-religious beliefs, there would be little disagreement in the process and little need for conflict resolution among developers. Beyond these overly simplistic and naïve tales lies a more subtle story of social and political economy, that has important implications for arguments about the logic of production in the 'new' economy.
A good explanatory story must be social because Linux is a collective good: it is a body of code built, maintained, developed, and extended in a non-proprietary setting where many developers work in a highly parallel way. It must be political because there exist both formal and informal structures and organizations, that function to allocate scarce resources and manage conflicts as well as promote certain practices and values. And self-evidently it must be economic, because at the core of the Linux process are individuals who engage in some kind of cost-benefit analyses and are maximizing or at least satisficing along some kind of utility function.
No single piece of this story -- even if 'correct' -- would by itself explain the outcome. Another way to put this point is simply to argue that Linux rests on a set of microfoundations -- the motivations of individual humans that choose freely to contribute -- as well as on macrofoundations -- social and political structures that channel these contributions to a collective end.
In addition to elucidating the logic of both, I will argue in this section that the two are autonomous from each other. The macro-logic of open source does not reduce to an aggregation of the motivations of the individuals who participate. More simply, this is not a self-organizing system. And the microfoundations that make up individual utility functions do not follow directly from a social and political structure that is somehow exogenous. I construct my explanation for the Linux process in three steps:
- What are the core microfoundations, the motivations that make up the guts of cost-benefit analyses and utility functions?
- What is the economic logic situating the collective good at play?
- What are the social and political structures that, in the context of individual motivations and the economic logic of software creation, drive the two essential dynamics that lead to successful open source development: maintaining coordination on the focal point, and managing complexity."
...
"Individual Motivations. The fun, enjoyment, and artistry of solving interesting programming problems clearly motivate open source software developers. To the extent that choosing your own work reduces perceived drudgery, it might be better to commit your time to an open source project than to a hierarchically-managed project where someone else can tell you what to do. Drudgery-type tasks should get taken of, in the aggregate, by two means. There may be someone in the community that finds a particular task challenging and interesting, even if it appears annoying to most. And there may be others for whom solving a particular problem, even if mundane, is important to a job responsibility. In both cases, the system benefits from increased numbers of users: there is more variation in what people find inherently interesting, and as Linux use expands and more people use it in their organizations they will write patches and drivers to help them in their daily work and share those 'boring' pieces of code with others.
Reputation also is clearly an important motivator. Of course this depends on a de facto intellectual 'property rights' system, in the sense that contributors must be assured in advance that they will get appropriate credit for what they do. As there is no law or patent system to provide this assurance, the system rests upon trust in a leader who reliably grants credit in a readme or history file and does so over time in ways that are perceived as fair. This supports directly the Lerner/Tirole argument about signaling. To the extent that programmers seek reputation with the intention later to monetize that reputation, reputations must clearly signal the importance and technical sophistication of a programmer's particular contribution. Peer review makes sense, as Lerner/Tirole point out, because excellent code is craftsmanship and there is no precise metric for quality outside the judgement of clever peers.
Reputation of this sort also functions to attract more cooperators. The logic here is that people seeking to generate good reputations for themselves will preferentially cooperate with other high quality coders since the marginal payoff from hard work in a joint project is higher when your collaborators are as good or better than you are."
...
"Economic Logic." The starting point for most economic analyses of open source is a standard collective action type analysis.57 Open source software is the epitome of a non-excludable good. It is also non-rival in the sense that any number of users can download and run Linux, without decreasing the supply that remains for others to use. In this context the economic puzzle is straightforward. For well-known reasons public goods (non-rival and non-excludable) tend to be underprovided in non-authoritative social settings. The situation with Linux ought to be at the worse end of the spectrum of public goods since the software depends on 'collective provision' -- it would not exist without contributions from a large number of developers. Why would any particular person choose to contribute -- voluntarily -- to a public good that he or she can partake of unchecked as a free rider? Since every individual can see that not only her own incentives but the incentives of other individuals are thus aligned, the system ought to unravel backwards so that no one makes substantial contributions, and there is no public good to begin with.
Part of the answer lies in individual motivations I explained above, that go beyond the narrow version of rational calculations that generate standard arguments about collective action problems. But there is also at play a larger economic logic that reframes the problem of collective action in this particular setting."
"Rishab Aiyer Ghosh takes an important step toward explicating that logic. Using the image of a vast tribal cooking pot, he tells a story about collective action where one person puts in a chicken, someone else puts in carrots, another person puts in some onions…and everyone can take out delicious stew. Nonexcludability is an issue because if anyone can take bowls of stew out of the pot without necessarily putting anything in, there might be nothing left for those who did contribute and thus they are unlikely to put anything in in the first place.
But what if the cooking pot was magically non-rival -- if production of stew simply surged to meet consumption without any additional expenditure of effort. Then everyone knows that there will always be stew in the pot and that even if people who don't put anything in take some out, there will still be plenty left for those who did contribute. In this setting an individual faces a different calculus: "you never lose from letting your product free in the cooking pot, as long as you are compensated for its creation."
The Internet makes a digital product like software 'magically' non-rival. Because a digital product can be copied an infinite number of times at no cost, this is a cooking pot that creates as many bowls of stew as there is demand. Given that, how are you going to be compensated for creating your product? In the digital environment this too is nearly straightforward although slightly more subtle. When I put my product into the cooking pot, I am giving away in effect a thousand or a million or really an infinite number of copies of that product. However, in my private utility calculations, multiple copies of this single product are not very valuable -- in fact the marginal utility of an additional copy to me is de facto zero.
But single copies of multiple products are, to me or any other single user, immensely valuable. In practice, then, I am giving away a million copies of something, for at least one copy of at least one other thing. That is a good trade and clearly a utility enhancing one for anyone who makes it. As Ghosh puts it, 'if a sufficient number of people put in free goods, the cooking pot clones them for everyone, so that everyone gets far more value than was put in.'"
...
"I believe the solution to this puzzle lies in pushing the concept of non-rivalness one step further. Software in some circumstances is more than simply non-rival. Operating systems like Linux in particular, and most software in general, are actually subject to positive network externalities. Call it a network good, or an anti-rival good (an awkward but nicely descriptive term). What I mean by this is that the value of a piece of software to any particular user increases, as more people download and use the same software on their machines.
Compatibility in the standard sense of a network good is one reason why this is so. Just as it is more valuable for me to have a fax machine if others also have fax machines, as more computers in the world run a particular operating system it is easier to communicate and share applications and files across those computers, making each of them more valuable to the user. Open source software makes an additional and very important use of network externalities, in debugging. Remember the argument that there exist an infinite number of paths through the lines of code in even a moderately complex program. The more users actively engaged in running a piece of software, the more likely that any particular bug will surface somewhere. And once a bug is identified it becomes possible to fix it, improving the software at a faster rate.
The point is that open source software is not simply a non-rival good in the sense that it can tolerate free riding without reducing the stock of good for contributors. It is actually anti-rival in the sense that the system positively benefits from free riders. Some small percentage of free riders will provide something of value to the system, even if it is just reporting a bug out of frustration. The more free riders in this setting, the better."
zurück zu Open Source Philosophie (Vorlesung Hrachovec, Winter 2008)
