为什么 OpenStack 与其他开源项目不同

还没有读者喜欢这篇文章。
A person holding on to clouds that look like balloons

Opensource.com

OpenStack 项目给我的感觉与其他开源项目不同。让我试着解释一下。

Henrik Ingo 几年前对开源项目规模与治理结构做了一项出色的分析。本质上,九个最大、最活跃的开源社区都扎根于非营利基金会内部。第十大开源社区比第九大社区小 10 倍,并且存在于一家公司内部。像一位优秀的工程师一样,Henrik 提供了他的数据并列出了他的假设。他并没有暗示增长是因果关系,只是存在很强的相关性。他正确地指出,当他在 2011 年夏天展示他的研究结果时,以 OpenStack 为例来看看这一切意味着什么,将会非常有趣。(他后来写了一篇出色的后续文章,比较了云项目。)

Henrik 的分析和观察预设了关于开源许可项目本身必须如何运作的某些标准。在获得基金会放大效应之前,它必须是一个“良好运行的项目”。很多人都描述了成功社区的要素。我最喜欢的包括 Dave NearyDonny BerholzKohsuke Kawaguchi。当然,还有 Jono Bacon 的重要参考。不久前,我在一篇博文中尝试捕捉并收集了成功的开源项目的模式和实践

当我们在 Outercurve 基金会担任执行董事和技术总监时,Paula Hunter 和我提供了基金会放大效应的理由。放大效应的原因可能是什么?我们认为它来自于基金会为围绕其项目的利益相关者所做的所有事情。基金会的存在是为了响应其利益相关者的要求,明确知识产权管理要求并提供知识产权风险缓解。项目社区必须从工程和治理的角度良好运行,但是一旦基金会存在,企业参与者就有了清晰的参与途径,并且对社区的投资可以大幅增长。

因此,扎实的工程实践 + 强大的社区治理 + 清晰的知识产权管理能够实现增长。目前为止一切都很好。

但是 OpenStack 作为一个开源项目有些独特。那是 2010 年。亚马逊在提供云服务方面拥有巨大的先发优势(2006 年)。Eucalyptus 是开源许可的,但由单一供应商控制(始于 2009 年)。Cloudstack 刚刚以开源许可证发布(2010 年 5 月),但仍由 Cloud.com 紧密控制。当时是中立供应商选项成熟的时机。当时的 Rackspace 首席执行官 Lew Moorman 和 NASA 首席技术官 Chris Kemp 在 OSCON 2010 上宣布了 OpenStack 的诞生。

大量供应商早期且坚定地投入到一个简单的基础设施中,以便将其快速发展为一个潜在客户市场。项目治理得以建立,人们开始聚集在峰会上。OpenStack 在两年内被正确地强制纳入一个中立的非营利基金会,以澄清知识产权所有权。(每个人都以 MySQL 为例,因为它已被 Sun Microsystems 收购(2008 年),然后被 Oracle 收购和勒索(2010 年)。)

但这就是 OpenStack 开始打破模式的地方。开始时代码相对较少。它从一开始就被创建为向前工程化。OpenStack 正在经历强制增长,其时间框架是其他大型、成功的开源许可基础设施项目的 20-25%。这项工作不是 20 年,而是在四年内变得非常庞大,已经推动了严肃的供应商主导的产品上市。

Linux 内核 Apache (httpd) gcc OpenStack
项目启动 1991 1995 1987 2010
基金会成立 2000 1999 1987* 2012
重新架构 2002 2002 1998 ???
中期代码行数 4,000,000 980,000 1,150,000 500,000
当前代码行数 17,000,000 1,700,000 6,900,000 2,300,000
中期贡献者人数 186 17 50 174
当前贡献者人数 1,000 17 94 575

注释:GCC 始于自由软件基金会;数据来自 Ohloh.net、维基百科和访谈

OpenStack 并没有像其他基础设施开源许可项目(例如 Linux、Apache)那样,在大型供应商介入之前,在简单的用例中通过实验和体验式使用而发展起来。OpenStack 继续表现出巨大的增长和参与度。随着供应商开始从各种 OpenStack 项目中开发云交付产品和服务,他们正在发现功能上的漏洞,需要他们快速创建新的 OpenStack 项目来填补这些空白。供应商也开始发现 OpenStack 本身可能无法扩展到某些行业的需求(例如,电信行业对 NFV 的需求)。同样,所有核心基础设施开源项目在其自然发展历史中都会遇到需要重置架构设计的点,以适应新用途和部署的压力。Linux、Apache 和 gcc 都曾在其历史上的某些时刻重新架构,以适应项目自然增长到新的部署和用途。

一些有趣的问题

  • OpenStack 项目核心开发人员何时集体重新架构/重构/重写核心 OpenStack 组件,以扩展到人们发现客户需要在未来 5 年内管理的真实世界工作负载?
  • OpenStack 基金会如何在竞争激烈的竞争环境中捕捉到这些消费者需求?
  • OpenStack 基金会将如何适应其供应商、用户和消费者利益相关者的需求?

开源社区是适应性极强的有机体。观察 OpenStack 作为一个项目社区和一个基金会继续成长和发展,以应对云市场的挑战,将是一件非常有趣的事情。

最初发布于 Once more unto the breach。在此通过 Creative Commons 重新发布。

标签
User profile image.
我是一名技术主管、创始人、顾问、作家、国际商务人士、系统开发人员、软件构建极客和标准外交官。我喜欢构建让客户欣喜若狂的团队和产品。自 1980 年以来,我一直在 IT 行业工作,既是客户又是供应商。

1 条评论

有人可能会说,这种情况已经在 OpenStack 中开始发生,事实上很早就开始了。有人还记得 Keystone/Keystone-light 转换 [1] 吗?还存在一个相当成熟的分解组件的趋势,以便它们可以更快地重新架构或发展:Cinder 从 Nova 中分离出来,Gantt 试图分离出 nova 调度器,Neutron 正在分离出 LBaaS/FWaaS/VPNaaS 并将其 IPAM 模块化等等。

[1] https://wiki.openstack.org/wiki/ReleaseNotes/Essex#Key_Highlights_of_the_Keystone_Transition

© . All rights reserved.