FreeBSD 项目的项目模型

“活动”是在项目过程中执行的工作元素 [PMI]。它有一个输出并通向一个结果。这样的输出可以是另一个活动的输入，也可以是流程交付的一部分。

“流程”是一系列通向特定结果的活动。一个流程可以包含一个或多个子流程。软件设计就是一个流程的例子。

“角色”与角色同义。角色在流程中以及流程结果中承担一定的责任。角色执行活动。对于项目成员和项目外部人员应该联系角色解决哪些问题，都有明确的定义。

“结果”是流程的最终输出。这与可交付成果同义，[PMI] 将可交付成果定义为“必须产生的任何可衡量、有形、可验证的成果、结果或项目或项目部分的完成项目。通常更狭义地用于指外部可交付成果，即项目发起人或客户需要批准的可交付成果”。软件、做出的决定或编写的报告都是结果的例子。

当说“FreeBSD”时，我们将指的是 BSD 派生的类 UNIX 操作系统 FreeBSD，而当说“FreeBSD 项目”时，我们将指的是项目组织。

FreeBSD 没有定义人们编写代码的方式模型。但是，Niels Jørgenssen 提出了一种关于如何将编写的代码集成到项目中的模型。

Jørgenssen 的变更集成模型

“开发版本”是 FreeBSD-CURRENT（“-CURRENT”）分支，“生产版本”是 FreeBSD-STABLE 分支（“-STABLE”）[Jørgensen]。

这是一个针对单个变更的模型，它展示了在编码之后，开发者会寻求社区审查并尝试将其与自己的系统集成。在将变更集成到称为 FreeBSD-CURRENT 的开发版本之后，FreeBSD 社区的许多用户和开发者都会对其进行测试。经过充分测试后，它会被合并到称为 FreeBSD-STABLE 的生产版本中。除非每个阶段都成功完成，否则开发者需要返回并修改代码，然后重新开始该过程。将变更与 -CURRENT 或 -STABLE 集成称为提交。

Jørgensen 发现大多数 FreeBSD 开发者都是独立工作的，这意味着许多开发者在不同的持续开发工作中并行使用此模型。开发者还可以处理多个变更，因此，当他们等待审查或其他人测试其一个或多个变更时，他们可能会编写另一个变更。

由于每次提交都表示一个增量，因此这是一个大规模增量模型。事实上，提交非常频繁，一年内^[3]进行了 85427 次提交，平均每天 233 次提交。

在 Jørgenssen 模型中的“代码”括号内，每个程序员都有自己的工作风格并遵循自己的开发模型。该括号很可能被称为“开发”，因为它包括需求收集和分析、系统和详细设计、实现和验证。但是，这些阶段的唯一输出是源代码或系统文档。

从逐步模型（例如瀑布模型）的角度来看，其他括号可以被视为进一步的验证和系统集成。这种系统集成对于查看社区是否接受变更也很重要。在代码提交之前，开发者可以自由选择与项目其余部分沟通的程度。为了使 -CURRENT 作为缓冲区（以便可以回滚一些具有未发现缺点的优秀想法），提交合并到 -STABLE 之前在 -CURRENT 中的最短时间为 3 天。此类合并称为 MFC（从当前合并）。

需要注意“变更”一词。大多数提交不包含根本性的新功能，而是维护更新。

此模型的唯一例外是安全修复和对 -CURRENT 分支中已弃用的功能的更改。在这些情况下，更改可以直接提交到 -STABLE 分支。

除了许多参与项目的人员外，FreeBSD 项目还有许多相关的项目。这些项目要么是开发全新功能的项目，要么是子项目，要么是其成果被纳入 FreeBSD 的项目^[4]。这些项目与常规开发工作一样适合 FreeBSD 项目：它们生成的代码与 FreeBSD 项目集成。但是，其中一些项目（如 Ports 和 Documentation）有权同时应用于两个分支或直接提交到 -CURRENT 和 -STABLE。

