开放源代码和内源代码

开源的成功在于其开放和协作的文化。让合适的人在大距离上自愿地进行异步协作，有助于以最佳的方式解决问题。其原则如下：

  • 开放协作

  • 开放沟通

  • 代码审查

将这些原则应用于组织内部的专有软件开发被称为 “内部开源”（inner source）。这个术语归功于Tim O’Reilly，早在2000年提出。内部开源是打破壁垒、促进团队和产品之间强大协作的一个有效方式。

但与开源和开放开发一样，仅仅将代码开放并不足以创造出内部开源文化。许多成功因素影响着内部开源方法是否能成功：

  • 模块化的产品架构：如果你有一个庞大的单体架构，这将使得人们不愿意贡献代码。同时，代码质量、文档以及你能多快理解和贡献代码，也会对内部开源的采纳产生重大影响。

  • 标准化的工具和流程：如果每个团队都有不同的工具链和工作流程，其他工程师也很难参与贡献。拥有一个统一的工程系统，以及相似的分支管理和 CI/CD 流程，将帮助团队集中精力解决问题，而不是被迫学习不同的工具和工作流程。

  • 自主性和自组织：只要组织将需求下推到团队，工程师们忙于按时完成任务，他们就不会有时间去贡献其他团队的工作。只有当团队能够自主地进行优先级排序并自组织工作时，才有自由参与其他社区——无论是开源还是内部开源。

内部开源可以帮助打破壁垒并提高工程速度。但它也与高水平的 DevOps 成熟度相关。内部开源是随着 DevOps 能力和开源成熟度的提升而逐步发展的。所以，它应该被视为加速的一个结果，而不是输入。

从技术上讲，内部开源通常是通过在企业中激活分支（forking）来实现的。这与分支工作流程密切相关，我们将在第 11 章《基于主干的开发》中介绍这一点。