【翻译】开源的简单经济学

Josh Lerner
Jean Tirole
Working Paper 7600
http://www.nber.org/papers/w7600
NATIONAL BUREAU OF ECONOMIC RESEARCH
1050 Massachusetts Avenue
Cambridge, MA 02138
March 2000


The assistance of the Harvard Business School’s California Research Center, and Chris Darwall in particular, was instrumental in the development of the case studies and is gratefully acknowledged. We also thank a number of practitioners—especially Eric Allman, Mike Balma, Brian Behlendorf, Keith Bostic, Tim O’Reilly, and Ben Passarelli—for their willingness to generously spend time discussing the open source movement. Jacques Crémer, Bernard Salanié, and Rob Merges provided helpful comments. Harvard Business School’s Division of Research provided financial support. The Institut D’Economie Industrielle receives research grants from a number of corporate sponsors, including Microsoft Corporation. All opinions and errors, however, remain our own.

ABSTRACT / 摘要

There has been a recent surge of interest in open source software development, which involves developers at many different locations and organizations sharing code to develop and refine programs. To an economist, the behavior of individual programmers and commercial companies engaged in open source projects is initially startling. This paper makes a preliminary exploration of the economics of open source software. We highlight the extent to which labor economics, especially the literature on “career concerns,” can explain many of these projects’ features. Aspects of the future of open source development process, however, remain somewhat difficult to predict with “offthe-shelf” economic models.

1. Introduction / 介绍

Over the past two years, there has been a surge of interest in open source software development. Interest in this process, which involves software developers at many different locations and organizations sharing code to develop and refine software programs, has been spurred by three factors:

• The rapid diffusion of open source software. A number of open source products, such as the Apache web server, dominate their product categories. In the personal computer operating system market, International Data Corporation estimates that the open source program Linux has between seven to twenty-one million users worldwide, with a 200% annual growth rate. Many observers believe it represents a leading potential challenger to Microsoft Windows in this important market segment.
• 开源软件的迅速普及。一些开放源码产品，如 Apache 网络服务器，在其产品类别中占主导地位。在个人电脑操作系统市场，国际数据公司估计，开放源码程序 Linux 在全球拥有 700 万至 2100 万用户，年增长率为 200%。许多观察家认为，在这个重要的市场领域，它代表了对微软视窗系统的一个领先的潜在挑战者。
• The significant capital investments in open source projects. Over the past two years, numerous major corporations, including Hewlett Packard, IBM, and Sun, have launched projects to develop and use open source software. Meanwhile, a number of companies specializing in commercializing Linux, such as Red Hat and VA Linux, have completed initial public offerings, and other open source companies such as Cobalt Networks, Collab.Net, Scriptics, and Sendmail have received venture capital financing.
• 对开放源码项目的大量资本投资。在过去的两年里，许多大公司，包括惠普、IBM 和 Sun，都启动了开发和使用开源软件的项目。同时，一些专门从事 Linux 商业化的公司，如 Red Hat 和 VA Linux，已经完成了首次公开募股，其他开源公司如 Cobalt Networks、Collab.Net、Scriptics 和 Sendmail 也获得了风险投资。
• The new organization structure. The collaborative nature of open source software development has been hailed in the business and technical press as an important organizational innovation.
• 新的组织结构。开放源码软件开发的协作性质已被商业和技术媒体誉为重要的组织创新。

Yet to an economist, the behavior of individual programmers and commercial companies engaged in open source processes is startling. Consider these quotations by two leaders of the open source community:

The idea that the proprietary software social system—the system that says you are not allowed to share or change software—is unsocial, that it is unethical, that it is simply wrong may come as a surprise to some people. But what else can we say about a system based on dividing the public and keeping users helpless? [Stallman, 1999]

The “utility function” Linux hackers is maximizing is not classically economic, but is the intangible of their own ego satisfaction and reputation among other hackers. [Parenthetical comment deleted] Voluntary cultures that work this way are actually not uncommon; one other in which I have long participated is science fiction fandom, which unlike hackerdom explicitly recognizes “egoboo” (the enhancement of one’s reputation among other fans) [Raymond, 1999b].

Linux 黑客所追求的 “效用函数 “并不是经典的经济函数，而是他们自己的自我满足和在其他黑客中的声誉这种无形的东西。【亲笔评论删除】以这种方式运作的自愿文化实际上并不罕见；我长期参与的另一种文化是科幻小说迷，它与黑客王国不同，明确承认 “自我感觉良好”（在其他粉丝中提高自己的声誉）[Raymond, 1999b]。

It is not initially clear how these claims relate to the traditional view of the innovative process in the economics literature. Why should thousands of top-notch programmers contribute freely to the provision of a public good? Any explanation based on altruism1 only goes so far. While users in less developed countries undoubtedly benefit from access to free software, many beneficiaries are well-to-do individuals or Fortune 500 companies. Furthermore, altruism has not played a major role in other industries, so it would have to be explained why individuals in the software industry are more altruistic than others.

This paper seeks to address this puzzle, by making a preliminary exploration of the economics of open source software. Reflecting the early stage of the field’s development, we do not seek to develop new theoretical frameworks or to statistically analyze large samples. Rather, we focus on three “mini-cases” of particular projects: Apache, Perl, and Sendmail.2 We seek to draw some initial conclusions about the key economic patterns that underlie the open source development of software. We find that much can be explained by reference to economic frameworks. We highlight the extent to which frameworks of labor economics, and in particular the literature on “career concerns,” can explain many of the features of open source projects.

At the same time, we acknowledge that aspects of the future of open source development process remain somewhat difficult to predict with “off-the-shelf” economic models. In the final section of this paper, we highlight a number of puzzles that the movement poses. It is our hope that this section will have itself an “open source” nature: that it will stimulate research by other economic researchers as well.

Finally, it is important to acknowledge the relationship with the earlier literature on technological innovation. The open source development process is somewhat reminiscent of the type of “user-driven innovation” seen in many other industries. Among other examples, Rosenberg’s [1976] studies of the machine tool industry and von Hippel’s [1988] of scientific instruments have highlighted the role that sophisticated users can play in accelerating technological progress. In many instances, solutions developed by particular users for individual problems have become more general solutions for wide classes of users. But as we shall argue below, certain aspects of the open source process—especially the extent to which contributors’ work is recognized and rewarded—are quite distinct from earlier settings.

2. The Nature of Open Source Software / 开源软件的性质

While media attention to the phenomenon of open source software has been recent, the basic behaviors are much older in their origins. There has long been a tradition of sharing and cooperation in software development. But in recent years, both the scale and formalization of the activity have expanded dramatically with the widespread diffusion of the Internet.3 In the discussion below, we will highlight three distinct eras of cooperative software development.

2.1 The first era: early 1960s to the early 1980s. / 第一个时代：60 年代初至 80 年代初

Many of the key aspects of the computer operating systems and the Internet were developed in academic settings such as Berkeley and MIT during the 1960s and 1970s, as well as in central corporate research facilities where researchers had a great deal of autonomy (such as Bell Labs and Xerox’s Palo Alto Research Center). In these years, the sharing by programmers in different organizations of basic operating code of computer programs—the source code—was commonplace.4

20 世纪 60 年代和 70 年代，计算机操作系统和互联网的许多关键方面是在学术环境中开发的，如伯克利和麻省理工学院，以及在研究人员有很大自主权的中央企业研究机构（如贝尔实验室和施乐公司的帕洛阿尔托研究中心）。在这些年里，不同机构的程序员共享计算机程序的基本操作代码–源代码–是很常见的。4

Many of the cooperative development efforts in the 1970s focused on the development of an operating system that could run on multiple computer platforms. The most successful examples, the Unix operating system and the C language used for developing Unix applications, were originally developed at AT&T’s Bell Laboratories. The software was then installed across institutions, being transferred freely or for a nominal charge. Many of the sites where the software was installed made further innovations, which were in turn shared with others. The process of sharing code was greatly accelerated with the diffusion of Usenet, a computer network begun in 1979 to link together the Unix programming community. As the number of sites grew rapidly (e.g., from 3 in 1979 to 400 in 1982), the ability of programmers in university and corporate settings to rapidly share technologies was considerably enhanced.

