2000 年，Tim O’Reilly 首次提出了 InnerSource 的概念，也就是内部开源（以下简称内源）。虽然这个概念已经提出了二十年，但在国内还是个较为陌生的事物。相对于内源，大家可能更加熟悉的是开源（Open Source），这种将软件源代码公开的发布模式已经成就了许多优秀的软件和开发者。而内源则是将开源的模式引入至公司或组织内，让开发人员们可以在内部施行开源的同时开发企业专有的软件。
为什么要推行内源
增加代码复用，提高产品质量
增加组件和代码的复用，也可以说是减少组件和代码的重复开发。大家都清楚，重复造轮子可以说是最没有意义的一件事，而内源可以有效的消除这个麻烦。
通俗一点的讲，团队 A 在开发时需要一个新功能，而这个功能团队 B 恰好之前做过，那么这时团队 A 就可以直接在内源仓库中将团队 B 的代码直接拿来使用，甚至还会交还给团队 B 一个质量更好的版本，就像 Linus 法则所说的：只要有足够多的眼球，就可以让所有 Bug 浮现。
但如果没有这个内源仓库的话，团队 A 只能重新开发这个功能。这个过程中所浪费的不仅是时间和成本，甚至还有更重要的——商业机遇。
加速知识共享，提升开发人员能力
如果开发人员处于相对孤立的环境，测试人员也仅限于自己的小团队，在 Bug 响应和解决问题的资源方面，当然会受到各种限制。如果这时团队拥有更多不同经验和观点的外部成员，他们可以找到并解决多少个问题？这会对产品的质量产生什么影响？答案当然是显而易见的。
而作为管理者，与你合作的开发人员都是获得了你认可的优秀的伙伴，但他们可能只与三五个人或十来人一起工作并互相学习。如果他们能和二十或三十个，或更多优秀的开发者一起工作，他们能够在知识共享的同时相互学习，提升自己的能力，自然能够带来产品质量的进步。
开放带来的创新
开发人员通常都是聪明绝顶的，让几十名甚至上百名聪明绝顶的开发人员在一起工作，这些头脑之间摩擦出来的火花能够为企业带来更多意想不到的惊喜，一个更炫酷的新功能甚至一个全新的产品都是有可能的。但如果在他们中间建立起各种无形的墙，这种创新能力无疑会大打折扣。
内源的发展现状
国外许多大厂也已经开始进行自己的内源实践，比如谷歌只有一个代码仓库，由来自世界各国数十个办事处的数万名开发人员共享，微软也在 2019 年宣布全面拥抱内源。更有影响力的是 PayPal 于 2015 年牵头成立的 InnerSource Commons 社区，他们现已为近百家公司、学术机构和政府机构提供支持和联系。
就国内而言，虽然仍旧是一个新鲜事物，但国内的大厂也都开始积极地推行内源。拥有两万多开发人员的腾讯自 2012 年就开始从下到上做内部开源，现已经能做到 65% 的项目内部开源。百度的内源推进工作也已经有了一些成果，如在百度内部应用很广的开源深度学习平台 PaddlePaddle 和 PHP 开发框架 ODP。就 ODP 项目来说，由于项目人力较少，无法面对较多的需求，于是在 2016 年开始内部开源，内源一年后，超过 200 名开发者加入到项目中做贡献，并且有超过 100 个 Patch 被和入。
可以说，内源在国内已经初见端倪，后面只会有更多的企业拥抱内源。
Gitee如何帮助企业进行内源实践
Gitee 企业版为企业提供了内部开源的治理能力，下图是 Gitee 企业版的内源管理界面：
在内源管理界面中，Gitee 企业版将代码仓库分为了三类：
1.专有仓库
专有仓库（内部仓库，或者私有仓库）是企业需要对权限进行严格管控的项目仓库，一般是企业的核心业务产品。此类仓库只有被授权的成员才能访问。
2.内源仓库
内源仓库是在企业范围内开源的仓库，此类项目允许企业内所有成员访问。成员可以按照使用开源软件的方法对项目进行贡献。
3.开源仓库
企业开源仓库跟常规意义上的开源项目没有任何区别，任何人都可以访问到此类仓库的代码，并依据常规的开源项目参与流程进行贡献。
除仓库外，还有开源 Issue 聚合、开源 PR 聚合、开源统计等，欢迎访问 Gitee 企业版体验：https://gitee.com/enterprises
当然，想要充分发挥 Gitee 企业版在企业内源实践的优势，更需要企业内部从管理上进行支持，通过制度和文化的建设来推动内源的发展，让其真正的发挥出效果。例如不断的给工程师和管理者们进行各种开源的布道；设定各种政策和流程来激励贡献者；不断树立各种标杆项目，标杆贡献者等等。
我们整理了一个内源知识库： https://gitee.com/InnerSource/ ，欢迎一起协作完善：）
