Motivation, Governance, and the Viability of Hybrid Forms in Open Source Software Development

Article: Motivation, Governance, and the Viability of Hybrid Forms in Open Source Software Development. Sonali K. Shah, University of Illinois at Urbana–Champaign. MANAGEMENT SCIENCE, Vol. 52, No. 7, July 2006, pp. 1000–1014

URL = http://faculty.washington.edu/skshah/Shah%20-%20Motivation,%20Governance,%20Hybrid%20Forms.pdf

Abstract

"Open source software projects rely on the voluntary efforts of thousands of software developers, yet we know little about why developers choose to participate in this collective development process. This paper inductively derives a framework for understanding participation from the perspective of the individual software developer based on data from two software communities with different governance structures. In both communities, a need for software-related improvements drives initial participation. The majority of participants leave the community once their needs are met, however, a small subset remains involved. For this set of developers, motives evolve over time and participation becomes a hobby. These hobbyists are critical to the long-term viability of the software code: They take on tasks that might otherwise go undone and work to maintain the simplicity and modularity of the code. Governance structures affect this evolution of motives. Implications for firms interested in implementing hybrid strategies designed to combine the advantages of open source software development with proprietary ownership and control are discussed.

From the introduction:

"This paper investigates two specific research questions from an empirical perspective. First, why do individuals participate in innovation communities? And, second, how do differences in governance affect individuals’ reasons for participation, as well as the type and quality of their contributions? To address these questions, this paper examines the motives of participants in two large and well-known communitybased software development projects. One community is open source and the other is gated source, meaning that the communities rely on different governance structures, although both seek to attract the efforts of volunteer software developers. The study of two communities with different governance structures allows me to investigate how such differences affect individual participation."

Findings

"Three key findings were uncovered. First, reasons for participation vary, but a critical subset of open source developers—hobbyists—participate because they derive enjoyment from the act of creating code. Second, reciprocity is a crucial factor in motivating contributions to the community. Third, governance structure has a first-order effect on patterns of participation. Two additional distinctions not present in the existing literature also emerged. First, the creation and contribution of code and knowledge to the community are two different activities and are motivated by different sets of factors.1 Second, the outcomes that motivate behavior are not always the same as the outcomes generated by the behavior. For example, some developers do attain status within communities and a select few have leveraged their open source efforts into high-paying jobs. Yet, it does not appear that these developers originally participated in the hopes of obtaining these rewards."

Issues with Gated Communities

• "Although the open source community greatly benefited

from the presence of hobbyist developers, virtually all long-term gated source participants continued to focus on need as their primary reason for project involvement

In describing their activities within the gated source community, participants voiced blatant disapproval of two elements of the governance structure: The level of code control held by the sponsor (the sponsor is the only actor able to make changes to the source code) and ownership by the corporate sponsor.

Day-to-day control over the code made participants question whether their efforts would go to waste, as their needs and activities might not be reflective of the sponsor’s financial interests:

I answer questions and stuff, but I don’t feel the need to contribute my changes to the community. It’s time consuming and I don’t know if [the corporate sponsor] will do anything with it

At the end of the day, they make the decisions with their commercial licensees in mind. (Long-term participant, gated source community, United States)

Ownership by the corporate sponsor raised four issues.

The first issue involves unrestricted use of the code by the participant:

Why should I contribute to something that is not mine?

It’s okay if it’s mine and someone else’s and someone else’s, but I have to be able to use it the way I want, whenever I want. (Short-term participant, gated source community, United States)

The second issue involves the fairness of restrictions on wider code use and distribution, as illustrated below.

I make the changes that I really need and so does everyone else and we benefit from one another.

There are a lot of things the project still needs that I keep asking [the corporate sponsor] to develop -- they are not absolutely critical, but they’d take the software to the next level and expand its capabilities : if I develop it and then [the corporate sponsor] says I can’t let others see it or work on it or use it in whatever way that makes sense—now come on! That’s not how it works! (Long-term participant, gated source community, United States)

The third issue involves various scenarios under which the sponsor might inadvertently or deliberately, in the words of a participant, “appropriate code away” from the community.

For example, conflicts over ownership and use might arise if the sponsor goes out of business, chooses to discontinue the project, or wants to sell the code.

The fourth issue involves problems created by the commercialuse clause of the license. Although the code may be used freely for developmental work by other firms, commercial use requires the negotiation and payment of a royalty fee to the sponsor. Many participants were wary that the sponsor might stipulate outrageous license terms for commercial use after the participant (on behalf of an employer or himself) invested in the creation of a product based on the code.

