What Makes a Virtual Organization Work: Lessons From the Open-Source World

In his 1998 article “Management’s New Paradigms,” Peter F. Drucker argues against the traditional view that the essential managerial task is to tell workers what to do.1 In fact, managing a workforce increasingly made up of knowledge workers has very different demands. Managers today, Drucker tells us, must direct people as if they were unpaid volunteers, tied to the organization by commitment to its aims and purposes and often expecting to participate in its governance. They must lead workers instead of managing them.

Drucker’s view of knowledge workers as volunteers seems to be on target with today’s economic, business and workforce trends. A number of industries have seen the breakup of large traditional organizations and the emergence of new, networked organizational forms, in which work is conducted by temporary teams that cross organizational lines. With a booming economy, there is a shortage of skilled labor, exacerbated by an aging population and fewer new workforce entrants. High-tech companies in particular are facing a war for talent, while people increasingly value personal time and autonomy over greater income and advancement. Consequently, companies seek to harness the talents and energies of dispersed “communities of practice.” At the same time, a record number of knowledge workers are self-employed freelancers, and more people choose periods of less than full-time work. If those trends continue, managers will increasingly face a workforce of volunteers — at least in spirit if not in fact.

How will the traditional management tasks of motivating and directing employees have to change in the face of these new realities? One way to answer that question is to examine an example of an economic enterprise that acts in many ways like a voluntary organization: the open-source software movement. Open-source software, such as the Linux operating system, is licensed as a public good — in other words, it is essentially given away for free. And many open-source software products are built, at least in part, by people who are neither employees nor contract workers and who receive no direct compensation for their participation. Nevertheless, open sourcing has become an increasingly popular way of doing business in the software world, and many entrepreneurs and investors are making considerable money from companies involved with open-source software. (See “About the Research.”)

What motivates people to participate in open-source projects? And how is participation governed in the absence of employment or fee-for-service contracts? The answers to those questions reveal some important lessons for organizations — whether or not they develop software products — about both the challenges of keeping and motivating knowledge workers and the process of managing various types of virtual organizations, such as ad hoc project teams, virtual teams, communities of practice and multicompany collaborations.

First, money is only one, and not always the most important, motivation of open-source volunteers. Although professional contributors may value a possible share in the collective wealth a successful new software project generates, they also are motivated by the personal benefit of using an improved software product and by social values such as altruism, reputation and ideology. In many cases, several motivations operate together and reinforce one another, suggesting that traditional organizations should plan for a broader array of work motivations than they often do today. (See “Why Virtual Organizations Work.”)

Second, despite the clear potential for chaos, open-source projects are often surprisingly disciplined and successful through the action of multiple, interacting governance mechanisms. Membership management, rules and institutions, monitoring and sanctions, and reputation build on the precondition of shared culture to self-regulate open-source projects. The implication is that traditional organizations should consider ways to shift from the management of knowledge workers — an oxymoron, some say — to the self-governance of knowledge work.

Motivating Contributors to Open-Source Projects

There are many different types of contributors to open-source projects: organizations and individuals; initiators and those who help with other people’s projects; hobbyists and professionals. Each has different needs. Our primary focus is on the many participants who are not employees or contract laborers of the companies that are directly involved with initiating or managing an open-source project. Such volunteers may play a significant role in open-source software product development, or they may simply participate in maintenance and enhancement work by reporting and fixing the bugs they encounter while using the software. Because they have access to the source code, volunteers can actually make changes to open-source programs, whereas users of proprietary software products (such as the Microsoft Office Suite) cannot.

Most professional volunteers have multiple, reinforcing reasons for participating in open-source projects. And there are both social and economic benefits.

The Social Benefits of Open-Source Participation

The social benefits of participating in open-source projects — altruism and gift giving, reputation and ideology — interact with the sheer joy and challenge of “hacking” to motivate professionals to volunteer their time and skill to open-source projects.