20 世纪 70 年代的许多合作开发工作集中在开发一个可以在多个计算机平台上运行的操作系统。最成功的例子是 Unix 操作系统和用于开发 Unix 应用程序的 C 语言，最初是在 AT&T 的贝尔实验室开发的。然后，该软件被安装在各机构中，被免费转让或收取象征性的费用。许多安装了该软件的地方进行了进一步的创新，而这些创新又与其他人分享。分享代码的过程随着 Usenet 的传播而大大加快，Usenet 是一个始于 1979 年的计算机网络，将 Unix 编程社区联系起来。随着网站数量的迅速增加（例如，从 1979 年的 3 个增加到 1982 年的 400 个），大学和企业环境中的程序员迅速分享技术的能力得到了极大的提高。

These cooperative software development projects were undertaken on a highly informal basis. Typically no effort to delineate property rights or to restrict reuse of the software were made. This informality proved to be problematic in the early 1980s, when AT&T began enforcing its (purported) intellectual property rights related to Unix.

2.2 The second era: early 1980s to the early 1990s. / 第二个时代：80 年代初至 90 年代初

In response to these threats of litigation, the first efforts to formalize the ground rules behind the cooperative software development process emerged. This ushered in the second era of cooperative software development. The critical institution during this period was the Free Software Foundation, begun by Richard Stallman of the MIT Artificial Intelligence Laboratory in 1983. The foundation sought to develop and disseminate a wide variety of software without cost.

One important innovation introduced by the Free Software Foundation was a formal licensing procedure that aimed to preclude the commercialization of cooperatively developed software. In exchange for being able to use and modify the GNU software (as it was known), users had to agree to make the source code freely available (or at a nominal cost). As part of the General Public License (GPL, also known as “copylefting”), the user had to also agree not to impose licensing restrictions on others. Furthermore, all enhancements to the code—and even code that intermingled the cooperatively developed software with that developed separately—had to be licensed on the same terms. It is these contractual terms that distinguish open source software from shareware (where the binary files but not the underlying source code are made freely available, possibly for a trial period only) and public-domain software (where no restrictions are placed on subsequent users of the source code).5

This project, as well as contemporaneous efforts, also developed a number of important organizational features. In particular, these projects employed a model where contributions from many developers were accepted (and frequently publicly disseminated or posted). The right to modify the official version of the program, however, was confined to a smaller subset of individuals closely involved with the project, or in some cases, an individual leader. In some cases, the project’s founder (or his designated successor) served as the leader; in others, leadership rotated between various key contributors.

2.3 The third era: early 1990s to today. / 第三个时代：90 年代初到今天

The widespread diffusion of Internet access in the early 1990s led to a dramatic acceleration of open source activity. The volume of contributions and diversity of contributors expanded sharply, and numerous new open source projects emerged, most notably Linux (a variant of the UNIX operating system developed by Linus Torvalds in 1991). As discussed in detail below, interactions between commercial companies and the open source community also became commonplace in the 1990s.

20 世纪 90 年代初，互联网接入的广泛传播导致了开放源码活动的急剧加速。贡献的数量和贡献者的多样性急剧扩大，出现了许多新的开放源码项目，最引人注目的是 Linux（由 Linus Torvalds 在 1991 年开发的 UNIX 操作系统的变种）。正如下面详细讨论的那样，商业公司和开放源码社区之间的互动在 90 年代也变得很普遍。

Another innovation during this period was the proliferation of alternative approaches to licensing cooperatively developed software. During the 1980s, the GPL was the dominant licensing arrangement for cooperatively developed software. This changed considerably during the 1990s. In particular, Debian, an organization set up to disseminate Linux, developed the “Debian Social Contract” in 1995. This agreement allowed licensees greater flexibility in using the program, including the right to bundle the cooperatively developed software with proprietary code. This more flexible licensing arrangement was adopted in early 1997 by a number of individuals involved in cooperative software development, and was subsequently known as the “Open Source Definition.” As the authors explained:

License Must Not Contaminate Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. Rationale: Distributors of open-source software have the right to make their own choices about their own software [Open Source Initiative, 1999].

Unlike the General Public License, this new license is not “viral”: it does not “infect” all code that was bundled with the software with the requirement that it be covered under the license agreement as well.

The past few years have seen unprecedented growth of open source software. At the same time, the movement has faced a number of challenges. We will highlight two of these here: the “forking” of projects (the development of competing variations) and the development of products for high-end users.

One issue that has emerged in a number of open source projects is the potential for programs splintering into various variants. In some cases, passionate disputes over product design have led to the splintering of open source projects into different variants. Examples of such splintering are the Berkeley Unix program and Sendmail during the late 1980s.

Another challenge has been the apparently lesser emphasis on documentation and support, user interfaces,6 and backward compatibility found in at least some open source projects. The relative technological features of software developed in open source and traditional environments are a matter of passionate discussion. Some members of the community believe that this production method dominates traditional software development in all respects. But many open source advocates argue that open source software tends to be geared to the more sophisticated users.7 This point is made colorfully by one open source developer:

[I]n every release cycle Microsoft always listens to its most ignorant customers. This is the key to dumbing down each release cycle of software for further assaulting the non-personal computing population. Linux and OS/2 developers, on the other hand, tend to listen to their smartest customers… The good that Microsoft does in bringing computers to non-users is outdone by the curse that they bring on experienced users [Nadeau, 1999].

[在] 每个发布周期中，微软总是听从其最无知的客户的意见。这是每个软件发布周期的关键，以进一步攻击非个人的计算机人口。另一方面，Linux 和 OS/2 的开发者倾向于听取他们最聪明的客户的意见。….. 微软在把计算机带给非用户方面所做的好事被他们带给有经验的用户的诅咒所超越了 [Nadeau, 1999]。

Certainly, the greatest diffusion of open source projects appears to be in settings where the end users are sophisticated, such as the Apache server installed by systems administrators. In these cases, users are apparently more willing to tolerate the lack of detailed documentation or easy-to-understand user interfaces in exchange for the cost savings and the possibility of modifying the source code themselves. In several projects, such as Sendmail, project administrators chose to abandon backward compatibility in the interests of preserving program simplicity. One of the rationales for this decision was that administrators using the Sendmail system were responsive to announcements that these changes would be taking place, and rapidly upgraded their systems. In a number of commercial software projects, it has been noted, these types of rapid responses are not as common. Once again, this reflects the greater sophistication and awareness of the users of open source software.

The debate about the ability of open source software to accommodate high-end users’ needs has direct implications for the choice of license. The recent popularity of more liberal licenses such as the Debian Social Contract and the Open Source Definition and the concomitant decline of the GNU license are related to the rise in the “pragmatists’” influence. These individuals believe that allowing proprietary code and for-profit activities in segments that would otherwise be poorly served by the open-source community will provide the movement with its best chance for success.

3. The Origins of the Three Programs / 三个项目的起源

Each of the three case studies was developed through the review of printed materials and interviews (as well as those posted on various web sites) and face-to-face meetings with one or more key participants in the development effort. In addition, we held a number of conversations with knowledgeable observers of the open source movement. In Sections 4 and 5, we will frequently draw on examples from the three cases. Nonetheless, we felt it would be helpful to first provide a brief overview of the three development projects.

3.1 Apache

The development of Apache began in 1994. Brian Behlendorf, then 21, had the responsibility for operating one of the first commercial Internet servers in the country, that powering Wired magazine’s HotWired web site. This server, like most others in the country, was at the time running the Unix-based software written at the National Center for Supercomputer Applications (NCSA) at the University of Illinois. (The only competitive product at the time was the server developed at the joint European particle physics research facility CERN.) The NCSA had distributed its source code freely and had a development group actively involved in refining the code in consultation with the pioneering users. As Behlendorf and other users wrote emendations, or “patches,” for the NCSA server, they would post them as well to mailing lists of individuals interested in Internet technology.

