开源将成为SDN最大的风险！

  在软件定义网络、云计算、SaaS及计算机网络几个相关领域中，Matthew Palmer拥有20年以上的工作经验。Matthew现为Wiretap Ventures风投合伙人，负责为云服务供应商及软件定义网络公司提供管理、市场及产品咨询服务。同时，Matthew还是Pareto Networks的联合创始人兼CEO，当下该公司已被Aerohive Networks收购。 近日，Matthew在SDN Central上发表了对开源之于SDN的看法，他认为，对于SDN来说，开源是最大的风险。以下为译文：

  在向大型企业、服务提供商、网络提供商和软件开发者就他们的SDN计划提供咨询服务时，我们经常被问到是采用开源 商业模式还是加入到某一开源的SDN生态系统中去。“正确”答案取决于很多因素，且因公司情况而异，这些因素有：机构的近期及长期目标、市场地位，以及从长远来看，SDN的战略和市场意义究竟孰轻孰重。

  我们强调的是，在决定是不是为某一开源解决方案投资前——本着为客户和合作伙伴创造价值的立场出发，弄清楚可替代方案的可行性以及该方案的优缺点很重要。

  为客户创造价值

  客户价值创造是指在生态系统中为终端用户创造价值;比如提供新功能或者为现有的流程或系统接入开源技术。

  一个项目要能为客户创造价值，往往需要具备以下特点：a) 开源项目管理上要稳定、透明;稳定的生态系统;b) 功能符合预期; c) 整合到现有的IT环境中;d) 提供解决方案(例如当用户纠结不知所措的时候);e) 广阔的开发者社区(以避免缺乏开发力量，针对特定的需求，能够找到对口的开发人员)。

  为合作伙伴创造价值

  合作伙伴价值创造是指在生态系统中为某一特定的生态系统的支持者创造价值，比如为开源项目增加功能或者插件。

  一个项目要能为合作伙伴创造价值，往往需要具备以下特点：a) 开源项目管理上要稳定、透明;稳定的生态系统;b) 充足的势头以吸引新用户/客户采用合作伙伴的解决方案; c) 广阔的开发者社区(比如有大量的开发者供雇佣);d) 对开发者而言，开源软件能够降低他们开发软件的工作量;e) 开源项目不会与希望使用该开源软件的合作伙伴产生竞争关系。

  三种开源生态系统

  在开源力量驱动的生态系统里，你得首先要理解开源生态系统的结构，才能搞清楚如何创造客户价值，又是怎样才能为合作伙伴创造价值。简单归纳下，主要的开源生态系统有以下三类：

  松散型项目和由组织机构管理的项目

  通常来讲，最具影响力的开源项目常由某组织负责，但是一开始的时候往往呈现为松散型项目。随着开发者社区的成长壮大，开源项目的客户价值逐渐清晰起来，合作伙伴的参与规则(开源软件各部件能否拿来卖钱)日趋健全，松散型项目常会演变为组织机构管理型。组织机构管理的开源项目有个特色，它们能够支持一些生存在同一生态系统的靠创业资本存活的企业。

  由厂商控制的项目

  若一个厂商直接(员工参与)或间接(招募合同工、教授推荐学生参与、很大程度上依靠厂商提供资金支持的半自治组织)对某一开源项目的贡献率在50%以上的话，这样的项目被称为由厂商控制的项目。该厂商通常是商业公司。此外，主导开源项目的厂商——需要寻找商业模式——形式可能有以下几种: a) 支持服务(像Red Hat对Linux提供的支持);b)向用户兜售开源软件的商业版(比如带Floodlight Controller功能的Big Switch);c) 在开源软件的基础上开发新的应用(带防火墙并为Floodlight增加CircuitPusher的Big Switch)。

  厂商控制的开源生态系统很少能转变为组织机构管理型的，原因在于，厂商限制了开发社区的多样性，减少了开发者在该社区外锤炼其他技能的机会。 对于SDN社区，这意味着什么呢?

  当前SDN开源社区主要由厂商控制

  如果我们来看看当下最为流行的SDN开源项目，我们将会发现它们大都由厂商控制：

  Floodlight：Big Switch

  Indigo：Big Switch

  LINC：InfoBlox

  Open vSwitch： Nicira (现在属于VMware公司的)(请见我们关于Open vSwitch的介绍)

  Trema：NEC

  例如——即使OpenFlow由开放网络基金会(ONF)驱动——然而如今ONF不再开发或维护任何软件——这就使得ONF不得不依赖于厂商控制的开源项目。

  SDN 开源：商业化道路上的潜在危险

  对那些跃跃欲试的SDN创业公司、网络或虚拟化厂商、程序员甚至是客户而言，将由厂商支配的开源项目抬高到战略高度并进行投资无疑是一种冒险行为，原因在于：

  1. 参与规则是由厂商一方设定的，在用户不知情下，厂商可随意更改。

  2. 生态系统中某一不太友好的公司收购了开源项目的主导厂商将使得整个生态系统面临着商业化的风险(比如Oracle从Sun手中获得MySQL、Java，VMware从Nicira手中获得SDN 的Open vSwitch)。收购后，这些公司就可以“为所欲为”：他们可以在未来版本中修改许可证条例，以消极接受来自第三方的新功能或新标准。

  3. 商业模式总是对处于支配地位的厂商有利——从定义来看，厂商控制的开源项目使得处于支配地位的厂商从生态系统中能得到最多好处。他们还有能力修改对他们不利的规则，从而严重影响到生态系统中其他成员的利益。支持由其他厂商控制的开源项目的公司融资有难度，这就是其中一个原因——一个公司若依赖于在早期就可能成为自己对手的公司，风投还敢投资吗?厂商常用的“伎俩”就是一旦第三方开发的应用吸引了大量用户之后，他们就可以鼓励开发者只为自己的项目开发应用。

  该风险对客户(被比常见的商业许可证更苛刻的规则所绑架)和合作伙伴(被排挤在外，预期收入不明朗)同样存在。可是，如果该应用有很多替代品，客户面临的风险就会降低。举例来讲，SNORT由SourceFire主导开发的，但是SNORT有很多替代产品，比如生态系统相对较小的IDS。

  厂商支配的开源项目对合作伙伴的风险更大——特别是决策环节不透明;缺乏外部社区支持和当前项目的主导者可能被会你的竞争对手收购。不要忘记MySQL被Oracle揽到麾下这个事实。

  SDN最大的风险：Floodlight 和 Indigo 广阔的客户基础和合作伙伴

  为了证明上面提到的几点，我们拿Floodlight 和Indigo举例(你可以把下面的推理用到任何由厂商控制的开源项目上)。现在我们知道Foodlight和Indigo用户基础好、合作伙伴多，如果我在Cisco开发团队里并且了解到：a) Foodlight和Indigo 开源项目由Big Switch主导;b) 该项目聚集了这个领域最为出色的开发者;c) 力图说服Cisco的竞争对手使用Floodlight 和Indigo 作为SDN策略;d) 代码与ONF所依赖的OpenFlow的参考实现走得很近——我可以轻易地以10亿美元的费用从John Chambers手里收购Big Switch，使它成为onePK的一部分。我这样做很可能就会扼杀掉OpenFlow以及其他任何新兴的SDN标准——将Cisco安装平台和渠道与由Floodlight控制的平台可编程方法结合，Cisco就能在一夜之间赢得SDN的大半壁江山。

  这也就是为什么厂商控制的开源项目对客户和合作伙伴来说可能会带来灾难。你煞费苦心助其成长的那家酷毙了的公司一旦被你的客户或对手收购，红利将不复存在，要么是你被厂商束缚，要么就成为悬在你头上的达摩斯之剑。

  结论

  我们在SDN市场上面对的问题是非常微妙的——随着在SDN项目中使用越来越多的由厂商控制的开源项目，这将给该生态圈的用户带来更大的风险，也就是说帮助SDN迈出第一步的开源软件有可能汇成消灭市场机会的一股暗流。

  如果你是客户，又恰好遇到一个这样颇费些谋略才能解决的问题——使用由厂商提供的开源软件是个明智的选择，它能帮你迅速地开始，你可以尽情地实验。如果你的问题牵扯到你的商业决策 ——那就请你留心其他方案，比如那些由众多自由开发者参与的项目 ——同时你也得考虑避免将厂商纳入到你的供应链商业模型中，从而还需要为他们支付使用费用。

  如果你是某一由厂商控制的开源项目的合作伙伴，谨慎地与厂商搞好关系。如果客户需要你提供授权，权宜之计是先让合作伙伴提供解决方案，同时加紧购买授权或开发你自己的软件。你得清楚如果开源项目很成功——你的对手很可能会吞并你所依赖的开源生态系统。

  如果你是ONF，请提早创建OpenFlow的参考实现，亡羊补牢，为时未晚——请参考我们关于LibOF的一些想法。

  如果你是Cisco，你还没有关注Big Switch，我会感到惊讶的。如果你是Cisco或VMware之外的一家大网络或虚拟化厂商，市场还是一片蓝海，到处都是机遇，请提早关注多种替代方案。

  最后，如何参与由厂商控制的开源项目以及参与到什么层次，可能不是轻易就能确定的。一条路不能走到底。今天适合你的，可能明天就不行了。对你的竞争者也是同样的道理。不论何时，都请记住要为客户创造价值，如果你选择参与由厂商控制的开源项目，也请你准备好备用方案。