Viability of Hybrid Forms in Open Source Software Development

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

URL = http://mansci.journal.informs.org/content/vol52/issue7/

Available via http://papers.ssrn.com/sol3/papers.cfm?abstract_id=898247

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.

Conclusion

"Governance practices can create shortcomings in hybrid forms, although some shortcomings can be ameliorated. For example, the firm sponsoring the gated source community has significant resources at its disposal and employed a team of developers and marketers to work on the gated source project. These employees took care of many of the tasks—such as assisting participants, incorporating suggestions and code, and maintaining the overall architecture of the code—that would have been fulfilled by volunteer hobbyists in the open source community.

Innovation communities represent a novel model for innovation development that has been documented in a number of diverse product areas. Our knowledge of this novel structure and the societal benefits it creates is growing, but many questions and issues remain to be explored. In this paper, I investigate issues pertaining to participation and governance in two software communities. I find that fun and challenge are key drivers of participation for hobbyists, a group that is critical to the functioning of the open source community. In addition, reciprocity and fairness are important issues, strongly affecting the willingness of volunteer developers to contribute to the community. Firms seeking to construct hybrid arrangements that balance community-based value creation with private value appropriation may encounter difficulties: the very mechanisms that allow them to appropriate private benefits may deter participation.

Excerpts

Reasons for participation

"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."

Open vs. Gated Communities

"The key distinctions between the open and gated communities are as follows. In the open source community, anyone can download, use, modify, and distribute the code. The code is owned by the collective and a special subset of developers, called committers, settle contested project decisions. In the gated source community, only those who have agreed to a license with the corporate sponsor can download, use, or modify the code. The license stipulates that the code may only be shared with other licensees. The corporate sponsor owns the code and retains the right to make project decisions. Finally, licensees who use the code for commercial purposes must pay a royalty to the corporate sponsor.

To be considered “open source,” a project’s licensing terms must meet the 10 requirements of the open source definition (Open Source Initiative 2004). Gated approaches attempt to selectively combine the benefits of collective development with the corporate benefits of private ownership and control. They are more restrictive than open source licenses from the perspective of the developer."

Volunteers Behave Differently in Open Source and Gated Source 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.

Ownership by the corporate sponsor raised four issues.

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

The second issue involves the fairness of restrictions on wider code use and distribution.

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."

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.

Those driven by their own needs might pursue either well-known or novel dimensions, potentially creating innovations that are useful to many or only to themselves, and that extend existing functionality or create altogether new functionality.

Cognitive evaluation theorists argue that intrinsic motivation is based on feelings of competence and self-determination—feelings supported by feedback in the form of information and rewards from external sources (Boggiano and Pittman 1992; Deci 1971, 1975; Deci et al. 1999; Lepper and Greene 1978). Informational content heightens feelings of competence and strengthens the feeling of internal control, raising (“crowding in”) intrinsic motivation. In contrast, controlling content heightens feelings of being stressed from the outside and strengthens perceived external control, decreasing (“crowding out”) intrinsic motivation. Additional research is required to understand the mechanisms by which the community encourages its members to provide informational content and quell controlling content.

Collecting such data on the career progression of volunteer software developers will improve our understanding of the individual and institutional-level factors supporting community-based innovation (for examples and a discussion of research on careers, see Barley 1989, Becker 1963, Goffman 1959, Hogg and McGarty 1990).

This information will aid in the design and management of innovation communities, and potentially in the design and management of other types of nonprofit organizations relying on volunteer labor.

It may also improve our ability to design more satisfying work environments for engineers and other technical professionals. 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).

For firms, community development offers the possibility to gain developmental assistance in noncritical areas and increase adoption (West 2003). Value appropriation requires the firm to define and control property rights. Unfortunately, activities that permit value appropriation by the firm are sometimes detrimental to value creation within the community."

Typology of Governance Rights in Gated Source Communities

Decision 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.

The restrictions placed on the gated code with respect to commercial use, modification, and distribution all 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."