Although open-source software has been around since the 1960s, much of the buzz was created in 1997 by Eric S. Raymond’s influential online publication, “The Cathedral and the Bazaar,”2 which triggered Netscape’s decision to open its Navigator browser. In “Cathedral” and subsequent papers, Raymond forcefully argues for the benefits of open-source software development and describes the motivations of participants. Carefully distinguishing between “hackers,” who build software, and “crackers,” who destroy it, Raymond waxes lyrical about the joys of hacking.3 Writing software can be challenging and fun. But why would hackers give their software away?

Altruism and reciprocity undoubtedly play a role in open-source participation, as they do with other volunteers. Open-source contributors have told us that they enjoy the sense of “helping others out” and “giving something back.” But just as philanthropists can bask in public esteem, open-source volunteers can benefit from enhanced reputations among their peers. Participating in open-source projects can be a highly visible activity: Much of it is coordinated over the Internet, where one’s performance can be monitored by other members of a particular open-source community. As an example, the Mozilla public Web site, which actively solicits volunteers, posts the names of individuals responsible for various parts of the project.

Consequently, participating in open-source projects is one way that software workers can develop a name for themselves or enhance their reputations. For example, in “How To Become a Hacker,”4 Raymond notes that writing open-source software and helping test and debug it are two critical ways to earn the respect of “alpha” hackers. Elsewhere, Raymond explains that gaining a reputation for one’s work is an important reward for participating in open-source projects: “We do keep score in the open-source world. . . . Our scoreboard is the ‘credit list’ or the ‘history file’ that’s attached to every open-source project. . . . If you see somebody’s name on several credit lists, then you know that person is doing lots of good work.”5

Gaining or enhancing reputation through participation in open-source projects can lead to such tangible rewards as employment opportunities or access to venture capital.6 But in “reputation cultures” such as academia and the open-source world, reputation serves as a coin of the realm in its own right. Raymond describes the hacker culture as a “gift” culture or “potlatch” culture, in which reputation is the only measure of success: “Gift cultures [unlike exchange cultures such as our society] are adaptations not to scarcity but to abundance. . . . In gift cultures, social status is determined not by what you control but by what you give away. . . . It is quite clear that the society of open-source hackers is in fact a gift culture. Within it, there is no serious shortage of the ‘survival necessities’ — disk space, network bandwidth, computing power. Software is freely shared. This abundance creates a situation in which the only available measure of competitive success is reputation among one’s peers.”

As important as reputation is as a motivation for open-source participation, ideology also undoubtedly plays a role. The belief that giving software away is the right thing to do is not uncommon in university computer-science research labs, where much open-source software originates. The corollary is the belief that proprietary ownership of software is evil. In the public Web site of the open-source GNU project, one page asks, “Is Microsoft the Great Satan?”7 The page gives the strong impression that the answer is yes. A similar impression is gained from reading the “Halloween documents,” which are edited versions of what are alleged to be confidential Microsoft documents discussing the open-source “threat.”8 In essence, some of the fuel for the open-source movement is the almost anarchic glee of hackers hoping to destroy what they regard as Microsoft’s evil empire — as evidenced by their enthusiasm for the Justice Department’s move to break up the company.

The Economic Benefits of Open-Source Participation

Although altruism, reputation and ideology are certainly powerful motivators of open-source participation, professionals cannot afford to be indifferent to economic issues. Self-employed professionals must earn a living somehow, and employed professionals must convince their superiors that working on open-source projects during company time is valuable. If volunteers’ labor provided economic benefits to someone else but not to the volunteers, contributions to open-source projects would likely not occur very often. As one developer explained: “My development contributions could possibly earn you money, but I would not contribute my time and programming effort solely for you to profit. I would be contributing to your source code because it would benefit me directly in some other way.”9

In other words, many professional developers worry about their own ability to benefit economically from participating in open-source projects. One benefit would be having a better software product to use.10 Another would be sharing in the collective wealth generated by successful commercialization of an open-source software product.11

The appeal of the better mousetrap underlies much open-source participation. Individuals and companies can benefit by enhancing the products they have already decided to use. For example, Linus Torvalds was a university student when he initiated the development of the Linux operating system. He liked the Unix operating system but couldn’t afford a workstation to run it, so he decided to use a version of Unix that would run on his PC. (See “A Brief History of the Open-Source Movement.”)

