初入开源世界的企业会犯哪些常见的错误？如何避免？

借鉴开放源码，将其应用于企业的整体流程，而不仅仅是开发。

开源软件越来越多的被采用，且延展到技术行业的每个角落，几乎所有的技术公司现在都在其产品中使用开放源码，很多公司会积极的参与到外部的开源项目中，甚至越来越多的公司开始创建开源项目用来达到商业目的。几乎在任何地方，我们都能看到开源以及人们更加深入的参与。

但是现实中，我们却看到太多的对于开源的错误理解，有的甚至丧失了很好的机会。

本文的意思并非说是所有的开源努力都是失败的。代码也写过了，产品也发布了，但是通常公司并不能从开源中得到他们应得到的益处，当然也就没有意识到他们正在做出的选择和权衡。

开源绝非是简简单单的许可协议和公开的GitHub仓库。当做完诸如各种承诺，向人们解释等事项之后，就要全身心的去走下去，它会影响到整个业务。以下是我们在数十家公司中看到的一些模式，因为他们属于以往探索开源软件的做法的先行者。经过实践证明：当做法得当，开源会让你整个公司都沟通顺畅了，成为吸引客户甚至竞争对手的新模式，提高工程质量和响应能力，并获得广泛的人才库。当然，这需要整个公司层面上去积极的参与，并兑现承诺。相反，如果是把开源仅仅是当作走过场，又或者是为了给产品增加新功能，这就是过去的官僚主义了，而这恰是工程师和他们的经理所最为痛恨的，开源就不会有任何的结果。

开源是途径，并非目的

开源重塑了企业的一些关系，并让业务更加的灵活，它让顾客乃至竞争对手成为公司的合作者。当参与开源的收益大于闭源代码时，公司就会拥抱开源，并鼓励这样的灵活业务。但是开源本身并不是一个结果，它是一种找到不同公司的利益相交的地方，并能够让这些公司合作起来 —— 它是一条途径，而不是一个地点。要想得到开源的更多收益，则须明确的走下去。

但是很多公司都会试图跳过这条路径，而直接到达终点。他们秘密的开发软件，然后在某一天说自己完美的实现了产品，并有着酷炫的功能，并声称：“现在我们开源了！” 要知道这从来都不会发生。我可以列举出一大堆理由告诉你，由此产生的项目不大可能带来开放源代码本应能得到的大部分收益。代码是使用了自由的许可授权、且有着公开的可访问的仓库，即使是产品有着相当的受众，也不会魔法般的突然出现很多参与者。所有的这一切都归因于一个原因，那就是：潜在的参与者会清楚明白的意识到 —— 你的项目没有开源的 整个过程。

一家开源的公司必须经历建设开发者社区漫长的过程，和其他利益相关的方进行合作，而且要跨越公司和项目的边界进行工作——只有代码是开放的，这一切才有可能。简短点来说，若要开源，必须经历这点。你可以从这条漫长的路径任意的点出发，但是就是不能直接跳过。

开源要趁早，不要等到万事俱备之后再开源

要等到所有的事情都完备的情况下再去开源，对于业务有着非常不利的原因：它会错失良机，以及先发优势。

当这些开发者们在秘密的进行开发，即隐藏在公司的保密协议背后在辛勤的工作，你的一些竞争对手已经早已开始建立联盟、进行协作、甚至一起投资了。所以要尽早的去进行开源项目的投资，让竞争对手追赶你，而不是相反。

一些公司对于过早的将代码开源的担忧有如下三个理由：第一，会对现有的开发流程不利，因为这涉及到开发方法和习惯的调整；第二，可能放弃潜在的信息优势：让竞争对手知道我们要开源一些项目，这意味着放弃了某些竞争优势；第三，通常是不好意思或感到囧：“我们的代码还没有准备好！我们的程序员们不乐意看到不够优雅的代码以及难以阅读的文档，等他们把这些都补上再说。”

其实这些理由都是可以理解的，也属于人之常情。让我们先来处理前两种情况：

开源可能需要对开发方法进行一些调整，而且说实话，开源的计划确实会为你的竞争对手提供一些信息，当然这也就需要你偶尔的应该去针对开源项目的时间进行合理的安排。

但是这种偶尔的情况发生的概率非常的小，如果说你的团队需要调整自己的工作方法，好的决策是尽早的改变，而不是拖延到未来。在项目早期阶段学习如何整合开源实践可能是棘手的，但是对于开源的新手来说，却能够更好地被引导，从而很快的熟悉它。在开发周期的后面来做这件事情的话，会面临项目截止日期的压力，那个时候再去改变，闭源的习惯早已经固化了每个开发者，会面临更大的困难。

至于说开源会对外发出明确的信号这件事情来说，谨记两件事：第一，无论如何，从整体的战略来说，竞争对手都会看的清晰明了，你得根据自己的业务性质来作出决定；第二，如果你的竞争对手改变了策略是因为看到你开源了项目，这不正中你意了吗？要明白自己的强项在哪里。在你的行动对他们有重要意义的情况下，他们在某种意义上自愿地将自己置于与自己的计划相关的领导作用。不要去可以隐藏什么，利用开源来将全部的优势显现出来。

最后我们再来看看不好意思的事情，即如何处理代码还没有准备好让外人看这个问题，方法很简单：尽管放手就好了。真实的情况是，你开源的越早，这些东西越少人关注，因为大家都知道没有那个代码仓库在初始阶段就是完美的。再说的更为露骨一点，不要以为会有人注意你，你随时都可以开源，因为大家关注代码是是否需要。

中层管理是关键，这是开源深入组织文化的地方

开源的实现，既可以是由上而下，也可以是至下而上。

