软件源代码托管，也就是把源代码交给中立的第三方保管（英文称为 software escrow），回应的是一种完全合理的担忧：为你构建并运维关键系统的供应商倒闭了，而你手上留下的，是一个自己离不开、却又维护不了的东西。托管协议把源代码存放在第三方那里，一旦真的发生这种情况，第三方就把它交付给你。

这种担忧是站得住脚的。问题在于这项工具经常被误解，而两者之间的落差催生出一类协议：每年都在花钱，真到需要它的那一天却帮不上忙。

签字之前应该先问的那个不舒服的问题： 如果明天就把代码交到你手上，你这边真的有人跑得起来吗？一份没有构建说明、没有基础设施定义、没有它所调用的第三方服务凭据、也没有数据的源代码托管，不是业务连续性方案。那只是一个文件夹。从未做过验证的托管协议，交付的往往正是这种东西。

软件源代码托管涵盖什么

这是你、供应商和托管机构三方签订的协议。供应商把材料存到托管机构，机构负责保管，而事先约定的交付条件决定你在什么时候拿到它。

真正值得谈判的是交付条件。破产是最显而易见、也最容易举证的一条。但在实务中，别的条件更重要：供应商停止维护产品、不再履行支持义务，或者被你的竞争对手收购。触发条件列得太窄，意味着恰恰在你最需要材料的那些含糊情形里，机构会拒绝交付。

托管的内容本身也应当不止源代码。至少要包括：具体到足以搭出一个可运行系统的构建说明、各个依赖的准确版本、基础设施配置、外部服务的清单以及凭据存放位置的说明，还要有一位写明姓名的技术联系人。缺了这些，源代码几乎一文不值。

而且托管内容必须持续更新。签约时取一份、之后再没刷新过的副本，只是一份已经没人在跑的软件的精确记录。

为什么多数托管在交付时失效

因为没有人检查过。

标准协议是一份法律文件，它默认技术内容没有问题。托管机构提供的验证服务分好几档，从确认介质可读，一直到把托管内容真正编译出来并在干净环境里跑一遍。所谓干净环境，指的是一台不带你们内部配置、也不带开发人员机器上那些历史遗留设置的机器。便宜的那一档几乎什么都证明不了。贵的那一档才是唯一能回答你真正关心的问题的版本。

认真验证一份托管内容时，常见的结论是：缺了一个没人写进文档的工具就构建不出来；依赖一个私有软件包仓库，而这个仓库会随供应商一起消失；需要一些从未列出的服务凭据；或者干脆就是一个比生产环境还旧的版本。

如果你打算为托管付钱，那就为验证付钱。未经验证的协议转移的是风险的感觉，而不是风险本身，而两者的价格差，比在最糟糕的时刻才发现真相的代价要小得多。

SaaS 的问题

传统托管假定软件将由你自己来运行。对于托管在供应商那里的软件，这个假定通常并不成立。

拿到一个你一直通过互联网访问的平台的源代码，你依然需要基础设施、部署工具、运维知识和你自己的数据，而其中大部分并不在托管内容里。即便包是完整的，把它立起来也要花上数周，而依赖这套系统的企业往往没有这几周时间，因为业务并不会因为供应商消失就停下来等你。

这就是为什么对在线软件真正有用的保护完全是另一副样子。数据导出权比代码更重要：一项按文档化格式完整导出数据的合同权利，而且要定期实际行使，而不是停留在承诺上。连续性承诺，即供应商同意在合同终止后仍按约定期限继续运行服务，买来的是仅靠代码得不到的迁移时间。一份你真正试过的、经过验证的导出，比任何你从没试过的托管内容都更有价值。

对大多数在线软件来说，托管协议是出于惯性买下的错误工具，这笔钱花在你已经证明自己读得懂的定期导出上更划算。

成本多少，适合谁

托管是一笔按年发生的费用，通常每年从几百英镑到几千英镑不等，取决于托管内容的体量、受益方数量和验证等级。验证单独计费，真正有分量的支出就在这一块，因此把预算全都压在保管费上、却把验证费用省掉，通常是最不划算的一种分配方式。

它确实适合：一旦中断就会给业务带来实质损失的系统；规模小到失败确有可能的供应商；本地部署或可以自行托管、你也确实跑得起来的软件；以及监管机构或客户合同要求必须做的场合。

它不太适合：反正你也不会自己运行代码的在线软件；替代品一抓一大把的通用系统；以及年费在合同金额里占比明显的小型供应商。

最值得先考虑的替代方案，其实就是自己拥有代码。如果这是你委托开发的定制项目，就把知识产权转让和每次发布时的仓库副本谈进合同。这样连托管机构都不需要了，而我们那篇技术尽职调查指南里列的要点，正是让这样一次交接真正可用的那些要点。

如果还是要买，怎么让它管用

不要照单全收标准清单，要把交付触发条件谈下来，除了破产之外，还要把供应商实际上放弃产品的情形写进去。

把托管内容写在合同正文里，而不是写在没人会看的附件里：构建说明、基础设施定义、依赖清单、外部服务盘点，以及一位写明姓名的联系人。

要求按约定的周期更新，或者每个大版本发布时更新，并且要求提供确实更新过的证据。

为托管机构真正把材料构建出来并运行起来的那个验证等级付费，然后把报告读完。一次查出问题的验证，正是在尽它的本分。

另外也要测一测你自己这边的准备度。如果材料明天就到，你这边由谁接收，接收之后第一件事做什么？没有内部负责人的托管协议是一张发票，不是一份计划。我们那篇灾难恢复指南里的思路在这里可以直接套用。

Mecanik 既自己往托管里存过代码，也在软件开发工作中帮客户判断过他们到底需不需要托管。多数时候，诚实的回答是：同样一笔钱，花在经过验证的备份和清晰的知识产权归属上，买到的保护更多。

常见问题

什么是软件源代码托管？ 这是客户、软件供应商和托管机构之间的三方协议。供应商把源代码和配套材料存到托管机构，当约定条件满足时，机构把它交付给客户，最常见的条件是供应商破产或停止维护产品。

为什么托管协议在交付时会失效？ 因为托管内容从未被验证过。常见结论包括：缺了未写进文档的工具就构建不出来；依赖会随供应商一起消失的私有软件包仓库；缺少外部服务的凭据；或者版本比生产环境还旧。只有把托管内容编译并运行起来的验证，才回答得了真正的问题。

软件源代码托管对 SaaS 有用吗？ 效果很差。拿到在线平台的源代码之后，你依然需要基础设施、部署工具、运维知识和自己的数据，把它立起来还要数周。数据导出权、合同里终止后的连续性期限，以及定期实际测试过的导出，对在线服务的保护要比代码托管好得多。

软件源代码托管要花多少钱？ 通常每年从几百英镑到几千英镑，取决于托管内容的体量、受益方数量和验证等级，验证单独计费。有分量的支出在验证上，缺了验证的协议转移的是风险的感觉，而不是风险本身。

托管有替代方案吗？ 对于你委托开发的定制项目，谈下知识产权转让加上每次发布时的仓库副本，就完全不再需要托管机构。对于在线软件，一份你真正试着读过的、有文档说明的导出，通常比任何你没试过的托管内容都更值钱。