内容简介:导读:虽然开源不会消失,但商业开源厂商前途未卜。随着全面托管服务的兴起,生产支持、工具和咨询机会已经在减少。云服务提供商正在采用开源软件,并使其商业化,但却没有为开源软件提供价值或为开源软件的未来发展提供支持。关于如何为开源提供资金支持,并未达成行业共识。很多人仍然认为开源软件应该是免费的。Redis 将其部分企业模块的许可改为 Apache 2.0+ Common Clause。这些模块不能被单独用在商业版 SAAS 中。这项举措专门针对云提供商。Redis 的这一举动引发了在开源社区潜伏已久的一个问题
导读:虽然开源不会消失,但商业开源厂商前途未卜。随着全面托管服务的兴起,生产支持、 工具 和咨询机会已经在减少。云服务提供商正在采用开源软件,并使其商业化,但却没有为开源软件提供价值或为开源软件的未来发展提供支持。关于如何为开源提供资金支持,并未达成行业共识。很多人仍然认为开源软件应该是免费的。
关键要点
-
虽然开源不会消失,但商业开源厂商前途未卜。随着全面托管服务的兴起,生产支持、工具和咨询机会已经在减少。
-
云服务提供商正在采用开源软件,并使其商业化,但却没有为开源软件提供价值或为开源软件的未来发展提供支持。
-
关于如何为开源提供资金支持,并未达成行业共识。很多人仍然认为开源软件应该是免费的。
-
“开放核心”或“双重许可”等模式似乎是支持未来商业开源的最有前景的方法。
-
开源许可可能会对商业化用途强加更多的限制。
-
过去的商业开源成功案例在未来并不一定也能成功。
Redis 将其部分企业模块的许可改为 Apache 2.0+ Common Clause。这些模块不能被单独用在商业版 SAAS 中。这项举措专门针对云提供商。
Redis 的这一举动引发了在开源社区潜伏已久的一个问题。开源的最佳案例是软件基础设施,而不是软件应用程序项目。如果云计算公司成为软件基础设施提供商,他们在市场方面的控制力有可能会让他们直接基于开源项目提供软件服务,而价格却低于提供同样服务的开源公司。
如果出现这种局面,开源公司还有未来吗?
讨论小组成员
-
Paul Dix——InfluxData 创始人兼首席技术官;
-
Matt Klein——Lyft 软件工程师及 Envoy 的创建者;
-
Heather J. Meeker——O’Melveny & Myers 硅谷办事处合伙人兼 OSS Capital 投资合伙人。
InfoQ:开源软件背后的商业模式是什么?换句话说,为开源提供资金的最佳方式是什么?什么样的软件不适合开源?
Paul Dix:我认为有很多模型都可以取得成功。第一种我将其称为“开源排泄”。例如,当谷歌、微软或 Facebook 这样的大公司认为他们开发的某些软件不能成为他们的关键知识产权,他们就会将其开源。这种软件可以被认为是资产负债表上的一种负债。大规模运行业务逻辑所需的基础设施软件就是一个很好的例子。它没有为你的业务带来多大价值,但没有它却又无法运营下去。因此,大型公司就将其开源,试图让其他大公司和开发人员参与其中,以此来降低在持续改进和错误修复方面所要花费的成本。参与开源开发的公司也可以通过让组织外部的开发人员获得这些技能而受益。对于招聘渠道来说,参与开源贡献的开发者可以成为很好的人才来源。当然,对于试图基于开源基础设施软件建立业务的公司来说,这种方法并不会带来什么好兆头。
对于希望将主要收入与某些开源软件项目开发相关联的企业来说,他们的选择非常有限。我认为他们唯一可以考虑的模型是开放核心:公司开发闭源软件,给开源软件添加新的功能,然后将其作为托管 SaaS 产品或作为在企业内部部署的软件。一些 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:你唯一不能利用开源软件来做的事情就是通过销售许可来获利。但是,在开发开源软件的私营企业中,仍然有足够的手段来赚钱。你只需要知道你要卖什么,以及要免费提供什么。纯粹的开源业务非常罕见——红帽是一个非常成功的例外。纯粹的开源业务主要销售服务——通常是指维护和支持,但它也销售质量控制。客户购买的是产品,而不是许可。如果你在质量控制和包装方面投入大量精力,你就可以开展销售开源软件包的业务。但是,实际上,你是在依赖自己的声誉。大多数开源企业通过“剃刀刀片”模式的一些变体来赚钱——送他们剃刀并卖掉刀片,其中剃刀是开源软件,刀片可以有多种形式。有些是追加销售模块(通常称为开放核心),有些是额外授权(相同软件的双重许可,如 MySQL),有些是“小部件结霜”(销售运行开源软件的硬件,可能是 iOT 产品)。在其中一些模型中,你需要使用其他类型的许可,这就是 Commons Clause 等变体的用武之地。
InfoQ:开源软件是否只对企业开发人员有意义,云供应商和开源供应商是否有办法在一起合作?
Dix:可能有,但取决于云供应商。云供应商并不是一定要参与开源项目。实际上,亚马逊似乎更喜欢收集开源项目,并将其作为托管服务,但却没有付出开发努力来推动 OSS 项目向前发展。谷歌和微软有一些合作关系,但我不确定它们是什么样的。此外,当他们认为没有必要继续支持其他公司开发开源软件时会怎样?他们可以雇佣必要的开发人员来推动这些项目。他们这样做的动机是让开发者为他们的托管付费。使用开源只是一种确保其他云供应商不会围绕专有的封闭 API 构建大型开发社区的方法。这三大云供应商正在互相争斗,而 OSS 基础设施公司可能会遭遇附带损害。例如,微软和谷歌将继续推动 Kubernetes 作为标准化的云 API,因为这样可以帮助他们压制 AWS(市场领导者)并将云 API 商品化。那些试图将 Kubernetes 变成企业的创业公司会怎样?如果它像 Open Stack 生态系统一样,那些初创公司将在未来三年内全部关门大吉(尽管对 Kubernetes 的咨询仍然会充满活力)。
Klein:我不确定我是否真已经理解了这个问题。流行的 OSS 将不可避免地被企业和云供应商使用。此外,云供应商可能会提供基于流行的 OSS 而构建的托管产品,而不必为开源项目提供实质性的回馈。在我看来,更大的问题是如何为 OSS 开发提供适当的资金,可以让社区先开发开源项目,后续还能从中获取价值(通过开放核心、SaaS、服务 / 支持或某种组合)。可惜的是,人们并没有就如何做到这一点达成共识。就个人而言,我相信在未来,软件基金会必须在为关键 OSS 提供中立的家园方面发挥更大的作用。基金会的额外责任是筹集资金来资助可以保持中立的开发和维护资源,同时仍然支持企业基于它们获取利益(无论是企业、云供应商等)。
Meeker:我们正处于这样的一个分水岭,此时产生了 Commons Clause 和其他替代许可模式,是因为云供应商采用小公司的软件,并在没有增加投入的情况下让软件商业化,但没有与提供软件的公司制定任何协议来支持软件的开发。至少,这是大多数开发人员在对开源模型感到沮丧时表达的痛点。一方面他们需要保持开放,一方面要付钱给他们的开发人员,其中一些正在流失资源。我认为,在可预见的未来,可直接用于云部署的企业软件供应商会对在开源许可下发布代码持谨慎态度。我希望我们会在云供应商和企业开发人员之间看到更多商业交易,因此可以分摊开发成本。至少,这将是最合理的一种结果。
InfoQ:谷歌、Netflix 或其他公司发布的开源项目是否会增强开源投入,还是他们有混合动机?
Dix:我认为这两者都有。让大型组织在自由许可下公开代码对所有人来说都有好处。但是,可以肯定地说,除了改善自由软件的状态之外,他们可能还有其他动机。这意味着你必须心里有数,即他们的项目目标可能并不总是与你的目标一致,无论开源项目如何管理,这一点都不会变。只要软件处于开放状态,如果企业赞助商的想法与你认为项目应该去的地方不同,你就有选择权。
Klein:没有哪个公司会仅仅出于善意而做任何事情。一般大型公司会出于多种原因发布 OSS。最重要的可能是为了招聘和可见性以及构建最终与云业务相关联的平台。这并不是说谷歌、Netflix 等公司发布的软件对行业没有产生深远的影响。它们当然有,但关键是要注意这些公司直接资助 OSS 开发的不可告人的动机。
Meeker:我认为结果比动机更重要。我认为大多数开发人员会说这些公司和其他公司发布的开源代码非常有用。私营公司有法律义务通过做出适合其业务的决策来管理其股东的资本。但这并不意味着帮助社区的行动会不利于企业自身。如今很多大公司都发现,参与开源社区对他们的业务来说非常有帮助。企业可以战略性地对能够为他们提供市场优势的开发技术加以保密,对于其他的可以放开访问。从经济意义上讲,有些软件最适合作为公共产品使用,有些软件在保密时最有效。道路可以共享,但可以出售在其上跑动的汽车。否则的话,就会出现不连通的道路和糟糕的汽车。
InfoQ:在未来,对于开源公司来说,有哪些可行的许可模式?
Dix:对于那些主要在他们拥有的开源项目上开展业务的公司来说,他们要么使用像 AGPL 这样的限制性许可,要么保持一部分闭源软件,作为基于自由许可的开源核心的补充。我更喜欢后一种模式,因为对于开源的代码,任何人都可以用它做任何他们想做的事情。他们可以使用它建立业务,将其作为产品的一部分发布。我更喜欢像 MIT 和 Apache 2 这样的自由许可协议。然后,公司还有闭源软件,以补充或增强开源项目的功能,这也这是他们的商业产品。事实上,没有什么能阻止其他公司围绕同一个开源项目创建闭源产品。
Klein:我认为,我们将继续看到公司试图以各种不同的方式从 OSS 中榨取价值。我认为最成功的模式将是我称之为“松散开放核心”的模式。我们的想法是建立一个开放的核心生态系统,其中主要的软件可以通过社区来驱动,而不必通过拒绝采用可与付费产品相竞争的补丁来疏远潜在的贡献者。这个模型中的企业附加组件可能包括 UI、审计、安全工具等,基本上就是任何可以使用开放 API 在核心 OSS 之上构建的东西。
Meeker:我想我们会看到很多变体。我认为,差异在于非开源许可将变得更加标准化。现在,它们几乎完全是临时性的,这对每个人来说都是净成本。
InfoQ:从现在起的十到二十年之内,你认为软件的开发方式会变成什么样?
Dix:它将继续是闭源和开源的混合体。我认为它不会像现在这样来回摆动。它不会完全公开,因为公司仍然需要客户有令人信服的购买理由,支持和咨询的经济效益不会发生改变。因此,公司将继续拥有闭源软件来获取价值。运营自有数据中心的公司的比例将显著降低,但由于规模经济的存在,仍然会有公司自有数据中心。
Klein:可能与今天的情况不会有太大不同。大多数基础设施软件将是 OSS,而大多数消费者系统将是专有的。基础设施方面的一个重要问题是,主要云供应商是否会“吃掉世界”,或者独立公司是否可以围绕 OSS 开辟出可行的收入模式。在我看来,那些专注于“松散开放核心”模式的公司将在云竞争中做得最好。这是因为很多增值服务仍然可以在基本云 SaaS 产品之上运行。
Meeker:20 多年前我开始编程,当时和今天之间的区别有几个方面。首先,我们有更好的开发工具,因此人们在开发应用程序时可以避免一些低级任务的单调乏味。其次,编码模块化程度更高,因此不需要重新发明轮子。第三,软件是协同开发的,这是因为我们现在有了很好的协作工具。我预计接下来的 20 年将会遵循相同的轨迹,更多代码将自动化或标准化,甚至由计算机编写,允许人类 程序员 专注于更高级别的用户功能。此外,我希望能够更加强调用户互动的质量。我想现在我们的 UI 专家太少了。软件应该是可用的,但不仅仅是功能性的。
结论
开源不会消失,问题是,基于开源开发的公司能否继续蓬勃发展?
如果要继续进行重要的开源开发,就需要创建新的许可和融资模式。
关于讨论小组成员
Matt Klein是 Lyft 的软件工程师,也是 Envoy 的创始人。他一直致力于操作系统、虚拟化、分布式系统、网络以及使系统在各种公司中易于操作。他领导了 Twitter 的 L7 边缘代理的开发,并基于亚马逊 EC2 开发高性能计算和网络。
Paul Dix是 InfluxDB 的创建者。他为初创公司、大型公司以及微软、谷歌、迈克菲、汤森路透和空军太空司令部等组织开发软件。他是 Addison Wesley 数据和分析系列书籍和视频的编辑。2010 年,Dix 为 Addison Wesley 撰写了”Service Oriented Design with Ruby and Rails”一书。2009 年,他开办了 NYC 机器学习工作坊,现在有超过 12,000 名会员。Dix 拥有哥伦比亚大学计算机科学学位。
Heather J. Meeker是 O’Melveny & Myers 硅谷办事处合伙人和 OSS Capital 投资组合合伙人。她就技术交易和知识产权事宜为客户提供咨询。她是开源软件许可方面的国际知名专家。她于 2016 年获得加利福尼亚州酒吧知识产权部门的私人业务知识产权先锋奖。她的最新著作“Open Source for Business”是一本面向律师、工程师和商业人士的有关开源许可协议的权威手册。Meeker 还是美国人法律学会正在进行的一项关于重述版权法的项目的顾问。
查看英文原文:
https://www.infoq.com/articles/will-cloud-computing-kill-open-source
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Chrome:杀死 URL
- Red Hat 杀死 KDE !
- GIL 已经被杀死了么?
- python – 如何杀死所有uwsgi实例
- Google 谈论杀死 URL 的第一步
- 甲骨文如何杀死 Java EE
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Head First Servlets & JSP(中文版)
(美)巴萨姆、(美)塞若、(美)贝茨 / 苏钰函、林剑 / 中国电力出版社 / 2006-10 / 98.00元
《Head First Servlets·JSP》(中文版)结合SCWCD考试大纲讲述了关于如何编写servlets和JSP代码,如何使用JSP表达式语言,如何部署Web应用,如何开发定制标记,以及会话状态、包装器、过滤器、企业设计模式等方面的知识,以一种轻松、幽默而又形象的方式让你了解、掌握servlets和JSP,并将其运用到你的项目中去。《Head First Servlets·JSP》(中......一起来看看 《Head First Servlets & JSP(中文版)》 这本书的介绍吧!
JS 压缩/解压工具
在线压缩/解压 JS 代码
RGB转16进制工具
RGB HEX 互转工具