Apache 的开发始于 1994 年。当时 21 岁的 Brian Behlendorf 负责操作国内最早的商业互联网服务器之一，该服务器为《连线》杂志的 HotWired 网站提供动力。这台服务器和国内其他大多数服务器一样，当时正在运行伊利诺伊大学国家超级计算机应用中心（NCSA）编写的基于 Unix 的软件。（当时唯一有竞争力的产品是欧洲粒子物理学联合研究机构 CERN 开发的服务器）。NCSA 免费发布了它的源代码，并有一个开发小组积极地参与到与先锋用户的协商中，完善代码。当 Behlendorf 和其他用户为 NCSA 的服务器写了一些修正，或称 “补丁 “时，他们也会把它们发布到对互联网技术感兴趣的个人的邮件列表中。

Behlendorf and a number of other users, however, encountered increasing frustrations in getting the NCSA staff to respond to their suggestions. (During this time, a number of the NCSA staff had departed to begin Netscape, and the University was in the process of negotiating a series of licenses of its software with commercial companies.) As a result, he and six other pioneering developers decided to establish a mailing list to collect and integrate the patches to the NCSA server software. They agreed that the process would be a collegial one. While a large number of individuals would be able to suggest changes, only a smaller set would be able to actually make changes to the physical code. In August 1995, the group released Apache 0.8, which represented a substantial departure from earlier approaches. A particular area of revision was the Application Program Interface (API), which allowed the development of Apache features to be very “modular.” This step enabled programmers to make contributions to particular areas without affecting other aspects of the programs.

The diffusion of Apache has been quite dramatic. Periodic surveys by Netcraft show that the share of publicly observable Web servers (i.e., those not behind firewalls) running Apache rose from 31% in April 1996 to 44% in June 1997 to 55% in September 1999.8 In 1999, the Apache Software Foundation was established to oversee the development and diffusion of the program. The current status of Apache, as well as the other two open source projects that we focused on, is summarized in Table 1.

3.2 Perl

Perl, or the Practical Extraction and Reporting Language, was created by Larry Wall in 1987. Wall, a programmer with Burroughs (a computer mainframe manufacturer now part of Unisys) had already written a number of widely adopted software programs. These included a program for reading postings on on-line newsgroups and a program that enabled users to readily update old source code with new patches.

Perl，即实用提取和报告语言，是由拉里-沃尔在 1987 年创建的。Wall 是 Burroughs（一家计算机主机制造商，现在是 Unisys 的一部分）的一名程序员，他已经编写了许多被广泛采用的软件程序。这些程序包括一个用于阅读在线新闻组的帖子的程序和一个使用户能够随时用新的补丁更新旧的源代码的程序。

The specific genesis of Perl was the large number of repetitive system administration tasks that Wall was asked to undertake while at Burroughs. In particular, Wall was required to synchronize and generate reports on two Unix-based computers as part of a project that Burroughs was undertaking for the U.S. National Security Agency. He realized that there was a need for a program language that was somewhere between the Unix shell language and the C language (suitable for developing complex programming applications). The Perl language sought to enable programmers to rapidly undertake a wide variety of system administration tasks. The program was first introduced in 1987 via the Internet. It has become widely accepted as a language for developing scripts for Apache web servers, and is incorporated in a number of other programs.

Perl 的具体起源是 Wall 在 Burroughs 工作期间被要求承担大量的重复性系统管理任务。特别是，作为 Burroughs 为美国国家安全局进行的一个项目的一部分，Wall 被要求在两台基于 Unix 的计算机上同步和生成报告。他意识到，需要一种介于 Unix shell 语言和 C 语言（适合开发复杂的编程应用）之间的程序语言。Perl 语言试图使程序员能够迅速承担各种系统管理任务。该程序于 1987 年通过互联网首次推出。它已被广泛接受为开发 Apache 网络服务器脚本的语言，并被纳入其他一些程序中。

Perl is administered on a rotating basis: the ten to twenty programmers (the number fluctuates over time) who have been most actively involved in the program take turns managing different aspects of the project. Wall himself has joined the staff of O’Reilly & Associates, a publisher specializing in manuals documenting open source programs. While he is no longer actively contributing to the programming, he remains active in managing the project.

Perl 的管理是轮流进行的：十到二十个最积极参加项目的程序员（人数随时间变化）轮流管理项目的不同方面。沃尔本人已经加入了 O’Reilly & Associates 的工作人员，这是一家专门出版开放源代码程序文档的出版社。虽然他不再积极为编程做贡献，但他仍然积极管理该项目。

Two efforts to establish a Perl-related foundation have foundered. The Perl Institute had been intended to ensure that less glamorous tasks, such as documentation, were undertaken, in order to enhance the long-run growth of Perl. The failure of these efforts may have reflected more about the specifics of the individual personalities involved than the prospects of the program itself.

3.3 Sendmail

Sendmail was originally developed in the late 1970s by Eric Allman, a graduate student in computer science at the University of California at Berkeley. As part of his responsibilities, Allman worked on a variety of software development and system administration tasks at Berkeley.

Sendmail 最初是由 Eric Allman 在 70 年代末开发的，他是加州大学伯克利分校的计算机科学研究生。作为他职责的一部分，Allman 在伯克利从事各种软件开发和系统管理任务。

One of the major challenges that Allman faced was the incompatibility of the two major computer networks on campus. The approximately one dozen Unix-based computers had been originally connected through “BerkNet,” a locally developed program that provided continuous interconnection. These computers, in turn connected to those on other campuses through telephone lines, using the UUCP protocol (Unix-toUnix Copy Protocol). Finally, the Arpanet, the direct predecessor to the Internet, was introduced on the Berkeley campus around this time. Each of the networks used a different communications protocol: for instance, each person had multiple e-mail addresses, depending on the network from which the message was sent. To cope with this problem, Allman developed in 1979 a program called “Delivermail,” which provided a way to greatly simplify the addressing problem. In an emendated form that allowed it to address a large number of domains, it was released two years later as “Sendmail.”

Allman 面临的主要挑战之一是校园内两个主要计算机网络的不兼容。大约十几台基于 Unix 的计算机最初是通过 “BerkNet “连接的，这是一个本地开发的程序，提供连续的互连。这些计算机又通过电话线与其他校园的计算机连接，使用 UUCP 协议（Unix-to-Unix 复制协议）。最后，Arpanet，互联网的直接前身，大约在这个时候被引入伯克利校园。每个网络都使用不同的通信协议：例如，每个人都有多个电子邮件地址，这取决于信息是从哪个网络发出的。为了解决这个问题，Allman 在 1979 年开发了一个名为 “Delivermail “的程序，它提供了一个大大简化寻址问题的方法。在一个允许它处理大量域名的修正形式中，它在两年后作为 “Sendmail “发布。

Sendmail was soon adopted as the standard method of routing e-mail on the Arpanet. As the network grew, however, its limitations became increasingly apparent. A variety of enhanced versions of Sendmail were released in the 1980s and early 1990s which were incompatible with each other—in the argot of the open source community, the development of the program “forked.” In 1993, Allman, who had returned to working at Berkeley after being employed at a number of software firms, undertook a wholesale rewrite of Sendmail. The development was sufficiently successful that the incompatible versions were largely abandoned in favor of the new version. By 1998, it was estimated that 80% of all e-mail traffic was sent by Sendmail.

