如何建立开放源代码程序
本文介绍建立开放源代码程序的关键考虑事项。
我们所说的“开放源代码”是什么意思？
开放源代码程序不仅仅是对代码库的公开访问。 它是指公开一个动态项目，让任何想参与的人都能参与进来。 若针对适当的项目正确地执行，开放源代码程序可帮助推动产品质量的大幅提升。
公司对项目开放源代码的一个关键原因是他们希望社区参与进来。 社区对热门项目做出了重大贡献，而且是免费的。
这不一定出于利他主义。 个人和组织使用项目是因为他们看到了个人或商业利益。 当项目不符合其需求或预期时，他们可能会利用此机会来解决 bug 或添加功能。 他们不是将这些改进保存在私有分支中，而是不得不将这些更改贡献回源存储库中，成为项目基线的一部分。 这种良性的改进循环是许多企业使用开放源代码模型来生产软件的原因。
开放源代码目标
概括而言，开源软件的参与维度分以下三种：
- 使用者，他们研究或使用其他人的存储库。
- 参与者，他们积极参与改进他人的存储库。
- 生产者，他们构建和维护对他人开放的自己的存储库。
当组织更深入地思考他们想要从每个维度中获得哪些成就时，最好评估他们现在所处的位置。 每个维度内有五个过程级别。
- 临时：没有现成的过程。 成功与否取决于单个工作。
- 托管：具有一个部分记录的过程。 成功与否取决于纪律。
- 已定义：具有一个已记录、标准化和集成的过程。 成功与否取决于自动化。
- 已测量：它具有量化管理的过程。 成功与否取决于针对业务目标的度量指标。
- 已优化：通过增量和创新性更改，具有持续且可靠地改进的过程。 成功与否取决于更改风险是否降低。
若要更好地了解组织的现状，请查看开放源代码自行评估。
应对哪种项目开放源代码？
许多项目并非一定具有开放源代码优势。 尽管你的标准可能因公司的目标和过程级别而有所不同，但在将项目开源之前，请考虑以下一些建议标准：
你的项目是否包含你想要保护的知识产权？ 如果是，则开放其源代码就会丧失其价值。 除非你认为收益大于风险，否则不要开放这类项目的源代码。
项目是否处于稳定状态，且代码质量良好？ 项目不一定要完美，但是如果该项目一开始就很糟糕，则潜在的参与者可能会离开。
项目对公司外部的人员是否有用？ 如果没有用，可能不会有任何参与者。
公司外部的人员是否能够参与？ 他们需要访问所有项目依赖项、生成过程以及运行项目所需的任何其他内容。 如果他们无法运行项目，则无法参与。
团队是否有足够的带宽来支持开放源代码程序？ 如果没有，则等到有足够带宽时再将项目开源。 如果你开放了一个项目的源代码但不支持此项目，则可能会失去构建信任社区的机会。
这些问题只是几个最常见的考虑事项。 你的组织可能要考虑其他业务或合规性问题。
设计开放源代码程序
运行开放源代码程序类似于运行 InnerSource 程序，但是前者面向的是公众。 因此，仍有一些需考虑的事项。
设置社区期望
README.md 和 CONTRIBUTING.md 等文件更为重要，因为它们会向不了解组织环境的人员公开。 需要从公司外部人员的角度对这些文件进行评估，确保它们清晰易懂。
此外，行为准则是一项需要说明的重要策略。 标准准则是将 CODE_OF_CONDUCT.md 文件添加到存储库的根目录中，并使用它来解释社区中参与者的预期行为。 应由组织中的多个组（包括法律团队）审阅此文档。 幸运的是，有许多标准的行为准则可供开始时遵循。 许多项目可按原样使用这些准则，而无需修改。 要了解详细信息，请参阅开放源代码行为准则指南。
让员工做好维护存储库的准备
员工可能没有使用开放源代码社区的经验。 为帮助他们做好准备，建议公司提供一系列指南，其中应涵盖每个人在开始工作之前应知道的重要事项。 应将这些指南发布到定期维护且仅供公司员工访问的内部存储库或门户。 下面是一些最重要的指南：
“是否应将该项目开源？”指南，它提供了一个框架，用于确定是否应将候选项目开源。 该指南可以构造为一个流程图、一组问题或一系列考虑事项。
设置核对清单，其中包括团队在启动已开放源代码的项目之前和之后需要完成的所有工作项。 此列表应包括获取对项目进行开源的审批、执行代码评审以确保在项目上线之前删除敏感数据，以及获取一个商标或执行开放源代码项目搜索以确保不会发生命名冲突等。
组织中关键人员的联系人列表，如果需要维护人员的直接支持，可能需要联系这些人员。 此列表应包括负责软件安全、站点安全、法律、公共关系等方面的人员。
指向入门存储库的链接，可将该存储库克隆为起点。 它应包含示例 README、许可证、行为准则、参与指南以及公司每个开放源代码项目所需的任何其他支持文件。 它不应包含任何你不希望无意中推送给公众的内容。
维护人员指南，用于说明维护人员在保持存储库正常运行方面的责任。 这些责任包括使存储库文档保持最新状态，以及确保问题和拉取请求及时得到相应人员的关注等。
通信指南，该指南为你不希望包括在
README.md、CONTRIBUTING.md或CODE_OF_CONDUCT.md等公共文件中的某些主题提供存储库维护人员指导。 这些主题可能是敏感业务主题（例如不讨论竞争者）或更常规的行为主题（例如：如何恰当地识别顶级参与者）。内部常见问题解答，用于提供常见问题的已批准答案。 在维护开放源代码程序的过程中，如果公司讨论的主题存在法律上的细微差别，此列表特别有用。
许可证政策，其中列出了法律部门已批准或拒绝用于使用开放源代码或参与贡献的许可证。