Programmers contribute to free software and open source projects for many reasons—some for the fun of it, some to improve their skills, others for a paycheck. Many people have wondered why these people give their work away. The truth is that many projects have incorporated in order to protect themselves from individual liability. Since the Free Software Foundation was founded in 1985, a number of new nonprofit foundations have formed, often around specific technologies, to serve the interests of programmers.
HBS professor Siobhán O'Mahony discusses her research on foundations formed around three projects: Debian, a complete non-commercial distribution of Linux; the GNU Object Model Environment (GNOME), which is a graphical user interface for Linux-based operating systems; and Apache, a public domain open source Web server.
Stark: Could you explain why the emergence of nonprofit foundations in the hacker culture appears to be a contradiction in terms?
O'Mahony: The hacker culture prizes autonomy and self-determination. Eric Raymond defines hackers as those who love programming for the sake of doing it, for the sake of obsessively solving a problem. Thus, hackers who contribute to the open source community are often intrinsically motivated.
It is important to realize, however, that hackers are a diverse group. I have interviewed hobbyists, students, academics, software professionals, and government workers who identify themselves as hackers. It is not safe to generalize about all of the values that hackers share, but they tend to agree on at least one thing: Respect must be earned and cannot be derived from position.
There are three big challenges that I identified.
—Siobhán O'Mahony
Much of what is funny about Dilbert cartoons is the disgust that technical workers have for managers who do not have intimate knowledge of the content of their work. This emphasis on demonstration of capabilities is even more critical in the open source community. One earns the respect of peers by demonstrating skills and making valuable contributions of code to a project.
Associated with these values is an embrace of informality and distaste for "administrivia"—for this too can take away from the pure joy of programming. So I suppose what can be considered to be contradictory is that many community-managed open source projects have incorporated and created nonprofit foundations with formal boards and designated roles and responsibilities.
Now there is a wide range of foundations that are emerging. At one end of the continuum are nonprofit foundations that act as little more than legal shells to hold a project's assets and allow it to collect donations. At the other end are nonprofit foundations that have elaborate committee structures, manage releases, and even hire employees.
Q: What were the greatest challenges faced by the three nonprofit foundations you studied?
A: There are three big challenges. One, which is common to all start-ups, is resources. Many foundations have been successful in garnering donations of hardware and equipment when needed, but do not have vast reserves to support legal expenses, travel, or conferences. However, since these foundations are primarily electronically constituted and manifested in the physical world only by a mailing address, their capital needs are minimal.
People are intimately aware of the fact that too much structure will disenfranchise the very people who make the most successful open source projects possible.
—Siobhán O'Mahony
Second is the tension between embracing the informal work norms and ethos of the hacker style of programming with the need to be more predictable and coordinated in managing software releases. Projects that are more closely coupled with commercial firms have experienced direct pressure from firms to communicate better and do more formal planning of what will be included in a release and when. Several projects that have created foundations are experimenting with this tension now—"How much structure can we impose on volunteers?" People are intimately aware of the fact that too much structure will disenfranchise the very people who make the most successful open source projects possible.
Lastly, open source software foundations have been thrilled to receive support from Fortune 500 firms in the software industry. This support is attenuated by the fact that no community-managed software project wants to be "taken over" or co-opted by one firm. The biggest tension here is how to sustain pluralism. If open source contributors only recognize each other based on individual merit, to the exclusion of monitoring where those people of merit are employed, then the pluralism necessary to maintain a community form could be threatened.
One of the most important roles foundations can play is to ensure that pluralism in the governance of these projects is sustained.
Q: Will the nonprofit foundation be an organizational model that will define future software development?
A: I cannot see into the future, but I think the first experiment is in play.
I see the Open Source Application Foundation (OSAF) as an example of the next wave. Mitch Kapor, a successful venture capitalist who founded Lotus Software, invested $5 million of his own money into building a personal-information manager, Chandler. In his own words, "The whole idea of founding a company to develop new productivity software was a complete non-starter. No sane VC would or should fund a venture to compete with the Microsoft monopoly."
Even though his project is in the early stages, over 33,000 people downloaded the very first release in its first two weeks and OSAF has received a grant from the Mellon Foundation to further their work for educational environments.
I doubt that nonprofit foundations will define the future of software development, but all evidence would indicate that they will continue to play an important role. Keep in mind that the Internet Engineering Task Force (IETF), which defines the protocols of the Internet, is a nonprofit professional society. What is different from professional nonprofits or nonprofits focused on charitable causes is that open source foundations produce software that is resold by third parties on commercial markets.
The more fundamental question that firms and policy makers need to be thinking about is just what type of good is software?
—Siobhán O'Mahony
Similar issues surface in the biotechnology world, where university and market conceptions of the life sciences can become intertwined. The more fundamental question that firms and policy makers need to be thinking about is just what type of good is software? The answer to this question may be shifting just as economic and social life becomes dependent upon a common computing infrastructure. When a successful entrepreneur with every possible advantage chooses to found a nonprofit instead of a firm, because this is more likely to lead to success, what can be inferred about the state of the software market?
Organizational theorists argue that nonprofit foundations are created to protect goods too valuable and socially desired to be left to the market, goods like education. If we are granting special tax privileges to organizations to produce software, we as a society are saying something about the nature of that good and the nature of the markets that create it.
Q: What were the biggest surprises that you encountered in this project?
A: The biggest surprise to me was the level of involvement that firms engage in with community forms on software development and standard setting in general. That is, forms that are not government sponsored nor formally constituted by partnership, alliance, or consortia agreements.
It is interesting to watch how individuals with limited power and resources negotiate and collaborate with the largest of corporations. Community may not be exactly the right word to describe these forms, as the term denotes more consensus than reality might dictate. I do think that we need to expand our definition and construction of the types of corporate alliances that are possible and productive to include collaboration with collectives that identify with political or occupational norms and values.
See Related Articles
Nonprofit Foundations and their Role in Community-Firm Software Collaboration
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."
