大多数与内部开源（Inner Source，简称内源）相关的信息和指南都集中在内部开源的方式和内容上。比如将内部开源解释为“从成功的开源项目中汲取有关软件开发的经验教训，并将其引入内部” （内容），或者“确保 GitHub 仓库对所有开发人员开放” （方式）。这些确实是有用的信息，但对我而言，却忽略了为什么需要内部开源。

了解为什么要采用内部开源，对于帮助调整团队内部开源的实施方式至关重要。目前有多种内部开源的方法，每种方法都有各自适合的应用场景。但是，除非对内部开源的基本原理理解的很深刻，否则很难选择合适的内部开源实施方法。

程序员们是充满好奇的艺术家

开源既可以单独拿出来说，但它同时也是自由软件运动的“分支”，它基于许多与软件开发有关的基本准则，核心自然就是一个个程序员们。自由软件和开源的共同点是它们都要求必须能够访问项目的源代码。为什么呢？原因很简单：这是对程序员们希望或需要阅读和修改代码的一种认可。它说明了一个基本原则，即程序员们是充满好奇的生物，他们不仅渴望了解事物的工作原理，而且也希望自己创造和更改它们。

程序员们是一群艺术家和手工艺人，那些成功的开源项目就是基于这种认识。可以这么讲，开源项目的 Licenses 定义了代码的文化，但是开源项目本身定义和开创了代码贡献者交流的文化，他们通过交流了解哪些方法有效，哪些并没有什么用。精英管理，透明度和社区的基本理念，开源亦或像 Apache 一样开放合作的模式，他们的核心方面，都是为了实现协作。协作不是最终目标，而是一个起点。全面拥抱精英管理、透明度和沟通无障碍的环境是协作可以扎根的理想土壤。而且，这三条指导原则中的任何一条（或全部）越“削减”，协作就越困难。到那时，你实际上根本就没有在做“内部开源”，因为内部开源的原因是要进行协作。

协作可以带来最佳的人员和结果

正是通过协作，自然地带来了所有内部开源的“福利”。无需强迫团队重复使用代码，他们将自然地重用他们已经协作过的高质量代码。实际上，如果发现必须强制重用某个项目的代码，则有力的证明了团队没有正确的在做内部开源。

协作同时也是创新本身的源泉。多元化社区共同协作的能力可以充分发挥出大家的潜力；协作还能够广泛的提出不同观点，这也能催化出更新的点子。我们在科学，数学和医学领域中都见过并理解了这一点。软件开发领域同样如此。

开源以及由此扩展的“内部开源”基于个人之间的协同工作，从而可以生产出强大，可靠，安全和创新的软件。与任何其他软件开发范例相比，内部开源所创造的项目和产品都可以减轻风险，更快地生产和实施，并在商业上取得成功。

企业公有云/私有化部署解决方案：Gitee 企业版