Similarly, individual professionals and organizations can often benefit from participating in open-source projects when their volunteering enhances the products they use. One open-source contributor was motivated to participate when he ran into problems with a 3Com card he was using. “I’ve been a Linux user for years,” he wrote, “but I’m only just now beginning to fully appreciate open source. Using open source is like getting dozens of detectives to work together to solve a good mystery. . . . With open source, everyone shares the clues they find. And . . . a dozen other detectives are there to confirm or poke holes in the theory.”12

In that instance, the fix the developer submitted was rejected by the software’s primary author because it might have caused problems elsewhere, but the author was able to solve the problem differently. Then the author published the revision so that others could benefit from it.

The 3Com example illustrates an important dynamic of the open-source world: The results of volunteer labor are provided as a public good, free of charge. The rights and obligations associated with open-source software are spelled out in licenses, as is the case with proprietary software. Open-source rights include the right to make copies and the right to access the source code, which is necessary to modify it. Open-source obligations may include the obligation to check enhancements with lead developers (called “checking in”) or to make all enhancements available to others. Although there are variations in open-source licenses and some are more favorable than others to the interests of commercial developers, the features of open-source licenses differ markedly from the licenses of proprietary software products.13

Open-source licenses prohibit the sale (collection of license fees) of open-source software and serve to ensure that no one party can unfairly monopolize the commercial rewards from others’ voluntary labor. The approach removes powerful reasons professionals might have for not contributing to an open-source project. (“I would not contribute my time . . . solely for you to profit.”)

At the same time, open-source licenses may appear to remove a powerful motivator to contribute — the ability to commercialize the product. And in fact, proponents of the open-source movement readily acknowledge that making money from open-source software is “nonintuitive.”14 Nevertheless, a number of different open-source business models, proposed or tried, can give volunteers economic rewards from their participation. The most prominent example is that of Red Hat Inc., which sells support for open-source software. Other business models include selling educational materials and using open-source software as a loss leader or as a hardware add-on. (See “Open-Source Business Models.”)

The opportunity to benefit commercially from open-source software — albeit in nontraditional ways —provides a powerful incentive for many individuals and companies to collaborate in the development of a product that none of them can own. Open-source business models can provide a level playing field —giving each open-source participant a fair chance to benefit from the common effort, while licenses prevent any participant from unfairly monopolizing all the benefits. Open-source licenses and business models provide incentives for individual companies to band together to challenge dominant software products. Of course, the dynamics of network marketplaces are such that the open-source movement could deflate rapidly if the products lose popularity.

The open-source example tells us that money as a motivator is not likely to go out of style — and that should be reassuring for traditional organizations. But a closer look at the social and economic benefits of open-source participation suggests some areas that traditional organizations will need to reflect on. (See “The Open-Source Challenge to Conventional Software Companies.”) Financial compensation in the open-source world usually takes the form of a share in collectively produced wealth, rather than wages or contract fees. That type of compensation is more similar to the stock options that high-tech firms distribute widely to their knowledge workers than to the compensation practices of most traditional firms. Furthermore, credit and reputation may be equally important motivators to open-source participants. Such benefits are more rarely bestowed by today’s traditional organizations. To the extent that credit and reputation are becoming a coin of the realm in knowledge work, managers should consider them essential to motivating employees.

Governing Open-Source Projects

The potential for chaos in open-source projects appears great. First of all, open-source volunteers are neither employees nor contractors. They can defect at any time, and the threat of job loss or wage cuts is largely ineffective as a management tool. Second, large numbers of people may participate in some open-source projects. There may be as many as 750,000 open-source developers; organizing the contributions of even a tiny fraction of that number would challenge any project leader’s skills. Third, some projects welcome all comers. For example, Netscape’s Mozilla site, which is updated regularly, at one point read: “So you want to help? Great! Please read the rest of the introductory documents on this web site. . . . After that, it would be a really good idea for you to join the appropriate mailing lists and to get a feel for how the community works together. Before you actually start coding up a project, we’d strongly recommend that you let us know about it. If you like, we can publicize the fact that you’re working on it, and perhaps someone else will want to work with you on it. If you don’t want it publicized, that’s fine too, but it would help us . . . to know how many different people are tackling the same kinds of problems. . . . Active contributors can be given write access to our CVS repository. Consult the guidelines . . . to learn about our build process and to find out how to get access.”15

