什么是内部开源？

内部开源是一种软件开发策略，公司采用开源的方法和文化来更有效地合作。

内部开源是什么意思？

内部开源在那些表现出色的开发和工程团队中正变得越来越受欢迎，这些团队采用了开源的方法来更高效地工作和合作。当这些团队采用内部开源策略时，他们虽然是在开发私有软件，但他们在团队内部共享和开放这些工作，从而允许每个成员，无论是开发人员还是产品经理，都可以为源代码贡献自己的部分。

内部开源本质上是一种软件开发策略，其目的是将开源的最佳实践应用于私有代码。这种方法不仅保留了供公司内部使用的软件，还在公司内部推广开源的文化，增强了工作的透明度，提高了团队间的合作，并消除了信息孤岛。

通过使组织内部的项目默认为开放状态，团队能够重新利用现有的解决方案，大大减少重复的工作，增强团队间的合作，并最大限度地发挥所有员工的才能。不论组织的大小，都可以从内部开源这种策略中受益，并且可以不断从大型开源项目中吸取经验，将这些经验应用到他们的软件开发实践中。

在大型组织和公司中，开发团队可能散布在各个不同的部门或不同的时区。这意味着许多开发人员可能从未见面或可能没有遵循相同的部门指导原则。但是，通过采用内部开源策略，这些团队可以统一到一个经过验证的工作流程模型，这种模型在开源项目中已经被证实是有效的。

PayPal通过其实践展示了，即使“开放”的概念在“开源”中仅限于一个组织内部的团队，采用开源的开发方法也可以使企业运作得更加高效并获得盈利。而其他一些公司，如Bosch、Autodesk、Bloomberg和SanDisk，都是采用内部开源策略的先锋，它们展示了使用与传统开源相同的、高效且低成本的方法来成功地完成复杂项目并创造创新性产品的能力。

为什么组织希望像开源项目一样运作？

从本质上讲，大型组织的操作模式与大型开源项目很相似，因为它们都包括许多变动和多个参与者，使用各种工具，并遵循各种策略和指导方针。但在传统的组织模型中，公司的运作通常是基于高层管理人员的指示。这意味着这些管理者需要处理和跟踪大量的信息，导致信息的流通可能会遇到瓶颈，从而有可能导致一些项目被忽视。

尤其是当项目变得更加复杂，或涉及更多的团队时，更有可能有些任务在一段时间内被遗忘。而在开源项目中，与开发相关的所有信息都会通过特定的文档和检查流程进行管理，确保随着时间的推移，项目中的各个部分都不会被忽视。

对企业来说，最重要的开源工作流程实践是：

确保项目的可见性
允许项目的分叉
允许拉取和合并的请求
测试
持续集成
文档化
使用问题跟踪器来跟踪项目中的问题

当组织采纳这种开源的开发思维时，他们能够更好地共享信息、消除信息隔离，并最终建立一个更加强大和高效的软件开发流程。

内部开源的优势

使用内部开源的组织会体验到与传统的开源开发相似的好处，例如：

代码质量更高：团队使用单元测试、代码覆盖率和持续集成等手段在项目早期就确保代码的优质
文档更加全面：代码不仅在注释中有详细记录，还在各种讨论中有非正式的描述，确保所有的信息都集中并且透明
有效的代码重用：代码和解决方案可以在整个组织中轻松地被查找和重用
强大的合作：团队间的合作变得更加紧密，代码审查过程更加流畅，沟通也更频繁，从而贡献的代码和解决方案也更多
健康的文化：打破了信息孤岛，所以开发者的工作满意度提高，有助于留住和吸引更多的人才

内部开源解决的问题

以下是大型组织经常面临的一些问题，内部开源有助于解决这些问题。

问题	解决方案
沟通：大型组织中的团队通常不是为了一个共同的目标而工作，而是分散在多个独立的团队中，每个团队都有自己的结构和领导方式。这导致了团队之间的沟通存在障碍，有时使用的术语和规范也不相同，导致真正有效的沟通和知识分享变得困难。	开源系统通过其开放和透明的特性，提供了一个平台，使得大量的人可以参与并为项目做出贡献。它采用扁平的沟通结构，消除了多余的中间环节，使得沟通变得直接和清晰，这样每个参与者都可以直接与其他利益相关者沟通。
发现：在大型组织中，由于部门间的沟通障碍和缺乏透明度，同一个软件解决方案可能会在不同的部门中重复创建，这意味着浪费了资源和时间。	在开源项目中，由于其透明性，团队可以搜索整个项目来查看是否已有相似的解决方案，从而避免了重复的工作。
繁文缛节：在许多组织中，由于存在严格的组织结构和权限设置，团队成员如果想访问某个项目或资源，可能需要经过一系列的审批流程，这不仅浪费了时间，而且可能转移了员工的注意力。	在开源项目中，团队成员通常可以自由地访问或查看项目，从而大大减少了与权限管理相关的行政工作。
修改：在传统的商业环境中，如果团队不能直接修改一个项目，他们必须依赖其他人来为他们进行所需的修改或添加新功能。但是，如果负责该项目的人员没有时间或不认为这些修改是必要的，那么这些修改可能就不会被进行。此外，由于担心新的变更可能影响项目的稳定性，可能会有一些犹豫或拖延授予访问权限。因此，为了满足自己的需求，团队可能会创建自己的版本的项目或应用，这导致了不必要的冗余和复杂性，因为多个团队可能会为解决相同的问题而单独构建多个应用。	当团队想要修改开源项目时，他们不需要事先得到许可。他们可以直接进行修改，并提交这些更改以进行系统测试。通常，团队会从主代码库创建一个分支，进行他们的修改，然后提交一个合并请求，供其他开发者审查和测试。对于那些负责审查和合并这些请求的人来说，这种工作流程降低了他们的工作压力，因为他们不需要自己从头开始做这些更改，而且这些更改已经经过了测试。这种方法还有另一个好处，那就是它可以减轻整体的系统负担，特别是对于需要生成报告的工具，因为系统只需要维护一个统一的代码库，而不是多个版本。