在开源你的项目之前需要了解什么

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

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

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

明确贵公司的目标

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

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

了解社区的期望

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

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

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

认识到社区是关键

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

如果工作量这么大，为什么要这样做呢？

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

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

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

启动您的公开问题跟踪器

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

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

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

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

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

请注意：虽然路线图及其所有相关讨论都在公开场合进行，并征求社区的意见，除非另有安排，否则公司可能仍然对路线图上包含什么、何时包含以及原因拥有最终决定权。这应该以尊重项目现在服务和支持的社区的方式进行。

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

定义贡献工作流程

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

这是一个典型工作流程的示例

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

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

不要忘记构建过程

在计划开源内部项目时，构建过程经常被忽视。这是不幸的，因为一旦项目发布，构建过程也会在开放环境中进行。

在开放构建过程时需要确保的一些事项

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

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

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

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

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

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

您现在明白了

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

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

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