Since anyone can join some open-source projects, project leaders would seem to lack that important mechanism of quality control — the ability to select people and assign them to particular tasks. In general, open-source projects have conditions that tend to promote freeloading, unstable membership or low-quality contributions.

In fact, however, many open-source projects work remarkably well, despite such management challenges. As a rule, open-source projects have well-structured governance models with clearly identified leadership. Often, the initial software developer maintains a lead role in the ongoing development and distribution of open-source products. Examples include Larry Wall’s leadership in Perl and Linus Torvalds’ in Linux. But it is usually the case that formal authority for an open-source project is vested in a team. For example, FreeBSD is managed by a 15-person team, called the “Core.” In a few cases, project leaders are elected by the membership. (See “Open-Source Governance Models.”)

As with proprietary-software-development efforts, work on open-source projects is partitioned by lead architects or designers into smaller units or modules, which can be tackled by individuals or teams. The architects also manage issues that require coordination across teams. The same pattern of deconstruction may occur within each module. Although module owners solicit (or receive) input from members, they have final authority for decisions in cases of disputes.

Open-source projects exhibit four interrelated coordination mechanisms, all in the context of the shared hacker culture: managed membership, rules and institutions, monitoring and sanctions, and reputation. By means of the interaction of such governance mechanisms, open-source projects can stay on track despite their obvious potential for chaos.

Managing Membership in Open-Source Projects

Anyone can get involved in a particular open-source project by identifying a bug or contributing a fix using Internet-based reporting systems. But achieving a responsible position in an open-source project requires a more formal process of vetting and quality control. For example, Apache volunteers are allowed to work on a project for a number of months, during which time the quality of their work can be assessed. After a probationary period, formal membership —the ability to remain in a particular role — is determined by a consensus vote of core Apache Foundation members.16

The Debian development effort (GNU/Linux, GNU/Hurd) is less democratic when it comes to accepting members. Project leaders (or delegates) have total authority over who works on their projects: They can admit or expel members. Project leaders are elected by developers; project leaders in turn appoint technical committees. If a developer does not agree with the actions or behavior of the project leader or technical committee, he or she can challenge those actions by following a documented resolution process.17

These examples show that those working on open-source projects find ways to restrict a potentially large and possibly unqualified workforce to one that is small enough to be manageable and of high enough quality to get the job done. But they also show that managing the membership of open-source projects works in conjunction with rules and institutions (such as how members and leaders are chosen) and with monitoring and sanctions (such as dispute-resolution processes and the ability to expel members).

Rules and Institutions

In well-functioning, cooperative efforts, community members participate in making and changing the rules, and the rules they adopt fit their unique needs.18 An example of the adaptability of open-source rules is the variety of open-source licenses. For example, the Berkeley Software Distribution (BSD) license poses no limits on the commercial use of open-source software, whereas the General Public License (GPL) prevents the release of proprietary derivative products through its “copyleft” (as opposed to copyright) provisions. In other words, some open-source licenses are more compatible with the interests of developer communities that want to commercialize open-source software. A drawback of so much variety is that some open licenses are incompatible with others. It is impossible, for example, to create —legally — an open-source product that combines elements of products licensed under GPL and Mozilla Public License (MozPL).

Another interesting aspect of rules and institutions in open-source communities is their procedures for discussing and voting on important issues. Most voting takes place over the Internet. For example, the Perl project uses a phased discussion-group process: request for discussion (RFD), first call for votes (CFV), last CFV, and results. (Each phase of the process is conducted during a specific, limited time period.) An example of the process at work is documented online. When Perl’s central electronic discussion group got bogged down with issues unrelated to product development, core members proposed a moderated discussion group for general discussions. The RFD related to that change included the rationale for creating the group, its charter, specifics of administration and the names of the action’s proponents. After two CFVs (including detailed instructions for the electronic voting process), an unbiased, third-party volunteer tabulated and posted the results. In total, approximately 1,200 members of Perl newsgroups participated in the vote, in which a two-thirds majority was required for the motion to pass.