Sendmail 很快就被采纳为 Arpanet 上路由电子邮件的标准方法。然而，随着网络的发展，它的局限性变得越来越明显。在 20 世纪 80 年代和 90 年代初，Sendmail 的各种增强版本被发布，但它们彼此不兼容–用开放源码社区的说法，程序的发展是 “分叉 “的。1993 年，Allman 在受雇于一些软件公司后回到伯克利工作，他对 Sendmail 进行了全面重写。这项开发工作非常成功，以至于不兼容的版本在很大程度上被放弃，而改用新的版本。到 1998 年，据估计 80%的电子邮件流量是由 Sendmail 发送的。

In 1997, Allman established Sendmail, Inc. The company, which has been financed by a leading venture capital group Benchmark Capital, is seeking to sell Sendmail-related software enhancements (such as more user-friendly interfaces) and services. At the same time, the company seeks to encourage the continuing development of the software on an open source basis. For instance, Sendmail, Inc. employs two engineers who work almost full time on contributions to the open source program, which is run by the non-profit Sendmail Consortium.

1997 年，Allman 成立了 Sendmail 公司。该公司得到了领先的风险投资集团 Benchmark Capital 的资助，正在寻求销售与 Sendmail 相关的软件改进（如更多的用户友好界面）和服务。同时，该公司试图鼓励在开放源码的基础上继续开发该软件。例如，Sendmail 公司雇用了两名工程师，他们几乎全职从事对开放源码计划的贡献，该计划由非营利性的 Sendmail 联盟管理。

4. What Does Economic Theory Tell Us about Open Source? / 经济理论对开源有什么启示？

4.1 What motivates programmers? Theory / 是什么激励了程序员？理论

A programmer participates in a project, whether commercial or open source, only if she derives a net benefit (broadly defined) from engaging in the activity. The net benefit is equal to the immediate payoff (current benefit minus current cost) plus the delayed payoff.

A programmer working on a software development project incurs a variety of immediate benefits and costs. First, the programmer receives monetary compensation if she is working for a commercial firm. Second, the programmer may be fixing a bug or customizing a program for her own benefit (as well as, in the case of an open source process, for the benefit of others.) Third, the programmer incurs an opportunity cost of her time. While she is working on this project, she is unable to engage in another programming activity. The actual cost of this time depends on how enjoyable the work is.

The delayed reward covers two distinct, although hard-to-distinguish, incentives. The career concern incentive refers to future job offers, shares in commercial open sourcebased companies,9 or future access to the venture capital market. The ego gratification incentive stems from a desire for peer recognition. Probably most programmers respond to both incentives. There are some differences between the two. The programmer mainly preoccupied by peer recognition may shun future monetary rewards, and may also want to signal her talent to a slightly different audience than those motivated by career concerns. From an economic perspective, however, the incentives are similar in most respects. We will group the career concern incentive and the ego gratification incentive under a single heading: the signaling incentive.

Economic theory [e.g., Holmström, 1999] suggests that this signaling incentive is stronger,

a) the more visible the performance to the relevant audience (peers, labor market, venture capital community),
b) the higher the impact of effort on performance, and

a) 绩效对相关受众（同行、劳动力市场、风险资本界）的影响越大。
b) 努力对业绩的影响越大，以及
c) 绩效对人才的信息量越大。


The first condition gives rise to what economists call “strategic complementarities.” To have an “audience,” programmers will want to work on software projects that will attract a large number of other programmers. This suggests the possibility of multiple equilibria. The same project may attract few programmers because programmers expect that other programmers will not be interested; or it may flourish as programmers (rationally) have faith in the project.

The same point applies to forking in a given open source project. Open source processes are in this respect quite similar to academic research. The latter is well known to exhibit fads. Fields are completely neglected for years, while others with apparently no superior intrinsic interest attract large numbers of researchers. Fads in academia are frowned upon for their inefficient impact on the allocation of research. It should not be ignored, however, that fads also have benefits. A fad can create a strong signaling incentive: researchers working in a popular area may be highly motivated to produce a high-quality work, since they can be confident that a large audience will examine their work.

4.2 Comparison between open source and closed source programming incentives. / 开放源码和封闭源码编程激励机制之间的比较

To compare programmers’ incentives in the open source and proprietary settings, we need to examine how the fundamental features of the two environments shape the incentives just reviewed. We will first consider the relative short-term rewards, and then turn to the deferred compensation.

Commercial projects have an edge on the current-compensation dimension because the proprietary nature of the code generates income. This makes it privately worthwhile for private companies to offer salaries.10 This contention is the old argument in economics that the prospect of profit encourages investment, which is used, for instance, to justify the awarding of patents to encourage invention.

By way of contrast, an open source project may well lower the cost for the programmer, for two reasons:

i) “Alumni effect”: Because the code is freely available to all, it can be used in schools and universities for learning purposes; so it is already familiar to programmers. This reduces their cost of programming for UNIX, for example.11

ii) Customization and bug-fixing benefîts: The cost of contributing to an open source project is lower if the activity brings about a private benefit (bug fixing, customization) for the programmer and her firm. Note again that this factor of cost reduction is directly linked to the openness of the source code.

i) “校友效应”。因为代码是免费提供给所有人的，它可以在学校和大学里用于学习；所以它已经为程序员所熟悉。这减少了他们对 UNIX 的编程成本，例如。11

ii) 定制和修复错误的好处。如果这项活动为程序员和她的公司带来了私人利益（修复错误，定制），那么对开源项目的贡献成本就会降低。请注意，这个成本降低的因素是与源代码的开放性直接相关的。

Let us now turn to the delayed reward (signaling incentive) component. In this respect too, the open source process has some benefits over the closed source approach. As we noted, signaling incentives are stronger, the more visible the performance and the more attributable the performance to a given individual. Signaling incentives therefore may be stronger in the open source mode for three reasons:

i) Better performance measurement: Outsiders can only observe inexactly the functionality and/or quality of individual elements of a typical commercially developed program, as they are unable to observe the proprietary source code. By way of contrast, in an open source project, the outsiders are able to see not only what the contribution of each individual was and whether that component “worked,” but also whether the task was hard, if the problem was addressed in a clever way, whether the code can be useful for other programming tasks in the future, and so forth.

ii) Full initiative: The open source programmer is her own boss and takes full responsibility for the success of a subproject. In a hierarchical commercial firm, however, the programmer’s performance depends on her supervisor’s interference, advice, etc. Economic theory would predict that the programmer’s performance is more precisely measured in the former case.

iii) Greater fluidity: It may be argued that the labor market is more fluid in an open source environment. Programmers are likely to have less idiosyncratic, or firmspecific, human capital that limits shifting one’s efforts to a new program or work environment. (Since many elements of the source code are shared across open source projects, more of the knowledge they have accumulated can be transferred to the new environment).

i) 更好的表现评估。外人只能不准确地观察典型的商业开发的程序的个别元素的功能和/或质量，因为他们无法观察专有的源代码。作为对比，在一个开放源码项目中，外部人员不仅能够看到每个人的贡献是什么，以及该组件是否 “工作”，而且还能看到任务是否困难，是否以巧妙的方式解决了问题，代码是否能在未来对其他编程任务有用，等等。

ii) 充分的主动性。开源程序员是她自己的老板，对一个子项目的成功承担全部责任。然而，在一个等级森严的商业公司里，程序员的表现取决于她的上司的干预和建议等。经济理论预测，在前一种情况下，程序员的表现会得到更精确的衡量。

iii) 更大的流动性：可以说劳动力市场在开放源码环境中更具有流动性。程序员可能有较少的特异性或公司特定的人力资本，限制了他们将自己的努力转移到一个新的程序或工作环境中。（由于源代码的许多元素是在开放源码项目中共享的，他们所积累的更多知识可以转移到新的环境中）。

These theoretical arguments also provide insights as to who is more likely to contribute and what tasks are best suited to open source projects. Sophisticated users derive direct benefits when they customize or fix a bug in open source software.12 A second category of potential contributors consists of individuals with strong signaling incentives; these may use open source software as a port of entry. For instance, open source processes may give a talented system administrator at a small academic institution (who is also a user!) a unique opportunity to signal her talent to peers, prospective employers, and the venture capital community.13

