2008 年至 2012 年，我驻扎在马萨诸塞州汉斯科姆美国空军基地外的一个小型基地，负责空军的大部分软件程序。我的工作是改造现有的指挥中心，一个被称为空天作战中心 (AOC) 的庞然大物，并使其现代化。
为了提供一些背景信息，AOC 是一个综合数据和作战中心。世界各地散布着大约十几个这样的主要中心。每个中心都负责规划空军在世界特定区域的行动。
AOC 的发展源于用户（空军人员）和供应商（商业和政府项目）之间的一种随意博弈。用户只是购买他们想要的东西，而供应商则愉快地拿走他们的钱并安装系统。结果是一系列独立系统；每个系统都安装了自己的硬件和软件，它们之间几乎没有资源共享。虽然团队依靠顽强的意志使其运转起来，但这非常低效，维护起来是场噩梦，用户不友好，而且敏捷性是以几十年为单位来衡量的。
我们的工作是处理那个烂摊子并修复它。我们的想法是构建一个标准的硬件和软件平台，然后将旧应用程序迁移到新平台。与此同时，我们需要将这些平台定义为任何新软件项目的目标平台。因此，我们开始研究各种选项，包括 JBoss、WebSphere、WebLogic、GlassFish 等。至少，我们想要一个标准的应用程序服务器和企业服务总线。
这是我的第一次严峻考验，它显示了空军和国防部 (DoD) 内部对开源软件的真正抵制。
重要的是要理解，在当时，开源软件在美国政府中并不流行，并且经常被关键决策者误解。国防部有一项政策，即所有购买的东西都必须是可支持的，这是一件好事。对于软件而言，这意味着必须有一种及时修复错误和其他问题（尤其是在安全方面）的方法。传统上，这意味着使用具有昂贵的年度维护合同的专有软件。这就是我试图改变的模式。
我并不孤单。汉斯科姆有几位杰出的工程师和项目经理也在尝试将开源纳入他们的项目中。我们清楚地认识到，开源是正确的方向。我们只是不喜欢被锁定在一个供应商的想法，他们可能会在未来收取他们想要的任何费用，或者更糟糕的是，一时兴起放弃他们的产品，让我们得不到支持。我们的软件用于关键操作，我们认为，考虑到有开源替代方案，专有软件的风险太高了。
我想要一个开源解决方案，并面临来自我们的律师、管理层、用户和专有供应商的相当大的阻力。有时这是一场艰难的斗争，直到国防部发布了关于使用开源软件的第一份官方指南，我们才开始获得 traction。最后，在所有这些戏剧性事件的中间，国防部领导层发布了一项政策更新，明确声明开源软件是可以接受的，只要有对其的支持，并且在必要时，支持可以来自政府程序员的形式。
这份备忘录是一个改变游戏规则的文件，但仅仅一项政策更新不足以让势头转向开源。
反对开源的论点是什么？
律师： “部门政策要求软件具有技术支持。”
在国防部关于开源的澄清指南发布之前，关于开源是否可以被视为用于采购的商业现成软件存在大量争论。为了避免任何感知到的风险，法律部门要求所有购买的软件都附带技术支持。此外，律师们希望软件背后的公司提供这种支持。我们不得不解释说，不仅开源产品背后有公司，而且如果需要，我们可以自己提供支持——如果一家专有软件公司倒闭，我们就无法做到这一点。
管理层： “风险太大了，即使我无法解释为什么。”
我们解释说，所有软件都存在一些相关风险，但我们能够选择比商业同类产品风险更低的开源软件。我们能够论证说，开源软件可能风险更低，因为有更多的程序员查看代码，并且质量可以很容易地看到。许多最大的商业公司都成功地依赖开源软件来满足其最关键的需求，我们也可以这样做。选择开源软件不是出于哲学原因——而是因为它必须完成工作并做得很好。
用户： “我们对我们现有的供应商感到满意。”
坚持使用有效的方案是完全合理的。但是，当你根本没有预算继续购买和支持所有板载的专有软件时，就该考虑开源软件了。开源解决方案可能并不总是具有与其专有同类产品相同的所有花里胡哨的功能，但该软件对于用户实际使用它的方式来说工作得很好。
供应商： “我们的更好！”
在某些情况下，这是真的。然而，在许多情况下，真正要问的问题是，“哪些软件解决方案足够好？”，而不是“哪些是最好的？”。最好的选择通常太昂贵，无法在整个企业中使用。我们努力坚持这样一条规则，即如果一个专有软件满足要求，并且没有相应的开源软件，我们愿意支付费用并选择专有解决方案。但是，许多都有类似的开源选项。
我为什么要如此努力地争取？
首先，我认为当政府为某件事付款时，我们应该回报公众。投资开源就是投资于公众可以免费使用的东西，而无需支付两次费用。我不能昧着良心付钱给专有供应商来为我们修改他们的系统，以便他们可以将改进后的系统出售给其他人，尽管在我的职业生涯中，我别无选择，只能这样做。
这通常是维护运营能力的问题。我不能冒险让我们的 AOC 因为其中一个许可证到期而不得不停止运营。我曾遇到一家软件供应商要求我们停止运营，原因是他们认为我们违反了许可证。（我们是合规的。）我们还有另一家供应商，他们的许可证非常昂贵，以至于我们为所有 AOC 保留了一个许可证池。我们不得不减少一个 AOC 的许可证数量以增加另一个 AOC 的许可证数量，因此我们必须提前知道危机何时何地爆发，以便重新分配许可证（这至少需要三到四天）。
我为开源而战的原因不仅仅是许可问题。如果商业软件解决方案不能像我们希望的那样工作，我们就必须与供应商合作更新软件。这假设我们有足够的影响力来做出更改，但通常情况并非如此。使用开源软件，我们可以 fork 代码并在其不起作用时进行必要的更改。
我为开源而战是因为我们需要创建一个创新和敏捷的环境。这是我大部分热情来源的地方。
我们在 AOC 中有超过 46 个主要应用程序和数百个较小的、专门的应用程序。传统上，在你完成软件开发后，可能需要长达五年的时间才能将其安装到 AOC 中。这在软件领域是一个漫长的过程，我希望将其缩短到对操作员真正有用的时间。
我的计划是将 AOC 的平台即服务 (PaaS) 以及实际上可以作为 AOC 开发工具包的东西分发给潜在的开发人员。它将包括 API 和测试存根服务，以便其他人可以与他们手头没有的软件进行虚拟集成。事实上，我想将其托管在互联网上并让公司下载。我希望在一家公司花费业务发展资金飞来与我会面并敲我的门之前，他们能够亲眼看看他们的软件是否可以在我们的环境中工作。
那么，如果你的 PaaS 是专有的，你该如何做到这一点呢？我可以购买企业许可证，可以使用开源解决方案，或者可以强迫所有这些公司购买专有的 PaaS（对于我想定位的小型软件商店来说并不容易）。因此，简单的答案是开源。（即使这样也面临一些挑战。）一旦一家公司能够证明他们的软件可以与我们的参考平台一起工作，我们将认真讨论将他们正式集成到该计划中需要什么。在软件通过第一个障碍后，部署时间从几年缩短到几个月。
更高层次的政治和资金问题使我的努力脱轨，整个现代化计划被推迟了。值得庆幸的是，我们启动的开源 PaaS 计划幸存了下来，现在是几个不同应用程序开发的基础，这些应用程序最终将取代主要的 AOC 应用程序。如果我今天开始这项工作，我会推动 OpenStack、OpenShift 和 Docker，而不是半定制的解决方案。
8 条评论