设计没有标准，也没有将设计收集到集中式存储库中。主要设计是 4.4BSD 的设计。^[5]由于设计是 Jørgenssen 模型中“代码”括号的一部分，因此每个开发者或子项目都可以决定如何进行设计。即使设计应该存储在集中式存储库中，设计阶段的输出也作用有限，因为方法论的差异会导致它们难以或根本无法互操作。对于项目的整体设计，项目依赖于子项目协商彼此合适的接口，而不是规定接口。

FreeBSD 的发布最好用一棵树来表示，其中每个主分支表示一个主要版本。次要版本由主分支的分支表示。

在以下发布树中，沿着特定方向依次出现的箭头表示分支。带有实线和菱形的框表示正式发布。带有虚线的框表示当时的开发分支。安全分支由椭圆形表示。菱形与框的不同之处在于它们表示一个分叉点，即一个分支分成两个分支的地方，其中一个分支成为子分支。例如，在 4.0-RELEASE 时，4.0-CURRENT 分支分为 4-STABLE 和 5.0-CURRENT。在 4.5-RELEASE 时，该分支分叉出一个名为 RELENG_4_5 的安全分支。

最新的 -CURRENT 版本始终称为 -CURRENT，而最新的 -STABLE 版本始终称为 -STABLE。在此图中，-STABLE 指的是 4-STABLE，而 -CURRENT 指的是 5.0-RELEASE 之后的 5.0-CURRENT。[FreeBSD]

“主要版本”始终从 -CURRENT 分支创建。但是，-CURRENT 分支不需要在那个时间点分叉，而是可以专注于稳定化。例如，在 3.0-RELEASE 之后，3.1-RELEASE 也是 -CURRENT 分支的延续，并且 -CURRENT 直到此版本发布并且 3-STABLE 分支分叉后才成为真正的开发分支。当 -CURRENT 恢复为开发分支时，只能随后发布主要版本。预计 5-STABLE 将在 5.3-RELEASE 左右从 5.0-CURRENT 分叉。直到 5-STABLE 分叉后，开发分支才会被命名为 6.0-CURRENT。

“次要版本”是从 -CURRENT 分支（在主要版本之后）或 -STABLE 分支创建的。

从 4.3-RELEASE^[6] 及其之后开始，当发布次要版本时，它会成为“安全分支”。这对于不想跟随 -STABLE 分支及其可能提供的新的/更改的功能，而是需要绝对稳定的环境（仅更新以实施安全更新）的组织很有用。^[7]

对安全分支的每次更新都称为“补丁级别”。对于完成的每个安全增强，补丁级别编号都会增加，这使得跟踪该分支的人员可以轻松查看他们已实施了哪些安全增强。在存在特别严重的安全漏洞的情况下，可以从安全分支创建全新的版本。例如，4.6.2-RELEASE 就是这种情况。

总而言之，FreeBSD 的开发模型可以看作以下树

FreeBSD 开发树，包含持续的开发工作和持续集成。

该树象征着发布版本，主要版本产生新的主分支，次要版本是主分支的版本。最上面的分支是 -CURRENT 分支，所有新开发都集成在此分支中，-STABLE 分支位于其正下方。在 -STABLE 分支下方是旧的、不受支持的版本。

开发工作云覆盖在项目之上，开发者使用他们认为合适的开发模型。然后，他们工作的结果会集成到 -CURRENT 中，在那里进行并行调试，最后从 -CURRENT 合并到 -STABLE。安全修复从 -STABLE 合并到安全分支。

许多提交者都有特定的责任领域。这些角色称为“帽子”。这些“帽子”可以是项目角色，例如公关官，也可以是代码特定领域的维护者。因为这是一个人们自愿利用业余时间参与的项目，所以拥有指定“帽子”的人并不总是可用。因此，他们必须任命一名代理，在他们不在时执行该“帽子”的角色。另一种选择是让一个小组担任该角色。

