我在今年4月18日写了一篇专栏文章，在文中质疑我们是不是果真需要CloudStack这个开源云计算项目;CloudStack的拥护者口口声称，它比另一个项目OpenStack更胜一筹。我打上问号的地方是，CloudStack的拥趸们表示CloudStack是最佳的，因为它与亚马逊的云计算基础设施之间的兼容性最好。
我当时引用思杰系统公司副总裁兼云计算平台总经理Sameer Dholakia的话说：“可以说，是否与亚马逊的基础设施兼容是检验云计算项目成功与否的试金石，而CloudStack具有这种兼容性。”随后，《CloudStack与OpenStack之争甚嚣尘上》这篇文章奋力驳斥，搬出了CloudScaling公司首席技术官Randy Bias的一套观点，他认为OpenStack在这一方面同样与亚马逊基础设施兼容。他表示，从API(应用编程接口)方面来看，Eucalyptus Systems等其他开放源代码可能与亚马逊平台之间拥有更佳的兼容性，对此我表示同意。
自那以后，老相识Peder Ulander就跟我打招呼，说要聊一聊。他之前在Sun微系统公司任职高级营销副总裁。Ulander任职Cloud.com的首席营销官后，实际上成了CloudStack的代言人，Cloud.com在去年7月被思杰收购。两者的争论开始进入这个阶段时，他和CloudStack团队的成员远在亚洲。等他回来后，他表示有番话想说。
Ulander开门见山地指出，思杰高管Dholakia今年2月在圣克克拉召开的CloudConnect大会上主动表示，将把CloudStack代码移交给OpenStack项目，但是OpenStack项目负责人给出的态度却很冷淡。John Engates是Rackspace公司的首席技术官，也是OpenStack项目的组织者之一，他当时与Dholakia在同一个专门小组，对此举不屑一顾;不管你怎么描述其态度，反正绝不是来一个热烈的拥抱。
毫无疑问，Dholakia的举动多少有点哗众取宠。他知道，CloudStack是从OpenStack分立出来的;OpenStack开发人员不希望沿着CloudStack已经走过的同一条道路前进。OpenStack开发人员在图谋自己的计划。不过，Dholakia的这番姿态的确表明了愿意合作，早在思杰把代码移交给Apache软件基金会，组建第二个、有些人说是竞争性的开源项目之前就表露了这番姿态。
Ulander表示，CloudStack“是由Cloud.com从头开始设计的，旨在类似亚马逊”，作为一项云服务来运行，尽管这并不意味着严格意义上的兼容。目的在于，让众多企业和服务提供商有办法来构建易于创建的云服务，以便与亚马逊的云服务协同运行，采用一种相似的架构。
CloudStack为GoDaddy、英国电信(BT)、日本电报电话公司(NTT)、塔塔集团(Tata)、韩国电信、IDC Frontier、LogicWorks、DataPipe以及另外22家客户所使用的服务充当着基础，这些客户大多已在实际应用中表明了基于CloudStack的服务如何可以与亚马逊的弹性计算云(EC2)协同运行。比如说，CloudStack中的CloudBridge转换工具明白亚马逊网络服务公司的API，并且把它们转换成能够被CloudStack架构识别的格式。如果你在基于CloudStack的私有云中用光了存储资源，就可以求助于亚马逊的简单存储服务(S3)云存储服务。
Ulander说：“我们仔细查看客户的优先项目清单时，发现有两项脱颖而出：构建的系统既要有可扩展性，又能够与亚马逊平台兼容。”这正是VMOps的开发人员重点关注的方面;VMOps是Cloud.com的前身，在2010年5月之前一直藉藉无名。
Dholakia、Ulander及其他CloudStack支持者不愿意自己被认为是破坏统一阵线的角色，建立亚马逊、VMware、微软及其他专有云服务提供商之外的开源替代方案。他们其实不是这种角色，只是在支持自己的计划。
但是Apache启动CloudStack项目让人引起怀疑的地方是这个说法：它是一套切实可行的代码库，将来可以在此基础上运行私有云/公共云混合环境。有望运行混合环境是私有云构建者作出决策的关键。没有哪个项目完全有权接过这一衣钵。
云计算大有潜力;从理论上来说，市场上有地方让两个开源项目和谐共存。但实际上，两个目标相似的开源项目往往不能无限期地共存下去。在某个时候，大部分开源开发人员会认定其中一个项目没有带来新的、不同的成果，因而把精力转向别处。比如说，由于JBoss应用服务器项目内部问题滋生出来，持不同意见的人把自己的人才带到别处，最终在Apache下面创办了Geronimo 项目。但由于JBoss团结一致，加上Geronimo项目缺乏开发人才，这才使得Geronimo无法将成果推向市场。同样，虽然类似Java的项目Harmony吸引来了优秀的人才，但是当Sun不愿公开Java的开放源代码后，它也就失去了推动力。
Ulander说不用担心，思杰愿意加大在CloudStack开发方面的投入力度，而且已经在CloudStack用户和服务之间拥有比OpenStack的管理接口更成熟的一种管理接口。
大致说来，Ulander所持的观点是，CloudStack和OpenStack大不一样，所以市场上容得下不止一种开源项目。现在思杰想要做得更好的就是，通过Apache基金会来开发一款核心产品，比如CloudStack开放源代码。Ulander表示，说白了，这不是CloudStack与OpenStack之争，而是思杰提供一种开源解决方案，为用户提供“庞大专有解决方案”(主要指拥有vCloud产品系列的VMware)之外的选择。思杰这家虚拟化技术厂商的一个竞争手段就是，通过低价策略，跟越来越多与VMware兼容的公共云平台抢生意，这些平台包括软银(SoftBank)、新加坡电信公司(Singtel)、Colt、Terremark和BlueLock。
但不管怎样，CloudStack还没有吸引来像OpenStack这么广泛的支持社区，这点无可争议。会不会是这个缘故：思杰与本身也在开展云计算项目的微软建立密切联系先促使惠普，后促使IBM和红帽下定决心、加盟OpenStack阵营?
Ulander指出，思杰将其由50个合作伙伴组成的自家社区带到了Apache旗下的CloudStack项目，这些合作伙伴包括英特尔、阿尔卡特-朗迅、瞻博和博科。
情况也许是这样，但是思杰在交给Apache软件基金会的提案中承认，大多数CloudStack代码来自现在是思杰开发人员的Cloud.com开发人员。那些重要开发人员中有两人已离职。思杰提到了外面的30位代码贡献者，但是这个数字与几个主要的、蓬勃发展的开源项目相比根本不值一提，它们每次发布的版本背后就有数百位代码贡献者。
提案声称：“大多数现有的代码贡献者是收费的代码贡献者，受雇于思杰。在过去的六个月间，CloudStack得到了非思杰员工的数次贡献……。”CloudStack在向Apache提交之前名义上是开源项目，但实际上是由思杰领导，并由思杰出钱的一个项目。Apache的产品质量许可证(Good Housekeeping seal of approval)也许会改变这种情况。但最后还是要看是不是有众多公司在以积极评审代码、修正版和贡献代码等方式，积极支持项目。
不管是什么原因，OpenStack都在这种支持方面迅速获得足够的人气。其最新成员包括红帽和IBM两大资深的开源项目支持者。除了Nebula、CloudScaling和Piston等云计算新兴公司外，OpenStack还早已得到了思科系统、英特尔、AMD、美国宇航局和戴尔的支持;总共有165家公司是社区成员。在贡献者这个关键的衡量尺度方面，OpenStack胜过CloudStack。
分析代码提交者服务器日志文件后发现，OpenStack最新版背后有226位贡献者。Rackspace、Piston和Nebula的大名赫然在列，这些公司都拥有OpenStack产品，而惠普、红帽和思杰本身也赫然在列。来自思科系统、SUSE、Canonical和Dreamhost的开发人员也贡献了代码。
所以，我们在一个广泛的领域有两个开源项目;这没有什么坏处。我只想提醒一下：在以前诸项目相互竞争的情况下，早期的主导性项目从长远来看往往成为全面主导的角色，只要它周围的社区得到持续下去。JBoss项目压倒了Geronimo项目;Sun将Java作为开源项目发布后，Harmony项目基本上也就失去了存在的理由。
我希望OpenStack和CloudStack都能不断发展，实现不一样的目的，各自获得一样好的声誉，而且经营着独立社区，为云计算构建者提供选择。我希望如此，但我没有押宝哪一方会胜出。
http://www.informationweek.com/news/cloud-computing/infrastructure/232901422?queryText=citrix
