在技​​术界，总是有很多关于“开放”一词的讨论，尤其是在涉及云的时候。毕竟，没有人想被锁在“封闭”系统中，对吗?9月9日，星期一，我的朋友Datamation的执行编辑詹姆斯·马奎尔(James Maguire)主持了一场有关“开源云” 的Google Hangout，这看起来是一个有趣的活动。他有来自Eucalyptus，Red Hat，Nebula和Citrix的人都准备在视频群聊中讲话。

近年来，我在许多小组中谈论开放云，总有一个问题出现：到底什么是开放源云?

在我看来，仅使用开源技术并不能使云开放，这是我每次有人问我时都会提出的论点。我喜欢像用户一样思考，坦率地说，云(以及其他地方)中的用户通常有一个主要问题，那就是数据。

数据可移植吗?也就是说，如果我将数据存储在一个云中，是否可以将其取出并移到另一个云中?这是一个简单的问题，但在每种情况下都没有一个简单的答案。

更进一步，工作负载是否可移植?也就是说，如果我在某个云上运行应用程序工作负载，是否可以将其转移到我选择的另一个负载上(而不是仅由同一供应商运营)?

是的，开源很重要。这意味着作为用户(如果我有技能)，我可以按照自己的意愿弯曲代码，以“抓挠自己的痒”并获得所需的东西。这也意味着可以出现跨多个供应商支持的真实标准。但是，现实情况是，许多用户将需要供应商提供的完全烘焙的解决方案。以OpenStack为例。如果您在供应商(Red Hat，Rackspace，HP，SUSE，Canonical，Piston，Nebula或其他)的一个OpenStack云中运行工作负载，您是否可以以完全可互操作的方式轻松地在这些实现之间移动数据?

今天的答案是是和不是。使用OpenStack Image Service(代号为Glance)，我应该能够在一个实现上快照一个映像并将其移到另一个实现上。这是一种开放形式，而不仅仅是开放源代码。在其他情况下，用户可能需要或希望进行混合部署，以跨所有方式的实现和供应商解决方案(专有的和基于开源的)移动数据。

云消费者需要问的问题不仅仅是代码是否是开源的(我个人认为应该是开源的)。需要问的更大的问题是，解决方案是否可以互操作?如果由于某种原因没有某种解决方案，那么即使代码本身是开放的，也很可能仍然存在被锁定到解决方案中的风险。