FreeBSD 管理架构的演变
作者：DR. MARSHALL KIRK MCKUSICK、BENNO RICE
伯克利软件发行版（BSD）始于 1977 年，是比尔·乔伊（Bill Joy）在加州大学伯克利分校发起的一个个人项目。到 1980 年，BSD 发行版已经从最初几款可以添加到 AT&T UNIX 系统的小程序发展为一个完整的系统，由四位自称计算机系统研究组（CSRG）的人协调管理。
那时，BSD 开发开始使用 SCCS 管理，这是第一个源代码控制系统。到 1983 年，套接字接口已经设计完成，并在其下实现了 TCP/IP，使少数受信任的外部贡献者能够通过 ARPAnet（后来的互联网）登录 CSRG 的开发机器，并使用 SCCS 直接更新源代码。CSRG 员工随后可以使用 SCCS 跟踪更改并在发布前进行验证。这种结构为 BSD 从大学分离出来成为开源项目后的现有 BSD 基础项目奠定了基础。
FreeBSD 项目成立
伯克利发布的最后一个 BSD 发行版是一个开源版本，名为 Networking Release 2，后来重新发布为 4.4BSD-Lite。该发行版缺少六个仍包含 AT&T 专有代码的内核文件。比尔·乔利茨（Bill Jolitz）为这六个缺失文件编写了替代版本，并发布了一个名为 386BSD 的系统，可在普通 PC 硬件上运行。由于对 Bill 的 386BSD 开发进度感到不满，一些开发者从 386BSD 分支出来，创立了 FreeBSD 项目。
遵循 CSRG 模型，FreeBSD 项目使用 CVS 源代码仓库管理代码。早期版本的唯一分发方式是极慢的 14.4K 拨号调制解调器。随着 FreeBSD 1.0 发布临近，开发者希望能更快地将系统推广到更大用户群。乔丹·哈伯德（Jordan Hubbard）联系了 Walnut Creek CD-ROM，该公司以创建开源软件 CD-ROM 发行版并销售为商业模式。FreeBSD 开发者扩大发行的目标与 Walnut Creek CD-ROM 的商业模式高度契合，因此 Walnut Creek CD-ROM 乐于将 FreeBSD 纳入其发行列表。Walnut Creek CD-ROM 为 FreeBSD 开发者提供了高性能开发机器，用于托管 CVS 仓库并管理其销售的发行版的发布工程。随着 FreeBSD 的受欢迎程度提升，Walnut Creek CD-ROM 还聘请了多名 FreeBSD 开发者全职从事 FreeBSD 工作。
随着 FreeBSD 使用范围扩大，发行版中内置的软件包数量也随之增加。为了防止 FreeBSD 发行版体积过大，创建了 ports。FreeBSD 基本系统仅包含关键程序和库，而 ports collection（目前有超过 25,000 个软件包）可用于补充基本系统以满足系统功能需求。例如，桌面计算机可以从 ports 安装窗口管理器、网页浏览器和邮件客户端；提供 Web 服务的机器可以安装 Apache 等程序。
最初，所有参与 FreeBSD 的开发者都可以向 CVS 仓库提交代码，但随着开发者数量增加，这种方式已不可行。迁移到 Walnut Creek CD-ROM 后，建立了核心团队负责提交代码并决定谁有权限提交。与此同时，引入了 GNATS 进行缺陷追踪。
FreeBSD 项目向团队化发展
随着 FreeBSD 的规模和需求扩大，并成为更多公司的核心技术，源代码仓库和主要开发机器从 Walnut Creek CD-ROM 转移到了雅虎，当时整个公司都运行在 FreeBSD 上。意识到让 FreeBSD 依赖单一公司的资助是不理想的，Justin Gibbs 于 2000 年创建了 FreeBSD 基金会，希望 FreeBSD 最终能够筹集足够的支持，以完全支撑 FreeBSD 项目基础设施。基金会完全能够支持 FreeBSD 项目资源则花费了十年时间。如今，它提供了许多支持，包括：负责市场营销和版本工程团队的员工；监督获得基金会资助的开发者的工作人员；以及其他基金会员工，负责处理志愿者没有时间或不愿意完成的系统开发工作。
最初，核心团队是永久任命的，成员数量最终接近 20 人。到 2000 年，约三分之一成员持续活跃于项目中，另三分之一则完全不参与。这些“闲置成员”几乎让核心团队的工作停滞不前。提交者之间对决策未能及时做出，或核心团队成员行为过于果断和激进而几近放任的情况感到日益不满。
因此，一些关键开发者，无论是否属于核心团队，越来越多地自行其是。无人愿意主动放弃他们所认为的核心团队的“高贵”头衔。为了实现更好的问责制、加快决策速度，并自然清理闲置成员，一些核心开发者提议让开发者选举产生核心团队。
Warner Losh 与 Poul-Henning Kamp、Wes Peters 等人一起起草了一套章程，确立了现行结构：核心团队由提交者提名，然后每两年由提交者选举产生。其背后的理念是，如果核心团队不值得信任，FreeBSD 项目就注定失败；但与此同时，又不可能通过立法来强制常识。仅仅通过把一群随机的人选进核心角色，似乎不太可能带来项目的团结，甚至难以在重大问题上形成共识。但大家也认同那句老话：“民主制度是最糟糕的政府形式。但别的制度更糟”。因此，选举产生的核心团队被认为是最佳解决方案。经过一定程度的施压，原有核心团队接受了这套章程，从而引入了首个由选举产生、由九名成员组成的核心团队。
不出所料，只有少数原核心成员进入了首届民选核心团队。总体效果被普遍认为是：核心团队的工作效率并未发生太大变化。然而，开发者整体的满意度有所提升，因为当一个看起来获得多数选民支持的民选机构行使其隐含权威时，就更难对其决策提出异议。
核心团队的职责是确保 FreeBSD 项目的正常运转。核心团队负责批准新的提交者，解决提交者之间的分歧，并通过诸如暂停提交权限等机制来管理提交者的纪律问题。他们还处理项目中出现的其他任何顶层事务。
为了精简对各个领域的管理，核心团队设立了其他团队或指定了负责人（称为“帽子”），来负责项目的特定方面。这些团队包括： • Ports 管理团队，负责监督维护 Ports 树的 217 名 ports 提交者。 • 文档团队，负责监督 126 名文档提交者，开发 FreeBSD 文档，并在其他提交者需要更新文档时督促他们。 • 安全官及其团队，负责处理安全问题，并监督安全通告和更新的发布。 • 由 7 人组成的系统管理团队，负责维护 FreeBSD 基础设施。 • 发布工程团队，由 Glen Barber 以及约 10 名协助他的提交者组成，负责 FreeBSD 的发布工作。 • 质量保证团队，负责运行持续集成构建，并创建一套不断扩展的回归测试。
此外，FreeBSD 基金会还协助开展倡导和市场推广工作。该团队由 Anne Dickison 领导，她与 FreeBSD 社区成员合作，为 FreeBSD 提供宣传、外联和社交网络方面的支持。
今日 FreeBSD
项目协作最初通过单一邮件列表来处理。随着时间推移，该单一列表上的流量不断增长，直到有必要将其拆分为多个邮件列表，每个邮件列表聚焦于特定主题领域，例如 networking、file systems、Ports、documentation、announcements 以及 general questions。最终，邮件列表数量的激增使得处理那些跨越多个领域的问题变得困难。一些协作是通过 Bug 跟踪来完成的，最初使用 GNATS，后来使用 Bugzilla，但在审查较大规模的变更时，尤其是涉及 FreeBSD 之外开发者的变更，这些工具显得力不从心。
2014 年，部署了 Phabricator 实例，这是一款由 Facebook 编写并发布的开源协作工具，用于支持对较大变更进行详细的 pre-commit 审查。Phabricator 在一定程度上以类似于 GitHub “PR” 的方式，促进对拟议变更的详细审查和讨论。Phabricator 为非 committers 提供了一个更为便捷的渠道，使其能够向 FreeBSD 提出变更建议，因为他们可以创建自己的 Phabricator 账号，发布其推荐的修改内容，并由 Phabricator 自动建议审查者，或以其他方式通知相应的 FreeBSD 开发者某项变更需要审查。
FreeBSD 源代码控制
当 FreeBSD 项目刚开始时，创始人选择使用 CVS 源代码控制系统。随着 2000 年Subversion 等较新的源代码管理工具的发布，迁移到更现代工具的压力开始增加。随着 Git 和 Mercurial 等新一波工具的出现，这种压力进一步加大。这些工具的分支模型和提交原子性都极具吸引力，而且它们在整体使用上通常也比 CVS 更容易。最终，在经过大量讨论、测试转换和验证之后，项目迁移到了 Subversion，其理由是它在操作方式上与 CVS 系统相当接近，并且在需要时，Git 和 Mercurial 都可以构建在其之上运行。
尽管已经转换到 Subversion，关于迁移到更新工具的讨论仍在持续。许多 FreeBSD 开发者正在积极使用 Git，而随着 GitHub 及其 pull request 模型的出现，也不断有人讨论 FreeBSD 是否应该采用 GitHub 或类似的平台。FreeBSD 项目在 GitHub 上存在，但它完全是只读的。在 GitHub 上打开的 pull requests 和 issues 只能在被转移到 Phabricator 或 Bugzilla 之后，才能提交到 Subversion 中。
FreeBSD 工作流
随着项目的发展，需要更加正式的结构来确保工作流程顺畅，同时又不打击创新。外部开发者会为 FreeBSD 提供 Bug 修复和更新。他们通过邮件列表或查阅源代码控制日志，确定一位合适的 committer，与其合作将修改内容合并进 FreeBSD。另一种方式是创建 Phabricator 账号，提出一个 issue，并由 Phabricator 基础设施识别合适的 committer 或工作组来进行协作。
Committers（目前共有 371 人）被授权向系统的特定部分提交修改。这些系统部分被划分为三个主要的 committer 组：documentation、Ports 和 source。许多 committers 同时属于多个组。Committers 通常只在其所属组中的一个自我界定的子范围内开展工作。所有修改（除琐碎修改外）都需要至少一名其他 committer 的审查。
在历史上，committers 可以直接进行他们认为合适的任何修改。这一策略曾导致基础设施受损，尤其是在对更为核心的系统（例如虚拟内存子系统）进行修改时。为了解决这些问题，开发者被鼓励在提交之前为其修改寻求审查。随后，这些做法被制度化，要求在提交日志消息中添加标签，以表明：
哪位其他项目成员审查了这些修改；
赞助机构（例如该项目成员的雇主）；
该修改所对应的缺陷报告编号；
讨论该修改的 Phabricator 线程；
何时发送提醒以将该修改合并到较旧的 stable / release 分支；
如适用，确认该提交修复了该 committer 之前所犯的错误（“Pointy Hat” 标签）。
共同工作与协作指南
尽管 FreeBSD 项目长期以来一直有一套关于成员应如何彼此互动的指南，但在这些指南被违反时，并没有明确必须遵循的规则和流程。规则和流程是在一些开发者分歧和不当行为出现后才被补充制定的，并明确了具体的行为期望。这些最初的规则主要围绕 CVS 内部的交互而制定。
这些最初的规则在行为期望的清晰度上，远未达到更现代的 “Code of Conduct（冲突守则）” 所包含的程度。不过，它们确实给出了在违反规则时，核心团队可以施加的制裁类型示例。这套初始规则一直足以应对需要，直到 2015 年出现了一些严重的项目成员不当行为事件，其影响扩散到了项目本身之外。该事件促使人们着手以现代 “Code of Conduct” 以及一整套配套流程来补充原有规则，以便在未来应对此类问题。
FreeBSD 招募
与所有成功的开源项目一样，开发者可能会失去兴趣，或因时间不足而离开项目。为避免出现冗余人员，必须有衡量开发者是否已经离开的指标。FreeBSD 项目采用的标准是：如果某人一年内未进行任何 commit，则取消其 commit 权限。
为了保持项目的生命力，必须不断招募新的开发者并将其引入项目。新贡献者接触项目的方式有多种。一种是偶然发现该项目并直接参与其中；另一种是通过大学或学院课程接触到项目；第三种是就职于在其产品或服务中使用 FreeBSD 的公司。FreeBSD 还参与谷歌编程之夏，并通过该项目获得了大量贡献。
为了营造一个友好且易于进入的社区，项目需要保持可见性，并为新开发者提供导师，帮助他们学习项目所采用的政策和流程。与活跃开发者合作的 committers 可以提名他们成为新的 committer。是否接纳新 committer 由核心团队负责决定。为简化过渡过程，并确保新 committer 理解项目的文化、流程和规则，他们会被分配一名导师（通常是提名他们的人），由其审查其修改，并确保这些修改获得适当的外部审查。只要他们熟悉并适应相关工作，通常在 6 至 12 个月后，导师会认定其已具备独立工作的能力。
FreeBSD 开发模式
该项目在识别需要变革的领域方面一直做得相当不错。当变更规模较小，且 / 或仅局限于项目中的某个小范围时，这些新领域的架构设计和开发过程通常进展顺利。然而，规模较大或影响深远的变更则一直较为困难。其中两个例子尤为突出：从单线程内核向多线程内核的转变，以及从 CVS 迁移到 Subversion。
最早在 1999 年就有人提出应当逐步放弃 CVS。有人建议项目迁移到当时仍处于 public beta 阶段的 BitKeeper。该建议最终未能落实，但这一提议以及随后围绕其他工具展开的讨论，都符合一种反复出现的模式：有人提出迁移到某个工具，其他人提出反对意见，或建议迁移到不同的工具；还有人会明确支持或反对前述一个或多个建议；最终，讨论在没有形成任何实质性结论的情况下逐渐消失。 2008 年，Peter Wemm 作为集群管理团队成员以及 CVS 仓库管理者之一，通过一种非常直接的方式打破了僵局：他干脆选择了 Subversion，亲自完成并验证了所有迁移所需的工作，并将其付诸实施。选择 Subversion 的原因在于，它在语义上与 CVS 高度契合，成熟度相对较高，并且另外两个最常被提及的竞争者——Git 和 Mercurial——都能够与 Subversion 互操作。
将内核从单线程迁移到多线程同样是一项规模巨大的工作，但在这一案例中，问题更多源于个人性格冲突以及对架构选择的分歧。 2000 年，Berkeley Software Design Inc.（BSDi）收购了 Walnut Creek CDROM。这次收购使原本受雇于 Walnut Creek 的开发者得以访问 BSD/OS 的源代码，后者是 BSDi 的一款商业 BSD 衍生系统。其中一位开发者 John Baldwin 借鉴了 BSD/OS 和 Solaris 的思想，为多线程 FreeBSD 内核设计了一套架构。另一位开发者 Matthew Dillon 则偏好一种不同的架构，其思路更接近 Amiga 内核所采用的方法。两人在多线程项目应当如何推进的问题上产生了严重冲突。由于核心团队不愿在技术争论中主动选边站队，上述冲突被进一步激化。最终，出于其他原因，Matthew 的 commit 权限被撤销，他离开了 FreeBSD 项目，创立了 DragonFlyBSD 项目。
为了尽量避免类似上述两种情况，核心团队引入了“FreeBSD Community Process”（FreeBSD 社区流程），作为一种更加制度化的机制，用于在项目内部提出并裁决重要或存在争议的变更。其核心理念在于，避免讨论在邮件列表上退化为无休止的争论，而最终却没有任何实际行动。
FreeBSD Community Process 借鉴了其他项目中的类似理念，尤其是 Python Enhancement Process（https://www.python.org/dev/peps/pep-0001/）、Joyent RFD Process（https://github.com/joyent/rfd/blob/master/README.md IETF RFC Process（https://www.ietf.org/about/standards-process.html）
凡是希望进行一项会对 FreeBSD 用户群体产生非琐碎影响的变更的 committer，或者事后来看，任何在遇到争议后不得不回退某项原本被认为并不复杂的变更的人，都需要将其拟议的变更内容写成文档。该提案需要描述其试图解决的问题，概述拟采用的解决方案，并指出该提案可能带来的任何后续影响。在经过 FreeBSD Community Process 编辑的审阅之后，该文档会被加入 FreeBSD Community Process 索引，提交到 FreeBSD Community Process 仓库，并发布以供讨论。每一份 FreeBSD Community Process 提案都是一份“活文档”，可以根据讨论过程中形成的结论不断更新。
只要达成共识，或者讨论已经持续了足够长的时间，核心团队将就是否接受该提案进行投票。核心团队被期望根据围绕该提案的讨论整体氛围来作出投票决定。
FreeBSD 核心团队与 FreeBSD Committers 的互动
从历史上看，核心团队的议程是私密的，核心团队内部的所有交流——无论是通过电子邮件、IRC，还是每月的视频会议——都保持不公开。核心团队向 committers 传达其活动情况的方式，仅限于由核心团队秘书编写的一份月度报告，内容是 core 已经采取的行动。核心团队秘书并非核心团队成员，但负责管理核心团队的议程，并处理与核心团队相关的许多沟通事务。该报告仅包含对核心团队已采取行动的简要总结，只讨论已经发生的事项。由于这份月度报告具有明显的事后回顾性质，committers 几乎没有机会参与核心团队的审议过程。
在 committers 多年不断推动之后，核心团队近来开始努力提高透明度，并为 committers 提供更多参与核心团队审议的机会。核心团队已开始在会议召开之前向开发者提供其议程。核心团队还在研究允许 committers 参加其视频会议的可能性。允许参与视频会议将需要明确区分哪些议程事项仅适合核心团队内部审议，并可能需要谨慎处理，例如开发者之间的争议。
FreeBSD 安全团队
安全官这一角色在多年中不断演变。最初，它只是一个头衔，用于指派某个人负责项目中与安全相关的问题。 2002 年，通过了一份正式章程（https://www.freebsd.org/security/charter.html），其中也明确承认，相关工作量并非一人所能承担，因此设立了一个向 安全官汇报的安全团队。近几年，人们也逐渐意识到，要找到一位同时具备相应背景并且有足够时间担任安全官的人并非易事。针对这一职责范围的扩展，核心团队重新定义核心团队的角色，使其更偏向管理职能，而核心团队则作为一个人员池，根据需要承担具体工作，用于应对安全问题、起草安全通告，并确保补丁被合入所有相关分支。
总结
同许多开源项目一样，FreeBSD 最初采用的是 Benevolent Dictator(s) For Life（终身仁慈独裁者）的治理模式。虽然这种方式在一定时期内可能有效，但往往会导致停滞，以及负责人逐渐老化、精疲力竭。基于这些原因，FreeBSD 先是转向核心团队，随后又发展为经选举产生的核心团队。
在其 24 年的历史中，FreeBSD 项目经历了四次重大的领导层变更，每次都产生了积极效果，使项目得以向前推进并应对新的问题。这也帮助项目避免了“老化”；committers 的年龄中位数始终保持在 30 多岁中后段。这个年龄段既足够年轻，拥有推动项目向前发展的时间和精力，又足够成熟，具备避免钻入死胡同所需的智慧，并且有耐心和经验，通过把事情一次性做对来避免技术债务，而不是满足于权宜之计。
FreeBSD 基金会的成立同样在确保 FreeBSD 项目拥有所需资源、取得成功方面发挥了重要作用。尤其重要的是，FreeBSD 基金会明确认识到其在 FreeBSD 生态系统中的角色：由核心团队和 committers 决定 FreeBSD 项目的技术方向，而基金会则通过基础设施、市场推广和对外联络来提供支持。
治理看似平凡，却对开源项目的成功至关重要。治理过多，项目会变得僵化；治理不足，项目则可能因“成功灾难”而失控，或因缺乏足够的结构而陷入停滞。迄今为止，FreeBSD 项目在治理方面做对了，但要让这一体系持续高效运转，仍然需要不断地调校。
MARSHALL KIRK McKUSICK 博士撰写书籍和文章，教授与 UNIX 和 BSD 相关的课程，并在软件专利、商业机密以及版权问题上提供专家证人证词，尤其侧重于与操作系统和文件系统相关的议题。自 1993 年FreeBSD 项目创立以来，他一直是该项目的开发者和 committer。在加利福尼亚大学伯克利分校任职期间，他实现了 4.2BSD fast filesystem，并担任 Berkeley Computer Systems Research Group（CSRG）的 Research Computer Scientist，负责监督 4.3BSD 和 4.4BSD 的开发与发布。
BENNO RICE 是 Dell EMC Isilon 部门的软件工程师，同时也是 FreeBSD 的 committer 以及核心团队成员。
最后更新于
这有帮助吗？