Due to these issues, those who participated tended to be developers with no other option but to use the gated source software, those who believed that they could trust the sponsor (e.g., the sponsor’s existing customers), and those willing to work under the licensing constraints (e.g., start-ups and consultants who believed they would gain financially from the technology). Many of these participants chose not to contribute the code that they created, leaving other developers with less to work with and build on. In the long run, this limits cumulative development activity and overall value creation. When these participants did contribute, their contributions often stemmed from strategic concerns."

Property Rights, Fairness, and Reciprocity

"This study highlights the importance of fairness in supporting exchange relationships. In this setting, property and decision-making rights affected individuals’ perceptions of fairness, which in turn affected their behaviors. Participants in each community were aware of who controlled property and decisionmaking rights and appear to view that actor as their primary exchange partner. That is to say, when assessing reciprocity within the community and choosing the extent to which they wish to create and contribute code, open source participants focus on the actions of volunteer community members, whereas gated source participants focus on the actions of the corporate sponsor.

The possibility of opportunistic ("unfair") actions by those holding control rights can both decrease and alter the character of volunteer participation. Gated source developers feared that the corporate sponsor might exercise control rights in a strategic manner benefiting the corporation over the community. As a result, gated source participants invested effort only if they very much needed the software and were less likely to contribute their findings to the community. Moreover, they were unwilling to engage in fun and challenging development activities, depriving themselves of an enjoyable activity and depriving the community of their efforts and talents. From the perspective of behavioral game theory and evolutionary psychology, it is not surprising that perceptions of fairness weigh heavily into an individual’s decision to work with others and even leads individuals to punish others at a cost to themselves (Barkow et al. 1992; Kahneman et al. 1986a, b). From this perspective, the creation of a neutral and accessible commons is crucial for fostering community-based innovation. Keeping a resource in the commons both allows others to draw on the resource and mitigates the number of strategic games played by others (Lessig 2001, p. 72)"

Governance Issues

"Here I discuss the impact of two broad sets of governance mechanisms—decision rights and property rights—on participation.

Decision-Making Rights

• Code Control.

In the gated source community, only the corporate sponsor is allowed to alter the source code. This strict control over the code affects both need-driven and hobbyist participants. Need-driven participants worry that their voices will be drowned out by the needs of the firm and its customers when software-related decisions are made. Such control limits the ability of hobbyists to work and contribute in self-defined ways. In addition, the volume of feedback and overall activity is likely to decline due to both decreased participation and tighter control over what is committed to the source code and, therefore, used by others.

• Domination of Mailing List Interaction.

Firms may inadvertently dominate mailing lists through a desire to influence the direction of the project or because firm employees represent a substantial portion of the participant pool, as might be the case when a firmsponsored community is newly created. This may act to inhibit developers from voicing heterogeneous views, resulting in decreased volunteer participation. This relationship was not directly observed in this study, however developers’ distaste of tightly controlled open source projects was observed.

Property Rights

Private Ownership of Source Code.

Private ownership of the code acts to dismantle the collective development process in a variety of ways. Most noticeably, ownership by the firm creates the possibility that the developer will not have access to the code at a later date. Participants value the results of their efforts and expect to continue using the software well into the future. The open source project gave them this right, but the gated source project did not make this guarantee. Private ownership also appears to inhibit reciprocity: if the firm is not donating the code to the community, why should the developer take additional time and effort to donate code to the firm?

Restrictions on Use, Modification, and Distribution.

... act to reduce the degrees of freedom that an individual can exercise when using and creating the code, particularly when compared to open source licensing arrangements. These restrictions can be thought of as limiting the value available to the individual developer, i.e., the developer can only use the code for certain purposes, modifications made and deployed must meet community standards (rather than his own preferences), and the code may only be shared with others willing to abide by the community’s governance arrangements, thereby decreasing the volume of subsequent improvements and feedback that many developers relish. On the other hand, these restrictions might create value for the company.

Restrictions on commercial use in the gated source community created additional problems because licensing terms were negotiated with the firm on an individual basis. This decreased trust dramatically by creating the possibility of ex post hold-up problems. Restrictions on commercial use with terms set in advance and applicable to everyone may be less problematic.

Proprietary Modifications.

A large part of the longstanding debate between free and open source software advocates concerns proprietary modifications. Software derived from free software cannot be made proprietary. The “copyleft” provisions of the GNU General Public License (GPL) and similar

The restrictions placed on the gated code with respect to commercial use, modification, and distribution all licenses mandate that all derivative works be distributed under the same licensing terms as the original software, thereby ensuring that code remains free (Stallman 2001). In contrast, the open source definition, while inclusive of free software licenses, allows proprietary modifications to be made (Open Source Initiative 2004). There exist examples of successful projects governed by both types of licenses, although GPL-style licenses appear to dominate the landscape (Lerner and Tirole 2005)." (http://faculty.washington.edu/skshah/Shah%20-%20Motivation,%20Governance,%20Hybrid%20Forms.pdf)