编写软件时，工程师们会用很多不同的方法来关注用户:例如听取用户的反馈，修正bug或添加用户呼吁的特性。由于基于网络的服务让用户能够更容易地转向新的应用，建立和维持用户的信任就变得更加重要。我们发现了一种虽然确实违反直觉，但极其有效的方法来获取并保持用户的信任，那就是让用户能容易地带着他们的数据离开你的产品。这不仅能防止锁定并获得信任，还可以迫使你的团队为获取技术优势而不断创新和竞争。我们管这叫“数据解放”。
锁定带来的问题
对软件工程师来说，从他们使用的服务中导出数据显然要比一般用户来得容易的多。如果有可用的API，我们工程师可以随便拼凑个程序来搞定。就算没有API，用屏幕截图工具也能弄到一份数据的副本。不幸的是，对大多数用户来说这并不可行，他们经常只能疑惑于到底能不能拿到自己的数据。直到最近，用户在向一个新的互联网服务中输入大量的个人数据之前，几乎都不会问是否能够把他们的数据快捷地取出来。他们更可能问这些问题：“我的朋友们也在用这个吗？” “这个可靠吗？” “提供这项服务的公司半年或一年后还存在的概率是多少？” 然而，随着用户们将越来越多的个人数据存储到无法触及的网络服务当中，他们开始意识到如果没有迁移数据的方法，他们大量的网络遗产就会有丢失的风险。将用户锁定的好处是让他们难以离开你而转投你的竞争对手。同样地，如果你的对手锁定了他们的用户，那这些用户也很难转向你的产品。尽管如此，将研发精力投入到创新上要比建立壁垒来阻止用户离开更可取。现在，让用户能更容易地试验产品会极大地提升他们对你的信任，未来也更有可能回到你的产品线来。
紧迫感
锁定用户会让公司变得并不急于创新。相反，出于商业原因，公司可能会决定延缓你们产品的开发，并把开发资源转移到其他产品上。这将使你的产品在与其他创新速率更快的公司的竞争中处于弱势地位。锁定让公司得到一个持续成功的表象，但失去了创新的支持，它实际上可能已经在走向夭折了。
如果你不想——或不能——锁定你的用户，那么参与竞争的最佳方式就是急速地创新。以Google搜索为例，这是一种无法锁定用户的产品：用户不需要安装软件，不需要上传数据，也不需要签什么合同; 如果他们想尝试其他搜索引擎，只要在浏览器中输入地址，就绝尘而去了。
Google的搜索引擎是怎么留住用户的呢？近乎执迷地专注于持续提升搜索质量。用户可以轻易地转移到其他服务这一事实已经向Google的搜索质量和排名团队灌输了一种惊人的紧迫感。在Google，我们认为如果让用户能够容易地离开我们的任何产品，对产品改进的失败就能立即反馈到工程师那里，他们则会开发更好的产品作为回应。
数据解放是什么样的
在Google，我们的态度是用户应该能够控制他们在我们的产品中存储的数据，这意味着他们能导出自己的数据。这不需要额外的金钱支出，更重要的是，不管数据总量大小，导出数据的工作量应该是一定的。分开下载一打照片不会带来多大的不便，但如果用户不得不一张一张地下载5000张照片呢？这得花上两周的时间。
如果以专有的格式存储，就算用户有了数据的副本，依然是被锁定的。一些15年前的文字处理工具生成的文档无法用现在的软件打开，就是因为它们是以专有格式保存的。所以重要的不仅是能够访问数据，还要能将其以广泛接受的标准格式存储。而且，这个标准应该有合理的许可条款：例如，对实现应当是无版权约束的。对于导出的数据，如果已经存在一种开放的格式（例如对于照片有JPEG或TIFF格式），就应该成为批量下载时的一个选择。如果产品中的数据还没有一种工业标准（比如blog就没有标准的数据格式），那么至少这种格式应该是文档公开的——要是你的产品能提供一个开源的格式转换器的参考实现就更好了。
重点在于用户对他们的数据应该有控制权，这意味着他们需要一种便捷的方式来访问数据。提供一套API或者一次下载5000张照片的能力并不完全能够让一般用户容易地导入导出数据。从用户界面的角度看，数据解放对用户来说就是一组用于导入或导出所有数据的按钮。
Google通过”数据解放前线”(Data Liberation Front)来解决这个问题，这是一个以简化Google产品的数据导入导出为目标的研发团队。数据解放的工作重点是可能阻碍用户转移到其他服务或同类产品的数据——即那些用户创建或导入的数据。这些都是用户通过直接操作而有意存储的数据——例如照片，Email，文档或广告方案——如果用户在别的地方开展业务，很可能会需要这些数据的副本。而间接产生的数据（比如日志数据）与锁定无关，因此不在任务的范围内。
另外一件数据解放不会去做的事是建立新标准：我们尽可能地让用户以现有的格式导出数据，比如在Google Docs中用户可以用OpenOffice或微软Office的格式下载文档。对于有些产品，还没有一种开放的格式能包含所有必要的信息，我们会提供计算机易读的格式，比如XML（我们使用Atom处理包含内容和评论的Blogger源），开放它的文档，并且，可能的话，提供格式转换器的参考实现（例如Google Blog Converters AppEngine项目）。我们希望提供给用户的数据格式能易于导入到其他产品中。由于Google Docs所处理的文档和电子表格始于开放的互联网兴起之前，所以我们提供了几种不同的导出格式；而对于大多数产品，我们则尽量避免陷入“要支持所有已知格式”的泥沼中。
用户的考虑
在这几种情况下，用户可能想要从你的产品中获得数据的副本：他们找到了更符合他们需求的产品，想把数据转移过去；你们宣布停止对他们正在使用的产品的支持；或者更糟的是，你做了一些失信于他们的事。
当然，用户想要一份数据的副本并不一定意味着他们要放弃你的产品。许多用户只是觉得在本地保存一份数据的备份会更安全。当我们首先“解放”Blogger时，观察到了这种情况：许多用户开始每周导出一次日志，同时还在继续使用Blogger写博客。这种情况更多地出于感性而非理性因素。用户自己电脑中的大多数数据根本没有备份，但托管的应用为了防范硬件错误和自然灾害，几乎都会在多个地点保存多份用户数据的备份。不论用户的忧虑是否理性，他们需要感到自己的数据是安全的：让你的用户信任你，这很重要。
案例分析：GOOGLE SITES
Google Sites是一款网站制作工具，可以通过浏览器进行所见即所得的编辑。在Google内部我们使用它编辑项目的页面，因为它能方便地创建和整合项目文档。2009年初我们承担了为Sites开发数据导入导出功能的工作。
在设计之初，我们需要决定Google Site应该使用什么样的外部文件格式。考虑到Sites提供的功能是协作创建网站，我们觉得要实现真正的解放，最适合的格式是XHTML。作为网页的开发语言，HTML也是网站最轻便的存储格式：只需要把XHTML页面放到你自己的网络服务器上，或者把它们上传到网络服务提供商那里。我们希望确保这种形式的数据可移动性能尽可能地简单，同时尽可能地减少数据损失。
Sites用它内部的数据格式封装一个网站中存储的所有数据，包括对所有页面的修改。解放这些数据的第一步是创建一套Google Data API。一个网站的完整导出由应用Google Sites Data API的开源Java客户端工具提供，并且将数据转换为一组XHTML页面的集合。
与其他Google Data API相同，Google Sites Data API也是基于AtomPub标准开发的。它支持以Atom文档作为线上传输格式对Google Sites进行RPC（远程过程控制）式的程序化的访问。数据可以很容易地封装为Atom的形式，因此在Google Sites的用例中Atom工作得很好。
这是一个Atom条目的范例，封装了Sites中的一个网页。可以用Content Feed将它还原到Google Sites。
<category scheme=” http://schemas.google.com/g/2005#kind“
term=”http://schemas.google.com/sites/2008#webpage”
label=” webpage“/>
< sites:revision> 2< /sites:revision>
… PAGE CONTENT HERE …
我们用粗体标出了实际被导出的数据，包括一个标识符、以ISO 8601格式表示的最后更新时间、标题、版本号和网页的实际内容。为了简化范例，强制认证元素和其他可选的信息被去掉了。一旦API准备就绪，第二步就是实现从一组Atom源到一组可移动的XHTML网页的转换。为了防止数据丢失，我们将每个Atom条目的元数据都嵌入到转换的XHTML中。如果在转换得到的页面中没有这些元数据，就说明在导入过程中出现了问题——无法确定XHTML的元素与原有Atom条目的对应关系。幸运的是，我们不用自己发明元数据嵌入技术；只要用hAtom微格式就行。
以刚才的范例来说明微格式的功能,下面是转换后的嵌入了hAtom微格式的XHTML：
id=”https://sites.google.com/feeds/content/site/…”>
… PAGE CONTENT HERE …
Updated on
Feb 9, 2009
(Version
高亮的类属性直接映射原来的Atom元素，表明了将其导入到Sites时如何重新构建Atom。使用微格式方法的额外好处是，只要作者愿意向页面中的数据添加一些类属性，任何网页都可以导入到Sites中。将用户导出的数据无损地重新导入的能力是数据解放的关键——可能需要花更多时间来实现，但我们认为这是值得的。
案例分析：BLOGGER
我们在做数据解放项目时经常遇到的一个问题是如何满足高级用户。这是我们最喜爱的用户。他们喜欢用我们的服务，存入了大量的数据，并且希望能够方便地随时导入或导出大量的数据。例如，五年间更新的日志和照片很容易就能达到几个G的容量，想要一举移动这么多数据确实很有挑战性。为了让导入导出操作对用户来说尽可能简单，我们决定实现一种一键式的方案，向用户提供一个Blogger导出文件，其中包括所有的文章、评论、统计页面，甚至每个Blogger博客的设置。这个文件会被下载到用户的硬盘里，还可以重新导入到Blogger，或者转换后迁移到其他博客服务。
我们在建立Blogger的导入导出体验时犯的一个错误是，在一次导入或导出操作时依赖单个HTTP事务。当传输的数据量变大时，HTTP连接会变得很脆弱。连接只要中断就会使操作无效，造成导出不完整或导入时数据丢失。对用户来说这是很令人沮丧的情况，而不幸的是，对于数据量较大的高级用户，这种情况更加常见。我们也忽略了部分导出的功能，导致高级用户在导入时为了获得更好的效果，有时需要采取笨拙的手段，例如手动分割导出的文件。我们意识到这对用户来说是糟糕的体验，我们希望在Blogger未来的版本中改正这个问题。
一个同我们处于竞争地位的博客平台采用了一种更好的方法，当在基于云的博客服务间迁移大量数据时，不以用户的硬盘作为中介。提供数据解放的最好方式是API，而提供数据可移动性的最好方式是用这些API实现云对云的迁移。这种迁移方式需要服务间的多个RPC来分散移动数据，每个RPC都可以在失败时自动重试，而无需用户的干预。比起单事务的导入操作，这种模型要好的多。它增加了成功率，并且带给用户更好的整体体验。但只有每项云服务都为用户的所有数据提供用于解放的API时，真正的云对云的数据可移动性才能得到体现。
挑战
正如你从这些案例中看到的，数据解放之路的第一步就是决定用户到底需要导出什么。一旦涉及用户自己创建或导入到你产品中的数据，情况就会变得复杂起来。以Google Docs为例：用户做导出操作时，显然对自己创建的文档具有所有权，但是那些他修改过的由别人创建的文档呢？他只拥有阅读权限的文档又如何？如果考虑到所有可读的文档，用户有阅读权限的文档数量会远远大于他实际读写过的文档数。最后，你还要考虑到诸如访问控制列表这样的元数据文档。这只是个例子，但适用于任何允许用户分享或协作处理数据的产品。
另一项需要紧记的挑战是安全性和授权。当你使用户可以非常快捷地导出数据时，也就大大减少了攻击者带着你全部数据逃跑所需的时间。这就是为什么最好在导出敏感数据（例如搜索历史）前强制用户进行授权，并且对用户发送导出操作通知（例如用email通知用户发生了导出操作）。我们在解放更多产品时，也一直在探索这些机制。
巨大的数据集合会产生另一个挑战。例如，一组数量很多的照片数据量很容易达到几个G，在当前大多数家庭的网络传输速度下就会造成一些困难。在这种情况下，我们或者提供一个可以与网络同步数据的客户端（例如Picasa），或者依靠已有的协议和API（例如Gmail使用的POP和IMAP协议）来让用户逐渐地同步或导出数据。