As to the tasks that may appeal to the open source community, one would expect that tasks such as those related to the operating systems and programming languages, whose natural audience is the community of programmers, would give rise to strong signaling incentives. By way of contrast, tasks aiming at helping the much-less-sophisticated end user—e.g., documentation, design of easy-to-use interfaces, technical support, and insuring backward compatibility—usually provide lower signaling incentives.14

4.3 Evidence on individual incentives / 关于个人奖励的证据

A considerable amount of evidence is consistent with an economic perspective.

First, user benefits are key to a number of open source projects. One of the origins of the free software movement was Stallman’s inability to improve a printer program because Xerox refused to release the source code. In each of the three scenarios described in section 3, the project founders were motivated by information technology problems that they had encountered in their day-to-day work. For instance, in the case of Apache, the initial set of contributors was almost entirely system administrators who were struggling with the same types of problems as Behlendorf. In each case, the initial release was “runnable and testable”: it provided a potential, even if imperfect, solution to a problem that was vexing considerable numbers of data processing professionals.

Second, it is clear that giving credit to authors is essential in the open source movement. This principle is included as part of the nine key requirements in the “Open Source Definition” [Open Source Initiative, 1999]. This point is also emphasized by Raymond [1999b], who points out “surreptitiously filing someone’s name off a project is, in cultural context, one of the ultimate crimes.”

Finally, the reputational benefits that accrue from successful contributions to open source projects appear to have real effects on the developers. This is acknowledged within the open source community itself. For instance, Raymond [1999b] notes three primary benefits that accrue to successful contributors of open source projects “good reputation among one’s peers, attention and cooperation from others, … [and] higher status [in the] … exchange economy.” Thus, while some of benefits conferred from participation in open source projects may be less concrete in nature, there also appear be quite tangible—if delayed—rewards.

The Apache project provides a good illustration of these observations. The project makes a point of recognizing all contributors on its web site, even those who simply identify a problem without proposing a solution. Similarly, the organization highlights its most committed contributors, who have the ultimate control over the project’s evolution. Moreover, it appears that many of the skilled Apache programmers have benefited materially from their association with the organization. Numerous contributors have been hired into Apache development groups within companies such as IBM, become involved in process-oriented companies such as Collab.Net which seek to make open source projects more feasible (see below), or else moved into other Internet tools companies in ways that were facilitated by their expertise and relationships built up during the open source movement. Meanwhile, many of the new contributors are already employed by corporations, and working on Apache development as part of their regular assignments.

Apache 项目为这些观察提供了一个很好的说明。该项目在其网站上强调对所有贡献者的认可，即使是那些仅仅发现问题而没有提出解决方案的人。同样地，该组织也强调其最坚定的贡献者，他们对项目的发展有最终的控制权。此外，许多熟练的 Apache 程序员似乎已经从他们与该组织的联系中获得了实质性的好处。许多贡献者被雇用到 IBM 等公司的 Apache 开发组，参与到 Collab.Net 等以流程为导向的公司中，这些公司试图使开放源码项目更加可行（见下文），或者以他们在开放源码运动中建立的专业知识和关系促进的方式进入其他互联网工具公司。同时，许多新的贡献者已经受雇于公司，并将 Apache 的开发作为他们常规工作的一部分。

There is also substantial evidence that open source work may be a good stepping stone for securing access to venture capital. For example, the founders of Sun, Netscape, and Red Hat had signaled their talent in the open source world. In Table 2, we summarize some of the subsequent commercial roles played by individuals active in the open source movement.

4.4 Leadership, organization and governance / 领导、组织与治理

A successful open source project also requires a credible leader or leadership, and an organization consistent with the nature of the process.

Although the leader is often at the origin a user who attempts to solve a particular program, the leader over time performs less and less programming. The leader must (a) provide a vision, (b) make sure that the overall project is divided into much smaller and well-defined tasks (“modules”) that individuals can tackle independently from other tasks, (c) attract other programmers, and, last but not least, (d) “keep the project together” (prevent it from forking or being abandoned).

The initial leader must assemble a critical mass of code to which the programming community can react. Enough work must be done to show that the project is doable and has merit. At the same time, to attract additional programmers, it may be important that the leader does not perform too much of the job on his own and leaves challenging programming problems to others.15 Indeed, programmers will initially be reluctant to join a project whose leadership qualities are yet untested unless they identify an exciting challenge. Another reason why programmers are easier to attract at an early stage is that, if successful, the project will keep attracting a large number of programmers in the future, making early contributions very visible.

Consistent with this argument, it is interesting to note that each of the three cases described above appeared to pose challenging programming problems. When the initial release of each of these open source programs was made, considerable programming problems were unresolved. The promise that the project was not near a “dead end,” but rather would continue to attract ongoing participation from programmers in the years to come, appears to be an important aspect of its appeal. In this respect, Linux is perhaps the quintessential example. The initial Linux operating system was quite minimal, on the order of a few tens of thousands of lines of code. In Torvalds’ initial postings in which he sought to generate interest in Linux, he explicitly highlighted the extent to which the version would require creative programming in order to achieve full functionality.

Another important determinant of project success appears to be the nature of its leadership. In some respects, the governance structures of open source projects are quite different. In a number of instances, such as Linux, there is an undisputed leader. While certain aspects are delegated to others, a strong centralization of authority characterizes these projects. In other cases, such as Apache, a committee will resolve the disputes by voting or a consensus process. At the same time, leaders of open source projects share some common features. Most leaders are the programmers who developed the initial code for the project (or made another important contribution early in the project’s development). While many no longer make programming contributions, having moved on to broader project management tasks, the individuals that we talked to believed that the initial experience was important in establishing credibility to manage the project. The splintering of the Berkeley-derived Unix development programs has been attributed in part to the absence of a single credible leader.

But what does the leadership of an open source project do? It might appear at first sight that the unconstrained, quasi-anarchistic nature of the open source process leaves little scope for a leadership. This, however, is incorrect. First, as we have already indicated, the leadership sets a vision. If the leader is credible and/or the vision is compelling, this vision helps coordinate expectations. Second, even though participants are free to take the project where they want as long as they release the modified code, acceptance by the leadership of a modification or addition provides some certification as to the quality of the latter and its integration/compatibility with the overall project.

As discussed by Max Weber [1968], some attributes underlie a successful leadership.16 First, the programmers must trust the leadership: that is, they must believe that the leader’s objectives are sufficiently congruent with theirs and not polluted by ego-driven, commercial, or political biases. For instance, the leadership must be willing to accept improvements on their merits even though they do not fit the leader’s original blueprint.

Trust in the leadership is also key to the prevention of forking. While there are natural forces against forking (the loss of economies of scale due to the creation of smaller communities, the hesitations of programmers in complementary segments to port to multiple versions, and the stigma attached to the existence of a conflict), other factors may encourage forking. User-developers may have conflicting interests as to the evolution of the technology. Ego (signaling) concerns may also prevent a faction from admitting that another approach is more promising, or simply from accepting that it may socially be preferable to have one group join the other’s efforts even if no clear winner has emerged. The presence of a charismatic (i.e., trusted) leader is likely to substantially reduce the probability of forking in two ways. First, indecisive programmers are likely to rally behind the leadership’s preferred alternative. Second, the dissenting faction may not have an obvious leader of its own.

A good leadership should also clearly communicate its goals and evaluation procedures. Indeed, the open source organizations go to considerable efforts to make the nature of their decision making process transparent: the process by which the operating committee reviews new software proposals is frequently posted and all postings archived. For instance, on the Apache web site, it is explained how proposed changes to the program are reviewed by the program’s governing body, whose membership is largely based on contributions to the project. (Any significant change requires at least three “yes” votes—and no vetoes—by these key decision-makers.)

5. Commercial Software Companies’ Reactions to the Open Source Movement / 商业软件公司对开放源代码运动的反应

