美国总务管理局 (GSA) 正在 计划 forge.gov，人们普遍认为它基于 forge.mil，即国防信息系统局 (DISA) 备受关注的协作平台。forge.mil 是一个非常了不起的想法：国防部内用于测试、认证和软件开发的单一目的地。
这听起来很明显，但这个想法仍然具有革命性。这将是第一个源代码的单一存储库，可以在国防部内数百个机构、指挥部和项目之间共享。开发人员将能够在熟悉的基于 Web 的环境中共享他们的工作。先前版本的 forge.mil 因不明原因被撤下，但当前版本基于 CollabNet 的 TeamForge 产品。如果您使用过 SourceForge，您就会明白这个概念。国防部是世界上最大的软件消费方，也是最大的软件开发方之一。其中大部分软件是冗余的，被供应商和集成商锁定，无法与其他软件协同工作，而且没有人记得如何维护它。毫无疑问，forge.mil 早该出现了。
然而，假设 forge.mil 是 forge.gov 的有用模板是很危险的。我认为 forge.mil 可能会使 forge.gov 重蹈 core.gov 和其他旨在鼓励政府源代码重用的失败尝试的覆辙。要理解为什么 forge.mil 可能有用，同时对 forge.gov 具有破坏性，您必须首先了解国防部是如何进行软件开发的。
COTS 与 GOTS
在 20 世纪 90 年代中期之前，国防部的大部分软件都归政府所有。GOTS，即现在所谓的“政府现成软件”，由国防部及其承包商构建和维护。这对于某些军事专用系统是合适的，但当政府无法再跟上商业企业的步伐时，该策略就过时了。对于许多常见的软件，如操作系统、电子表格和 Web 浏览器，开放市场生产出更具创新性和更高质量的产品。因此，命令下达了：使用商业软件。COTS（“商业现成软件”）开始占据主导地位。
波音、洛克希德·马丁、通用动力和其他集成商不再从头开始编写大量软件。相反，他们的商业模式发生了变化。他们现在将商业软件粘合在一起，并编写代码来填补空白。然而，他们的商业模式仍然相同。他们不再寻求从代表政府编写的专有软件中获取租金，而是寻求从他们完成的集成工作中获取租金。
这是一项利润丰厚的业务：最新的无人机由数百个软件系统组成，其中一些是商业上可用的，一些是由集成商编写的。如果我是集成商，我是唯一一个知道所有部件如何组合在一起的人，我可以向任何希望在其平台上部署技术的人收取可观的费用。想想苹果公司封闭的 App Store，但它在空中飞行，腹部绑着导弹。
当然，这没有什么不正当之处。集成商正在做市场要求的事情，控制对平台的访问是一种完全合法的商业模式。但这会阻碍重用，这意味着国防部很难有效地使用其购买或开发的软件。您可以在我的朋友和 美国开源组织 同事 John Scott 的优秀文章“失去软件(e)”中阅读更多关于这个奇怪的市场及其后果的信息。
开放性作为一种绝望的行为
因此，DISA 的 Rob Vietmeyer 决定借鉴开源社区和互联网治理的原则。DISA 更开放和透明的开发流程可以消除重用障碍，鼓励协作，并阻止专有或封闭系统。COTS 软件仍然是王者，但当政府需要控制自己的集成、制定自己的标准并对其自身基础设施行使管理权时，它仍然可以开发自己的 GOTS 解决方案 — 这次是以开放、协作的方式。曾经封闭、行动迟缓且高度专有的 GOTS 现在可以以更低的成本和更低的新创新进入门槛来生产。由于这种“开放 GOTS”是使用熟悉的开源方法构建的，因此这些项目很有机会协同工作。
围墙花园和道德风险
到目前为止，国防部软件问题听起来与政府软件问题类似。但不要误解 forge.mil。它不是典型的开源开发环境。如果您与 forge.mil 项目团队交谈，例如 CollabNet 的 Guy Martin，如果您将 forge.mil 与 SourceForge 进行比较，他会很快纠正您。forge.mil 是非常不同的。面对这个严重崩溃的市场的所有挑战，forge.mil 不得不做出一些重大牺牲。
您首先会注意到 forge.mil 的一点是您无法访问它。对 forge.mil 的访问受到严格限制。要获得访问权限，您必须拥有官方的国防部通用访问卡 (CAC) 或让国防部雇员为您担保“ECA 证书”。国防分析研究所的 Dave Wheeler 将其描述为“门控开发”。在 mil-oss 邮件列表中，这被称为“CAC 墙”。
CAC 墙有一些意想不到的后果，并提出了一些非常棘手的问题。首先，它阻止了许多不为国防工业基地工作的善意开发人员帮助内部项目。墙后实际上有数万名开发人员，而 forge.mil 将该群体与公众和没有 CAC 或 ECA 凭证的政府雇员隔离开来。这种交易是通过将这些不受欢迎的人拒之门外，他们创造了一种安全感，因此胆小的项目经理更可能托管他们的代码。这种安全感的代价是受众比他们在更公共的平台上托管所能召集的受众小得多。
CAC 墙还造成了分裂社区的危险激励。如果国防部有人想要破解一段开源代码会发生什么？他们会将破解托管在 forge.mil 上，公众可能永远看不到这些破解。如果我已根据开源许可证许可了我的项目，那是因为我希望其他人做出贡献。如果该代码消失在 CAC 墙后，我将被切断与数万名国防部开发人员的联系。这种“forge.mil 分支”情景非常严重。这是一个每个人都失败的情景。
最后，CAC 墙可能会为居住在其后的开发人员带来道德风险。在开源社区中，人们对他们提交的代码非常谨慎，因为他们永远无法真正确定谁是朋友，谁是敌人。在一个每个人都“受信任”的社区中，开发人员可能会变得自满，从而更容易受到编写不良或恶意代码的攻击。
尽管存在这些实际担忧，但 CAC 墙对于 forge.mil 仍然有意义。DISA 对正在开发的代码有一些合理的安全担忧。他们权衡了这种风险与公众监督、与外部项目合作的优势，并且他们做出了明智的决定，将代码保留在“CAC 墙”之后，并且值得称赞的是，他们鼓励 forge.mil 开发人员尽可能将补丁向上游贡献，而不是托管在 forge.mil 上。
forge.mil 作为榜样
因此，我们在 forge.mil 平台上看到了所罗门式的判断。由于其非常独特的市场动态，国防部需要利用开源项目、开源开发模式，鼓励协作，并减少对专有平台的依赖。但要实现这一点，DISA 不得不将所有工作都放在 CAC 墙后。
forge.mil 引起了其他机构的关注。这怎么可能不引起关注呢？国防部的情况是最糟糕的：最严重的问题、最复杂的市场条件和最可怕的后果。因此，其他首席信息官注意到了，并且关于 forge.mil 实验的报道也连篇累牍。
这使我们 得知 GSA 的 Dave McClure 正在 计划 forge.gov，即 forge.mil 的民用对应物。这令人兴奋。这也令人恐惧，因为他们似乎正在效仿 forge.mil 模式，将访问权限限制为仅限美国公民。Guy Martin 说：
我意识到，以美国公民身份的积极识别和审查过程的形式设置进入壁垒，会激怒一些认为一切都应该是自由和开放的人……
请把我算作被激怒的人。我想非常清楚地表明这一点：在 forge.mil 中做出的妥协对 forge.gov 来说是危险的。如果 forge.gov 要遵循 forge.mil 的“CAC 墙”方法，它将永久性地损害“开放 GOTS”运动。
forge.gov 不能是 forge.mil
forge.mil 可能具有启发性和鼓舞性，但它是一个特殊情况，并且充满了削弱其效用的妥协。在 forge.gov 的情况下，它将托管民用机构的非机密代码。没有必要创建“受信任”的环境。没有必要验证参与者的公民身份或安全许可。标准的开源机制已经足够充分：只有项目负责人可以将代码提交到存储库，补丁的半正式审查程序等等。无论如何，我很难想象为什么允许 3 亿人 访问会更好地保护存储库的安全。让我们同意，将美国公民身份作为先决条件是适得其反、行不通、不必要，最重要的是：它是不符合美国精神的。
整个约旦都采用了 VA 的 VistA 软件用于其国家医疗保健系统。无数海外研究人员通过开源项目与他们的美国同行合作。当我们与世界分享我们的源代码时，它提高了软件的质量，实际上是一种独特的实用外交方式。
既然我们不需要像在 forge.mil 中那样控制对项目的访问，我就不得不怀疑为什么我们需要一套规定的工具来托管每个项目。TeamForge 是一款优秀的软件，但实际上有数十种可行的替代方案。开发人员对他们的工具非常挑剔，并且对作为这些代码存储库核心的版本控制系统极其挑剔。如果我们自作主张地选择他们的工具，我们会为进入设置不必要的障碍。
理想的 forge.gov 是两个 forge.gov。
考虑到这一点，我们应该将 forge.gov 项目分为两个。
首先，forge.gov 作为民用政府使用和创建的开源项目的目录非常有用，其中许多项目都愉快地驻留在 机构网站 或 公共存储库 上。Forge.gov 可以成为项目和开发人员轻松找到彼此的方式。如果您愿意，可以将其称为政府的 Freshmeat 或 Ohloh。让我们称之为 forge.gov 目录。forge.gov 目录将尽可能具有包容性，跟踪我们可以找到的每个开放 GOTS 项目的进展情况。
当然，仍然有一些项目需要基础设施，forge.gov 可以提供这一点。forge.gov 存储库将由 GSA 作为一项服务提供给各机构，并提供完整的开发环境。在这里，我想到了 github 或 SourceForge。
我认为通过拆分这些角色并避免可怕的 CAC 墙，我们可以包括尽可能多的贡献者，并充分利用已经进行的优秀的开源工作。
我遗漏了什么吗？我是否忽略了国家安全问题？我是否不理解同质化开发工具集的优势？请告诉我。
[感谢 Melanie Chernoff、John Scott 和 Jim Stogdill 帮助将这篇文章缩减了一半以上。]
1 条评论