我们起草了这篇报道来回答最近听到的多次被问到的问题，特别是来自于打算创建他们自己的私有云的组织机构的问题。 您是怎么比较OpendNebula和OpenStack的呢？ 这真是一个复杂的问题。因为开源项目和技术呈现出多维度，这个问题没有唯一的答案。但是我们并不会畏惧回答这个问题，简而言之，它们代表了两种不同的开源模形。OpenNebula侧重于用户的需求而OpenStack是厂商驱动的。 这并不是质疑它们哪一个更优，它们只是代表了不同的方法。让我们来基于如下的开源属性做比较：内部结构、管理模式，路标定义，贡献者概况，目标用户，产品和市场竞争力。显然这种比较是有偏颇的（无法避免），但是我们将尽可让的让它中立。 不同的开源项目模型 这个两个项目都遵照Apache2.0标准发布代码，依照公共的路线图遵照透明的开发流程，对于贡献者都是相同的许可标准。尽管如此，它们有着明显的不同，特别是以下方面：
现在的问题是： 为什么OpenNebula遵照的是“慈悲的独裁者”的管理模式？ 在我们看来，OpenStack的管理者是互相竞争的财团，他们试图创建他们自己的产品或者得对特定设备提供兼容。这种多厂商的模式增加了创建基础平台的难度，因为这个平台既要满足项目的需求又要平衡每个厂商的目标。有趣的是这些厂商同时还提供与OpenStack组件直接竞争的商业软件。 传统上讲，多厂商工业财团是长远来讲商业化核心组件的最佳途径，特别是当已经存在了基础稳定的软件，但短期内这种方式并不会从草稿产生一个完全符合企业级需求的解决方案。这种状况下增加更多的开发者和成员只会使项目进展慢下来。众所周知的Brooks法则可以适用于开发和管理阶段。OpenStack已经达到了一个峰值，基于共识的方式限制了这个项目的竞争力。 我们相信有着极强个人领导力的集中模式将会是快速构建产品已就绪的、企业级的开源产品的最佳途径，特别是在市场快速发展的初始阶段。请不要给我们打个控制欲极强的标签；我们这么做是因为我们想要创建一个伟大的产品，我们想要对整个产品负责，我们需要对我们的用户负责。“慈悲的独裁者”的模式是像Android,Linux Kernel等这些成功的开源产品所遵循的模式，在我们看来，它是关注工程质量的最有效的方法，是优先响应用户需求的最佳方法，也是长期维护项目的最佳方法。 基于以上原因，组织做出如下论述：OpenNebula是由用户创建为用户服务的，OpenStack是由厂商开发为厂商服务的。 这看起来有点像是承诺，但是我们一直信守着这一理念很多年，还没有发现什么可以证明这样做是错误的。 B 不同的云模型
虽然有多个组织打算创建云，就有多少种关于云计算的理解，但它们大部分都落入这两个极端的云计算模型：
虽然OpenStack现在正在试图让每个人都得到所需，它原来被创建出来就是做为一种开源的力量来与亚马逊的云服务（AWS）竞争的。因些，OpenStack着重关注了基础供应的部分，而OpenNebula则更好的满足了企业云计算的需求。这两个工具都支持基础云计算，它们提供的功能还是有一部分重合的。然而每个云模型都代表了不同的架构约束，需要不同的接口，管理能力和集成支持。OpenNebula和OpenStack满足了不同的需求，实现了完全不同的理念。 C 不同的产品视图OpenNebula是一个单一为企业准备的开源产品，易于安装和操作，它仅有一个安装和升级过程，一站式的社区和长期商用支持。任何组织可以使用这个开源的版本来创建产品云，并通过社区的邮件列表得到最大程度的支持。此外，任何组织可以从开发者那直接购买商用支持服务。最重要的是我们不提供商用版的软件，我们提供对于社区软件的商用支持。
另一方面，OpenStack是由许多个不同成熟度的子项目构成的，需要相当复杂的集成来获得一个功能性的云基础设施。不断增加的组件和子项目数量使得集成，协作和发布一个单一清晰的解决方案更加的困难。每个对使用OpenStack有兴趣，需要商业支持和企业的成熟度的机构都将被（负责项目的厂商）推荐布署一些企业版的产品。  从商业的角度讲，OpenNebula无法与OpenStack竞争，但是因为有了HP，Red Hat 和IBM 等许多厂商，它们都与OpenStack相关，就可以竞争了。 这些企业级的产品包括了不同版本的OpenStack组件，这些组件有着扩展的功能，客户化功能的补充和集成，这些消耗着OpenStack的兼容性和交互性。甚至于它们中的一些包括了专有组件，并且与关键的底层功能实现有着明显的差异。 因此选择了OpenStack的公司实际上使用的是基于OpenStack的专有软件，这些公司被牢牢的套在厂商提供的特定版本的软件上，且厂商仅支持的是它自己的版本而不是社区版本。更糟的是，没办法从一个厂商迁移到另一个厂商，换句话说，这些软件没有提供开源软件的总体利益：低成本，不绑定，灵活性和交互性。 |
