Openness in Open Source Software Development
Hoddinott and Bailetti
The four factors of openness
Peter Hoddinott and Tony Bailetti [1]:
“we had occasion to find ourselves struggling as we tried to make sense of instances of the word open in the context of community code. For example, we found instances where open meant that releases of the code were made available to the general public (i.e., non-members of a consortium); however, releases to the general public were delayed 12 months from the time it was available to the members of the consortium. We also found instances where what open meant depended upon the level of membership. The more expensive memberships provided these members more privileges to participate in and influence the processes, for example with veto power. In these examples, open is not equated with full access; instead, open is a matter of degree and that degree is metered out in a distinctly defined hierarchy of privilege.
This seeming confusion and differences about what is open and what is source and the use of open source to refer to phenomena that fall well outside the OSD, led us to conclude that we need to better understand the characteristics of the systems in which open source assets are produced, used and distributed.
We conceptualize any such system as being comprised of four components:
1. Network: the network of individuals and organizations that produce, use and distribute an asset
2. Processes; the processes, approaches, rules and understandings that lead to the production, use and distribution of an asset
3. Governance: the governance structure of the organization and the projects within the organization
4. Value: value created through collaboration and value appropriated through competition
We observe that a healthy open source system is required to compete with a strong proprietary system; that is, an open source system cannot compete by virtue of the distribution license alone.
What one would generally agree upon as being an open source system could be expressed in terms of the health of its four components. Such a definition would not be static, but would arguably be more accurate and useful in determining the true value of an open source system. For example, one could speak in terms of a system not having reached the status of being open source until it is deemed to be healthy. And an open source system may subsequently cease to be an open source system if its health deteriorates beyond some point. This line of inquiry could then further leverage health of the four components as a means for distinguishing other types of systems such as closed systems and community systems.
Our initial suggestion as to what is relevant for assessing the health of each of the four components of a system is as follows:
1. Network: Large, distributed and diverse: We distinguish between an asset produced by a well developed network from an asset produced by a small number of collocated producers who have similar characteristics. A general reference model for an open source asset would be one that is produced by a well developed network that is able to integrate, test, and quality assure contributions from a large number of diverse individuals and organizations dispersed throughout the world
2. Process: Includes meritocracy where one is recognized for the quality of their contributions; transparency in communications and guidelines; recruitment and promotion methods; and mechanisms for dealing with difficult people
3. Governance: Includes participation; relationship between contribution and the influence that can be asserted; membership's influence over a project, influence over the overall system governance, and ability to alter the governance structure
4. Value creation and appropriation: Usefulness of the asset; how free-riders are addressed--if it is too easy to appropriate value no one would pay for a membership or undergo an apprenticeship to move from being a developer/contributor who writes code or documentation to a committer with write access to the codebase; access to the asset by virtue of the license.” (http://www.osbr.ca/archive.php?issue=10§ion=Ar#A2)
West and O'Mahony
Source
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”
URL = http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf
Definition: Transparency and 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.”
(http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)
Introduction
West and O’Mahony:
“there were two distinct types of openness: transparency and accessibility. Transparency allows outsiders (i.e. non-sponsors) to understand what is happening and why — and, in the case of an open source community, allows use of the community’s final product, the source code. Accessibility allows external participants to directly influence the direction of the community to meet their specific wants and needs, regardless of whether the external party is a hobbyist or an organizational adopter. In some cases, external contributors could be sellers of goods and services that might either compete with or complement the sponsor’s business.
How were these two different types of openness provided? By comparing our data across 12 sponsored open source projects, we found that the design choices made by sponsors of open source communities could be categorized into three dimensions: 1) the organization of production; 2) community governance and 3) intellectual property.
Decisions with regard to the organization of production shaped how code development would took place, while community governance decisions shaped the processes by which decisions were made within the community; and intellectual property design decisions affected the allocation of rights to use the community’s output.
these three dimensions of community design formed the basis of a participation architecture.”
(Note from West and O’Mahony: The concept of an “architecture of participation” was initially articulated by O’Reilly (2005) as a set of heuristics that encourage participation and innovation. The “participation architecture” construct we develop here is intended to meld that earlier usage with an interorganizational analog to the “technical architecture” of Baldwin and Clark (2006).} (http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)
Typology Introduction: The Three Dimensions of Design
i.e. 1) the organization of production; 2) community governance and 3) intellectual property.
West and O’Mahony:
““there were two distinct types of openness: transparency and accessibility. Transparency allows outsiders (i.e. non-sponsors) to understand what is happening and why — and, in the case of an open source community, allows use of the community’s final product, the source code. Accessibility allows external participants to directly influence the direction of the community to meet their specific wants and needs, regardless of whether the external party is a hobbyist or an organizational adopter. In some cases, external contributors could be sellers of goods and services that might either compete with or complement the sponsor’s business.
How were these two different types of openness provided? By comparing our data across 12 sponsored open source projects, we found that the design choices made by sponsors of open source communities could be categorized into three dimensions: 1) the organization of production; 2) community governance and 3) intellectual property.
Decisions with regard to the organization of production shaped how code development would took place, while community governance decisions shaped the processes by which decisions were made within the community; and intellectual property design decisions affected the allocation of rights to use the community’s output.
these three dimensions of community design formed the basis of a participation architecture.
We found that the degree to which sponsors’ offered transparency or accessibility in these key areas affected sponsors’ ability to attract external participants and grow these communities. By examining sponsors’ community design decisions, we discovered that one of the primary challenges sponsors faced was how to how manage the tension between controlling the community in order to leverage their investment in it and opening up access to the community in order to attract greater growth of participants.” (http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)
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.”
(http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)
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.” (http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)
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.” (http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)
More Information
West, Joel, 2003, “How open is open enough? Melding proprietary and open source platform strategies,” Research Policy 32 (7), 1259-1285.
West, Joel, 2007. “Value Capture and Value Networks in Open Source Vendor Strategies,” Proceedings of the 40th Annual Hawai‘i International Conference on System Sciences, Waikoloa, Hawai‘i, p. 176.