每家公司都应设立开源项目部门（OSPO）！

任何一家具有雄心壮志的现代公司，都应设置开源项目部，以对软件的整个生态施加影响。一家公司若是想增强自己在业界的影响力，将开源的消息放出、最大限度地发挥其项目的影响力，或者是为了提高产品的开发效率，一个全方位的开源计划是必须的。在观察了许多类似团队的运作后，我总结了成功的开源程序的六个共同特点：

1. 营销很重要。 千万不要低估牛X的营销计划和品牌战略的力量。
2. 对开源的社区和生态作战略投资。 一些社区相比之下，会更加契合企业的技术目标。
3. 拥有强大的法律顾问。 没有强大的法律顾问，无疑是置企业管理于危险的境地。当然这些法律顾问可能也会扼杀创新，所以你要准备好平衡的艺术。
4. 要和产品策略一致。 如果开源项目部对于公司的产品策略毫无帮助，无疑是白白的浪费资源。
5. 制定并传达您的最终用户和开发人员社区支持战略和指南。 你公司的任何人，若有意要参与一个现有项目的话，能够清晰的理解社区是如何运作的，并轻松入门。一定会吸引更多的人来。
6. 雇佣那些开源大拿。 那些开源的实用主义者们无处不在，但是真正具有创新精神、超前思维、低调的开源倡导者们却是非常稀有和罕见的。如果你想做到与众不同，那么雇佣他们来运营开源项目部，是非常明智的选择。

嗯，接下来，我们就来聊聊开源项目部的进化史。

何为成功的开源

回想一下，当年“开源”还是新鲜事的时候，很多人都迫切的想知道它的结果。从开发者到系统管理员，再到企业的管理层，每一个都在努力的尝试着去理解这样一个代码开放的世界。这其中当然也包括大型的软件供应商的高层、以及有风投看中的创业公司，而这些人的疑问是：这些商业模式能成为独角兽？如何在开源的大潮中获得好处？

那时，就开始有公司设立部门为他们的开源战略描绘蓝图了，最为耀眼的莫过于Google在2004的决定，尽管当年有像IBM、英特尔、Oracle等公司也纷纷设立了开源的部门，但是Google依然独树一帜。假如可以回到过去的话，我猜测他们知道开源成为主流的话一定不会设置开源的部门，毕竟，当所有人都在使用开源软件时，还需要什么开源的愿景和战略蓝图吗？

这个想法稍稍是天真了一点，但是也说明了目前的一些现状。尽管当下的开源已经是主流，非常的普及了，但是在大多数科技公司，包括创业公司，在开放源代码开发和生态系统方面，管理层仍然存在缺乏经验的现象。许多技术公司的管理层根本就不会在开源社区花费精力，他们依然对激励的策略茫然不知，更不用提许可协议那些细微的差别，至于产品和商业模式的多样，或者是开源和商业如何混搭成新的具有竞争力的产品，更是天方夜谭。很多人还依然对于开源项目的认识，停留在毋需付费就可获得软件的阶段。其中或许有一些人明白，开源可以招聘到顶级人才，即使他们也不会明白：”舍不得孩子，套不得狼” 的道理。他们也没有悟得一个道理，开源的生态系统是成员遵守规则的共同管理的系统，从而维系公平的竞争环境。

事实证明，2017年的公司设立开源项目部是前所未有的迫切！当然要理解这个部门之前，还需要了解一下开源的流程，看这个部门作为关键的核心，是如何为其它部门服务的：