Linux uses a similar voting process. When community members believed that the existing newsgroup, comp.security.unix, was aimed at Unix administrators rather than at home and small-business users of Linux, they voted to create a new newsgroup to com plement the other newsgroup.19 The first call for discussion refers the reader to the online Introduction to Usenet Voting, which reveals another important aspect of open-source governance — it is not a democracy: “Understanding this principle is necessary to understanding how Usenet operates. You, the user, have absolutely no rights regarding Usenet as a whole, and you cannot complain about anything being ‘undemocratic,’ ‘violating your civil rights,’ ‘un-Constitutional,’ etc. . . . The final arbiter of which groups are created and which ones are not is not the voting system! The one person who can overrule the voting system is the moderator of news.announce.newgroups. Currently this job is held by David ‘Tale’ Lawrence, occasionally known as the ‘Thousand-Pound Gorilla’ thanks to the old joke (Q: Where does a 1,000-pound gorilla sit? A: Anywhere he wants to.). Jokes aside, while Tale has overturned voting results on occasion, he has done it only very, very rarely and even then only after lengthy deliberations.”20

Monitoring and Sanctions

Rules and institutions are vulnerable to decay if members have no means of observing behavior and ensuring compliance. Successful communities must have access to graduated sanctions against those who violate group norms and to low-cost mechanisms for resolving conflict.

Sanctions and conflict-resolution mechanisms appear to be reasonably well developed in open-source communities. There are strong social pressures against noncompliance with norms in open-source communities. Flagrant or continued noncompliance results in flaming (sending someone angry or hostile e-mail), spamming (flooding someone with unsolicited e-mail) and shunning (deliberately refusing to respond). Faced with such sanctions, members often leave the community on their own initiative; leaders don’t always have to expel offending members. Even leaders are not immune to social sanction when community members are incensed by their behavior. At one point, a “flame war” erupted between open-source leaders Eric Raymond and Bruce Perens. When details of the interaction were posted online, community members responded with sharp criticism.21

Although not always resolved to everyone’s satisfaction, conflict is generally not considered detrimental for open-source projects, because deliberation is a valued principle of community behavior. Sometimes, of course, conflicts end badly for some or all participants. One developer explained how a badly handled conflict destroyed motivation to work on an open-source project: “I now have such bad feelings associated with the whole affair that I don’t like to think about [it], much less work on it. I’ve stopped working publicly on it.”22

In the conflict, the same tools that support collaboration were used to destroy it: “Mr. J proceeded to mail me back and tell me that he would do whatever he pleased (again, putting it mildly). He also added a text description offering to let me perform an obscene act on him to his sig file [signature file, appended to the end of e-mail messages], which he used publicly on mailing lists and whatnot. Completely appalled at this point, I e-mailed his providers for web space and connectivity, threatening them and him with lawsuits if he didn’t remove my name from his postings. This got another nasty response from Mr. J, but eventually did get him to remove my name from his sig file.”

The Importance of Reputation

Monitoring and sanctions work because people care about what others think of them. While the opportunity to build a reputation may be an important motivation for joining an open-source project, the desire to maintain a good reputation is a key mechanism in making sure that open-source projects continue on track. The fear of exclusion can be a motivational factor. Performance and behavior in the open-source world are always visible: All members can see whether a volunteer has done a good job or whether a manager has followed accepted norms of behavior or the results of a vote.

Of course, it is important to realize that the same things that make communities strong also can make them narrow-minded, self-deluding and contentious.23 As in any other community, the open-source movement occasionally exhibits political behavior, lack of fairness, work stress and burnout.

The Shared Culture of Open Source

An essential precondition for the operation of all four governance mechanisms — membership management, rules and institutions, monitoring and sanctions, and reputation — is a set of shared values and assumptions about how things work.24 “Hacker culture” grows from, and is maintained by, direct and indirect interactions among open-source community members, which in turn are enabled by the Internet.25 Shared cultural knowledge and enabling technology make it possible for open-source participants to collaborate successfully, often without face-to-face interaction or prior personal acquaintance.

