如何管理成功的 InnerSource 程序
在这里，我们将讨论如何设计 InnerSource 程序，以便在任何软件开发组织中体验到开源模式最大的优势。
什么是 InnerSource？
任何人都可以随意使用、修改和共享开源软件。 使用开源软件，任何人可以出于任何目的查看、修改和分发项目，共享代码仍会使软件更完善、更可靠。
InnerSource 是将开源模式应用于具有有限受众的项目的做法。 例如，公司可以建立一个 InnerSource 程序，该程序反映典型的开源项目结构，但只有该公司的员工才能访问此程序。 从效果上说来，它是受公司防火墙保护的开源程序。
InnerSource 权益
InnerSource 程序可以提供传统闭源模型所不能提供的很多优势。
首先，它们鼓励透明性。 如果可以访问其他公司项目的源代码，开发人员也许就能更高效地处理自己的项目。 他们可以看到不同的团队如何解决与自己所面临的问题类似的问题，并且经常可以找到他们可以重用的代码和其他资产。 访问团队问题、拉取请求和项目计划还能提供更好的数据，让开发人员能够了解项目开发的速度和方向。
其次，它们能减少冲突。 如果使用者团队依赖于其他团队所拥有项目的 bug 修复或新功能，则他们可以通过这个渠道来提议所需的更改。 如果出于任何原因不能合并这些更改，则使用者团队可以选择对项目进行分支以满足其需求。
最后，它们标准化做法。 开发组织面临的一个常见挑战是，不同的团队常在运行方式上存在分歧。 构建 InnerSource 计划是采用标准约定的好机会，让每个开发团队都可以使用这些约定，即使这些团队不遵循相同的做法。 例如，两个团队可能更倾向于接受贡献。 让这两个团队对各自公开流程的方式进行标准化，可以让任何人更轻松地参与其中任一流程。
这些示例只是使用 InnerSource 程序可享有的几个优势。 若要了解详细信息，请参阅 InnerSource 简介。
在 GitHub 上设置 InnerSource 程序
设置存储库可见性和访问权限
你可以将 GitHub 存储库配置为具有三种级别的可见性。 用户尝试访问存储库时，不满足可见性要求的用户将看到“找不到”页面。 级别包括：
- 公共存储库对所有人都可见。 此可见性适用于真正的开源项目，向组织内部和外部人员提供访问权限。
- 内部存储库仅对拥有这些存储库的组织的成员可见。 此可见性适用于 InnerSource 项目。
- 专用存储库仅对所有者以及其添加的任何团队或个人可见。 此可见性适用于仅由特定用户和组访问的项目。
在建立了存储库可见性后，即可基于个人或团队来配置访问权限。 有以下五种权限级别：
- 读取级别，建议用于想要查看或讨论项目的非代码参与者。
- 会审级别，建议用于需要在没有写入权限的情况下主动管理问题和拉取请求的参与者。
- 写入级别，建议用于经常主动推送内容到项目的参与者。
- 维护级别，建议用于需要在不没有敏感或破坏性操作权限的情况下管理存储库的项目经理。
- 管理员级别，建议用于需要对项目具有完全访问权限（包括管理安全性或删除存储库等敏感和破坏性操作）的用户。
详细了解按级别分类的存储库访问权限。
创建可发现的存储库
随着 InnerSource 程序的发展，存储库的数量可能会显著增加。 尽管可以将所有这些资产提供给组织，但这样做也可能让人很难高效地找到内容。 若要提前解决此问题，最佳做法是让团队考虑如何让他人可以更轻松地找到并使用其存储库。
一些最佳做法包括：
- 使用描述性的存储库名称，如
warehouse-api或supply-chain-web。 - 包括简要说明。 一两句话应该足以让潜在用户了解项目是否符合其需求。
- 许可存储库，以便客户知晓如何使用、更改和分发软件。
- 在存储库中包含一个
README.md文件。 在有人访问存储库时，GitHub 会使用此文件作为登陆页面。
添加 README 文件
README 文件传达对项目的期望，并有助于管理贡献。 README 文件可以：
- 清楚地表述项目的目的和愿景，使潜在使用者了解项目是否满足其需求。
- 提供视觉帮助，如屏幕截图或代码示例，以动态阐释项目。
- 包含指向应用的生产或演示版的链接以供查看。
- 设置先决条件和部署过程的期望。
- 包括对你所依赖项目的引用。 这些引用是宣传他人工作成果的好办法。
- 使用 Markdown 引导读者浏览格式正确的内容。
如果将 README 文件放在存储库的隐藏 .github、docs 或根目录中，GitHub 会识别出该 README 文件并将其自动呈现给存储库访问者。 如果存储库包含多个 README 文件，则所示文件是从以下位置中选择的，顺序如下：先是 .github 目录、然后是存储库的根目录，最后是 docs 目录。
查看一些精彩的 README 示例。
项目启动后，使用电子邮件和其他社交渠道进行宣传。 接触适当的受众可以大大促进项目参与。
管理 GitHub 上的项目
随着项目的关注度越来越高，可能需要大量的工作来管理涌入的用户和贡献。 根据具体项目，可能仅仅是管理项目参与者的期望就需要大量的工作。
为了提前解决此问题，GitHub 会在存储库的根位置（或 /docs 或 /.github）查找 CONTRIBUTING.md 文件。 使用此文件来解释项目的贡献策略。 确切的详细信息可能会有所不同，但最好让潜在的参与者了解项目遵循哪些约定、团队在哪里寻找拉取请求、为 bug 报告请求了哪些详细信息等。
如果 CONTRIBUTING.md 存在，GitHub 会在用户创建问题或拉取请求时向其提供链接，以鼓励跟进。
此外，请考虑向存储库中添加 CODEOWNERS 文件，以定义负责评审代码修改的个人或团队。
创建问题和拉取请求模板
GitHub 支持新问题和拉取请求的初学者模板。 使用它们为新创建的问题或拉取请求提供初始描述文本。
例如，如果你的项目有 .github/ISSUE_TEMPLATE.md，那么只要用户启动创建问题的过程，他们就会看到此内容。 不一定要始终引用 CONTRIBUTING.md 中的必要详细信息，只需使用模板文本像填写表单一样填写问题即可。
这对于拉取请求来说是相同的，但路径为 .github/PULL_REQUEST_TEMPLATE.md。
定义工作流
对于鼓励外部贡献的项目，请确保指定项目遵循的工作流。 该工作流应包含有关以下内容的详细信息：在什么情况下、以何种方式使用分支处理 bug 和功能，如何打开拉取请求；以及存储库团队外部人员在推送代码之前应了解的其他任何详细信息。 如果尚未考虑好使用什么样的工作流，应考虑 GitHub 流。
应传达管理发布和部署的策略。 工作流的这些部分将影响日常的分支和合并，因此将其传达给参与者非常重要。 详细了解它们与 Git 分支策略的关系。
度量程序成功
任何尝试 InnerSource 的团队，都应考虑要跟踪哪些种类的指标来度量其程序是否成功。 尽管传统的指标（例如“面市时间”和“报告的 bug”）仍适用，但它们不一定能够说明通过 InnerSource 实现的好处。
请考虑添加指标来显示外部参与对于提升项目质量的作用。 存储库是否接收来自外部源、可修复 bug 和添加功能的拉取请求？ 在围绕项目及其未来的讨论中是否有积极的参与者？ 该程序是否激励了 InnerSource 扩展，从而在其他方面让组织受益？
简而言之，指标很难确定，尤其是要度量个人和团队贡献的价值和影响时。 如果误用，指标可能会损害文化和现有过程，还可能负面影响对于组织或领导团队的集体情绪。 考虑度量 InnerSource 采用情况时，请考虑以下内容：
- 度量过程，而不是输出
- 代码评审周转时间
- 拉取请求大小
- 正在进行的工作
- 打开时间
- 针对目标而不是绝对指标进行度量
- 度量团队而不是个人的贡献
- 项目的唯一参与者数
- 重用代码的项目数
- 跨团队 @mentions 的数量
在这些 InnerSource 案例研究中了解其他人获得的成功。