许多这些角色并没有正式化。正式化的角色会有一个章程，其中规定了该角色的确切目的以及相应的权限和责任。编写此类章程是项目的新部分，因此尚未为所有角色完成。这些角色描述并非正式化，而是对角色的总结，并在可用情况下提供指向章程的链接和联系地址。

FreeBSD 项目中的官方角色是或多或少正式化且主要为管理角色的角色。他们对其领域拥有权力和责任。以下列表显示了责任线，并对每个角色进行了描述，包括由谁担任。

核心团队有责任向贡献者授予和撤销提交权限。这只能通过核心邮件列表上的投票来完成。Ports 和 Documentation 子项目可以向在这些项目上工作的人员授予提交权限，但迄今尚未撤销此类权限。

通常，贡献者会由提交者推荐给核心团队。贡献者或外部人员联系核心团队要求成为提交者不被看好，通常会被拒绝。

如果开发人员感兴趣的特定领域可能与其他提交者的维护领域重叠，则需要征求这些维护者的意见。但是，通常是这位提交者推荐开发人员。

当贡献者获得提交者身份时，会分配给他一位导师。通常情况下，推荐新提交者的提交者会主动担任新提交者的导师。

当贡献者获得其提交权限时，会从Pretty Good Privacy签名的电子邮件发送到核心秘书、端口管理器或nik@freebsd.org，发送给admins@freebsd.org、指定的导师、新的提交者和核心，确认新账户的批准。然后，导师会从新提交者那里收集密码行、安全外壳公钥和PGP密钥，并将其发送给管理员。创建新账户后，导师会激活提交权限，并指导新提交者完成其余的初始流程。

当贡献者提交一段代码时，接收代码的提交者可以选择推荐授予贡献者提交权限。如果他们向核心推荐，核心将对此推荐进行投票。如果投票赞成，则会为新的提交者分配一位导师，并且新的提交者必须将其详细信息发送给管理员以创建账户。之后，新的提交者就可以准备进行他们的第一次提交。按照传统，这是通过将他们的姓名添加到提交者列表中来实现的。

请记住，提交者被认为是在过去 12 个月内提交过代码的人。但是，只有在 18 个月的非活动期过后，提交权限才有资格被撤销。

但是，没有自动执行此操作的程序。有关未由时间触发的提交权限的反应，请参阅第 1.5.8 节。

当核心决定清理提交者列表时，他们会检查过去 18 个月内谁没有进行提交。管理员会撤销未提交代码的提交者的提交权限并删除其账户。

提交者也可以请求退休其提交权限，如果由于某种原因他们不再积极地向项目提交代码。在这种情况下，如果提交者要求，核心也可以在稍后恢复提交权限。

此流程中的角色

提交新的或修改的代码是 FreeBSD 项目中最频繁的流程之一，通常每天会发生很多次。只有“提交者”才能提交代码。提交者提交自己编写的代码、提交给他们的代码或通过问题报告提交的代码。

当开发人员编写的代码是非平凡的时，他们应该寻求社区的代码审查。这是通过向相关列表发送邮件请求审查来完成的。在提交代码以供审查之前，他们应确保它能够与整个树正确编译，并且所有相关测试都能运行。这称为“提交前测试”。收到贡献的代码后，应由提交者审查并以相同的方式进行测试。

当对从外部供应商贡献的源代码的一部分进行更改时，维护者应确保将补丁贡献回供应商。这符合开源理念，并使与外部项目的同步变得更容易，因为每次发布新版本时都不必重新应用补丁。

在代码可供审查并且不再需要进一步更改后，代码将提交到开发分支 -CURRENT。如果更改也适用于 -STABLE 分支或其他分支，则提交者会设置“从 Current 合并”（“MFC”）倒计时。在提交者设置 MFC 时选择的几天过去后，系统会自动向提交者发送一封电子邮件，提醒他们将其提交到 -STABLE 分支（以及可能的安全分支）。只有安全关键的更改应合并到安全分支中。

