| 开源、闭源软件、云计算......开源使用效果最好的地方是软件基础设施，而不是应用软件项目。如果云计算公司成为软件的基础设施提供商，它们的市场控制力可能让它们得以接管开源项目，并以低于销售开源服务的公司的价格销售这些软件服务。若真如此，开源公司还有未来吗？ |
本文转载云头条，原作者：Michael Stiefel是Reliable Software公司的负责人，是一名软件架构和开发顾问。
虽然开源开发不会消失，但商业开源厂商的未来不是很有希望。随着全面管理的服务大行其道，生产支持、工具和咨询等方面的机会已随之减少。
云提供商在采用开源软件，并使其商业化，但未必增添价值或支持未来开发。
业界对于为开源开发提供资金的最佳方式缺乏共识。许多人仍然认为，开源软件应该是免费的。
“开放核心”或“双重许可”等模式似乎是支持未来商业开源的最有前景的方法。
开源许可可能会在商业使用方面变得更有限制性。
无法保证将来会复制过去的商业开源成功案例。
Redis已将部分企业模块的许可方式改为采用Apache 2.0+ Common Clause许可证。这些模块无法用作独立的商业SaaS。此举专门针对云提供商。
相关的争议引出了在开源社区已存在一段时间的问题。开源使用效果最好的地方是软件基础设施，而不是应用软件项目。如果云计算公司成为软件的基础设施提供商，它们的市场控制力可能让它们得以接管开源项目，并以低于销售开源服务的公司的价格销售这些软件服务。
专家小组成员
Paul Dix：InfluxData公司的创始人兼首席技术官。
Matt Klein：Lyft公司的软件工程师和Envoy的开发者。
Heather J. Meeker：著名律师事务所美迈斯（O’Melveny & Myers）的硅谷办事处合伙人兼OSS Capital的投资组合合伙人。
Paul Dix：我认为有很多模式可以成功。首先是我所说的“开源物尽其用”（open source exhaust）。谷歌、微软或Facebook之类的大公司就是这样，它们开发的一些软件被认为不是其关键知识产权的一部分。这种软件就好比资产负债表上的一笔负债。大规模运行业务逻辑所需的基础设施软件就是这方面的典例。它没有提供为贵公司带来价值的秘诀，但没有它你又无法运营。因此，大公司会开源，试图让其他大公司和开发商参与其中，以支付持续改进和修复错误的成本。参与的公司还可以通过让外部的开发人员学习这些技能而受益。他们是以后可招聘的后备对象。
当然，对于试图靠开源基础设施软件开展业务的任何公司来说，这种方法不是好兆头。
如果公司希望主要的收入来源与开发某个开源软件项目有关，它们的选择很有限。我认为眼下唯一经过验证的模式是开放核心：公司开发的闭源软件为开源软件补充或增加新功能，然后将其作为托管的SaaS产品或作为内部部署的企业软件来卖。一些开源软件（OSS）倡导者认为，采用这种模式的公司实际上不是开源公司。然而，我能想到的每一家采用开放核心的公司投入到OSS的预算在开发研发预算中所占的比例都比任何大企业大得多。 Elastic、Cloudera、RedisLabs、InfluxData及其他许多公司都采用开放核心，开发OSS的人员在开发团队中的比例远高于谷歌、微软、Facebook、Netflix或采用开源物尽其用模式的其他任何大公司的开发团队。
开源基础设施公司过去认为，可以靠生产支持和工具来实现创收。然而，云提供商和完全托管服务的崛起对这种模式产生了负面影响，以至于我认为这种模式不可行。更多的证据表明云在继续影响开源基础设施，MongoDB最近宣布改变许可证就是个佐证。
最后，可以靠服务和支持来开展业务。这是为OSS开发提供资金的最低效方法。其创收方式如同一家咨询机构，不过如果你打造一个咨询团队，希望他们的计费工时有很高比例。这直接有悖于让你的团队开发OSS软件。如果他们在开发OSS，并不按时计费。任何咨询机构选择一个已经大受欢迎的OSS项目并提供咨询服务会更好。
最后一种方法是借助志愿者社区的免费工作。这对大型基础设施项目不起作用。随着项目日益受欢迎和复杂化，管理和激励在晚上和周末工作的志愿者团队变得非常困难。该模式适用于开发后基本上可以标记为已完成的小型代码库。大项目需要某种赞助，才能存活下来并向前发展。
Matt Klein：已尝试过诸多商业模式。它们都归结为下列模式的某种变体（以下是简单描述）：
开放核心：软件的一部分是OSS，软件的一部分在付费墙后面。
SaaS：代表客户将OSS作为服务来运行。
服务/咨询/支持：对客户使用OSS所需要的各种辅助支持和开发收费。
一些商业模式结合了上述方法，所有上述模式都不乏成功案例。
实际上没有为OSS开发提供资金的“最佳方式”，因为有效的方式通常依赖具体项目。遗憾的是，无论采用哪种方法，靠OSS实现创收并非易事，因为许多用户从根本上认为OSS应该是免费的。哪些类型的软件开发根本不适合OSS？首先想到的就是代码库。一些库对现代系统来说绝对至关重要，但靠OSS库使用实现创收极其困难。比如说，多年来OpenSSL方面没有投入开发和资源，导致整套关键的互联网基础设施建立在一款维护不善又很基础的软件上。
Heather J. Meeker：开源软件方面唯一不能做的就是销售许可证来利用它。但是在开发开源软件的私营企业中，仍有足够的空间来赚钱。你完全要知道自己在卖什么、送什么。纯粹的开源公司很罕见，大获成功的Red Hat是个例外。纯粹的开源公司销售服务，主要是维护和支持，但也销售质量控制。客户买的是产品，而不是许可证。如果你在质量控制和包装方面投入大量精力，可以造就一家销售开源软件包的公司。但那样的话，实际上你销售的是对你声誉的依赖。大多数开源公司以“剃刀刀片”模式的某种变体来赚钱：给他们剃刀，向他们卖刀片。剃刀是开源软件，刀片有多种形式。一些是向上销售的模块（常常名为开放核心），一些是替代权利（相同软件的双重许可，比如MySQL），一些是“widget frosting”（销售在开源上运行的硬件，比如可能是iOT产品），还有一些是推先体验（一种在公开发布代码之前销售体验代码这种服务的“禁运”模式）。在其中几种模式中，你需要使用其他类型的许可证，这时候Commons Clause之类的替代许可证有了用武之地。
Dix：可能有，但这取决于云供应商。并不要求云供应商非要搞开源项目。的确，亚马逊似乎满足于拿来现成的开源项目，将其作为托管服务来提供，没有商业安排或开发工作来推动OSS项目向前发展。谷歌和微软有一些合作，但我不确定这种合作是什么样子。此外，如果它们认为没必要继续支持其他公司开发开源，会发生什么？它们可以轻松雇用推动这些项目发展所需要的所有开发人员。它们这么做的动机是，让开发人员为托管服务付费。围绕开源构建代码只是确保另外的一家云提供商无法围绕专有的封闭API来构建庞大开发社区的一种方法。三大云供应商正在你争我斗，OSS基础设施公司可能到头来是间接受害者。比如说，微软和谷歌将继续推动Kubernetes发展，作为标准化的云API，因为Kubernetes帮助它们将市场领头羊AWS拉下宝座，使云API实现商品化。那些试图将Kubernetes变成业务的初创公司会怎样？如果Kubernetes像OpenStack生态系统一样发挥作用，那些初创公司会在未来三年内全部关门大吉（不过Kubernetes咨询业务会蓬勃发展）。
Kelin：我不确信自己完全理解这个问题。流行的OSS将不可避免地被企业和云供应商使用。此外，云供应商可能会提供基于流行的OSS而建的托管产品，却未必对该项目给予重大的回馈。在我看来，更大的问题是如何合理地为OSS开发提供资金，带来社区优先的开发模式，同时仍可以从中获取价值（通过开放核心、SaaS、服务/支持或某种组合）。遗憾的是，如何做到这一点方面还没有达成共识。我个人认为，将来，众多软件基金会要在为关键的OSS提供中立的家园方面发挥更大的作用。基金会另外的责任是筹集资金，为开发和维护资源提供资金，在保持中立的同时，仍然支持靠开源获取商业利益（无论是企业还是云等）。
Meeker：我们经历的分水岭时刻就是云提供商采用小公司的软件，不增添重大价值就将软件投入商业市场，但又没有与支持开发的那家公司达成任何安排，这个分水岭时刻导致了Commons Clause及其他替代许可模式。至少，这是大多数开发商对开源模式感到沮丧时表达的痛点。它们需要保持将门打开，付钱给开发人员，其中一些在流失资源。我认为，在可预见的未来，开发适用于未经修改的云部署的企业软件的供应商会对采用开源许可证发布代码持谨慎态度。我预计我们会看到云提供商和企业开发商有更多的商业安排，那样可以分摊开发成本。至少，这将是最经济合理的结果。
Dix：我会说两者都是。让大企业公开发布采用自由许可证的代码对大家都有好处。但可以肯定地说，除了改善世界上自由软件的现状外，它们可能还有别的动机。这意味着你心里要有准备：它们在某个项目上的目标可能并不总是与你的目标一致，但无论如何管理开源项目，情况都是如此。只要软件是开放的，如果企业赞助商偏离了你认为项目应该走的方向，你有路子可选。
Klein：没有哪家公司出于善意来做事。大公司发布OSS出于诸多原因。除了打造最终与云业务相关联的平台外，几个重要的原因是便于招聘和扩大知名度。这倒不是说谷歌和Netflix等大公司发布的软件对行业并没有深远的影响，当然有影响，但重要的是牢记为什么公司直接为OSS开发提供资金背后别有用心的动机。
Meeker：我认为结果比动机更重要。我怀疑大多数开发商会说这些公司及其他公司发布的开源代码大有益处。但那些公司做正确的事才做得很好。私营公司负有法律义务：做出对本公司来说正确的决策，监管股东们的资本。但这并不意味着帮助社区的行动也不利于自身业务。如今许多大公司发现，积极参与开源社区对业务有好处。软件访问不是零和博弈。企业可采用战略性的手段，限制别人访问自己开发的带来市场优势的技术，但可以免费发放并不带来市场优势的技术。从经济意义上讲，一些软件用作公共产品最有效，而一些软件用作专有产品最有效。共享道路但销售在道路上行驶的汽车是明智之举。相反的话可能意味着互不联通的道路和糟糕的汽车。
Dix：如果公司主要靠它们拥有的一个开源项目开展业务，要么需要使用AGPL之类的限制性许可证，要么需要让闭源软件补充采用自由许可证的开源核心。我青睐后一种模式，因为对于开源代码而言，很显然谁都可以随意处理开源代码。他们可以使用开源代码，建立业务，将其作为产品的一部分来交付。我青睐MIT和Apache2之类的自由许可证用于开源。然后，公司的闭源软件补充或增强开源项目的功能。很显然，这是它们的商业产品。事实上，没有什么能阻止其他任何公司围绕同一个开源项目开发闭源产品。
Klein：我认为我们会继续看到许多公司试图以各种不同的方式从OSS获取价值。我个人认为，将来最成功的模式将是我所说的“松散开放核心”（loose open core）。其想法是，建立一个开放核心生态系统，主要的软件保持由社区驱动，没必要通过拒绝采用与收费产品竞争的补丁来疏远潜在的贡献者。采用这种模式的企业附件可能包括：用户界面（UI）、审计和安全工具等，基本上是可使用众所周知的API在核心OSS上构建的任何组件。
Meeker：我认为我们会看到诸多变化。我认为，区别就在于，非开源许可将变得更标准化。眼下，它几乎完全是临时性的，这对每个人来说都是净成本（net cost）。
Dix：继续是结合闭源和开源的方式。我认为与现在的方式不会有很大的差异。软件不会完全公开，因为公司仍需要客户有令人信服的理由来购买，支持和咨询的经济因素不会改变。因此，公司会继续让闭源软件来推动价值。自行运营数据中心的公司所占的百分比会显著降低，但由于规模经济效应，仍会有公司自行运营数据中心。
Klein：可能与今天的情况没什么大不同。大多数基础设施软件将是OSS，而大多数消费者系统将是专有系统。基础设施方面的一大问题是，各大云提供商会“吃掉世界”？还是说独立公司会围绕OSS搞出一种切实可行的收入模式？在我看来，那些专注于“松散开放核心”模式的公司会在对付云竞争方面做得最好，这是由于许多增值服务仍然可能在基本的云SaaS产品上运行。
Meeker：20多年前我开始编程，当时和现在的区别体现在几个方面。首先，开发工具更好了，因此人们在开发应用软件时可以避免一些单调乏味的低级任务。其次，代码模块化的程度大大提高了，因此不大需要重新发明轮子。开源对这第二个方面起到了助推作用。第三，软件是协同开发的，这是由于我们现在有了可以协同开发的工具。我预计，今后20年会更加遵循同样的发展轨迹；更多的代码将实现自动化或标准化，甚至由计算机编写，好让人类程序员专注于更高级的用户功能。此外，希望，用户交互的质量会受到更大程度的重视。我认为眼下，UI专家太少了。软件应该易用，而不仅仅是能用。
开源不会消失；问题是，基于开源开发的公司能否继续存活下来？
如果开源开发领域继续要有重大的发展，就需要创建新的许可模式和资助模式。