This section examines the interface between open and closed source software development. Challenged by the successes of the open source movement, the commercial software corporations may employ one of the following two strategies. The first is to emulate some incentive features of open source processes in a distinctively closed source environment. Another is to try to mix open and closed source processes to get the best of both worlds.

5.1 Why don’t corporations duplicate the open source incentives? / 为什么企业不复制开放源代码的激励措施？

As we already noted, owners of proprietary code are not able to enjoy the benefits of getting free programmer training in schools and universities (the alumni effect); nor can they easily allow users to modify their code and customize it without jeopardizing intellectual property rights. Similarly, and for the reasons developed in section 4, commercial companies will never be able to duplicate the visibility of performance reached in the open source world.

In contrast, they can to some extent duplicate some of the signaling incentives of the open source world. Indeed, a number of commercial software companies (e.g., video game companies, Qualcomm for the Eudora email program) list people who have developed the software. It is an interesting question why others do not. To be certain, commercial companies do not like their key employees to become highly visible, lest they be hired away by competitors.17 But, to a large extent, firms also realize that this very visibility enables them to attract talented individuals and provides a powerful incentive to existing employees.

Another area in which software companies might try to emulate open source development is the promotion of widespread code sharing within the company. This may enable them to reduce code duplication and to broaden a programmer’s audience. Interestingly, existing organizational forms may preclude the adoption of open source systems within commercial software firms. An internal Microsoft document on open source [Valloppillil, 1998] describes a number of pressures that limit the implementation of features of open source development within Microsoft. Most importantly, each software development group appears to be largely autonomous. Software routines developed by one group are not shared with others. In some instances, the groups seek to prevent being broken up by not documenting a large number of program features. These organizational attributes, the document suggests, lead to very complex and interdependent programs that do not lend themselves to development in a “compartmentalized” manner nor to widespread sharing of source code.18

5.2 The commercial software companies’ open source strategies. / 商业软件公司的开源战略

As should be expected, many commercial companies have elaborated strategies to capitalize on the open source movement. In a nutshell, they expect to benefit from their expertise in some segment whose demand is boosted by the success of a complementary open source program. While improvements in the open source software are not appropriable, commercial companies can benefit indirectly in a complementary proprietary segment.19

One such strategy is straightforward. It consists of commercially providing complementary services and products that are not supplied efficiently by the open source community. Red Hat and VA Linux for example, exemplify this “reactive” strategy.20

A “reactive” commercial company may still want to encourage and subsidize the open source movement, for example by allocating a few programmers to the open source project.21 Red Hat will make more money on support if Linux is successful. Similarly, if logic semiconductors and operating systems for personal computers are complements, one can show by a revealed preference argument that Intel’s profits will increase if Linux (which unlike Windows is free) takes over the PC operating system market. Similarly, Sun may benefit if Microsoft’s position is weakened. Oracle may wish to port its database products to a Linux environment in order to lessen its dependence on Sun’s Solaris operating system. Because firms do not capture all the benefits of the investments, the free-rider problem often discussed in the economics of innovation should apply here as well. Subsidies by commercial companies for open source projects should remain limited unless the potential beneficiaries succeed in organizing a consortium (which will limit the free-riding problem).

A second strategy is to take a more proactive role in the development of open source software. Companies can release existing proprietary code and create some governance structure for the resulting open source process. For example, Hewlett-Packard recently released its Spectrum Object Model-Linker open source in order to help the Linux community port Linux to Hewlett Packard’s RISC architecture. They can even (though probably less likely) encourage “ex nihilo” development of new pieces of open source software. This is similar to the strategy of giving away the razor (the released code) to sell more razor blades (the related consulting services that HP will provide).

Various efforts by corporations selling proprietary software products to develop additional products through an open source approach have been undertaken. One of the most visible of these efforts was Netscape’s 1998 decision to make “Mozilla,” a portion of its browser source code, freely available. This effort has been so far relatively unsuccessful. Indeed, the Mozilla effort only received approximately two dozen postings by outside developers. Perhaps (and we can only conjecture here), the launching failed because it occurred too late (many exciting tasks had already been completed). It is also likely that Netscape did not adopt the right governance structure. Leadership by a commercial entity may not internalize enough of the objectives of the open source community. In particular, a corporation may not be able to credibly commit to keeping all source code in the public domain and to adequately highlighting important contributions.22

In this light, it is tempting to interpret the creation of organizations such as Collab.Net as efforts to certify corporate open source development programs, just as investment banks and venture capitalists play a certification role for new firms. Collab.Net, a new venture funded by the venture capital group Benchmark Partners, will organize open source projects for corporations who wish to develop part of their software in this manner. Collab.net will receive fees for its online marketplace (SourceXchange, through which corporations will contact open source developers), for preparing contracts, for helping select and monitor developers, and for settling disputes. Hewlett Packard released the core of its E-speak technology (which enable brokering capabilities) to open source23 and posted six projects related to this technology.

Hewlett Packard’s management of the open source process seems consistent with Dessein [1999]. Dessein shows that a principal with formal control rights over an agent’s activity in general gains by delegating his control rights to an intermediary with preferences or incentives that are intermediate between his and the agent’s. The partial alignment of the intermediary’s preferences with the agent’s fosters trust and boosts the agent’s initiative, ultimately offsetting the partial loss of control for the principal. In the case of Collab.net, the congruence with the open source developers is obtained through the employment of visible open source developers (for example, the president and chief technical officer is Brian Behlendorf, one of the cofounders of the Apache project) and the involvement of O’Reilly, a technical book publisher with strong ties to the open source community.

When can it be advantageous for a commercial company to release proprietary code under an open source license? The first condition is, as we have noted, that the company expects to thereby boost its profit on a complementary segment. A second is that the increase in profit in the proprietary complementary segment offsets any profit that would have been made in the primary segment, had it not been converted to open source. Thus, the temptation to go open source is particularly strong when the company is too small to compete commercially in the primary segment or when it is lagging behind the leader and about to become extinct in that segment.24

5.3 Can commercial activities pollute the open source process? / 商业活动能否污染开放源码进程？

The flexible open source license allows for the coexistence of open and closed source code. While it represents in our view (and in that of many open source participants) a reasonable compromise, it is not without hazards.

First, the open source project may be “hijacked” by a participant who builds a valuable module and then offers proprietary APIs to which application developers start writing. The innovator has then built a platform that appropriates some of the benefits of the project. To be certain, open source participants might then be outraged, but it is unclear whether this would suffice to prevent the hijacking. The open source community would then be as powerless as the commercial owner of a platform above which a “middleware” producer superimposes a new platform.25

Second, the coexistence of commercial activities may alter the programmers’ incentives. To understand why it may be useful to make an analogy with academia (despite some differences between the academic research and open source development processes).

To put our reflections in perspective, let us first argue against the view that one should prevent academic research from being polluted by outside activities. We believe that these outside activities—e.g., for an economist, work with firms and financial intermediaries and participation in the public policy process; for an engineer, consulting with large firms and part-time work in start-ups—provides a useful two-way transfer of knowledge between practical matters and fundamental research. They also provide academics who desire it with (instantaneous and intertemporal) job diversification and thereby increase the attractiveness of academia. Yet, like many researchers, we are concerned that these outside activities may pollute the research process and make it less attractive. There are several reasons for this.

First, a field may be deprived of some of its best minds if they neglect fundamental research and pursue applied, specific-purpose projects rather than broader, generalpurpose innovations. The field may lose some of its allure as an exciting intellectual environment in which new insights accrue at a rapid pace and a large community that avidly reads about the latest developments.

Second, the academic process may lose some of its integrity. The high-powered incentives provided by outside activities may induce researchers to sell off some of the long-term reputational capital in the academic community. This happens for instance when a researcher puts his intellectual weight behind a dubious idea, directs students excessively to his or her start-up or consulting firm, rejects papers submitted to scientific journals simply because they do not mesh with the views espoused in the outside activity, or stops freely exchanging knowledge. To be certain, some of these behaviors are already motivated by purely academic incentives. Our point is simply that these may be exacerbated by the presence of powerful outside incentives, and by the shortening of the relationships that results from the move of academics to other communities.

