开源项目发布前须知

您的公司即将发布一个内部项目作为开源项目。恭喜！您知道您的代码已准备就绪，但您是否已准备好承担所有新的责任？

一旦项目以开源形式发布，您的公司不仅要对项目负责，还要对将围绕它形成的社区负责。这通常需要更改开发/构建/发布工作流程。这与代码本身无关；而是与围绕代码的所有流程和基础设施有关，这些流程和基础设施使开源项目取得成功。

以下是您在发布开源项目之前需要了解和期望的内容。

明确贵公司的目标

在您进一步深入之前，请花点时间评估贵公司最初发布该项目的目标。公司将投入大量时间和精力来为此发布做准备，并在维护项目和围绕它形成的社区方面投入更多精力。虽然这些努力可能是利他的，但更可能是公司期望从其投资中获得回报。

在深入项目及其社区之前，请确保您了解这些目标。采取措施确保您的公司能够实现这些目标不仅对公司有帮助，对自由和开源软件 (FOSS) 整体也有帮助。那些不知道或没有实现其开源项目目标的公司会完全退出 FOSS 的参与，这对任何人都没有好处。

了解社区的期望

虽然您的公司可能仍然掌握着王国的钥匙，并决定合并哪些贡献以及何时捆绑发布，但所有开发工作都必须在公开场合进行，并与围绕它形成的社区进行沟通和协调。

换句话说，项目必须按照已建立的开源项目社区期望运行。这些期望包括（但不限于）：

• 所有开发工作——包括错误修复、新功能开发、产品路线图以及关于这些事项的讨论和问题跟踪——都公开进行，并与社区协调与合作。
• 与代码相关的所有构建过程（持续集成/部署等）都公开运行，并且社区可以访问。
• 公司接受来自社区的贡献，“贡献”不仅指代码，还包括文档、设计、产品路线图指导、治理以及与项目相关的其他事项。所有贡献都必须及时审查和考虑，并且必须公开提供反馈。

认识到社区是关键

开源一个项目会产生大量工作，尽管实际上它通常不比专有软件开发工作量大。尽管如此，将流程和文化转变为在公开场合高效有效地工作并支持开源社区可能需要相当大的努力。

如果这么麻烦，为什么要这样做呢？

正如我之前提到的，企业通常不会出于善意发布项目。他们这样做是因为他们希望从希望围绕项目形成的社区中受益——但只有当公司赢得、建立并维护社区的信任时，这些好处才会发生。

这种信任是通过公开进行所有工作，并与社区进行沟通和协作来实现的。公司做出的任何完全单方面或私下的决定都会违反这种信任并疏远社区。当社区被疏远时，他们就会离开（有时会分叉代码以在其他地方重新开始）。

如果一个社区消失了，就无法从中获益。这让公司拥有一堆开源但无人使用或关心的代码，更不用说无法实现其在开源项目时设定的目标了。

启动您的公共问题跟踪器

一旦项目发布，所有错误报告——以前的和新的——都必须在项目的公共问题跟踪器中可用。以下是您需要做的一些事情：

• 将预先存在的错误/工单/问题移动到项目的问题跟踪器。
  • 请注意，移动通常需要脚本。
  • 在移动任何内容之前，请查看所有现有问题并关闭那些真正没有希望修复的问题。
  • 在将任何预先存在的错误/工单/问题移动到公共跟踪器之前，请务必从中删除任何专有信息。
• 决定是否将已关闭的错误/工单/问题移动到公共跟踪器。
  • 这是可选的，但它可以为未来的开发提供有价值的背景信息。
  • 在公开任何计划移动的已关闭错误/工单/问题之前，请务必从中删除任何专有信息。
• 创建一个新的工作流程，以便所有错误/工单/问题都将高效地路由到公共问题跟踪器并从中通过。
  • 协调和培训所有报告或与错误/工单/问题交互的公司员工。
  • 如果您使用公开可用的问题报告工具（例如，ZenDesk），则新的工作流程必须确保在那里报告的问题能够高效地转移到公共问题跟踪器，并且报告方（通常是客户）仍然可以获得他们期望的服务和信息。

准备好公开您的产品路线图

一旦项目以开源形式发布，其开发路线图和所有相关讨论都将公开可用。

• 现在，所有关于路线图内容（以及原因）的讨论和决定都必须公开进行，并征求社区的意见。
• 社区反馈应融入路线图。

请注意：虽然路线图以及关于它的所有讨论都在公开场合进行，并征求社区的意见，但除非已做出其他安排，否则公司可能仍然对路线图的内容、时间和原因拥有最终决定权。这样做应以尊重项目现在服务和支持的社区的方式进行。

如果公共路线图包含与专有功能交互或依赖于专有功能的功能，则与项目交互的每个人都必须小心，不要在关于公共路线图的讨论中泄露专有信息。

定义贡献工作流程

一旦项目以开源形式发布，所有对其的贡献都必须使用一个面向公众的工作流程，无论贡献来自原始公司还是社区。

以下是一个典型工作流程的示例：

• 贡献者将公共存储库fork或克隆到他们自己的计算机。
• 贡献者创建存储库的功能分支，并在该分支上开发他们的贡献。这项工作在他们自己的计算机上完成时是私有的。
• 一旦他们的贡献准备就绪，贡献者会将他们的贡献提交回公共存储库。（该过程取决于使用的版本控制系统和项目的偏好。）
• 贡献由有资格这样做（通常称为核心贡献者）的社区成员公开审查。这些人然后选择合并、推迟或关闭（拒绝）贡献。如果贡献被合并，它可能会合并到 master/head 或不同的分支，但这取决于项目的需求和工作流程。

每个项目都必须考虑并决定其特定的贡献需求和工作流程，并在项目的 CONTRIBUTING.md 文件中公开提供这些信息。

不要忘记构建过程

在计划开源内部项目时，构建过程常常被忽视。这很不幸，因为一旦项目发布，构建过程也会在公开场合进行。

在公开构建过程时，请务必注意以下事项：

• 没有专有或仅限内部使用的代码分支。
  • 如果存在，它将背叛社区的信任，社区将会离开。
  • 它还会大大增加合并和维护代码所需的工作量。
• 所有构建过程都必须针对公开可用的代码工作，无论是 master/head 还是为构建维护的稳定分支（无论哪种方式对项目和产品最有意义）。
• 所有构建工件都应在构建完成后立即公开提供。
  • 之后如何分发它们（例如，推送给客户）是商业决策，但构建工件（包括最终二进制文件）始终是公开可用的。

支持对社区治理和工具的公开讨论

一旦项目发布，所有影响项目或其社区的决策都必须公开做出，包括治理变更、版本控制或持续集成等工具的调整以及沟通渠道的更改或添加。

这不一定意味着每个细小的决定都必须提交给委员会或需要整个社区的充分讨论。通常，从社区征求建议和反馈并在做出决定时考虑它们就足够了。

所有最终决定、背后的原因及其预期结果都必须公开宣布、可用并在项目用于此类事物的任何跟踪系统（通常是邮件列表加上文档系统或 wiki）中记录。

公开与特定项目相关的任何其他内容

现在您明白了

与项目相关的任何事情都需要公开进行。

一旦项目以开源形式发布，它就不再属于“您”，即公司，而是属于“我们”，即社区（公司是其中的一部分）。这意味着今后所有环节都必须包含社区。

^{非常感谢 John SJ Anderson 对本文的审阅和建议。文章中的任何和/或所有缺陷完全由我负责。}