延迟提交到 -STABLE 和其他分支允许进行“并行调试”，其中提交的代码在各种配置上进行测试。这使得对 -STABLE 的更改包含更少的错误，从而使分支名称名副其实。

当提交者编写了一段代码并想要提交它时，他们首先需要确定它是否足够简单，无需事先审查即可提交，或者是否应该首先由开发人员社区审查。如果代码很简单或已过审查，并且提交者不是维护者，则应在继续之前咨询维护者。如果代码由外部供应商贡献，则维护者应创建要发送回供应商的补丁。然后提交代码，然后由用户部署。如果他们发现代码存在问题，将报告该问题，提交者可以重新开始编写补丁。如果供应商受到影响，他们可以选择实施或忽略补丁。

贡献者进行代码贡献时的区别在于，他们通过 Bugzilla 界面提交代码。维护者会获取此报告，审查代码并提交。

此流程中包含的角色有

核心选举至少每两年举行一次。^[8] 会选举出九名核心成员。如果核心成员人数降至七名以下，则会举行新的选举。如果至少 1/3 的活跃提交者要求，也可以举行新的选举。

如果要举行选举，核心将至少提前 6 周宣布此事，并指定一名选举经理来负责选举。

只有提交者才能被选入核心。候选人需要在选举开始前至少一周提交其候选资格，但可以在投票开始前完善其陈述。他们在候选人名单中列出。在撰写选举声明时，候选人必须回答选举经理提交的一些标准问题。

在选举期间，严格遵守提交者必须在过去 12 个月内提交过代码的规则。只有这些提交者才有资格投票。

投票时，提交者可以对最多九名候选人投票支持一次。投票将在四周内进行，并会在“开发者”邮件列表上发布提醒，所有提交者都可以访问该列表。

选举结果将在选举结束一周后公布，新核心团队将在结果公布一周后上任。

如果出现投票平局，将由新当选的核心成员解决。

投票和候选人声明会被存档，但档案不公开。

核心宣布选举并选择一位选举经理来准备选举，准备就绪后，候选人可以通过提交其声明来宣布其候选资格。然后提交者投票。投票结束后，宣布选举结果，新核心团队上任。

核心选举中的角色有

项目中有一些子项目正在开发新功能。这些项目通常由一个人完成 [Jørgensen]。每个项目都可以自由地组织其认为合适的开发方式。但是，当项目合并到 -CURRENT 分支时，必须遵循项目指南。当代码在 -CURRENT 分支中经过充分测试并被认为足够稳定且与 -STABLE 分支相关时，它将合并到 -STABLE 分支。

项目的需求由开发人员的愿望、社区通过邮件、问题报告、商业资助开发功能或科学界贡献的直接请求给出。属于开发人员责任范围内的愿望会交给该开发人员，他们会在请求和自己的愿望之间安排时间优先级。一种常见的方法是维护由项目维护的 TODO 列表。不属于某人责任范围内的项目会被收集到 TODO 列表中，除非有人自愿承担责任。所有请求、其分配和后续操作都由Bugzilla工具处理。

需求分析以两种方式进行。收到的请求会在邮件列表中进行讨论，包括主要项目和请求所属或由请求产生的子项目。此外，子项目的开发人员将评估请求的可行性，并确定它们之间的优先级。除了已进行的讨论的档案外，此阶段不会创建任何合并到主要项目中的结果。

由于开发人员根据他们认为有趣、必要或获得资助来做的事情来确定请求的优先级，因此没有关于将哪些请求视为需求以及后续正确实施的整体策略或优先级。但是，大多数开发人员对哪些问题更重要有一些共同的愿景，他们可以向发布工程团队寻求指导。

项目的验证阶段分为两个方面。在将代码提交到当前分支之前，开发人员会请求同行审查他们的代码。此审查在很大程度上是通过功能测试完成的，但代码审查也很重要。当代码提交到分支时，会进行更广泛的功能测试，如果代码行为不符合预期，则可能会触发进一步的代码审查和调试。这种第二次验证形式可以被认为是结构验证。尽管子项目本身可能会编写正式的测试（例如单元测试），但这些测试通常不会被主项目收集，并且通常在代码提交到当前分支之前会被移除。^[9]

