# 构建和运行开源社区

* 原文链接：[Building and Running an Open-Source Community](https://freebsdfoundation.org/wp-content/uploads/2020/09/Building-and-Running.pdf)
* 作者：**MARSHALL KIRK MCKUSICK**

伯克利软件发行版（BSD）最初是 Bill Joy 在加利福尼亚大学伯克利分校时的一项兼职工作。当时他与四个其他学生共用一间办公室。今天，BSD 拥有成千上万的开发者，且被全球数百万用户使用。这是我们如何走到今天的故事。

FreeBSD 是一款开源操作系统，源自加利福尼亚大学伯克利分校于 1992 年和 1994 年发布的 4.4BSD-Lite。FreeBSD 是少数在 25 年以后仍然活跃的开源项目之一。

开源项目的典型生命周期是，一个人或有时一个小团队对某个事情产生兴趣，并为此编写一堆代码。通常，最终的结果是，他们实现了这个想法，或者团队的领导者感到无聊而转移到其他项目，导致项目终结。如果你查看 SourceForge 和 GitHub，你会发现 90% 的项目是“黑暗的”，意味着它们至少一年没有任何提交。具有长期生命力的开源项目必须有某种方法将领导权从一个人传递给另一个人。本文的大部分内容都在探讨 FreeBSD 的治理结构及其如何随时间的演变。

## 当前 FreeBSD 的用户

今天，FreeBSD 最广泛的应用是提供核心互联网支持。FreeBSD 被用来操作根域名服务器、主要的网络托管、路由基础设施，并作为主要商业操作系统的基石。例如，奈飞的内容分发服务器就运行在 FreeBSD 上，这些服务器贡献了全球三分之一的互联网流量；纽约互联网（New York Internet）负责东海岸的许多网络基础设施；BBC 的服务器也主要运行在 FreeBSD 上。Juniper Networks 的路由器和 Network Appliance 的文件服务器都是建立在 FreeBSD 基石上的。FreeBSD 在嵌入式操作系统和设备市场中得到了广泛应用，因为一些公司需要将其知识产权嵌入操作系统中，因此不能使用 Linux，因为其使用了 GNU 公共许可证（GPL）。我将在本文后续讨论 GPL。

Verisign 使用 FreeBSD 来处理其关键的互联网名称服务查询。Verisign 使用 FreeBSD、Linux 和商业操作系统，因为他们希望操作系统多样化，以防其中某个操作系统出现零日漏洞。发生零日漏洞时，他们可以关闭受影响的系统而不丧失服务，因为他们的服务必须始终保持在线。他们看重 FreeBSD，因为它足够小众，不太可能成为攻击目标。它足够坚固，破解它比破解其他操作系统更难，而 FreeBSD 的安全性部分来源于其代码库的缓慢变化。罕为人知的是，FreeBSD 是索尼 PlayStation 4 及之后版本的操作系统。苹果的 Darwin 操作系统（Mac OS X 的基础操作系统）直接源自 FreeBSD。

## 伯克利的计算机系统研究小组（CSRG）

![](https://github.com/user-attachments/assets/8b9862f2-28c4-4e6e-8906-39c845d49af1)

图片由 Ollivier Robert 提供。

我将从一些历史开始，回到 1970 年代和 1980 年代，当时 BSD 在加利福尼亚大学伯克利分校进行开发。BSD 从 1977 年开始在伯克利启动，最初是 Bill Joy 独自进行的项目（Bill Joy 后来成为了 Sun Microsystems 的创始人之一）。

第一款发行版叫做 BSD 发行版，发布于 1977 年初，包含了 Bill 编写的三个实用程序，这些程序可以运行在 UNIX 上：

* C shell
* ex/vi 编辑器
* Pascal 编译器/解释器

你只需要将这些工具添加到现有的 UNIX 版本中。通常，你运行的是第六版 UNIX，也叫做 V6。随着用户逐步迁移到 1979 年发布的第七版 UNIX（Version 7），他们也可以将 BSD 工具带过去。1979 年 5 月发布的 2BSD 版本增加了更多的工具。

到目前为止，加利福尼亚大学伯克利分校一直在 Digital Equipment Corporation（DEC）的 PDP-11 机器上运行 UNIX。PDP-11 具有 16 位的地址空间，因此最大支持 64K 字节的文本和 64K 字节的数据。UNIX 是基于交换的系统。UNIX 会将程序加载到内存中执行，并在程序完成后释放内存。

1978 年，DEC 发布了他们的 32 位 VAX 计算机（VAX 代表虚拟地址扩展）。伯克利是早期采用者之一，收到了序列号为 7 的 VAX 机型，最大内存容量为四兆字节。VAX 是第一个支持虚拟内存的硬件平台，它上面运行 UNIX。VAX 的供应商操作系统是 VMS，这主要是一个批处理系统。VMS 最初的前端是一个原始的命令行界面，供交互式使用，但 UNIX 用户对其并不喜欢。

UNIX 最初的 VAX 移植（32/V）是由贝尔实验室的 John Reiser 和 Tom London 完成的，并没有利用虚拟内存硬件。它像 PDP-11 一样作为基于交换的系统运行。因此，无法运行任何大于物理内存的程序。

加利福尼亚大学伯克利分校（UCB）的用户使用的是 Franz Lisp，而 Franz Lisp 需要的地址空间远远超过伯克利的 VAX 机器的四兆字节物理内存。虽然 VMS 支持虚拟内存，但它的接口并不令他们满意。因此，Bill Joy 在四周的圣诞假期里，将 Ozalp Babaoglu 的 VM 系统移植到 UNIX /32V 中。假期结束后，移植工作稳定到足够的程度，以至于它永久取代了伯克利使用的 VMS。

包含 VM 系统的版本成为了 3BSD，并在 1979 年发布。3BSD 发行版是第一个包含完整内核、工具和库等的伯克利发行版。分发完整的系统成为了 BSD 发行版的模型，并且至今仍在使用。

美国国防高级研究计划局（DARPA）资助了大量早期的计算机基础设施研究。DARPA 希望有一个通用的机器和操作系统，可以在所有 DARPA 项目中使用，以便它们可以轻松地在不同项目之间转移由支持的小组开发的代码。

DARPA 希望增加其他功能，最重要的是实现 TCP/IP 以取代他们早期的 NCP 网络基础设施，因为 NCP 仅支持 254 台主机。

伯克利获得了一项 DARPA 合同，负责“加固”BSD 内核并帮助集成网络代码。这个合同促成了伯克利计算机系统研究小组（CSRG）的成立。

从 Bill Joy 的办公室开始，CSRG 最终发展成了一个令人惊讶的四人小组。他们花了大量时间与其他人交流，了解他们在系统上做了什么，收集他们的改进和新的工具，将其带回来并整合进系统中。

在 1970 年代，网络主要由运行在 1200 波特的拨号链路组成。大多数对 CSRG 的贡献都是通过九轨磁带进行的，尽管偶尔也会通过非常慢的链路发送电子邮件附件。

在 1980 年代初期，CSRG 开始使用来自贝尔实验室的源代码控制系统 SCCS。这是第一次，SCCS 使他们能够跟踪系统中所做的所有更改、谁做的这些更改以及做这些更改的原因。在 1980 年代初期，使用源代码控制系统是一个新颖的概念。

作为 DARPA 的承包商，CSRG 获得了访问 ARPAnet（最终成为互联网）的权限。ARPAnet 使得扩展能够参与系统开发的人员成为可能。特别是，CSRG 拥有网络连接，这使得其他人能够远程登录到他们的机器，从而避免了使用调制解调器跨越全国或更远距离连接时产生的高昂长途费用。最重要的是，他们拥有源代码控制系统，可以避免冲突并跟踪谁在做什么。

最初，CSRG 向 10 位其他可信人员提供了 CSRG 机器的账户，这些人可以登录并更新源代码。这种做法比之前通过磁带和电子邮件接收并由 CSRG 员工整合的方式效率更高。被选中的人是那些做出了大量贡献并理解 CSRG 喜欢的工作方式的人。他们会协调一些与他们合作的人员，从而将活跃贡献者的总数增加到大约 100 人。

CSRG 员工使用 SCCS 跟踪更改并在发布之前进行验证。CSRG 的关键角色是确保系统整体保持一致。在每次发布之前，CSRG 团队会让源代码控制系统列出自上次发布以来所做的所有更改。在那个时候，变化列表可以打印出来，因为它并不庞大。CSRG 团队会逐一查看每个更改，确保它符合要求，并且不会破坏其他程序。当发现某个更改（例如在“diff”程序中）导致了“patch”程序的故障时，他们会联系做出更改的人，以便修复需要修正的程序。

这种结构为当前基于 BSD 的项目奠定了基础，拥有：

* 监督开发的核心小组，
* 向系统提交代码的更大群体，
* 以及为提交代码的人提供支持的更大群体。

## FreeBSD 项目结构

目前，FreeBSD 项目使用 Subversion 作为其源代码控制仓库。FreeBSD 项目正在转向使用 Git，因为 Git 更为广泛使用并且易于理解。所有人都可以下载仓库，但只有参与项目的部分人员可以更新它。

一款 FreeBSD 发行版由大约 100 个库和 750 款实用程序的核心系统组成，以及支持 Intel/AMD 32/64 位、ARM 32/64 位、MIPS、PowerPC、RISC-V 等处理器的对称多线程内核。

所有其他软件都维护在 ports 中，目前有 32,000 余款软件包。ports 按照不同的功能进行组织：软件开发、网站托管、路由等。ports 拥有一个数据库，允许用户查找他们需要的内容。ports 有两种版本：用户可以选择下载源代码并自行构建，或者可以选择已为各种架构编译好的软件包，直接下载二进制文件。

## 发布

FreeBSD 有一个正式的结构来发布软件。开发树的顶端称为 Current，这是进行持续开发的地方。

FreeBSD 会定期从 Current 分支出一个新的基本发行版，称为 Stable 分支。首先在 Current 中完成错误修复，然后进行测试。在这些修复被证明合理且稳定后，它们会通过一个叫做 MFC（从 Current 移动）的方法迁移到 Stable 分支。从 Current 向 Stable 分支的提交会引用在 Current 树中做出的特定更改。在 Stable 分支的生命周期内，应用二进制接口（ABI）从不更改。

许多项目只有当前版本，因为它们不想支持旧版本，因为继续维护旧版本需要相当多的工作量。由于 FreeBSD 被许多构建嵌入式系统的公司使用，因此 FreeBSD 必须在相当长的时间内继续维护早期版本。历史上，FreeBSD 尝试继续为旧版本提供至少为期五年的安全级别维护。

## FreeBSD 社区

大多数 FreeBSD 的贡献者是志愿者。一个相对较新的现象是，一些公司雇佣人员与 FreeBSD 项目对接，并确保公司修复的问题能够上游合并。

理解一个开源项目的关键在于明白如何让该项目对志愿者有吸引力。志愿者只做他们想做的事。他们不像传统的软件开发公司中那样为你工作：在传统公司中，你有经理，你支付员工工资，经理会告诉员工他们需要做什么。即使是一些不太受欢迎的任务，还是会有人被指派去做，并完成任务，因为这是他们的工作。

在开源项目中，工作力量来自于自愿投入时间的人。他们通常不会自愿去做自己不感兴趣的事情。只有他们想做的事才会做。开源项目的贡献是他们的最低优先事项（排在工作、家庭、休闲等之后）。因此，如果工作发生危机，或者他们家庭有问题，或者想去度假，所有这些事情都会优先于他们的开发工作。即便最初的好意也可能被其他优先事项抢先处理。作为最低优先事项的结果是，你实际上没有固定的时间表。

志愿者是临时的。大多数参与开源项目的人会感到兴奋，工作一段时间后失去兴趣，然后去做其他事情。大多数人不会把一生的事业都投入到某个特定项目中。因此，项目需要计划并应对这种短暂性。如果未能做到这一点，项目最终会积累大量“死木”，这会逐渐拖慢整个项目的进度。未能清除死木是项目失败或“死掉”的常见原因之一。这些死木人物需要离开。

开源项目需要自我组织，因为它们通常没有付费员工或经理。为了实现长久成功，项目必须是民主的，所有成员都应该根据他们对项目的贡献能够在项目的层级中晋升。Linux 是这个规则的明显例外，Linus Torvalds 从一开始就启动并仍然管理着这个项目。但即便是 Linux，也必须找到一个新的领导路径。

开源项目失败的常见原因是大领导和他们的朋友控制了项目。一个新来的参与者如果想要加入，能上升的层次是有限的。他们永远无法进入领导角色，或者通常甚至无法成为领导的直接下属。一个成功的项目必须能够改变领导层，否则领导层就会成为“死木”，使得项目失去方向。

一个项目必须预见到人员更替并优雅地管理它。问题归根结底回到“短暂性”这一问题。项目需要有一个系统来清除死木。这个系统必须非常清晰和透明，必须明确指出不是领导者在挑选某些人。必须有维持参与项目的标准。每个人都必须符合这些标准，当你不再符合这些标准时，就该离开。在 FreeBSD 项目中，保持作为项目提交者的标准是，你必须每 12 个月至少提交一次代码。

## 组织结构

FreeBSD 项目的组织结构由四个同心圆组成

### 用户

最外层是用户。FreeBSD 用户可以提交和接收错误反馈，并参与 FreeBSD 邮件列表的互动。大多数用户没有参与开发，但有些人会提交和接收错误反馈。

确定开源项目用户数量是困难的。通常，用户数量是基于项目软件的下载量。项目通常喜欢统计下载量，然后使用某个乘数来决定这代表了多少用户。由于软件是免费的，许多人可能会下载它，但最终并未使用它。另一方面，一次下载可能是整个公司（如奈飞）进行的，他们将其部署在成千上万的机器上。要平衡这些极端情况几乎是不可能的。因此，FreeBSD 项目只是发布下载量，并让其他人选择使用的乘数。

### 开发者

在用户层内是开发者，大约有 6,000 名。很难精确统计开发者的数量。这个估算是基于有多少独特的名字发布过 bug 列表、参与过各种邮件列表讨论，以及有多少人被记入源代码树中提交的代码。

开发者与项目的联系更加直接。他们编写代码、提交 bug 报告、与项目互动以完成任务。开发者有源代码库的读取权限。如果他们有想要提交的更改，他们需要找到一个有权限将更改提交到源代码树的人。然后他们将更改提交给这些提交者（提交者将在下一个小节中说明）。与提交者建立直接联系是最有效、通常是最快的方式来完成更改，尽管更改也可以通过发送拉取请求来提交。

### 提交者

提交者是能对系统进行更改的人。近年来，提交者的数量在 350 到 400 人之间变化。大多数提交者被授权对系统的特定部分进行更改。通常，提交者会负责 ports 树中特定的一组 Port，他们同意承担这些 Port 的责任。他们将获得对该 Port 组的提交权限。如果他们想对系统的其他部分进行更改，则需要扩展他们的提交权限。

通常，Ports 没有像核心系统和内核那样受到严格的监督。负责处理该 Port 的人通常不需要与其他提交者核实。该 Port 所属的社区，例如 Apache，已经有很多监管了。因此，提交者的工作是确保 FreeBSD 与 Apache 的最新发布保持同步。提交者可以征求其他意见，但他们不必须这么做，通常也不需要这么做。

所有对核心系统和内核的更改都需要至少由另一名提交者进行审查。提交信息必须列出谁进行了审查。所有的提交更改都会发送给所有提交者，因此任何列为已进行审查的人，如果觉得他们的反馈没有得到解决，可以提出异议。

提交者是将开发者的更改反馈进项目的关键。开发者会找到在他们感兴趣的领域内工作的提交者。通常，开发者通过查看谁在他们感兴趣的代码上积极做出更改，找到相关的提交者，并直接联系他们。

他们一起合作，将更改提交进去。当某个开发者开始更加投入时，提交者可以提名该开发者成为提交者。成为提交者的过程有些复杂。若开发者被提交者提名，核心团队（下节中所述）将做出决定。

新提交者必须有一位导师，通常是提名他们的提交者。导师负责确保提交者不会犯下致命错误。导师帮助开发者学习他们需要知道的内容：如何管理源代码控制工作流程；如何使用 Phabricator（提供提交前代码审查工作流程的论坛）；如何使用 Bugzilla（用于跟踪 bug 报告的论坛）；在哪里了解项目的编码风格；在哪些邮件列表上发布审查请求；哪些更改需要更广泛的审查；甚至一些小细节，如应该在哪个 IRC 频道参与讨论。

导师关系通常持续几个月到一年以上。那些在项目中非常活跃的人可以比那些不太活跃的人更快完成导师过程。大多数提交者都很感激有导师的帮助，因为他们不想做出那些会被视为愚蠢或与项目方式不符的事情。通常，即使在导师允许他们独立工作后，他们仍然会继续请求导师审查他们的更改。

项目需要处理一个遗憾但重要的任务，即识别并撤销那些不再参与的提交者的提交权限。项目需要制定一个明确且一致执行的政策，以撤销不活跃提交者的权限。

FreeBSD 的退休政策是：如果提交者一年内未使用提交权限，则自动暂停其提交权限。在暂停后的六个月内，只需请求重新激活提交权限即可恢复。若提交权限被暂停满 18 个月且未使用，提交者将需要重新经历提名和导师指导过程。

重复提名和导师指导过程的原因是，项目的工作方式会随着时间的推移而变化。新的规则和程序会被引入，主要工具可能发生变化，例如源代码控制系统的切换。可能会添加新的工具，比如 Phabricator 审查系统。也可能会有 bug 跟踪系统的变化，通常还有邮件列表、IRC 频道等的重新组织。返回的提交者需要有人帮助他们重新适应。因此，回归的提交者的导师指导期通常较短。

避免失去提交权限实际上是一个很小的门槛。保持提交权限只需每年进行一次提交，并且可以通过更新个人信息（别人查看“此人是谁”时能看到的内容）来完成。因此，这个门槛几乎是微不足道的。

最近对项目成员构成的研究发现，提交者的平均年龄为 39 岁，中位数年龄为 37 岁；最年轻的提交者为 25 岁，最年长的为 68 岁；最多的群体集中在 31 至 40 岁之间。

大多数加入项目的人从事软件开发已经至少十年了。他们通常从青少年时期开始，到 20 多岁中后期时已经有 10 年的经验。许多人来自 Linux 领域，在那里他们已经晋升到达了可以走的最高层次。他们希望能够继续晋升，了解了 FreeBSD 后，看到它的结构非常合适，因此加入了项目。

虽然项目中也有青少年提交者，但稍微年长一些的成员的好处在于，他们已经过了“青春期的烦恼”，也就是说，他们已经不再在邮件列表上争吵了。与他人讨论时，他们往往更加成熟，几乎没有人身攻击。

避免在邮件列表中发生争斗，特别是人身攻击是非常重要的。因此，邮件列表会受到严格监控。如果有人开始陷入无休止的争论或进行人身攻击，他们会被叫停，并被告知将这些内容移出列表。邮件列表一旦中毒，想要重新恢复秩序就非常困难。

### 核心团队

项目由九人组成的核心团队领导。核心团队的职责是监督和管理 FreeBSD 项目。

何者负责项目的历史随着时间的推移而发展。当 BSD 项目在伯克利大学开始时，采用了“领主与主人”的方式，所有最终决策由一个人做出。BSD 项目由 Bill Joy 创办并管理，直到他离开前往 Sun Microsystems。之后，Mike Karels 接管了项目，后来由 Kirk McKusick（本文的谦卑叙述者和作者）接手。

当 BSD 项目从伯克利大学分离并传递到外部世界时，出现了几个发行版，包括 Bill Jolitz 的版本，后来是 NetBSD 和 FreeBSD。本文关注的是 FreeBSD 的发展历程。

在成立 FreeBSD 组织时，组织者决定设立一个七人组成的核心小组，负责监督项目的管理。最初的核心小组是自我选拔的。设立项目的人自行委任为核心团队成员，他们是“终身沙皇”。

正如许多开源项目一样，随着时间推移，一些人开始失去兴趣。没有机制来替换他们，而大多数人不愿意离开，因为在核心团队中有一定的声望。

于是，一群人聚集在一起，决定制定一套章程，其中包括将核心团队职位设为选举产生的规定。核心团队的成员人数也扩展到了九人。整个核心团队每两年选举一次。核心团队成员由提交者提名并选举产生。任何活跃的提交者都可以竞选核心团队成员。候选人是自我选择的，不需要提名。

每个候选人都需要发表一份声明，说明自己为何应当当选为核心团队成员。近年来，核心团队候选人会举办一系列的“办公时间”活动，候选人会出席并回答问题，阐述他们对项目的愿景。

经过规定的几周后，选举开始。每个提交者有九票。得票最多的九个人将成为下任核心团队成员。虽然曾有设立任期限制的努力，但目前并没有这种限制。选民非常清楚谁在核心团队中推动了工作，谁与他人合作愉快。无所作为的人可以继续竞选，但他们往往不会连任。历史上，每两年会有三到四名核心团队成员更换。

核心团队的主要责任之一是监督管理项目的各个小组。这些小组包括：

* 管理项目服务器的小组，
* 负责发布工程的小组，
* 管理质量保证和持续集成测试的小组，
* 组织和运行 FreeBSD 峰会的小组，
* 处理安全问题的小组，
* 负责监督 Ports 库的小组，
* 监督系统文档的小组。

一个重要任务是组织 FreeBSD 峰会，会议上，实际使用该系统的人讨论他们的工作内容、需求和期望看到的改进。峰会的关键成果之一是列出由某些人自愿承担的任务。事实上，峰会通常提供了大量的创意，这些创意成为了未来路线图的一部分，帮助规划出需要完成的大目标。最重要的是将路线图付诸实施，这需要鼓励人们将一些创意转化为实际的成果。

核心团队还负责新增和移除提交者。如前所述，增加新提交者的请求会提交给核心团队。核心团队审核请求，确保找到一个或多个合适的导师，并在一切就绪后批准该请求。提交者的移除通常通过上面描述的超时机制进行。

核心团队的另一个重要角色是解决提交者之间的分歧。大多数时候，分歧会通过邮件列表或 IRC 频道来解决。有时，存在哲学上的不同，双方无法解决。偶尔，这些分歧会演变成“提交战争”。某个提交被检查进系统，然后又被撤回，再次提交，等等。在这种情况下，核心团队需要介入并进行裁决。

核心团队用于执行决策的工具是暂时暂停提交权限。例如，在解决提交战争时，核心团队可以强制实施冷静期。在两周内双方都不允许进行提交。极少情况下，提交者的提交权限可能会被永久移除。在项目历史上，完全移除权限仅发生过两次。考虑到 FreeBSD 项目在历史上有成千上万的提交者，这个数字极小。

## 贡献者类型

贡献的类型有很多种，拥有广泛的视角很重要。FreeBSD 项目没有层级结构：例如内核提交者比工具提交者更重要，工具提交者又比文档提交者更重要等。某些其他项目确实有这样的层级结构，但在 FreeBSD 项目中，所有类型的贡献都没有被赋予更高的价值。人们在自己擅长的领域做贡献。

以下是一些人们做贡献的领域：

* Ports 维护者（196 名提交者在过去 12 个月内向 Current 提交了 27,840 次提交）。这些提交不包括 MFC 和其他可能使总数增加 50% 的更改。
* 工具维护者（193 名提交者在过去 12 个月内向 Current 提交了 4,334 次提交）。他们维护着 775 个工具和库。这些提交不包括每次提交时的一到两个额外的 MFC。
* 内核维护者（71 名提交者在过去 12 个月内向 Current 提交了 6,056 次提交）。这些提交不包括每次提交时的一到两个额外的 MFC。
* 文档组（75 名提交者在过去 12 个月内向 Current 提交了 2,076 次提交）。一个提交可能是手册的一整个章节，或者一个完整的手册（man）页面，这通常比代码提交更大。FreeBSD 项目的一大优势是它的文档比大多数其他开源项目要好。如今，文档已设置了多语言支持，大部分文档大约有 10 种语言版本。
* 安全团队（7 名成员）。大多数时候，他们的工作不多，但一旦出现安全威胁，他们必须立刻处理！例如，心脏出血漏洞。拥有七名团队成员使得每天 24 小时都有覆盖。团队成员分布在美国、澳大利亚、日本、印度、东欧和西欧。
* 系统管理员（7 名成员，由 5 名网站管理员和 2 名邮件管理员组成）。这是一个不被感激但非常必要的任务。项目有多个网站、许多在线文档、需要维护的镜像、邮件列表、构建服务器、开发机器等。
* 发布工程师（1 名主力，10 名助手）。在实际发布阶段，助手的数量会显著增加。
* 质量保证（2 名主力，5 名助手）。这是 FreeBSD 项目中新成立的小组。许多开源项目没有这样的团队。

宣传和推广小组（2 名主力，6 名助手）。大约十年前，该小组的成员当选为核心团队的一员。这促成了徽标的更改和网站的完全改版。这些变化表明，核心团队不仅仅关注编程，还包括项目的运营和推广。

## 许可证

大多数商业软件采用传统的版权方式进行开发。通常源代码不可用，或者仅在非常有限的方式下提供，通常需要签署保密协议。接收者可能甚至不能修改源代码，当然也不能将其传递给其他人。由于开源项目通常希望源代码能够被共享，因此它们不使用传统的版权。

开源软件通常使用 GNU 通用公共许可证（GPL），有时也被称为“Copyleft”许可证。根据 GPL 版本 2（GPL 2）许可证，软件必须提供源代码，包括对源代码所做的任何更改。在更具限制性的 GPL 版本 3（GPL 3）许可证下，除了必须提供源代码之外，如果这些源代码受到专利保护，您还必须免费提供这些专利，以供使用您代码的任何人使用。GPL 3 许可证引起了许多不安。许多公司通过为其代码中的想法申请专利来规避 GPL 2 许可证的限制。他们按要求发布源代码，但要求任何使用该代码的人支付专利费。这种做法违背了 GPL 的精神，这也是创建 GPL 3 许可证的原因。

Linux 内核使用 GPL 2 许可证，这意味着任何为 Linux 内核编写的代码都必须发布。一些公司利用其专利来控制他人对其使用的权利。许多公司通过创建可加载的二进制模块来避免发布源代码，这些模块会被加载到 Linux 内核中。可加载模块是一种避免 GPL 条款的有争议的方式。

Linux 并未转为使用 GPL 3 许可证。但是，许多其他 GNU 软件采用了 GPL 3 许可证，包括大多数围绕 Linux 内核打包的软件，如 GCC 编译器及其库。目前尚不清楚，在加载 GPL 3 库时，您的程序是否会受到 GPL 约束。GPL 3 许可证让许多公司感到不安，这有利于那些采用 BSD 许可的项目。

另一种常见的方法是 BSD 许可证。有时被称为“复制中心”许可证，意思是可以拿到复制中心，复制你想要的任何数量。源代码和专利权可能提供，也可能不提供，即你可以选择是否将你的更改反馈回来。

FreeBSD 使用 BSD 许可证，这在其成功中发挥了重要作用，尤其是在那些将专有代码集成到内核中的公司中。实际上，FreeBSD 项目获得的代码数量与 GPL 开源项目差不多，但由于学习曲线较长，过程需要更多时间。

X 公司基于 FreeBSD 构建其专有产品，并选择不将任何东西反馈回来。后来，到了升级底层 FreeBSD 到下一个版本的时机。他们需要移植他们所做的许多错误修复，并且必须移植所有的更改。这是一个漫长且昂贵的过程。他们意识到，如果他们当初反馈了错误修复，那么这些修复就已经在那里了。因此，这次经历促使他们逐渐开始反馈一些错误修复。两年后，他们升级到下一个版本。他们意识到，许多更改其实并不是专有的。如果他们将这些更改贡献回来，那么其他人就可以维护它们。到第三次升级周期时，公司开始尝试反馈与其产品特定的代码。结果是，公司开始雇佣提交者，以便为他们提供直接的通道，了解系统中发生的变化，并促进他们的错误修复和增强功能被合并回 FreeBSD。

## 结论

建立一个开源社区需要持续不断的努力。人们往往会倾向于坚持一直以来的做事方式。为了保持活力，项目必须随着时间推移而适应用户需求的变化。社区必须对新人保持欢迎，并为他们的成长提供路径。新人需要导师来帮助他们融入社区。与此同时，导师们需要接受项目中新方法的引入。FreeBSD 项目已经成功地平衡了这些需求超过四分之一世纪。我希望它能继续做到这一点，未来很多年仍然如此。

***

**DR. MARSHALL KIRK MCKUSICK** 撰写书籍和文章，教授与 UNIX 和 BSD 相关的课程，并提供有关软件专利、商业机密和版权问题的专家证词。自 1993 年项目成立以来，他一直是 FreeBSD 项目的开发者和提交者。在加利福尼亚大学伯克利分校时，他实现了 4.2BSD 快速文件系统，并且是伯克利研究计算机科学家，负责监督 4.3BSD 和 4.4BSD 的开发和发布。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20200708-ji-zhun-ce-shi-tiao-you/community.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.