George Dafermos, our favourite Peer Governance researcher at the TU Delft, has kindly provided me with some research papers in that area, which allows us a much-needed update of our Governance section.
I will be abstracting/excerpting a number of them.
The first one is already quite a gem.
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]
Apart from a study of participatant motivation, and how it differs in pure communities from hybrid (firm owned) ones, it offers a very clear definition of Gated Source Communities.
Most valuable is its typology of the governance rights (i.e. in decision-making and property), that can be wielded by a firm over the voluntary developers.
See here for details.
So what are Gated Source Communities?
Sonali K. Shah:
“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.”
And what are their Governance rights vis a vis the community of developers?
Sonali K. Shah:
“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.
“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.
“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.”