• 法律：多数公司都会混合使用一些许可协议、或嵌入、或OEM第三方的工具、又或者是专利组合、以及多个商标、和版权等。这种混合的知识产权局面，就会要求规划和预期，即考虑采用公司层面上的法律框架，以平衡近期的公司利益（例如保护所述知识产权的所有权），对于开源的规划要有长期的目标。
• 营销：有一部分人认为开源计划毋需搞营销，这是大错特错的，开源是需要营销的，只是和传统的公司的营销方式有些不同罢了。
• 产品管理： 作为公司，任何东西的发布，都是产品发布，无论其是否开源，亦或是是否有直接的经济收入，所以为了更佳的确保所发布的开源产品的质量，所以要将开源通盘考虑进公司的产品组合和战略中！
• 工程：你的工程团队是否深刻理解参与开源社区的规则和要求？他们是否有法律许可来提交代码？他们是否知道第一次提交补丁，不需要一定是解决了大问题的？
• 客户支持：软件产品是需要考虑在发布后如何支持客户的，无论能否带来直接或是间接的收入。所发布的开源产品，亦需要可靠的支持模型，即使它是“自助服务”。
• 社区发展：你将如何鼓励他人参与开源社区？这和传统意义上的问答论坛是不同的，尽管问答也是整体的一个部分。什么是最佳的社区模式？你是否能够确定所到来的用户和开发者是能够感受到被欢迎的？
• 生态发展：千万不要将这条和上述几条给混淆了，你打算如何和其它的社区互动？你打算将自己的项目封闭起来？还是将之视为整个开源社区的一个不可或缺的部分？

当评估该如何执行开源的规划时，上述也不过是和其它的活动类似一样需要考虑的几件事情的列表。在你的产品组合中，开源软件愈发的重要——其实这是肯定的——所以，为了更好的确保增强公司的整体战略，并产生放大效果，请慎重考虑开源。

接下来让我们回顾一下历史，看看我们今天所掌握的最佳实践，有哪些公司趟过那些坑，然后总结出来的。

工程小组

对于开源软件来说，1998和1999这两年具有非凡的重要意义！绝对是其历史的里程碑式的年份。这主要归因于Linux的壮大，再也不是昔日“吴下阿蒙”，很多公司开始对Linux平台进行开发。典型的例子就是IBM和英特尔，他们均开始设立工程小组，从而让他们自身的平台能够运行Linux。他们之所以这么做是因为如下两个原因：

1. 更加强调他们在开发者社区的中立性，是一项非常重要的市场策略
2. 作为社区参与的直接结果，能更有效地增加现有产品的销量。

随着时间的推移，这两条渐渐演进为一种模式，企业决定那些开源项目值得去投入，然后为开源团队分配工程资源，并且和内部的产品团队携手合作。基本上发展成为：企业对开源进行持续的投入，开源团队利用工程资源，不断的为开源作出贡献和努力。

功夫不负有心人，开源团队并没有令人失望！在此取得了极大的成功！英特尔为 Linux 内核项目以及其它开源项目的贡献是有目共睹的了！ IBM 的“对Linux投入10亿美元”、“和平、爱和Linux”的营销手段也是赫赫有名，IBM除了市场活动之外，还为建立 Eclipse 社区投入很大的精力，甚至还是 Apache 软件基金会的最主要的贡献者。当然，这两家公司还对熟悉知识产权法的律师进行了良好的武装，尤其是涉及到影响开源软件的版权法和商标法。这些努力为在开源语境下更广泛地理解知识产权法铺平了道路。

但是，工程第一的方法仍然是有局限的，然而以开源计划中心的视野来看上述情形的话，依然有很多内容可以挖掘。且待我徐徐道来。

Google 的实验

让我们回到2004年，那时的开源只能说是刚刚显露出一点点优势，参与到社区的公司获得的益处还不是特别的明显，就在整个技术界对于开源的未来增长持观望态度的时候，Google 成立了开源项目部（OSPO）。

Google 不仅仅是为开源贡献代码和以及将开源应用到自己的产品中，Google 对于开源的理解走得更远一些：

1. 开发了 Google Code 代码托管平台，很多优秀的开源项目都孵化于这个平台。
2. 创建了影响深远的 Google 暑期代码开发（GSoC），这是一项为学生提供捐赠，让学生在暑假完成一些开源项目的实现。

事后看来，Google是一家创新型的公司，有着朝技术世界迈进的远见卓识，公司清楚地看到“开源影响力”是实现其目标的一条途径。而这最终体现在对于充满天分的OSPO团队成员、以及具有远见卓识的经理——Chris DiBona的信任！

可是，事实上，Google 的故事所带来的影响并没有那么的明显，甚至还让人感到灰心。即使是在Google运营开源项目部13年后的今天来看，很少有公司在开源交互等方面，能像Google在2004年所做的那样。然而，在这13年当中，Google OSPO 为整个公司所带来的回报是非常丰富的，这其中包括在开源社区广泛的影响力、代表着全球数千名开发者的美好愿望、以及时刻都在进行的招聘卓越工程师的渠道。