对于每个源代码区域至少有一人对其非常了解，这对项目来说是一个优势。某些代码部分有指定的维护人员。其他部分有事实上的维护人员，而某些系统部分则没有维护人员。维护人员通常是编写和集成代码的子项目成员，或者是从其编写平台移植代码的人。^[10]维护人员的工作是确保代码与代码来源项目保持同步（如果它是贡献的代码），并应用社区提交的补丁或修复发现的问题。

投入 FreeBSD 项目的大部分工作都是维护。[Jørgensen] 创建了一个图表，展示了更改的生命周期。

Jørgenssen 的变更集成模型

此处，“开发版本”指的是 -CURRENT 分支，而“生产版本”指的是 -STABLE 分支。“提交前测试”是指同行开发人员在被要求时进行的功能测试，或尝试运行代码以确定子项目的状态。“并行调试”是指在代码包含在 -CURRENT 分支中时可能触发更多审查和调试的功能测试。

在撰写本文时，项目中有 269 名提交者。当他们将更改提交到分支时，就构成了一个新版本。社区中的用户跟踪特定分支非常普遍。新版本的即时存在使更改立即广泛可用，并允许社区快速反馈。这也为社区提供了他们期望的响应时间，以解决对他们来说重要的问题。这使得社区更加投入，从而允许更多更好的反馈，这些反馈反过来又会激发更多的维护，并最终应该创造出更好的产品。

在更改树中历史记录对提交者未知的部分的代码之前，提交者需要阅读提交日志以了解某些功能为何以这种方式实现，以避免犯以前已经考虑过或解决过的错误。

在 FreeBSD 10 之前，FreeBSD 包含一个名为 send-pr 的问题报告工具。问题包括错误报告、功能请求、功能增强以及项目中包含的外部软件的新版本通知。尽管 send-pr 可用，但鼓励用户和开发人员使用我们的 问题报告表单 提交问题。

问题报告发送到电子邮件地址，然后将其插入问题报告维护数据库。一个 Bugbuster 会对问题进行分类，并将其发送到项目中的正确组或维护人员。在有人承担报告责任后，将对报告进行分析。此分析包括验证问题并为问题想出解决方案。通常需要来自报告发起人甚至 FreeBSD 社区的反馈。一旦针对问题创建了补丁，可能会要求发起人尝试一下。最后，将有效的补丁集成到项目中，并在适用时进行记录。然后它将按照维护部分中所述的常规维护周期进行。问题报告可以处于以下状态：打开、已分析、反馈、已修补、挂起和关闭。挂起状态用于当由于信息不足而无法取得进一步进展，或者当任务需要大量工作而目前没有人处理时。

问题由报告发起人报告。然后由 Bugbuster 进行分类并交由正确的维护人员处理。他们会验证问题并与发起人讨论问题，直到他们拥有足够的信息来创建有效的补丁。然后提交此补丁，并关闭问题报告。

此流程中包含的角色是

[FreeBSD].

[FreeBSD] 有许多提交者应该遵循的规则。但是，这些规则有时会被违反。以下规则的存在是为了能够应对错误行为。它们规定了哪些操作会导致提交者提交权限被暂停多长时间。

为了使暂停有效，任何核心成员都可以在“核心”邮件列表上进行讨论之前实施暂停。对于屡犯者，核心成员可以通过 2/3 的投票获得更严厉的处罚，包括永久撤销提交权限。（但是，后者始终被视为最后的手段，因为它本质上容易引发争议。）所有暂停都会发布到“开发人员”邮件列表，这是一个仅供提交者使用的列表。

重要的是，您不能因犯技术错误而被暂停。所有处罚都源于违反社交礼仪。

参与此流程的角色

