在你的项目开源之前应该确认的几件事

特别说明：本文由开源之道发布并授权转载。

最近总是看到很多项目开源的信息，但是仔细一读，发觉根本就不是那么回事，比如XX开源深度学习框架、XX开源手机客户端数据库等等。仅仅是开放了代码而已。其它似乎什么都没有做。作为内行的你来说，是否有点痛心疾首？开源真的就没有方法论可言了？

你所在的公司决定将自己内部开发的项目开源了。除了准备好代码之余，是否确定了诸如开源的目标、开发流程等等？开源绝非是将代码开源即可，除了代码还有很多事情需要确认和准备，别急，且待我慢慢道来。

其实，我忍不住想用电影《蜘蛛侠》里面的一句经典台词：“能力越强，责任越大。”来绑架你的开源行为，一旦你的项目开源了，这同时也意味着，你的公司不仅要为项目本身负责，而且要为围绕项目所构建的社区负责，而这通常有意味着需要更改开发/构建/发布工作流程。这不仅仅是代码本身的问题，而且包括那些围绕代码的所有流程和基础设施，唯有这些适应开源的方法论，方能确保项目的成功。

以下就是我要和大家说的，关于在项目开源之前应该去确认的几件事情。

确定公司开源的目的

在事情没有开始发展之前，请花一些时间来评估为什么公司要选择开源？要知道，开源一点都不简单，相反，会是非常艰难的过程，如果是三心二意的话，很有可能坚持不下去。

公司在项目开源之前已经花费了大量的时间和资源来开发，在开源之后，还要花更多的时间和精力去维护和经营围绕项目的社区。所有的这些看起来都是利他主义的，但公司的目标是盈利的。这是所有人都去思考的问题。

请在开源之前，要三思。开源某种程度上并不能使你的公司直接赚到钱，请一定要理解自己的目标。或许是为了声誉，或许是为了吸引人才，或许是其他原因。总而言之，要想清楚。

开源不仅要满足公司的目标，也要对自由和开源软件（FOSS）有利。如果不能满足上述二者的诉求，开源将毫无意义。

理解社区的期望

当你的公司还掌握着项目的绝大多数权力的时候，可以决定那个贡献可以合并到主干，也决定着什么时候发布版本，即使这样，也要确保所有的开发流程都是在开放的沟通情形下完成的，而且是围绕着社区来进行协作的。

换句话说，该项目必须按照社区对开源项目的期望进行操作。这些期望包括（但不限于）：

• 所有的开发工作 – 包括bug修复、新的功能开发、产品的路线图、以及讨论和问题追踪，所有的这些事情都要公开的进行，并与社区协调配合。
• 所有和代码相关的 构建流程 （即持续集成、持续部署等内容）均是公开操作的，并社区成员是可以访问的。
• 公司要接收来自社区的 贡献，这里的“贡献”不仅仅指的是代码，它也包括文档、设计、产品路线指导、治理、以及与项目有关的其它事项。所有的贡献必须及时的进行review，和认真的考虑，且要进行公开的反馈。

要明白社区才是关键

开源一个项目需要做很多的工作，虽然在实践中通常没有比专有软件的开发需要做的更多。然而，流程的改变和文化的转型是需要付出很多努力方能有所结果，然后才是进一步的更加公开、有效，并获得社区的支持。

既然有这么多的工作，我为什么要开源了呢？

正如我在开始的时候所提到的，一家企业开源某项目并不是完全的处于大公无私的、利他的行为，之所以开源，企业通常是希望能够从项目所围绕的社区获得一定的利益。但是，企业要获得这些利益的前提是能够赢得、构建、维持住社区的信任。

信任是在项目在公开的进行中所产生的，须在社区的氛围下进行沟通和协作。公司做出的任何完全单方面或私人的决定都会违反这种信任，疏远社区。当社区分崩离析时，人们就会离开（有时会有人fork代码另起炉灶）。

任何人都没有办法从一个消失的社区中受益。这样的结果就是，这家公司拥有看起来开放，却无人问津的代码而已。与自己当初的目标背道而驰！

启动开放的缺陷跟踪系统

一旦一个项目发布了，所有的 bug 报告 —— 旧的还是新的 —— 都必须公示在项目的缺陷跟踪系统，以下所列出来的是你应该去做的事情：

• 将 原先已经存在的缺陷 移到项目的缺陷跟踪系统
  • 要知道迁移的过程通常是需要写一些脚本的
  • 在你移动任何东西之前，检查所有现有问题，并关闭那些没有真正希望被修复的问题。
  • 确保这些过去的缺陷当中所包含的专有的信息要删除，然后在将之移入缺陷跟踪系统。
• 决定要不要将已经修复的缺陷公开
  • 这是可选的，但是它却能够提供有价值的上下文。
  • 确保这些已经修复缺陷当中所包含的专有的信息要删除，然后在进行公开。
