Nonprofit Foundations and their Role in Community-Firm Software Collaboration

HBS Working Knowledge by Siobhán O'Mahony: Contributors to community-managed projects have created nonprofit foundations despite the fact that such formal structures are an anathema to the hacker ethos of technical autonomy and meritocratic decision making. The technical organizations that emerged since the federal government privatized the Internet may have partially influenced the design of these foundations, but some features are the unique product of managing community software in a commodity world. One thing that stands out from either the early Internet working groups or the typical corporate standard-setting bodies of the past is the role of nonprofit software foundations in enabling collaboration between a community of individuals and corporate actors.

...

Facilitating Community-Corporate Collaboration: A New Actor in the Supply Chain
The foundations that emerged in this study are incorporated, organized by and for individual members, and produce benefits for the public, but do not redistribute profits to their members. What is unique about these foundations, in relation to technical communities of the past, is that these foundations also own assets that are sold by third parties in commercial markets and may in fact compete with other commercial offerings. Firms that use free and open source software have, in effect, allowed community-managed projects that grew out of a politically motivated social movement to become a part of their supply chain. This interdependence has fostered a new set of working relations among community projects, their foundations, and firms. Figure 1 [not shown here. -Ed.] outlines the role of nonprofit foundations in this new collaboration model. Foundations hold the assets and property rights of technical communities that produce software, but do not pay their developers or redistribute profits to their members. Community members retain the ability to set their own technical direction and manage the culture, norms, and governance of their own projects. In return for assigning their intellectual property to a foundation, they are granted protection from individual liability and a means to represent the project.

Firms can sell and distribute the community's work at a profit by creating complementary software, hardware, and services that reflect their conception of market needs. They can modify the work of the community as long as they respect the terms of community licenses and contribute improvements back to the code base where required. In return, firms offer sponsorship and support to both individuals and foundations. Individual volunteers that are working on components of critical interest to firms may be hired to continue their efforts as sponsored contributors. Proprietary code, financial resources, hardware, and equipment that firms wish to donate to the project are entrusted to the foundation. In return, some foundations offer firms advisory or sponsor roles: mechanisms that can provide them with a voice on the project. On a day-to-day basis, commercial support of community-managed projects is enacted through the sponsored contributors that work on those projects. On a legal basis, the foundations play an important mediating role. In Figure 1, release coordination is depicted with a question mark sitting between the authority of projects and their foundation. The strength and role that foundations play when collaborating with firms may well depend on the degree to which the authority of the foundation touches the technical core of the project.

In this model, the ownership and maintenance of code is decoupled from its sale and distribution. Without some means to retain their rights it is unlikely that community-managed projects would have had the base of power necessary to engage with firms and create this model (O'Mahony, 2003). Firms, for example, could have legally used community-developed software without necessarily collaborating with them. Community-managed projects held two bases of power that helped firms consider them a credible partner for collaboration: the market share and user base that derived from a project's technical excellence, and the legal and normative controls that encouraged users to "give back" to the project. These two bases of power offset technical communities' lack of economic and political power and helped establish them as a viable commercial actor with which firms could partner.

Granted, this analysis provides a rather static view of the legal and organizational structures that undergird a larger and more complex network of social relationships that flow in and out of these different forms. For example, a volunteer contributor could become sponsored by a firm and then be elected to a board position of a nonprofit foundation. Individuals who were once volunteers and have since founded firms may be active in shaping the nonprofit foundations that represent their project. Informants often stressed that they wished to perceive each other as individual contributors without regard to organizational affiliation. And yet many informants who occupied two or more roles acknowledged that they often experienced role conflict when their activities touched multiple interests.

This touches on an implicit but unarticulated tenet of the hacker ethos: the desire to maintain pluralism. This belief takes two forms. First there is pluralism in voice and process. Raymond has argued that with "more eyes, more bugs are shallow" (1999). An unstated condition is that diverse eyes are necessary for this lay maxim to hold. The more programmers from diverse cultures and backgrounds run various applications in different computing environments, the more likely it is that each user will detect problems unique to them. This allows code to be tested and contributions designed at a level that would require more permutations than are possible at most software firms. Diversity matters as much as volume. The second form of pluralism is required to make multilateral contributions possible: pluralism in the computing infrastructure itself. Software that is created independent of any one vendor's terms; is portable to different types of operating systems; and is interoperable with other applications allows pluralistic contributions to continue. The principle of pluralism depends upon shared standards and protocols, but, I would argue, it also depends upon a form of organizing that prevents dominant interests from forming.

Herein lies a source of conflict. Individuals contributing to community projects want to recognize each other as individuals, retain their individual autonomy, and remain as free from their employment affiliations as possible. On the other hand, without recognition of organizational affiliation, preserving pluralism will be more difficult. Project responses to potential conflict of interest problems have varied, but one feature that works in their favor is public disclosure. The organizational affiliation of project leaders is typically publicly available. When the relationship of one's activities to one's organizational affiliation becomes suspect, other community members are likely to be vocal about their concerns. For contributors who adopt project-based e-mail addresses, affiliation is less public. Over time, this could lead to further blurring of these different roles. The structure foundations provide may become one means to help preserve pluralism.

The evolution of a symbiotic relationship between community-managed projects and firms required adaptation from both actors, and some of these changes are manifested in the roles that nonprofit foundations fulfill, but not all. An understanding of how community-managed projects and firms maintain this relationship at the level of code contribution requires much more explication than has been discussed here. This structural examination of the community-firm collaboration model distributes a very different set of power, ownership, and rights than has been fully appreciated. From an economic perspective, one might ask, have community-managed projects outsourced their distribution costs? Or, have firms outsourced their development costs? Arguments could be made to support both lines of thought. That is in itself perhaps a test of mutualism. A more sociological perspective might question whether community-managed projects that are both politically and pragmatically motivated have successfully resisted co-optation by powerful market dominants. Legally, nonprofit foundations play a critical role in preventing this from happening, but this role reinforces mutual relations that are normatively maintained. Equally significant implications are likely to stem from the intellectual and innovative contributions that can result from collaboration with a new type of actor in the software industry.

Excerpted with permission from the chapter "Nonprofit Foundations and their Role in Community-Firm Software Collaboration" in Making Sense of the Bazaar: Perspectives on Open Source and Free Software, Siobhán O'Mahony, ed. O'Reilly & Associates Publications, 2003 (forthcoming). Copyright (c) 2003 Siobhán O'Mahony. Permission is granted to copy, distribute, and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License."