FreeBSD 项目有一个发布工程团队，其中包括一位首席发布工程师，负责创建 FreeBSD 版本，以便通过网络发布给用户社区或在零售店出售。由于 FreeBSD 在多个平台上可用，并且针对不同架构的版本同时发布，因此团队中每种架构都有一位负责人。此外，团队中还有一些角色负责协调质量保证工作、构建软件包集以及维护更新的文档集。当提到发布工程师时，指的是发布工程团队的代表。

当版本即将发布时，FreeBSD 项目的形态会发生一些变化。将制定一个发布计划，其中包含功能和代码冻结、中间版本的发布以及最终版本。功能冻结表示不允许将任何新功能提交到分支，除非发布工程师明确同意。代码冻结表示不允许对代码（如错误修复）进行任何更改，除非发布工程师明确同意。这种功能和代码冻结被称为稳定化。在发布过程中，发布工程师拥有完全的权限来恢复到旧版本的代码，从而“撤消”更改，如果他们发现这些更改不适合包含在版本中。

有三种不同类型的版本

对于 -STABLE 分支的版本，发布流程在预期发布日期前 45 天开始。在第一个阶段（前 15 天），开发人员将他们在 -CURRENT 中拥有的想要包含在版本中的更改合并到发布分支。当此阶段结束后，代码进入为期 15 天的代码冻结期，在此期间仅允许错误修复、文档更新、安全相关修复和次要设备驱动程序更改。这些更改必须事先获得发布工程师的批准。在最后 15 天期限开始时，将创建一个发布候选版本以进行广泛测试。在此期间，更新不太可能被允许，除非是重要的错误修复和安全更新。在此最终阶段，所有版本都被视为发布候选版本。在发布流程结束时，将创建一个具有新版本号的版本，包括网站上的二进制发行版和 CD-ROM 映像的创建。但是，在发送到 freebsd-announce 邮件列表的明确说明这一点的 Pretty Good Privacy 签名消息之前，该版本不被视为“真正发布”；在此之前标记为“发布”的任何内容都可能正在处理中，并且在发送 PGP 签名消息之前可能会发生更改。^[11]。

-CURRENT 分支的版本（即所有以“.0”结尾的版本）非常相似，但时间范围是前者的两倍。它在发布前 8 周开始，并宣布发布时间表。在发布流程开始的两周内，将启动功能冻结，并且应将性能调整保持在最低限度。在发布前四周，将提供正式的测试版。在发布前两周，代码将正式分支到新版本。此版本被赋予发布候选版本状态，并且与 -STABLE 的发布工程一样，发布候选版本的代码冻结得到了加强。但是，主要开发分支上的开发可以继续。除了这些差异之外，发布工程流程是相同的。

*.0 版本进入自己的分支，主要面向早期采用者。然后，该分支会经历一段稳定化时期，直到 发布工程团队 确定满足了对稳定性的要求后，该分支才会成为 -STABLE，而 -CURRENT 则针对下一个主要版本。虽然对于大多数情况下都是使用 *.1 版本，但这并不是强制要求。

大多数版本是在自上次版本发布以来被认为足够长的时间的特定日期发布的。目标是每 18 个月发布一次主要版本，每 4 个月发布一次次要版本。用户社区已明确表示，不能为了自我强加的截止日期和目标发布日期而牺牲安全性和稳定性。为了防止时间上的偏差在安全性和稳定性问题方面变得过长，在将更改提交到 -STABLE 时需要额外的纪律。

[ FreeBSD ]

Git 是一个用于处理文本文件多个版本并跟踪谁提交了哪些更改以及原因的系统。一个项目存在于一个“仓库”中，不同的版本被认为是不同的“分支”。

Bugzilla 是一个维护数据库，包含一组用于在中央站点跟踪错误的工具。它支持错误跟踪流程，用于发送和处理错误，以及查询和更新数据库以及编辑错误报告。该项目使用其 Web 界面将“问题报告”发送到项目的中央 Bugzilla 服务器。提交者也拥有 Web 和命令行客户端。