While it is too early to tell, some of these same issues may appear in the open source world. Programmers working on an open source project may be tempted to stop interacting and contributing freely if they think they have an idea for a module that might yield a huge commercial payoff. Too many programmers may start focusing on the commercial side, making the open source process less exciting

6. What are the Open Economic Questions about Open Source? / 关于开源的公开经济问题有哪些？

There are many other issues posed by open source development that do not lend themselves as neatly to conventional economic frameworks. This section will highlight a number of these as suggestions for future work.

To what extent will reliance on breaking software projects into distinct modules serve to limit the effectiveness of open source? The success of an open source project is dependent on the ability to break the project into distinct components. Without an ability to parcel out work in different areas to programming teams who need little contact with one another, the effort is likely to be unmanageable. Some observers argue that the underlying Unix architecture lent itself well to the ability to break development tasks into distinct components. It may be that as new open source projects move beyond their Unix origins and encounter new programming challenges, the ability to break projects into distinct units will be less possible. But recent developments in computer science and programming languages (e.g., object-oriented programming) have encouraged further modularization, and may facilitate future open source projects.

Can the management of open source projects accommodate the increasing number of contributors? The frequency and quality of contributions to each of the open source projects studied appears to be highly skewed, with a few individuals (or at most a few dozen) accounting for a disproportionate amount of the contributions, with most programmers making just one or two submissions. Many contributors to Sendmail, for instance, are students, who use the open source project as part of their software engineering training. These claims are corroborated by the assessment of over 4000 contributions to a Linux development site by Dempsey, et al. [1999], who conclude that developers of more than two Linux applications, while accounting for only 9% of the overall sample, account for over 38% of the total contributions. If large numbers of lowquality contributions are becoming increasingly common, there may be substantial management challenges in the future.26 In this setting, sorting though the large number of software submissions of varying quality is likely to be an increasingly onerous task, one that will swamp the efforts of a volunteer staff. One possibility is the model being adapted by Sendmail, where professional employees of the for-profit firm manage the open source submissions (as well as making their own contribution). But in general, the extent to which individual open source projects can accommodate substantial growth in contributors remains an open question. (At the same time, it must be acknowledged that the same skewness of output is also observed among programmers employed in commercial software development facilities [e.g., see Brooks, 1975].)

To what extent do open source projects have a greater or shorter effective life span than traditional projects? One of the arguments offered by open source advocates is that because their source code is publicly available, and at least some contributions will continue to be made, its software will have a longer duration. (Many software products by commercial vendors are abandoned or no longer upgraded after the developer is acquired or liquidated, or even when the company develops a new product to replace the old program.) But another argument is that the nature of incentives being offered open source developers—which as discussed above, lead them to work on highly visible projects—might lead to a “too early” abandonment of projects that experience a relative loss in popularity. An example is the XEmacs project, an open source project to create a graphical environment with multiple “windows” that originated at Stanford. Once this development effort encountered an initial decline in popularity, many of the open source developers appeared to move onto alternative projects.

Our ability to answer confidently these and related questions is likely to increase as the open source movement itself grows and evolves. At the same time, it is heartening to us how much of open source activities can be understood within existing economic frameworks, despite the presence of claims to the contrary. The literature on “career concerns” provides a lens through which the structure of open source projects, the role of contributors, and the movement’s ongoing evolution can be viewed.

1. The media like to portray the open source community as wanting to help mankind, as it makes a good story. Many open source advocates put limited emphasis on this explanation. 媒体喜欢把开源社区描绘成想要帮助人类，因为这是个好故事。许多开源倡导者对这种解释的强调是有限的。  2

2. These are summarized in Darwall and Lerner [2000]. 这些都在 Darwall 和 Lerner[2000] 中进行了总结。  2

3. This history is of necessity highly abbreviated. For more detailed treatments, see Browne [1999], DiBona, Ockman, and Stone [1999], Gomulkiewicz [1999], Levy [1984], and Raymond [1999a]. 这段历史必然是高度简略的。更详细的论述，见 Browne [1999], DiBona, Ockman, and Stone [1999], Gomulkiewicz [1999], Levy [1984], and Raymond [1999a].  2

4. Programmers write source code using languages such as Basic, C, and Java. By way of contrast, most commercial software vendors only provide users with object, or binary, code. This is the sequence of 0s and 1s that directly communicates with the computer, but which is difficult for programmers to interpret or modify. When the source code is made available to other firms by commercial developers, it is typically licensed under very restrictive conditions. 程序员使用 Basic、C 和 Java 等语言编写源代码。作为对比，大多数商业软件供应商只向用户提供对象或二进制代码。这是与计算机直接通信的 0 和 1 的序列，但程序员很难解释或修改。当商业开发商将源代码提供给其他公司时，通常是在非常严格的条件下授权。  2

5. It should be noted, however, that some projects, such as the Berkeley Software Distribution (BSD) effort, did take alternative approaches during the 1980s. The BSD license is much less constraining than the GPL: anyone can modify the program and redistribute it for a fee without making the source code freely available. In this way, it was a continuation of the university-based tradition of the 1960s and 1970s. 然而，应该指出的是，一些项目，如伯克利软件发行（BSD）的努力，在 20 世纪 80 年代确实采取了其他方法。BSD 许可证的限制比 GPL 要少得多：任何人都可以修改程序并有偿重新发布，而不需要免费提供源代码。在这方面，它是 1960 年代和 1970 年代基于大学的传统的延续。  2

6. Two main open source projects (GNOME and KDE) are meant to remedy Linux’s handicap on the desktop (mouse and windows interfaces). 两个主要的开源项目（GNOME 和 KDE）是为了弥补 Linux 在桌面上的缺陷（鼠标和窗口界面）。  2

7. For example, Torvalds [1999] argues that the Linux model works best with developer-type software. Ghosh [1999] views the open source process as a large repeated game process of give-and-take among developer-users (the “cooking pot” model). 例如，Torvalds[1999] 认为 Linux 模式在开发者类型的软件中效果最好。Ghosh[1999] 认为开放源码过程是开发者-用户之间的大型重复博弈过程（”煮锅 “模式）。  2

8. A complication is introduced by the fact that firewall-protected servers may be quite different in nature. For instance, a survey of both protected and unprotected servers in the summer of 1996 by Zoma Research concluded that open source server programs, including Apache, accounted for only 7% of all installations, far less than the contemporaneous Netcraft estimate. 受防火墙保护的服务器在性质上可能有很大的不同，这就带来了一个复杂的问题。例如，1996 年夏天，Zoma Research 对受保护和不受保护的服务器进行了调查，结论是包括 Apache 在内的开放源码服务器程序只占所有安装量的 7%，远远低于 Netcraft 同期的估计。  2

9. Linus Torvalds and others have been awarded shares in Linux-based companies that went public. Most certainly, these rewards were unexpected and did not affect the motivation of open source programmers. If this practice becomes “institutionalized,” such rewards will in the future be expected and therefore impact the motivation of open source leaders. Linus Torvalds 和其他人在上市的基于 Linux 的公司中获得了股份。最肯定的是，这些奖励是出乎意料的，并没有影响开放源码程序员的积极性。如果这种做法变得 “制度化”，这种奖励在未来就会被预期，从而影响到开放源代码领导者的积极性。  2

10. To be certain, commercial firms (e.g., Netscape, Sun, O’Reilly, Transmeta) supporting open source projects are also able to compensate programmers, because they indirectly benefit financially from these projects. Similarly, the government and not-for-profit corporations have done some subsidizing of open source projects. Still, there should be an edge for commercial companies. 可以肯定的是，支持开源项目的商业公司（如 Netscape、Sun、O’Reilly、Transmeta）也能够对程序员进行补偿，因为他们间接地从这些项目中获得经济利益。同样，政府和非营利性公司也对开放源码项目进行了一些补贴。不过，商业公司还是应该有一个优势。  2