有的时候，某些公司会将拥抱开源视为整个公司的战略部分：上层领导认识到开放源码的好处，然后在促进变革的过程中作出广泛的改变，在公司的各个部门都非常的重视开源。然而有些时候，某些公司的开源之路是从软件工程师们开始，因为他们是一线员工，明白开源给他们带来的好处。后一种情况，开源的活动是在环境的趋势下形成，又或者是工程师向自己的经理倡导、说服，无论那种情况，对于开源的推动是来自公司的基层——一线工程师，而不是公司整体的大的战略。

无论是那种方式，自上而下也好，自下而上也罢，中层经理对于开源的实现都起着巨大的作用和影响。

中层管理层是传递关于传达问题和优先事项信息的渠道。当这些转变涉及开源开发时，只有当经理们认识到发生了什么事情的时候，组织才回去认真的思考和行动。中层管理是开源内化的关键群体，如果他们没有认同这种做法，整体的组织就无法从开源中获益，甚至恰得其反。

这里我们举一个例子，绝大部分公司在转向开源时都得重新考虑评估和考核的事情，随着员工在参与开源项目花费时间的增多，那么在评估时就很难知道该如何衡量他们的业绩。如果管理人员过于注重预算和在其直接职权范围内的可交付成果，那么这些管理者就会低估员工在开源项目中的工作，这其中包括宣传、帮助其它开发者入门、审核其它贡献者的代码、以及传统公司没有过的各种事项。一名由公司某业务部门付工资的开发者，参与到开源项目中，会以公司的利益为主，进而去传播。这时如果Ta的经理试图抹杀Ta在开源的工作，那么出现的情况就是，越来越多的开发人员会将时间集中在业务部门的直接目标上，因为即使那样会对公司造成的损失，但对于个人来说则是“考核过关”。

再举一个例子，参与开源的积极活动一个非常有趣的好处就是能够在公司范围内增强内部的沟通。开发人员开始与其他业务部门的人员合作，若不是因为开源项目，他们可能一辈子也不会进行任何的合作。当双方的经理都意识到并支持这样的合作时，这些联系对于沟通来说自然是最为有效的。

开源的成功需要来自中层管理的大力支持，而不仅仅是组织层次结构的顶层或底层。

要对来自文化的抵抗有所准备

开源不仅对于在代码中产生了转换的效应，而且也会对组织的其它部分甚至非技术部分也会有所影响。如果经理和人力资源部门拒绝让这种转换扩散到整个公司，那么开源协作的技术优势和对企业文化的潜在改进就会遭到惨败。

当一群有经验的开源开发人员一起工作时，他们会以可识别的模式进行。他们有着共同的一系列使用的协作工具（版本控制仓库、缺陷跟踪、自动化测试系统等等），他们将倾向于以常规方式使用这些工具，这些工具在许多不同的项目中是常见的。即使对于非软件代码的任务也是如此：作者和编辑也会以与开发团队编写代码相同的方式来处理文档，使用相同的惯例和约定来协调工作以及作出决策。开放源码协作工具包不仅仅是技术协作的基础设施，而且还包括所有这些过程。

一个习惯于开源协作工具的员工，会自然而然的在各种场合下使用和推广这些工具，默认情况是共享的，并且始终保持开放的态度，这已经是根深蒂固的一种文化了。举例来说，一个组织该如何面对任务所有者一直在变更的情况？一定会对开源的一些边界产生怀疑。

所以招聘和人力资源也要随着逐步的开源而进行相应的转变。那些优秀的候选人当他们和公司外部的人进行协作时，会留下证明自己很牛的证据的。他们在公共的空间留下了自己的成绩，这是在整个社区的利益相关者都可以看得到的。开源能够为公司招聘到最顶级的人才创造了机会，但同时开源也形成了对所有人公开的新的人才市场。这就对管理和人力资源提出了更高的要求，他们必须应对这些新的挑战。

开源的开发因此会给公司的非工程部门带来压力，他们需要作出相应的调整，不能够认识到实际的需要，又或者是不能够满足，这对于初入开源界的公司都是较为正常的挑战。

社区无法代替你的开发者

有些时候，某些公司会认为开源是一条找到廉价的开发的方法，他们监视着他们投资的开源项目，将之转换为人力，然后开始数着提交队列中的代码行数，并开始对比自己内部的开发人员的生产力，然后梦想着“社区”会发展壮大，这样他们就可以将自己的员工分配到其他项目中去了。我可以放心的告诉你，这样的事情是永远也不会发生的，除非太阳从西边出来。

开源的贡献能够提供真正有价值的内容，甚至可以完成你一些想要完成的工作，但是他不会降低你开发的成本，公司自己的开发人员能够处理公司的优先事项，并且会对公司负责，这点是非常有价值，没有哪家公司会放弃自己雇佣开发人员。

当一个开源项目成功的时候，不仅对公司有很大的价值，而且对整个社区的价值都有很大的提升，二者是成正比的。或许会出现多家公司共享核心的情况，但您自己的组织的开发投资可能会保持不变甚至增加。在这个水平上成功的项目，投资只应增加，不应减少。

在某些时候，您可能会减少对项目的投资，但这是因为某些条件使得项目对您而言不再那么有价值，而不是因为您突然获得了与以前相同的价值。这里有一个很好的经验法则，那就是：无论社区的规模大小，开源投资与收益是成正比的。

总结

一旦您的业务使用并参与到开源项目中，请务必记住：开源仅是一条路径，要明确而坚定到走下去，且要从一开始就让中层管理参与进来。谨记开源的教训：将之应用于整个流程，而不仅仅是开发部门。这条道路没有终点，需要持续的进行投入，当然这样才会有持续不断的回报。只有一直走下去，开源的战略才能凸显其功效，偶尔的失策也就不算啥事。

本文基于知识共享署名 - 共享4.0国际许可。