Mailman 是一个自动管理邮件列表的程序。FreeBSD 项目使用它来运行 16 个通用列表、60 个技术列表、4 个受限列表和 5 个带有 Git 提交日志的列表。它也用于 FreeBSD 社区中其他人和项目设置和使用的许多邮件列表。通用列表是供公众使用的列表，技术列表主要用于特定兴趣领域的开发，封闭列表用于内部通信，不供公众使用。项目中的大部分通信都通过这 85 个列表进行 [FreeBSD，附录 C]。

Pretty Good Privacy，更广为人知的是 PGP，是一种使用公钥架构的密码系统，允许人们对信息进行数字签名和/或加密，以确保双方之间的安全通信。当向许多收件人发送信息时，会使用签名，使他们能够在收到信息之前验证信息是否未被篡改。在 FreeBSD 项目中，这是确保信息是由声称撰写该信息的人员撰写，并且在传输过程中未被更改的主要方法。

Secure Shell 是一种安全登录远程系统并在远程系统上执行命令的标准。它允许在两个相关系统之间建立和保护其他连接（称为隧道）。此标准存在两个主要版本，FreeBSD 项目仅使用版本二。该标准最常见的实现是 OpenSSH，它是项目主发行版的一部分。由于其源代码更新频率高于 FreeBSD 版本，因此最新版本也存在于 ports 树中。

“端口”是一组元数据和补丁，这些元数据和补丁是在 FreeBSD 系统上正确获取、编译和安装外部软件片段所需的。正如以下图表所示，端口的数量呈惊人的增长速度。

image::portsstatus.svg

image::portsstatus.svg 显示了 1995 年至 2022 年期间 FreeBSD 可用的端口数量。曲线看起来先是呈指数增长，然后从 2001 年中旬到 2007 年中旬以每年约 2000 个端口的速度线性增长，之后增长速度开始下降。

由于端口描述的外部软件通常处于持续开发中，因此维护端口所需的工作量已经很大，并且还在增加。这导致 FreeBSD 项目的 ports 部分获得了更强大的结构，并且越来越成为 FreeBSD 项目的一个子项目。

Ports 拥有自己的核心团队，由 Ports 管理员 领导，并且该团队可以在未经 FreeBSD 核心批准的情况下任命提交者。与 FreeBSD 项目不同，在 FreeBSD 项目中，许多维护工作经常会被授予提交权限，而 ports 子项目包含许多并非提交者的活跃维护者。

与主项目不同，ports 树不会分支。FreeBSD 的每个版本都遵循当前的 ports 集合，因此可以获取有关在哪里查找程序以及如何构建程序的更新信息。但是，这意味着依赖于系统的端口可能需要根据其运行的 FreeBSD 版本进行不同的处理。

使用未分支的 ports 存储库，无法保证任何端口可以在 -CURRENT 和 -STABLE 之外的任何版本上运行，尤其是旧的次要版本。既没有保证此功能的基础设施，也没有足够的志愿者时间来保证此功能。

为了提高沟通效率，依赖 Ports 的团队（例如发布工程团队）有自己的 Ports 联络员。

FreeBSD 文档项目始于 1995 年 1 月。从最初的项目领导、四位团队领导和 16 名成员开始，现在共有 44 位提交者。文档邮件列表的成员略低于 300 人，这表明围绕它存在一个相当庞大的社区。

文档项目的目的是提供 FreeBSD 项目的良好且有用的文档，从而使新用户更容易熟悉该系统，并为用户详细介绍高级功能。

文档项目的主要任务是在“FreeBSD 文档集”中处理当前项目，并将文档翻译成其他语言。

与 FreeBSD 项目一样，文档也拆分到相同的分支中。这样做是为了确保每个版本都有一个更新版本的文档。仅在安全分支中更正文档错误。

与 ports 子项目一样，文档项目可以在未经 FreeBSD 核心批准的情况下任命文档提交者。[FreeBSD]。

文档项目有一个 入门指南。它既用于向新项目成员介绍标准工具和语法，也用于在处理项目时作为参考。