在第一部分中，我们讨论了参议院军事委员会 (SACS) 试图阻碍国防部 (DOD) 中的开源 Accumulo 项目。他们指示国防部首席信息官 (CIO) 在 Accumulo 被允许进入国防部之前，必须完成一系列报告流程，并指示 Accumulo 团队将其工作向上游贡献到相关的开源项目中。这似乎是试图解散该项目，因为他们假设该项目正在与私营部门的产品和项目竞争。
Accumulo 案例不是第一个，也不会是最后一个遇到这种阻力的项目。随着政府越来越适应开源，它将不可避免地创建更多自己的项目，并与现有项目合作。因此，与其狭隘地看待 Accumulo，不如趁此机会更广泛地思考政府如何创建开源项目，如何选择受支持或不受支持的软件，以及当政府项目开始与私营部门竞争时应该发生什么。
这是我的看法，很大程度上受到我在第一部分中提到的 OMB Circular A-130 §8b1(b) 的启发。虽然 A-130 大多是软弱无力的，但它确实体现了许多常识性的 IT 实践，并且它是一个很好的框架，可以用来回答其中一些问题。如果您还不熟悉该部分，现在是重新阅读它的好时机。
政府资助的开源项目是否会自动与私营部门竞争？
否。
这里有一个思想实验：如果 Accumulo 是通过 CRADA、IRAD 或 SBIR 计划进行技术转移项目的产物，会怎么样？在这些计划中，政府与私营部门合作开发技术，并经常为该技术的创造者提供对工作成果的某些特殊权利，以便他们可以从中赚钱。开源也是如此，只是知识产权对所有人开放，而不仅仅是主承包商。因此，开源本身并没有任何反竞争之处。事实上，使用开源作为技术转移策略可以促进美国软件行业的创新和增长。
从历史上看，政府的项目帮助了私营部门，而不是伤害了私营部门。从高性能计算到安全，政府的开源项目推动了技术进步，创造了企业，并普遍提升了所有行业的水平。我甚至可以说，开源应该是技术转移的首选方法，而且我不是 唯一 一个 人这么认为。
这并不是说任何开源项目都值得做。A-130 的 §8b1(b)(iii) 告诉我们，当商业世界中已经存在重复项目时，政府不应创建重复项目
(iii) 支持其已简化或以其他方式重新设计的工作流程，以降低成本、提高效率，并最大限度地利用商业化的现成技术；
只要所讨论的项目不是冗余的，开源就是开发新技术并确保政府和私营部门都能广泛使用的绝佳方式。
政府用人员和资金支持开源是否公平？
因此，政府可以赞助创新项目，前提是有明显的任务需求。这就给我们留下了一个关于政府资助的贡献者的问题。许多 Accumulo 维护者是政府雇员或承包商。我们现在处于一个奇怪的灰色地带，政府正在为可能（最终）直接与其他商业产品竞争的商业软件项目提供资源。这不好吗？
如果政府项目发现商业世界无法满足的任务需求，那么花费资源来满足该需求是有道理的。例如，美国空军网络集成中心生产了“轻量级便携式安全”操作系统，该操作系统允许远程办公人员安全地连接到国防部网络。它基于 Linux。虽然有许多商业 Linux 发行版可用，但没有一个完全满足 LPS 的要求。至关重要的是，AFNIC 并非仅仅是重新打包 Linux。他们正在尽可能多地重复使用商业上可用的软件，并花费时间和金钱为原本通用的 Linux 发行版添加真正的、差异化的价值。这意味着 LPS 符合 A-130 的 §8b1(b)(iv)
(iv) 通过避免或隔离定制设计的组件、使用可以在生产前进行全面测试或原型设计的组件，以及确保用户的参与和支持来降低风险；
至少在开始时，Accumulo 案例没有什么不同。单元格级安全性和使 Accumulo 独一无二的其他功能在 NSA 中尚不可商用。与 LPS 一样，他们基于商业上可用的组件构建了他们需要的东西。这非常普遍，而 NSA 有先见之明，将这项工作作为开源项目发布，应该得到奖励。
Accumulo 最初是政府开发的软件，现在是商业上可用的软件，这一事实并不影响政府继续开发和改进该软件的能力。毕竟，改进软件是 2009 年国防部“开源备忘录”明确鼓励的
(ii) 无限制地修改软件源代码的能力使国防部能够更快地应对不断变化的情况、任务和未来威胁。
说完这些：仅仅因为政府可以根据自身需求定制软件，并不意味着他们应该这样做。不要忘记，A-130 的 §8b1(b)(i) 和 §8b1(b)(ii) 也必须得到满足。如果一个项目突然变得重复或不符合机构的任务，则该项目应使用现有的商业组件。
那么当一个项目变得重复时会发生什么？
SASC 担心 Accumulo 在某种程度上干扰了 HBase 和 Cassandra 项目，尽管 Accumulo 解决了许多问题，但并非所有问题都相同。如果 HBase 或另一个项目开始响应政府的需求并提供类似 Accumulo 的功能，A-130 建议政府仔细审查这些商业产品或向上游贡献其代码以消除冲突。§8b1(b)(v) 和良好的开源礼仪都同意这一点
(v) 证明预计的投资回报率明显等于或优于可用公共资源的替代用途...
当然，Accumulo 的工作人员已经向公众发布了他们的项目，并且是在他们提供的解决方案没有竞争的情况下发布的。当他们这样做时，根据 FAR 和 DFAR 的条款，Accumulo 变成了商业软件。这完全改变了情况。Accumulo 现在就像任何其他商业产品一样，可以凭其优点取胜或失败。正如我们之前讨论的那样，只要 Accumulo 以经济高效的方式推进其任务，政府就应该可以自由地支持该项目。这里没有造成任何损害。事实上，Accumulo 正在推动该软件领域的发展，并鼓励 HBase 和 Cassandra 等项目跟上步伐，这很棒。这是市场运作的一个例子，没有 SASC 的干预。
政府可以分叉开源项目吗？
“分叉”是指创建您自己的项目版本，而不是与其主流社区协作，这稍微复杂一些。分叉在开源社区中被广泛理解为最后的手段、核选项，因为它会产生技术债务，并剥夺主流项目宝贵的关注。
如果政府在没有明确理由的情况下创建了现有功能项目的自有版本，这不仅是一个糟糕的技术决策，也是一个糟糕的政策。例如，创建一个通用操作系统或文字处理器不是一个机构的任务。有大量此类产品可作为商业产品使用，政府没有理由通过排挤已经向公众提供的可行替代方案来破坏美国软件行业。
有更好的策略可用。政府（就像一家私营公司一样）可以尽一切努力使用现有的商业可用代码，而不是承担自己版本的整个项目的责任。这可能意味着添加他们需要的特定模块，或维护主流项目的可选补丁集。正如我们已经讨论过的那样，§8b1(b)(iv) 对此有明确规定，并且这已经是国防部运营的源代码库 forge.mil 的政策。forge.mil 的工作人员积极阻止商业代码托管在那里，因为他们担心他们会——即使是无意中——创建该项目的政府专用分支。如果政府需要为了自身目的而修改商业软件，他们应该将自己的活动限制在他们需要的特定更改上，而不是创建一个全新的作品。
这并不意味着禁止分叉。这意味着分叉的决定是严肃的，分叉的机构应准备好对替代方案、成本论证、支持和维护计划以及风险缓解策略进行分析。实际上，首先避免分叉要容易得多。
那么政府应该在什么时候合并项目？谁来决定？
人们可以想象机构选择构建和支持 HBase 或 Cassandra 替代方案的许多合法理由。他们是否做出了错误的决定？这完全有可能。但我认为，应该允许机构拥有这种自由裁量权。只要他们正在创建与任务相关且真正新颖的东西——Accumulo 无可争议地属于这种情况——这种自由在总体上是有益的。
我可以想象，Apache 的 Accumulo 项目会有一天决定与其他项目竞争成本太高。项目负责人随后将选择将一些 Accumulo 特有的功能发送到其他上游项目，以期减轻其维护负担。同样，这种情况经常发生，并且是开源流程的伟大可能性之一。
反过来也是如此：HBase 维护者可能会认为 Accumulo 的功能很有价值，并选择将其中一些功能从 Accumulo 拖回 HBase。他们完全可以自由地这样做，这也是开源项目中经常发生的事情。
可悲的是，SASC 已经决定，它比项目维护者更适合管理 Accumulo 项目。这对所有开源项目来说都是一个危险的先例。该立法背后的意图是好的：分叉通常是不好的，政府应该避免与私营部门竞争。与此同时，Accumulo 是开源的。这使 Accumulo 免受这些批评，并且在任何情况下，§8b1(b) 和 2009 年国防部开源备忘录 都为项目经理提供了充足的指导，可以用来做出此类决定。在 2013 年国防授权法案 (NDAA) 中添加语言是完全没有必要的，而且可能适得其反。
那么该怎么办呢？
如果代码是闭源的，您可以争辩说 Accumulo 正在浪费政府资源并干扰私营部门。幸运的是，情况并非如此——任何人都可以免费使用它，包括 Cassandra 或 HBase 项目。将 Accumulo 视为政府推动技术进步的精明策略是有用的。了解到政府关注单元格级安全性等问题，Accumulo 已经鼓励其他类似项目解决这些相同的问题。通过这种方式，Accumulo 和 HBase 之间的竞争与我们在科学研究中看到的竞争类型并没有什么不同：许多参与者都在推进技术进步，从而使每个人都受益。我们不会梦想将政府资助的研究视为对私人资助研究的威胁，那么是什么让这些软件项目与众不同呢？
然而。
虽然我认为国会干预没有必要，但显然我们需要讨论改进政策的方法，以减少这些情况的不确定性。具体来说，我们将如何知道政府项目何时是允许的，并且不干扰私营部门的良好工作？我将提出政府每个软件项目都应该问自己的几个问题，以回答这个重要问题
- 它对任务至关重要吗？ 显然，政府机构不应该浪费时间创建对其任务来说是多余的项目。这一个很容易，并且包含在 A-130 的 §8b1(b)(i) 中。
- 你确定没有商业解决方案吗？ 政府项目经理可以使用各种工具来帮助他们更多地了解其问题的市场。通过 RFI、行业日以及与行业的定期沟通，您可以确保在开始维护自己的软件项目的复杂而昂贵的过程之前，您已竭尽所能地寻找商业选择。在第 929 节中，SASC 指示国防部首席信息官确保已完成这项功课，但根据 §8b1(b)(ii) 和 §8b1(b)(iii)，这样做的规则和流程已经非常明确。
- 你确定没有其他替代方案吗？ 我的意思是，真的确定吗？不要仅仅依靠行业来告诉你那里有什么。您的许多解决方案可能作为开源项目提供，这些项目无法从可以响应 RFI 或参加行业日的商业实体中受益。对此要慎重：很容易进行快速 Google 搜索并宣布市场贫瘠。也很容易将门槛抬得高不可攀，并说因为没有经过认证的、带有嵌入式 IMAP 服务器的 XML 转换引擎，所以您必须构建自己的。要合理。
- 如果分叉，有必要吗？ 关于这个决定，有很多文献，包括 §8b1(b)(iv)，我在这里不再赘述，但分叉的决定是一个严肃的决定。您可以通过补丁满足您的要求吗？您是否准备好在可预见的未来承担维护负担？这个决定很复杂，项目办公室不应轻率对待。分叉起初可能看起来更容易，但从长远来看会困难得多。
- 您是否考虑了所有成本？ 这非常困难，但请花点时间阅读 §8b1(b)(v)，并弄清楚您让自己的生活变得多么复杂。因为您正在使用自己的项目，所以您是否承担了更大的维护负担？更高的支持成本？额外的认证或认可工作呢？您的退出成本呢——将来是否会更难转向更好的替代方案，因为您正在使用政府特定的软件？
- 您的假设仍然成立吗？ 这是最重要的问题，也是 Accumulo 案例要求提出的问题。您可能阅读了 §8b1(b)(vii)，完成了您的替代方案分析、您的市场调查、确定了您的需求，但那是两年前的事情了。现在仍然没有替代方案吗？也许有另一个项目您可以合作以减轻您的负担？定期、诚实地重新评估您的假设将使您免于跑得太远。
现在轮到您了：机构还应该考虑什么？
2 条评论