• 创建新的工作流，以让所有的缺陷能够通过公开的缺陷跟踪系统更加的有效。
  • 为公司所有缺陷报告者或参与者进行培训和协调。
  • 假如你选择来网上公有的服务（如Zendesk），新的工作流必须确保这些缺陷的报告能够有效的迁移到这些服务上来，而且要确保报告方（通常是客户）仍然能够收到他们所期望的服务和信息。

准备好产品路线图的公开透明

一旦项目以开源的形式发布，其开发的路线图，以及所有相关的讨论均须在公开的地方进行。

• 所有关于项目的路线图（以及为什么）讨论和决定都必须要公开，并且要以社区的名义进行。
• 社区的反馈需要集成到路线图当中来。

请记住：虽然路线图和所有关于它的讨论都是在公开的和社区的投入中发生的，要知道除非是发生了变故，否则公司依然有对项目最终的决定权：决定项目的走向，何时以及为什么。当然，这些应该在尊重项目现在服务和支持的社区的方式来完成。

公开的项目路线图，可能会包含一些功能，这些功能或者和专有的功能有所交互，或者是和专有的功能有依赖关系，那么公司里与项目有交互的每个人都要小心，请不要在公开的路线图中去讨论专有的信息和内容。

定义好协作的流程

项目以开源的形式发布之后，所有的贡献都必须使用公众的工作流，无论贡献来自原始公司还是社区。

我这里列举一个典型的工作流：

• 贡献者能够 fork 或 clone 公共的仓库到自己的电脑上。
• 贡献者在自己的分支上开发新的功能，这些工作，贡献者是在自己的电脑上完成的，是私有的。
• 一旦完成了所开发的内容，贡献者就会将这些内容提交到公共的仓库。（该过程取决于正在使用的版本控制系统以及项目自身偏好。）
• 这些内容会被社区有资格的社区成员（通常是核心贡献者）进行审核，这些核心成员去选择合并，推迟或关闭（拒绝）这些内容。如果内容被合并了，可能合并到主干或其它的分支，这取决于项目的需要和流程。

每个项目都必须考虑和决定其具体的贡献需求和工作流，而且最好是写入一个叫做 CONTRIBUTING.md 的文件，让人们能够访问到。

也不要忘记构建流程

关于构建流程的部分，往往是从内部到开源的项目最容易忽略的步骤，这是不应该的，构建流程应该和项目一同对外开放。

以下是开放构建流程之前要确保的事项：

• 确保 代码中没有专有的或仅供内部的fork
  • 如果有的话，那么可能会失去社区的信任，那样的话，人们会选择离开。
  • 它也将大大增加合并和维护代码所需的工作量。
• 所有构建过程都必须针对的是公开的代码，不管是主干还是稳定版的分支，用于构建的可维护的（也就是对产品和项目有意义的内容）。
• 构建完成后，所有的构建 artifacts 都应该立即公开。
  • 至于之后的分发（如，推送给客户）该如何进行则是公司自己的决定，但构建 artifacts（包括最终的二进制文件）则始终是公开可获取的。

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

一旦一个项目发布之后，所有有影响的、社区本身的决定均需公开出来，包括治理的变更、诸如版本控制系统、持续集成等工具的调整、以及更改或增加沟通的环节。

这并不一定意味着每一个小的决定都必须发送给委员会，或者要求全社区进行充分的讨论。通常只要征求社群的意见和反馈意见，在做决定时就考虑一下。

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

尽可能开放所有的环节

你可能现在已经隐隐约约觉得上述的段落可以总结为一句话：

任何与项目有关的任何事项 都要在开放的前提下完成。

项目一旦开源，它将不再属于”你们”-公司，它现在属于“我们”——“社区”（公司只是社区的一份子），这也就意味着社区的发展涵盖了所有。

译后记

开源，是关于理念、行为、文化等多重因素所早就，无论你是个体还是公司，开源一个项目绝非仅靠几条方法就能无敌于天下，它是一个过程，一个观念转变，认知上升的过程。此处的方法只是告诉你做点什么事情，而真正开源的过程，是体现在每一个细节中，文档的撰写、Bug 的修复、邮件列表的讨论、Wiki的撰写、IRC或线上讨论会议的每一句话、每一个决策。直接决定着项目的走向和社区的活跃度。文化、观念、认知的转变，是其中最难的部分。

关于原作者

VM (Vicky) Brasseur – VM(简称 Vicky)是一名管理者，其中包括管理人、管理项目、流程、产品、以及p^Hbusinesses，在她超长的18年的技术生涯中，她曾经担任分析师、程序员、产品经理、软件工程经理、软件工程总监。目前，她是一名顾问，为公司提供有关开源的战略、政策和程序的建议。 她的博客地址：anonymoushash.vmbrasseur.com .

本文由作者VM (Vicky) Brasseur 发表在Opensource.com上：What to know before you open source your project。本文在Creative Commons BY-SA 4.0许可证下发布。由开源之道精心编译，欢迎转载！