最后不得不提到一个人，那就是Chris DiBona，正是他的远见卓识让Google上述的成绩成为了可能，当然也要归功于Google公司对于这个人本身的信任。

开源之道

多年以来，我观察和研究过形形色色的开源项目，在衡量成功与失败方面做了很多的努力，也提出过类似最佳实践之类的方法，或者说至少什么事情不能去做。但是可以确定的一件事情是：野心和预算与最终的成功直接相关。假如你只拥有其中一项，成功的几率则会大大的折扣，如果你一项都没有，笃定会失败。但是最终上述的这些方法论，终究能够为你的公司在成功的道路上，助上一臂之力。

领导一个开源项目，需要在知识产权智慧，市场营销，创新愿望，创业精神和雄心壮志等之间付出相同的努力。这些努力通常是企业核心战略的中心——从开发者关系和社区营销，到产品开发和尖端工程。因此，领导这些工作的团队应该是聪明的，精益作业，在公司内部的多个部门都有相应的位置，甚至也许最重要的，与公司的核心战略保持一致。

开源项目部门必须是深刻理解开源的“大人物”主持（或者说：开源的实用主义是行不通的）

在前面的段落中其实已经有了明确的表达，我是非常推崇Google对待开源的方法论的。话虽然这么说，但是Google也不是尽如人意的。但是Google在开始走开源的时候就做对了一件事，那就是找到了一位渴望看到开源蓬勃发展的领导者。从这一点上来说，开源是如此的普遍，使得技术相关角色的每个人都在某种程度上参与到开源生态系统中来。但是对于开源的信徒来说，那些相信开源的方法是解决所有领域问题的终极方法的人！这些人是相对罕见的，他们才是公司需要的，为公司主持和倡导开源工作的人。

工程思维第一

要在业界产生最大的影响力，卓越的工程能力是关键。来自IBM、Intel、RedHat均提交了大量的代码，这都让他们在交付产品的速度和增加发布后的使用率占据了关键角色。IBM 在 Apache web服务器的早期就下了重注，将之纳入旗舰产品WebSpere，稍后又下注到Linux上，视其为未来的平台，即X86服务器。再后来，创建了著名的 Eclipse 基金会，则是非常成功的开源故事了，围绕Eclipse所构建的生态系统，成为开源界的佳话。Intel 也将赌注下在了Linux上，亦视其为未来的平台，包括处理器和 IoT 战略，多年以来都是Linux的主要贡献者，虽然在其它项目上相比Linux的投入少了很多，但是也算不错了，比如图形驱动、大数据（Hadoop）、存储（Ceph、CoprHD）等。更不用提红帽了，整个的产品战略都是赌定了开源软件上，红帽是Linux内核、OpenStack、以及无数的开源项目的主要贡献者。

为了尽可能的让代码贡献的影响最大化，开源部门可以做到以下几点内容：

1. 推荐最佳的生态系统让公司去投入资源，
2. 确保公司内的其他团队履行其法律义务并遵守规则，
3. 培训公司内部的其他团队以正确的姿态参与到开源社区中。

如此的话，有了开源部门卓越的领导力，这些团队可以让整个公司往正确的方向发展，确保其工程工作与其他部门保持一致。若没有开源部门的指导，公司内部的很多部门会发现他们可能做着重复的工作，甚至会出现更糟的情形，与公司内部的他人有着冲突。开源部门坐镇中央，情况则完全不一样，不仅公司的效率会得到优化，而且对于公司在开源的影响力是提升的，无论是公司内部，还是外部。

知识产权法

开源的成功，从始至终都得归功于现代知识产权法的一些概念，尤其是和商标、版权相关的，没有知识产权法，就不可能有开源的成功。开源定义本身要求软件项目的版权许可符合某些标准，才能成为正式的“开源”。因此，开源项目的成功往往还取决于优秀的律师，那些能够深刻理解开源之道和知识产权法的作用。诀窍是找到那些了解风险但不会扼杀创新的少数律师。一个强大的法律团队，能够理解许可证合规性的价值，可以清楚地传达任何特定开源活动的风险，并帮助培训公司内其他法律顾问，关于知识产权法在开源软件中的作用。

