Participation Architecture

From P2P Foundation
Jump to: navigation, search

From The Role of Participation Architecture in Growing Sponsored Open Source Communities. By Joel West and Siobhán O’Mahony at


West and O’Mahony:

“We define a participation architecture as the socio-technical framework that extends opportunities to external participants and integrates their contributions.

A participation architecture guides interactions and exchange in an online community and encompasses the social, legal, and technical capabilities offered to community members. While sponsored communities were by some measures less open than most autonomous communities, in all cases, the decision to create an open source community was inherently a more open approach than a proprietary software development approach.” (


West and O'Mahony look at how transparency and accessibility are expressed in 3 dimensions of organizational design: i.e. 1) the organization of production; 2) community governance and 3) intellectual property.

Transparency vs. Accessibility

West and O’Mahony:

“Transparency meant that the code was publicly available, that most of the software production process was discussed on public mailing lists or discussion boards, and that the software release cycle and goals were also provided on the community website.”

“The second type of openness sponsors considered when designing a sponsored community was the degree of accessibility — the amount of control sponsors would relinquish to the community. An accessible community not only provides visibility, but allows some outsiders to gain access to either the project’s code repository, community planning processes, or strategic decision-making.

Sponsors explicitly recognized that granting accessibility triggered the loss of some corporate control in a way that a purely transparent model did not — particularly when external participants were from other (possibly competing) companies.” (

Openness in the Organization of Production

West and O’Mahony:

“We identified three design parameters that provided contributors with transparency and accessibility to production processes:

1. Live code access provides transparency by offering the community the chance to review the most recent “live” version of source code on the community website — which is more likely to have bugs than a finished product. Nearly all of the sponsored communities (10/12) allowed external participants to anonymously access the most current source code, subject to the sponsor’s license terms. External contributors were thus able to follow the community’s development cycle and contribute bug reports if they were so inclined.

2. Public commit process refers to the opportunity for community members to become directly involved in the production process by earning (through demonstrated technical proficiency) the right to directly commit software changes to the community repository.

While all of the autonomous communities provide such accessibility, only some (5/12) of the sponsored communities did so. Seven of the sponsored communities did not publicly explain how one could go about acquiring commit rights to their projects, but most of them (6/7) encouraged people to send code patches via email.

The lack of information about gaining committer rights is not necessarily an inhibitor for participation but it limits the status and influence that a contributor can achieve. As one community member explained, “people can be phenomenally valuable contributors without having access for a long time. Somebody else can check their code, but people don’t like it. It is seen as a mark of belonging.” Sponsors that did not provide commit rights recognized such rights would increase participation but were unwilling to relinquish that much control over their code.

3. Subproject creation is a mechanism by which a community based on the sponsor’s original code can grow to assume new functionality or new directions. We defined subprojects as new “start-up” projects that were allowed to govern themselves and address unmet needs independent of the larger community; allowing creation of such subprojects provides accessibility by decentralizing control over growth and innovation in the community. While all of the autonomous projects allowed community members to autonomously propose subprojects based on their own initiative, only 5 of the 17 sponsored communities did so.

Source code access offers potential external community participants transparency into the development process which can help them learn how the code is developed. Without awareness of the community’s production process, the learning curve to make a meaningful contribution and thus gain membership or access within the community will be limited. The ability to create subprojects offers access to external parties by providing them opportunities to shape the future direction of the project. This type of access sends a powerful signal as to the ease with which external contributors can get new ideas proposed and accepted. Allowing individuals the right to earn commit rights offers the ultimate degree of accessibility – the ability to make direct contributions to the code.” (

Openness in Governance

West and O’Mahony:

“We define openness in open source governance as the amount of decision-making control that sponsors relinquished to the community.”

To provide both leadership and legitimacy, some communities have a formal concept of membership, vesting members with key governance decisions, and are thus more accessible to participants. For other communities, de facto control remains with founding individuals (due to superior legitimacy or technical knowledge) or with founding firms (that provide the bulk of ongoing resources). The design levers available for managing openness in governance include:

1. Nonprofit foundations. All five individually founded communities and two sponsor-founded communities created a formal, legal, non-profit foundation to help manage community governance and assets; however, for historical reasons, the Linux foundation plays a more limited role than the others. As O’Mahony (2003, 2005) identifies, such foundations provide institutional permanence independent of any one individual, as well as legal status to negotiate with external entities (largely for the provision of resources). Because the creation of a non-profit foundation requires a board of directors and regular meetings, the introduction of such organizations also increased the transparency of control of the community assets.

2. Membership. Four out of five of the individually founded open source communities have formal processes by which an individual is recognized as a member; one community recognized both individuals and firms as separate classes of members. Only one sponsor founded community project created a nonprofit foundation with a membership base, while two others were under development at the time of our study. After offering external contributors membership rights, this sponsor experienced unprecedented growth in participation. Communities with a membership base provide members with some voice in formal governance matters (typically through annual elections and the right to vote on project wide decisions such as license or name changes), while nonmembership communities remain either fully sponsor-controlled or retain ad hoc governances mechanisms.

3. Membership fee. Two communities (one individually founded and one sponsor founded) obtain funds from interested firms by selling memberships at a range of prices. In general, membership fees were not adopted by sponsors trying to create communities, but by those sponsors trying to create commercial ecosystems.

4. Release authority. The ultimate test of an online production community is who makes the final production decisions. For an open source community, this decision occurs when software is released. This authority may vest in the members, the affiliated foundation or remain with the sponsor or individual founder. Again there is a dramatic differences in openness between autonomous and sponsored projects: the community holds authority in all but one autonomous community (Linux), but only in two of the 12 sponsored communities. Such limited accessibility appears to reflect the sponsor’s desire to align the features, quality and schedule of open source releases to its commercial goals.”

In conclusion:

“By creating a membership organization and the opportunity to elect leaders, a few sponsors offered potential contributors the ability to develop a sense of belonging and become more vested in the community’s future. The ability to gain “membership status” was viewed as a motivational and recruitment tool. Sponsors who adopted these community design features did so with the belief that divesting some control was necessary in order to attract talented contributors. However, most sponsors did not create an independent form of governance, retained exclusive release authority, and final say on all key community decisions.” (

Openness in the Governance of Intellectual Property

West and O’Mahony:

Parameters of openness:

“1. Content ownership. Most communities that created an affiliated foundation also vest ownership in the foundation (Linux an exception), as did two sponsored communities. For the other sponsored communities, ownership remains with the sponsor. Ownership of the content by a foundation provides a credible assurance to community participants that the code will remain available to participants in perpetuity (O’Mahony 2005). The direct ownership of the code by sponsors in most of the communities was a clear direct and symbolic measure of their design to maintain ongoing control over the terms by which outside participants access the code.

2. Subproject ownership. For the projects that allowed creation of new subprojects, the conditions of access were not necessarily the same as for the core code. For the five sponsored projects that allowed subproject creation, in four cases, ownership of the subproject output was the same as for the core project (two owned by the sponsor, two owned by the foundation); for one sponsored project, the output was owned by the contributing community members.

3. Software license. 10 of the 12 sponsored communities use one of the more than 50 licenses approved by the Open Source Initiative. As Lerner and Tirole (2005) and others have noted, the most popular open source license is the GNU General Public License (GPL). This widespread use and popularity among potential participants influenced the decisions of two sponsors — Mozilla and Helix — to offer their product under both their own license and the GPL, while other sponsors mentioned the importance of using a license deemed compatible with the GPL or the Lesser GPL (LGPL). Two sponsors used licenses that are as yet unapproved by the OSI. One community (Sendmail) was founded using an approved license (BSD) but the sponsor subsequently chose to release a major update under a nonapproved license that discriminates against forprofit users. The last (Sugar) created its own license (adapted from the Mozilla Public License) that required publicity for their technology when used by service providers.4

4. License type. Open source licenses such as the BSD or Apache license allow recipients to use the code largely without restriction, while “free software” licenses (notably the GPL) compel recipients to return any modifications or changes (West, 2003). Rosen (2004) classifies these two types as “permissive” and “reciprocal”; a few licenses (such as the LGPL) impose reciprocal obligations on part but not all of the code. Four of the sponsored communities in our sample use a dual license strategy to implement price discrimination, with non-profit users selecting the free reciprocal license (i.e. the GPL) and for-profit users customarily paying to use the software without the reciprocal obligations (cf. Välimäki, 2003).

In conclusion:

The ownership of code was the most dramatic difference between autonomous and sponsored projects, in that the sponsor in nearly all cases retained ownership of the core (if not subproject) code. A subset of the sponsors used the objectionable restrictions of the reciprocal license to provide revenues through a dual license policy, but otherwise the sponsored and autonomous communities followed similar license policies, either using standard or their own open source licenses.” (


Article: The Role of Participation Architecture in Growing Sponsored Open Source Communities. By Joel West (San Jose State University College of Business) and Siobhán O’Mahony (UC Davis Graduate School of Management) February 6, 2008 preprint version of Industry and Innovation, Special Issue on “Managing Open Innovation Through Online Communities”


More Information


Baldwin, Carliss Y. and Kim B. Clark, 2005, “The architecture of cooperation: Does code architecture mitigate free riding in the open source development model? Harvard Business School Working