To leaders of traditional organizations, the findings may at first glance appear to be a bit troubling. Although the importance of organizational culture is often stressed in traditional organizations, much less emphasis has been placed on building self-control (to preserve one’s reputation) and social control (for peers to monitor and sanction others’ behavior) into formal organizational control systems. And the idea of voting procedures for key business decisions may unsettle more than a few managers. However, the specific forms that the governance mechanisms take in open-source projects are probably less important to traditional organizations than the fact that they exist. Managers should give careful thought to the categories, the relationships among them and how they can be applied in different contexts.

The Open-Source Movement and the Organization of the Future

The open-source movement exhibits many of the qualities said to characterize new organizational forms. But those characteristics are tempered by mechanisms and processes ensuring that order reigns despite the potential for chaos:

• The intrinsic motivation and self-management of autonomous knowledge workers play important roles in open-source projects. Economic rewards and management processes are also important. Still, the types of economic rewards and management behaviors observed in open-source projects differ quite substantially from those observed in traditional organizations For example, open-source rewards emphasize collective performance (the successful commercialization of an open-source product) and individual benefit (benefit in use) as much as they emphasize an individual’ performance. And the development and maintenance of personal reputation figure prominently in both motivation and control when it comes to open-source projects.
• Membership in open-source projects is fluid, but only to some extent. Open-source projects maintain stable core of participants while capitalizing on the temporary efforts of numerous volunteers. Membership in particular open-source communities is an important part of members’ professional identities.
• Control in the open-source world is maintained through autonomous decision makers following a few simple rules. The key rules, defining appropriate con duct and fair play in benefiting from the collective effort, are embodied in software licenses, rules of membership and voting procedures. Different open-source projects adopt somewhat different rules, showing adaptability to unique circumstances.
• Self-governance, both formally through discussion and voting and informally through social control, is evident in open-source projects. At the same time, project initiators and “alpha” hackers can retain a powerful influence on a project’s direction — as long as they maintain their reputations for high-quality work and appropriate social behavior.

• Information technology is a key enabler of the open-source movement. Technology is required both for product development and support and for project coordination. Communication technology makes behavior highly visible to the community, which in turn permits enforcement of the rules. Many open-source governing bodies hold occasional face-to-face meetings to make decisions, but day-to-day decision making occurs almost solely through the Internet.

In short, there is a relatively high degree of correspondence between the open-source movement and popular depictions of the organization of the future and the virtual networked organization. Therefore, the open-source movement provides some suggestions about how management must change in the years ahead. At the same time, care should be taken in attempting to apply the lessons of the open-source movement to other contexts, because many of its characteristics are unusual or unique:

• A precondition for the open-source movement is a large “community of practice” with a strong, shared culture of technical professionalism. Whether open-source motivation and governance principles would work in other settings may depend on the existence of an active community of talented practitioners.
• Successful open-source projects have involved work that is intrinsically challenging. Whether the open-source model would work for routine activities, such as basic customer service or projects such as developing a new word processor, remains to be seen.
• The open-source movement is evolving rapidly. Whether current rules and processes will retain their character in the face of such rapid change is unknown.
• Software developers enjoy using technology for communicating and decision making. Other types of workers might prefer traditional communication and decision-making practices and fail to adapt to electronically mediated self-governance.
• Finally, self-governance is essential to the success of the open-source movement. Without self-governance, perceptions of fairness would diminish and the motivation of the volunteers would erode. Without volunteers, the movement would collapse. Furthermore, self-governance in the open-source movement is heavily reinforced by business models that offer the possibility of economic benefit and by legal arrangements designed to ensure fairness. It is not clear how well this style of self-governance would work in the absence of such strong reinforcing conditions.

Although managers in industries other than software development may prefer more traditional styles of management, they should remember that the world is changing and workers are changing along with it. In a labor force of volunteers and virtual teams, the motivational and self-governing patterns of the open-source movement may well become essential to business success.