公司一旦将代码开源了，也就意味着软件的功能的决定，再也不是你一家说了算了。代码就在哪里，不增不减，所有的特性和功能对所有人开放，但公司仍然拥有一些内在的价值：

1. 品牌，受商标法管辖
2. 所有权，受版权法管辖，
3. 许可证，则决定了其他人如何与你的代码和社区进行交互。

当然，软件供应链中还有许多其他层次的价值，但往往它们并不那么明显。这个时候，公司的法律顾问的价值就体现出来了。

公司的法律顾问还可以在许可协议方面帮助我们，我们通常会花大量的时间去选择、纠结开源项目的许可协议上，但是对于希望在一个或多个软件开发领域中颇有影响的公司来说，遵从许可是特别重要的。因此，需要开源部门和法律顾问们通力合作，确保在不违反法律的情况下，还能扫掉阻碍创新的”绊脚石”。

战略联盟（不仅仅是MBA的事情）

开源项目部的另外一个非常重要的职能是产品的战略。开源项目部驱动着软件的生产效率、创新、以及在业界的影响力。这三个对象，有时候会出现不一致的情形，同一家公司不同部门，开源的战略出现不一致的情形的机会更是大大的增加。开源项目部最终是为公司的利益服务的，尽管这听起来不是那么的顺耳。在有些公司，我们可以看到在开源方面的努力会直接导致矛盾重重，给人的印象是完全没有任何的规划，还有些公司，就是限制开源，那导致的后果就是开源的工作完全是无效的。

一家公司发布了项目X，这是一个针对容器编排的非常有创意的项目，稍晚些时候，公司的其他部门又发布了项目Y，也是一个针对容器编排的非常有创意的项目。面对这种情形，一个好的开源部门团队并不是阻止这样的事情发生（虽然能够防止是最佳的解决办法），而是说假如这样的情况发生了，开源部门能够帮助公司传达一个明确的原因：为什么会发生这样的情况？为什么非如此不可？这也就意味着开源部门的团队必须和工程团队在发布代码时有非常良好的沟通。现实中有很多这样的例子，公司内的某个团队一意孤行的开源了某项目，而公司其他团队事先还不知道，造成了公司管理层和外部社区很大的困扰，最终还导致没有一个好的结果，浪费了各种资源。打破创新和混乱之间的细微关系可能很困难，但绝对值得去尝试。

再次强调一下，就战略而言，有必要将开源部门放在一个中心的位置，从而作出开源的战略！这也意味着当公司内的一个团队想将开源项目带给这个世界时，开源项目部需要资源来处理这整个过程，从而让这个团队能够在合理的时间框架内从容的发布项目。开源项目部通过坐镇中央的方式来协调，能够清晰的传达信息，确保各个团队的协作，最终的目的是让项目获得成功。

请遵循开源之道

开源项目部，或者是开源团队，如果运用得当，对于一家软件企业来说，对各个方面都会产生积极的影响，比如客户支持团队、工程部门、产品管理、业务开发、以及市场营销。以上我们提到的都是非常关键的因素，假若你仍然顾此失彼，可能还需要认清现状：开源已经是你整个业务的核心！可能连你自己都不知道。 处于中心位置的开源项目部门就是实现的途径，而能从开源中获得最大好处的做法就是—— 参与到开源中去。

预告：本文的姊妹篇《细说Google开源项目部的前世今生》下周出炉，敬请期待！

关于作者

John Mark Walker 是 Dell EMC 的产品管理总监，否则管理ViPR 控制器产品，以及CoprHD开源项目，他也是资深的开源社区活跃者，如ManageIQ、Gluster、Hyperic，乃至过去的SourceForge。

关于激进的言论，请关注他的Twitter：@johnmark，他也有领英账号：johnmarkwalker，也不定期的会更新自己的博客：johnmark.org。

John Mark 经常在各个开源技术会议上做演讲，并有优秀的论述开源的文章，如根本就不存在开源社区、永远不要搞创新、逝者如斯：写在VA Linux IPO 十年之际。

本文由作者John Mark Walker 发表在Opensource.com上：What is an open source program office? And why do you need one?。本文在Creative Commons BY-SA 4.0许可证下发布。由开源之道翻译共享，欢迎转载！