11. While we are here interested in private incentives to participate, note that this complementarity between apprenticeship and projects is socially beneficial. The social benefits might not increase linearly with open source market share, however, since the competing open source projects may end up competing for attention in the same common pool of students. 虽然我们在这里对参与的私人激励感兴趣，但请注意，学徒制和项目之间的这种互补性是有社会效益的。然而，社会效益可能不会随着开源市场份额的增加而线性增长，因为相互竞争的开源项目最终可能会在同一个共同的学生库中争夺注意力。  2

12. A standard argument in favor of open source processes is their massive parallel debugging. Typically, commercial software firms can only ask users to point at problems: beta testers do not fix the bugs, they just report them. It is also interesting to note that many commercial companies do not discourage their employees from working on open source projects. In many cases where companies encourage such involvement, programmers use open source tools to fix problems. Johnson [1999] builds a model of open source production by a community of user-developers. There is one software program or module to be developed, which is a public good for the potential developers. Each of the potential developers has a private cost of working on the project and a private value of using it; both of which are private information. Johnson shows that the probability that the innovation is made need not increase with the number of developers, as free-riding is stronger when the number of potential developers increases. 支持开放源码进程的一个标准论点是它们的大规模并行调试。通常情况下，商业软件公司只能要求用户指出问题：β测试者不修复错误，他们只是报告它们。同样有趣的是，许多商业公司并不阻止他们的员工参与开放源代码项目的工作。在许多公司鼓励这种参与的情况下，程序员使用开放源码工具来修复问题。Johnson[1999] 建立了一个由用户-开发者组成的社区的开放源码生产模型。有一个待开发的软件程序或模块，这对潜在的开发者来说是一个公共物品。每个潜在的开发者都有在该项目上工作的私人成本和使用它的私人价值；这两者都是私人信息。约翰逊表明，创新的概率不需要随着开发者数量的增加而增加，因为当潜在开发者的数量增加时，搭便车的情况更严重。  2

13. An argument often heard in the open source community is that people participate in open source projects because programming is fun and because they want to be “part of a team.” While this argument may contain a grain of truth, it is puzzling as it stands; for, it is not clear why programmers who are part of a commercial team could not enjoy the same intellectual challenges and the same team interaction as those engaged in open source development. The argument may reflect the ability of programmers to use participation in open source projects to overcome labor market rigidities that make signaling in other ways problematic. 在开源社区经常听到的一个论点是，人们参与开源项目是因为编程很有趣，因为他们想成为 “团队的一部分”。虽然这个论点可能包含一丝真理，但它是令人费解的；因为，不清楚为什么作为商业团队一部分的程序员不能像从事开源开发的程序员那样享受同样的智力挑战和同样的团队互动。这个论点可能反映了程序员有能力利用参与开放源码项目来克服劳动力市场的僵化，而这种僵化使得以其他方式打信号成为问题。  2

14. Valloppillil [1998] further argues that reaching commercial grade quality often involves unglamorous work on power management, management infrastructure, wizards, etc., that makes it unlikely to attract open source developers. Valloppillil[1998] 进一步认为，达到商业级别的质量往往涉及到电源管理、管理基础设施、向导等不光彩的工作，这使得它不可能吸引开源开发者。  2

15. E.g., Valloppillil’s [1998] discussion of the Mozilla release. 例如，Valloppillil 的 [1998] 关于 Mozilla 发布的讨论。  2

17. For instance, concerns about the “poaching” of key employees was one of the reasons cited for Steve Jobs’ recent decision to cease giving credit to key programmers in Apple products [Claymon, 1999]. 例如，对 “挖走 “关键员工的担忧是史蒂夫-乔布斯最近决定停止在苹果产品中对关键程序员给予奖励的原因之一 [Claymon, 1999]。  2

18. Cusamano and Selby [1995], however, document a number of management institutions at Microsoft that attempt to limit these pressures. 然而，Cusamano 和 Selby[1995] 记录了微软公司一些试图限制这些压力的管理制度。  2

19. Another motivation for commercial companies to interface with the open source world may be public relations. We do not view this as a permanent strategy, however, as programmers and consumers presumably cannot be so easily fooled over an extended period. Similarly, firms may temporarily encourage programmers to participate in open source projects to learn about the strengths and weaknesses of this development approach. 商业公司与开放源代码世界对接的另一个动机可能是公共关系。然而，我们不认为这是一个永久性的策略，因为程序员和消费者不可能在很长一段时间内如此容易被愚弄。同样，公司可以暂时鼓励程序员参与开源项目，以了解这种开发方式的优势和劣势。  2

20. Red Hat provides support for Linux-based products, while VA Linux provides hardware products optimized for the Linux environment. In December 1999, their market capitalizations were $17 and$10 billion respectively. 红帽公司为基于 Linux 的产品提供支持，而 VA Linux 则提供为 Linux 环境优化的硬件产品。1999 年 12 月，它们的市值分别为 170 亿美元和 100 亿美元。  2

21. Of course, these programmers also increase the company’s “absorptive capacity” and help the company with the development of the proprietary segment. 当然，这些程序员也增加了公司的 “吸收能力”，并帮助公司发展专有部分。  2

22. For instance, in the Mozilla project, Netscape’s unwillingness to make large amounts of browser code public was seen as an indication of its questionable commitment to the open source process. In addition, Netscape’s initial insistence on the licensing terms that allowed the corporation to relicense the software developed in the open source project on a proprietary basis was viewed as problematic [Hamerly, Paquin, and Walton, 1999]. The licensing terms however may not have been the hindering factor, since the terms of the final license are even stricter than those of the GPL. 例如，在 Mozilla 项目中，网景公司不愿意公开大量的浏览器代码，这被认为是它对开放源码过程的承诺值得怀疑的表现。此外，网景公司最初坚持的许可条款允许该公司在专有基础上重新许可在开放源码项目中开发的软件，这被认为是有问题的 [Hamerly, Paquin, and Walton, 1999]。然而，许可条款可能不是阻碍因素，因为最终许可的条款甚至比 GPL 的条款更严格。  2

23. Some of the E-speak code remains proprietary to Hewlett Packard; so will some applications and utilities developed in the future. It should also be noted that HP can profit by providing services to E-speak users, which, while not proprietary, should be an arena in which HP has a natural advantage. 一些 E-speak 代码仍然是惠普公司的专利；未来开发的一些应用程序和实用程序也将如此。还应注意的是，惠普可以通过向 E-speak 用户提供服务而获利，这虽然不是专利，但应该是惠普具有天然优势的领域。  2

24. See, for example, the discussion of SGI’s open source strategy in Taschek [1999]. 例如，见 Taschek [1999] 中对 SGI 的开放源码战略的讨论。  2

25. The increasing number of software patents being granted by the U.S. Patent and Trademark Office provide another avenue through which such a “hijacking” might occur. In a number of cases, industry observers have alleged that patent examiners—not being very familiar with the unpatented “prior art” of earlier software code—have granted unreasonably broad patents, in some cases giving the applicant rights to software that was originally developed through open source processes. 美国专利和商标局授予的越来越多的软件专利提供了另一个可能发生这种 “劫持 “的途径。在一些案例中，行业观察家声称，专利审查员–对早期软件代码中未获专利的 “现有技术 “并不十分熟悉–已经授予了不合理的宽泛专利，在某些情况下，申请人获得了最初通过开放源代码程序开发的软件的权利。  2

26. Linus Torvalds has succeeded in overseeing the Linux process by delegating to trusted lieutenants who themselves have sub-delegated. 莱纳斯-托瓦兹（Linus Torvalds）通过授权给自己信任的副手，而这些副手自己又转授权，成功地监督了 Linux 进程。  2