亲爱的Stacker们，
在过去的三年里，OpenStack社区弥漫着武断和不公平的定位，尤其是对于AWS和VMware。这种观点最现实的表达就是OpenStack应该建立和维护一套它自己的差异化的API。
我毫不掩饰自己的信念，那就是这一选择将伤害OpenStack，或许已经带来了伤害。现在，这个问题变得更加严峻，我希望能够说服你们支持我的观点，那就是OpenStack应该立即拥抱既定的公有云API和特性。这对于OpenStack的成功至关重要，更重要的是这样做才真正符合OpenStack的使命。
为了说服你们，我首先会介绍一下有关差异化的API集合的这段历史，然后，我们再看看为什么AWS和GCE支配公有云是不可避免的。我会揭穿围绕着有关抄袭这个公有云API的所有谎言，最后，我们将直击云计算中“创新曲线”的胡言乱语。
我们为何沦落到如此地步？
当OpenStack在2010年夏天发布的时候，在它最初的两个模块中并没有“native”API。Nova最初只提供EC2 API。该部分是由NASA贡献的，侧重于重新打造一个兼容EC2的私有云系统。Rackspace API是在EC2 API之后添加进来的，也就是在2010年那个夏天，OpenStack项目发布不久之前。
本段引用自NOVA项目[README]：You have come across a cloud computing fabric controller. It has identified itself as “Nova.” It is apparent that it maintains compatibility with the popular Amazon EC2 and S3 APIs.
请注意，在NOVA项目中没有任何描述提及过“native APIs”以及对目前的NOVA[README]的比较。
该项目的另一半Swift，使用它自己原生的API，其中一部分，也就是最初的Swift代码是来自于RackSpace的Cloud Files服务。
简单来说，OpenStack最初的“native”API，其中一半是AWS兼容的（NOVA），另一半是RackSpace公有云兼容的（Swift）。
然后，RackSpace并购了ANSO Labs ，从而实际上“拥有了”OpenStack代码另一半的贡献者。更重要的是，大多数能够决定该项目技术方向的项目团队负责人（PTLs） 都成为了RackSpace的员工。
在并购ANSO Labs的这段时间里，RackSpace的API才被更改为“nova-api”，这就是现在所谓的Nova的“native API”。 该API在很大程度上与RackSpace Cloud Servers公有云服务的API是一致的。至今这个API变动不大，并且深深的影响了这个项目的命名法则（例如，“floating IPs”与“elastic IPs”) ，并在某种程度上影响了Nova的方向。
根本没有什么所谓的“native”API。事实上，把RackSpace Cloud Servers API称为“native API”是在宣扬一个概念，有一个OpenStack Nova API是独立于Amazon API的。现在很明显，事实上最初的OpenStack native API就是它的AWS EC2 API。
我们来控制OpenStack
自2010年上述决定做出以来，OpenStack项目的管理已日趋成熟。OpenStack基金会，一个独立的组织，目前主导着OpenStack的战略和商务方向，而其开发团队的技术精英在主导该项目的发展方向。
简而言之，社区控制着该项目的方向，并且是时候主张按照符合我们的最佳利益策略来兼容公有云了，而不仅仅是由一个单一的，虽然是主要的贡献者来主导了。如果不能改变这个策略，最终很有可能会导致这个项目变得无足轻重而死去。
亚马逊主宰公共云
很明显AWS（也有可能是GCE）将完全主导公有云的竞争。但更重要的是，who cares？AWS和GCE主导并不意味着OpenStack失败。事实上，OpenStack很明显正走向“赢得”私有云的竞赛的道路上，并且快速拥抱Amazon将使得OpenStack处于主导混合云的关键位置。
在2011年二月的Cloud Connect大会上，我做过一个主题演讲，勾勒了“两个云的故事蓝图”，用数字比较了AWS和RackSpace Cloud Servers的规模和增长。在那个时候，我相信是RackSpace的年增长率给他们打了一剂强心针，使得在公有云的市场上他们被放在了AWS的死对头的位置（当时AWS年增长率是100%而RackSpace是90%）。
但在这之后的两年半的时间里，变化太大了。AWS的增长率有增无减，GCE正式加入竞赛。与此同行，RackSpace面临着增幅下滑。如果RackSpace今年Q2-Q4的盈利等同Q1，他们的公有云将从最高90%的年增长率下滑到30%，在过去几年中出现惊人的跌幅。请参阅下图，假设2013年季度财季增长保持不变。
虽然没有关于GCE的增长率的公开信息，但我相信它与AWS是持平的。客户对他们的公有云服务的兴趣是如此之高，以至于他们等待列表中的客户数量已经大于实际上大多数生产环境中的公有云客户名单数量。而他们还仍然处于内测阶段。
是什么导致RackSpace公有云的突然下滑？ 从公布的信息来看， AWS，很可能是GCE正在领跑公有云服务，并且给OpenStack社区一个显而易见的选择。
Amazon控制着公有云的创新曲线
2010年时，一些人认为标准化RackSpace公有云API将允许OpenStack控制创新曲线，而不是Amazon的创新曲线。从那时起，Amazon继续推新功能，并以惊人的速度整合到产品中。很简单，他们控制着公有云的创新曲线。AWS的竞争对手所添加的每一个公有云特性都将直接与AWS已经内置的功能进行对比。
OpenStack可以在私有云和混合云中的创新曲线中起主导作用，但这需要我们支持公有云中领先的创新曲线。OpenStack要想主导私有云和混合云的创新，它必须拥抱企业希望联合的公有云。
OpenStack可以主导混合云的未来
虽然我曾经批判了这一观点，我曾经认为私有云和公有云需要看起来一样并且互联互通，如果我们大量的采用云。现在我们看到企业客户需要混合的云解决方案：连接到公有云的私有云，这样他们就可以在两头运行工作负载，并且可以有所选择和控制，以积极推动经济和业务敏捷性。
有争议的或许是一套基于OpenStack的公有云服务是否会成为这个公式的另一半。在这一点上有这样的公有云的可能性似乎降低到了微乎其微。AWS和GCE的地位已经确立，全球影响力，快速的功能迭代和增长率奠定了他们的领先位置。有什么可以阻挡？坦率的讲，在技术雷达上已经没有竞争者。
在AWS和GCE主宰的公有云市场里，希望提供一种混合选项的私有云必须接受这些领跑者。
这一切导致一个必然的结论：OpenStack的未来必将是成为与主流的公有云兼容的混合云，这些主流的公有云就是AWS和GCE。如若其他情况出现，我们只有当他们的市场地位已经确立时才需辩论和评判。
因为类似甲骨文和谷歌在Java虚拟机与Davilik虚拟机的裁决，法庭很可能无法保护公共的API。
法律上的恐惧毫无根据
在公有云的API保护上的恐惧、不确定和怀疑完全是愚蠢的。阻止OpenStack社区复制AWS和GCE API是没有法律依据的。要牢记的是Amazon的API已经被复制了。他们有能力针对因此受到的影响而成功地采用一个新的法律措施，事实上之前他们并没有反对复制API。
整个OpenStack社区受益
拥抱Amazon符合全体社区成员的利益，把OpenStack定位成为企业和SaaS提供商的最佳选择，他们希望有这么一个公有云生态系统，这样他们的应用在任何时候都可以部署到最适合它们的基础设置中。
换句话说，如果基于OpenStack的公有云拥抱主要的公有云API，它们会受益于AWS的生态系统，它们将可以在这份大蛋糕中切到一块。同样，主机托管公司也有机会出售托管的私有云，并且是和公有云兼容的，也解决了企业的混合云问题。事实上，这可能是RackSpace梦寐以求的目标。
正是出于这个原因，RackSpace也将是我的倡议受益者。他们将处于一个特殊的位置，将能够部署私有的托管OpenStack 混合云，并且是兼容客户任何想要的公有云的混合部署方案。
现在是时候拥抱Amazon和AWS API 啦！
是该OpenStack社区做出抉择的时刻了，选择一个兼容公有云的策略将使得该项目能够主导私有云和混合云市场。
时间非常关键。AWS已经涉足提供私有AWS regions给政府（AWS GovCloud），甚至是特殊机构（CIA/NSA）。有理由推断，他们可能会扩大这项计划，必将威胁到OpenStack目前所处的机遇。
我的倡议如下：
1. 拥抱主流的公有云API，GCE、AWS、Azure，甚至vCloud ；
2. 重新命名Nova API为Rackspace Cloud Servers API；
3. 创建一个新的低级别的API并且一道桥接的API模型；
4. 展开测试和refstack周边工作 ；
5. 拥抱现有的AWS互操作性测试架构，例如Cloudscaling aws-compat和Eucalyptus eutester库。
AWS和谷歌是我们的朋友，因为他们传播和采用云计算。他们在为我们所有人“做大蛋糕”。他们共同创造一个丰富并且充满活力的公有云生态系统，OpenStack可以通过一个同样丰富和富有活力的私有云生态系统与之共舞。我希望OpenStack将能主导混合云解决方案。请帮助我使之成为现实。