在 Government Computer News 最近的一篇文章中，我探讨了在不采用政府自行开发的现成开源软件方法的情况下，如何利用开源重塑联邦 IT 的挑战。在那篇文章中，我指出，政府越来越多地使用开源软件已经从“是否使用”转变为“如何部署”。最新的证据是美国管理与预算办公室 (OMB) 宣布的 联邦采购政策 草案，该政策推动美国政府 (USG) 的采购和 IT 政策。从许多方面来看，这都是一项具有前瞻性的政策。如果加以澄清，它甚至可以变得更好。
一点背景介绍
该政策既重申又扩大了政府 第二份开放政府国家行动计划 中提出的“改进对联邦政府定制开发软件代码的访问”的目标。该计划强调使用（以及回馈）开源软件，以促进创新、降低成本并造福公众。它还推进了可以追溯到 本届政府早期 的长期“默认为开放”目标。
政策草案包含几个组成部分。首先，它提供了关于软件采购考虑因素的推荐“三步流程”，以最大限度地减少定制开发软件的采购。其次，它确立了在公共领域或作为开源软件发布代码的要求，复制了各机构早期为发布内部开发代码而制定的政策。
最后，受保机构必须交付在联邦政府协议履行过程中产生的定制代码以供重用，并在符合某些例外情况的前提下，使其在政府范围内广泛可用。正如广泛报道的那样，每个受保机构都将参与一项试点计划，即“每年将其至少 20% 的新开发定制代码作为开源发布”，使用现有的 开源促进会 许可，但为必要的额外许可留有余地。
“三步分析”
虽然媒体报道的重点是最后一项，但吸引我眼球的是“三步分析”。它似乎试图重申现行政策。但是，草案的措辞是否会在不经意间冒着鼓励政府自行开发的 (GOTS) 解决方案胜过商用现成 (COTS) 解决方案的风险？
这需要仔细阅读。作为第一步，“受保机构必须首先进行替代方案分析，并表明优先使用政府拥有适当许可权或重用能力的现有软件解决方案。这可能包括联邦共享服务或以前开发的、可供政府范围重用的代码。”（强调部分为后加）只有当分析得出结论，“没有现有的联邦解决方案能够有效且高效地满足其运营和任务需求时，受保机构随后才必须探索是否有合适的 COTS [商用现成] 解决方案可用。”（再次强调部分为后加）这是第二步。（只有在没有找到现有“联邦”和/或 COTS 解决方案的情况下，机构才应进入第三步，并考虑采购定制软件。）
这种三步分析的表述与现有的避免 GOTS 和定制方法的 IT 改革举措和政策形成对比。例如，政府的 共享服务战略 强调了商业组织在为机构提供 IT 共享服务方面的关键作用，其中商品 IT、模块化和“开放解决方案”的使用日益增多，同时减少了重复支持。这一关键要素应反映在第一步分析中。
它也与 A-130 通告 的长期方法形成对比，该通告指示机构优先“使用可用的和合适的现有联邦信息系统、软件、技术和共享服务和/或信息处理设施”，并在其最新版本中强调“所有 IT 系统和服务都只能运行供应商支持的解决方案。”
无论是有意还是无意，“联邦解决方案”的强调表明，该政策可能倾向于 GOTS 而不是 COTS。对于开源社区、解决方案提供商以及已经接受经过验证的商业支持开源的政府机构来说，这将是一个非常令人担忧的问题。
我和其他人 撰文 指出，经过实践检验的、商业支持的开源的优势之一是它是 COTS。它可以由多家供应商支持，并为机构提供敏捷、可重用、模块化的方法。美国国土安全部最近的一份 报告 发现，“对于政府而言，项目分支的长期维护成本通常要高得多，因为政府必须为每次更改付费（而不是与他人分担维护成本），而且该分支也与主要开源项目的未来创新脱节。”这一发现与开源文献的原则基本一致，后者“强烈建议尽可能避免创建项目分支”。然而，政府及其承包商经常不必要地鼓励创建项目分支。在政策草案中明确解决这个问题将是向前迈出的重要一步。
开源的使用在政府和商业领域都顺风顺水。这项政策草案是这方面的最新例证，它关注的不是“是否”应该使用开源，而是“如何”使用。它具有前瞻性，并且在进行必要的澄清后将会得到改进，上面已经提到了一些澄清。如果没有这些澄清，就存在将 GOTS 提升到 COTS 之上、开源项目分支化以及“单打独斗”支持的真正风险。
评论已关闭。