Home

Project outline

Final report

Press coverage

related research

people

 

Papers

Open source versus proprietary code – competition, cooperation, and balance
Marshall Van Alstyne, University of Michigan
mvanalst@umich.edu

This brief statement proposes research on two economic and legal questions inherent in the choice of Open Source Software (OSS) relative to proprietary code.[1]

1. What are the socially optimal intellectual property and licensing regimes that balance interests in short term access and long term creation?

There are at least two great challenges for intellectual property law regarding software. The first is balancing the incentives to invest in it – including creation, maintenance, usability, manuals, etc. – against the social cost of these incentives. Usually, the socially optimal price of a product is its marginal cost. So, for software, whose marginal cost of re-production is zero, welfare is greatest when the price is zero. The trouble is that first copy costs are not zero. The price after creation needs to account for the welfare hole before creation when no one derives value from software they need. Since writing software also involves subroutine reuse, programmers also benefit from having a large base of freely accessible code. But again, the trouble is that a large after-creation code base had to come from somewhere. The sooner it’s created, the sooner others can use it and build on it so the greater the need for incentives. But most incentive mechanisms limit access and reuse after creation so they lower the desire for incentives.

The problem is that short-term access restrictions, caused by incentives, are often swamped by long-term growth and innovation, also caused by incentives. Research needs to contribute a better understanding of how IP mechanisms promote and retard software innovation, and how they facilitate adoption and reuse. It should also help establish reasonable time limits on incentives that enhance social welfare.

The second challenge is how to protect software with dual properties. Assuming that software merits some form of protection – and even GPL effects broad access via IP law – what do we protect? Do we protect form or function? Are principles of copyright that protect expression and derivative works more suitable than principles of patents that protect process and functional equivalence? As Samuleson and others have noted, software serves as a “machine in text.” In interfaces it exhibits properties of expression but as instructions it operates as a process. It falls between a work of expression and an innovation.

The trouble is that protecting expression can block others from obvious representations while protecting function and its equivalents can block others from obvious algorithms. Research needs to contribute a better understanding of what aspects of software might be protected as reasonable reward. As a special case of information, how do we define software and how do we facilitate its growth and distribution throughout a society?

2. How should OSS and proprietary code compete? What are the optimal behaviors for each? Who gets what value?

What is software value? Let us suppose it is the increased satisfaction of those who use it. Both systems compete for users including user-developers. Whether the return to programmers is “egoboo” or “egobucks,” software must be used in order to be useful. The measure of software’s real utility is the measure of value to its user base, individuals and institutions, now and in the future. No use means no value.

If value is created through use, the tricky part is deciding how to compete for users and how to share the value created. OSS competes for value in two ways. It creates value to users through free – in terms of liberty and usually price – access to code. It also creates value through the satisfaction authors derive from having users. Even in gift cultures, a donor gets no satisfaction if a recipient rejects a gift. This complicates economic welfare analyses because most models do not account for people having preferences over other people’s consumption habits, as authors do here. But in both cases, user and author satisfaction, value is rarely transferred. Users keep their value and author satisfaction grows in proportion to user value.

This differs from the commercial model. Proprietary code competes on value to the same two communities, users and developers, but on different terms. It creates value for users but differs in typically offering functionality that is protected and unavailable elsewhere. Access is restricted and value is transferred in exchange for access. If developers derive satisfaction from having users it is usually less than the satisfaction of earned income.

To these sources of value, we need to add network externalities. These are the demand economies of scale or benefits that an existing network of adopters gets from new adopters. In the case of software, there is a largely unrecognized two-sided or “internetwork” externality (see working papers by Parker & Van Alstyne, Rochet & Tirole, Caillaud & Jullien). This arises because users benefit from a larger developer pool just as developers benefit from a larger user base. Competing platforms need to get both sides on board, just like credit cards need merchants who accept them and consumers who carry them. We’ve worked on a model of competition, based on internetwork externalities, that uses free information strategically to bring both sides on board <http://papers.ssrn.com/paper.taf?abstract_id=249585>. That logic focuses solely on free in the sense of price. We’d like to extend it to support free in the sense of liberty.

I propose that each system, open source and proprietary, benefits by becoming a bit more like the other. Commercial code competes more effectively if it allows wider access, encouraging users to keep a greater share of their value, and promoting network effects. Open code competes more effectively if it succeeds in transferring some nonzero fraction of user value to developers, growing their ranks, setting expectations for future growth, and helping them do what they do. Transfers need not be dollars, as developers contribute reciprocally to one another, but neither should users expect always to free ride.

Research should contribute an understanding of what users and developers value, of how these communities interact, and of what middle ground might provide more hybrid vigor.


[1] Prepared for the Brussels workshop on OSS research, it is intended for a general audience.