内部开源：如何在企业内部发挥开源的魔力

将开源开发的方法应用于企业内部可以提高创新能力，缩短产品上市时间，并使员工和客户感到满意。

各行各业、规模各异的公司都在实施内部开源的工作方式，以推动更高水平的开发协作和代码重用。他们的最终目标是提高创新力，缩短上市时间，培养、保留和吸引人才，当然，还有让他们的客户满意。

本文将介绍内部开源和其中的一些重点，还有内部开源可以帮助解决哪些问题。我还会讨论包括指标在内的内部开源流程中的一些组成部分。

什么是内部开源？

内部开源是把开发开源软件中学到的经验教训应用到公司内部开发软件的实践。因为它是在公司环境中完成的，所以内部开源是在公司内部网络中发生的。

在内部开源中，开发人员将会有相应的回报和付出。

回报：

其他人的代码可重用或直接拿来使用（而不是以不同的方式重写同一个项目） 来自更多人对代码的测试，补充和修复

付出：

代码供他人重用或使用 在其他人的项目中进行协作，补充，测试或修复代码

看到这里，你可能会问，这不就是协作开发吗？的确是这样，但是，对于团队相对孤立的大型公司而言，它的作用是极大的。这时就需要补一补开源相关的课程了。

有了内部开源，开发人员不仅可以与他们在特定领域内的团队成员进行协作。他们还有机会在特定领域之外的代码和项目上进行协作。一切都是开放的，这就默认了开发人员能够阅读所有内部源代码和文档，不用再为了阅读它们而唯命是从。

在内部开源项目中，围绕代码的所有决策都将记录在案并公开。这样会创建一个非常全面的日志，新的参与者或团队可以使用该日志来快速了解并了解项目的历史。

内部开源可以解决什么问题？

封闭或孤立的开发模式所产生的问题，让他们开始追求内部开源。

重复开发

多次以不同方式构建同一事物的成本很高。将代码写完后重用，或者在此基础上构建新的代码，这会具有更高的成本效益。它可能导致相同产品矩阵中外观和感觉不同的产品。客户期望且理应得到同一产品矩阵中的产品能够提供无缝，一致的体验。重复开发也可能意味着你的产品与产品之间无法无缝结合使用或根本无法结合在一起。如果你的目标是提供统一集成的解决方案，那么对不起。如果你不花时间在重新造轮子上，完全可以可以更快地进入市场。

产品上线时间变慢

重复开发导致产品上线时间变慢，但也可能是由于封闭和孤立的开发环境所带来的依赖性。如果你的产品需要与另一个你没有发言权的产品集成，则必须等待有人同意添加你的功能或修复某个 Bug，这意味着你需要花费较长时间才能进入市场。你会因为速度变慢而错过市场机会吗？其他公司会趁机击败你吗？

局限性

如果你的开发环境是孤立的或封闭的，你的测试人员也仅限于你那个特定的小组。在漏洞响应和解决问题的资源方面，你也可能会受到限制。拥有更多不同经验和观点的外部人员可以找到并解决多少个问题？这会对产品的质量产生什么影响？

许多开发者在和聪明，敬业的人们一起工作，他们为出色的产品构建功能，提供支持，这非常棒。但是在封闭或孤立的环境中，你可能只与三五个人或十来人一起工作，建立联系、相互信任并向他们学习。

你如果能和20或30个，或更多杰出的开发者一起工作，那不是会更好吗？你能成就些什么？你能在这个过程中学到什么？如果你可以从其他项目和领域中学习，将会获得什么新技能？你难道不想在这样的地方工作吗？

一切如何融合在一起？

让我们看一下内部开源流程的一些关键点。我与50多个开发者聊了聊，询问他们需要什么。以下是他们的回答：

给予我们：

较低的准入门槛 正确的环境（比如，如果不必要，不要让我们更改工具包） 以指导为主，而不是强制要求

我们可以：

掌握自己的命运 管理和控制我们自己的项目 高效的沟通

并且：

把事情简单化，不要让过程或程序变得繁重复杂

以下是需要主要注意的事项：

文化相关

Opensource 社区内部已经达成共识，即内部开源更多地是关于管理和文化上的转变，而非是否能够共享代码和拥有正确的工具。为了正确的进行内部开源，公司需要在内部培养开放性和透明性的文化和环境。对于许多公司而言，这就意味着转型。

信任是所需文化的重要组成部分。使用团队内部的开发模式，开发者将与自己的团队成员建立信任，并且他们对团队代码的完整性充满信心。内部开源会让这些团队对外开放以征询团队外部的意见，因此他们自然会对质量和风险感到担忧。所以就必须建立信任，这就需要一个允许协作和开放沟通的环境，这对于健康的内部开源工作至关重要。

辅导制度是文化健康的另一个关键方面。简而言之，在内部开源的环境中的思维定式是：“让我们讨论一下怎么将这些代码提高到可以合并的水平”，而不是：“我们并不了解你，所以我们不信任这些代码，因此我们拒绝接受它们。”

法律相关

根据公司的性质，构建内部开源的最大步骤之一就是修订政策和流程，以使开发者能够内部访问大多数代码。与公司法务部门紧密合作，在不损害系统应用程序和保护内部代码的安全性的前提下确定政策，这一点很重要。

培训相关

在为开发者提供的信息太少与提供的授权过于严格之间寻求平衡。为他们提供清晰易懂的入门信息，相关准则以及基本的操作方法信息。根据协作开发的成熟度级别，一些团队可能需要更多的深入培训或实操培训。在这些情况下，它有助于确定在早期的参与者中哪些人可以指导和带领其他同事。

工具相关

内部开源需要一个能够实现在高安全级别中访问，协作，通信和易于查找的环境。如果开发人员已经在使用强大而安全的协作工具进行域内开发，可以考虑继续使用。不管你使用哪种工具，都要为代码传输或从其他工具转移代码提供清晰的过程。

机会

尤其是在刚刚开始时，内部开源可能需要投入大量精力进行综合的实施、代码审查、修订，还要寻找合适的协作机会。为这些活动分配时间和资源对于成功至关重要。

指标

内部开源会大量提高团队的活跃度。新成员的加入，他们之间的协作，他们中的一些人将做出自己的贡献。在以上这些活动中将产生许多东西。创建各种项目，随之而来的就是各种发布、提交代码、编译和请求代码合并（PR）。

这些是在内部开源早期阶段易于衡量的数据点，看到它们呈上升趋势可能会令人鼓舞。但是，要记住它们只是数据点。他们并没有完整地呈现出价值。

所以专注于最终目标至关重要。采用内部开源后你可能会寻求实现以下一个或多个目标：

提高质量，员工和客户的满意度，创新和（或）整合

缩短上市时间，降低成本和（或）减少缺陷

原作者：Erin Bank
原文链接：https://opensource.com/article/17/9/innersource