目前大多数与内部开源（Inner Source）相关的信息和指南都集中在内部开源的方式和内容上。比如将内部开源解释为“从成功的开源项目中汲取有关软件开发的经验教训，并将其引入内部” （内容），或者“确保 GitHub 仓库对所有开发人员开放” （方式）。这些确实是有用的信息，但对我而言，却忽略了内部开源的最重要方面：为什么。
了解为什么要采用内部开源，对于帮助调整团队内部开源的实施方式至关重要。目前有多种内部开源的方法，每种方法都有各自适合的应用场景。但是，除非对内部开源的基本原理理解的很深刻，否则很难选择合适的内部开源实施方法。这就需要了解内部开源的“前辈”：开源（Open Source）。
开源既可以单独拿出来说，但它同时也是自由软件运动的“分支”，它基于许多与软件开发有关的基本准则，核心自然就是一个个程序员们。自由软件和开源的共同点是它们都要求必须能够访问项目的源代码。为什么呢？原因很简单：这是对程序员们希望或需要阅读和修改代码的一种认可。它说明了一个基本原则，即程序员们是充满好奇的生物，他们不仅渴望了解事物的工作原理，而且也希望自己创造和更改它们。
程序员们是一群艺术家和手工艺人，那些成功的开源项目就是基于这种认识。可以这么讲，开源项目的 Licenses 定义了代码的文化，但是开源项目本身定义和开创了代码贡献者交流的文化，他们通过交流了解哪些方法有效，哪些并没有什么用。精英管理，透明度和社区的基本理念，开源亦或像 Apache 一样开放合作的模式，他们的核心方面，都是为了实现协作。协作不是最终目标，而是一个起点。全面拥抱精英管理、透明度和沟通无障碍的环境是协作可以扎根的理想土壤。而且，这三条指导原则中的任何一条（或全部）越“削减”，协作就越困难。到那时，你实际上根本就没有在做“内部开源”，因为内部开源的原因是要进行协作。
正是通过协作，自然地带来了所有内部开源的“福利”。无需强迫团队重复使用代码，他们将自然地重用他们已经协作过的高质量代码。实际上，如果发现必须强制重用某个项目的代码，则有力的证明了团队没有正确的在做内部开源。
协作同时也是创新本身的源泉。多元化社区共同协作的能力可以充分发挥出大家的潜力；协作还能够广泛的提出不同观点，这也能催化出更新的点子。我们在科学，数学和医学领域中都见过并理解了这一点。软件开发领域同样如此。
开源以及由此扩展的“内部开源”基于个人之间的协同工作，从而可以生产出强大，可靠，安全和创新的软件。与任何其他软件开发范例相比，内部开源所创造的项目和产品都可以减轻风险，更快地生产和实施，并在商业上取得成功。
为什么？因为行之有效！
从本质上讲，为什么要采用内部开源的答案很简单，因为它确实行之有效。
本文由作者 Jim Jagielski 发表在 medium.com 上：The "Why" of Inner Source 。由 Gitee 精心翻译共享，本文在 Creative Commons BY-SA 4.0 许可证下发布。转载请注明文章来源。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。