联邦政府是世界上最大的代码采购方。那么，为什么这些由纳税人资助，并且对我们民主制度的日常运作至关重要的代码，却常常被隐藏在公众视野之外？ 要回答这个问题，需要从两个方面入手：为什么政府如此频繁地在封闭平台上构建软件？以及一旦构建完成，为什么代码不向公众发布？
使用开源
当你在一个开放平台上构建软件时，贡献开源会容易得多。虽然可以将 VBScript（Visual Basic for Applications）开源，但你可能会从像 Ruby 或 Python 这样拥有更活跃在线社区的平台获得更大的动力和更热烈的反响。然而，在政府部门，更常见的情况是从一开始就倾向于“企业级”专有平台，这使得政府走上了闭源的道路。
对“企业级”解决方案的需求
在政府 CIO 部门中，普遍存在对开源的 FUD（恐惧、不确定和怀疑），认为开源安全性较低、漏洞多或成本更高，并且如果你不投资真正的“企业级解决方案”，就会陷入无尽的痛苦。一方面，如果机构向软件供应商开支票，他们知道自己会得到什么。合同中明确规定了功能、升级计划，并在出现问题时分配责任。更重要的是，供应商提供了一个电话号码，机构在需要帮助时可以拨打。“在支持论坛发帖，会有人回复”对于 CIO（首席信息官）来说可能是一个可怕的想法。
开源背后缺乏商业推手
甚至在交易发生之前，闭源平台可能已经拥有炫目的营销页面和一批联邦销售人员，他们会打电话给机构并在会议上设展台，这些都是开源平台传统上不做的事情，除了 Red Hat 和少数其他公司。当 CIO 办公室要求“企业级”功能，如审计跟踪或满足某些合规性要求时，你可以肯定闭源解决方案会确保这些功能被纳入下一个发布周期。
闭源承包商
最后，这些闭源平台是政府承包商所熟悉的，因为这是计算机科学课程中教授的内容，也是他们一直被要求提供的。如果一家经验丰富的开发公司拥有一批 ColdFusion 开发人员，当他们投标合同时，他们会建议使用 ColdFusion 构建项目。更不用说，政府的 RFP（需求建议书）可能范围界定得偏向他们已经知道的遗留技术。所有这些都意味着，在编写第一行代码之前，项目就几乎不可能看到机构防火墙之外的世界。
但是，即使机构正在使用闭源平台，也没有理由他们的自定义代码不能仍然是开源的。
贡献开源
除了 18F（数字服务）、消费者金融保护局 (CFPB) 和少数其他机构外，政府实际上并不编写代码。事实上，即使想编写，它也很少有相关的人力知识。相反，机构传统上扮演着非技术项目经理的角色，为功能需求提供规范，并选择承包商来交付最终功能。机构中负责监督合同的联络点很少与开源社区互动，更不用说对开源充满热情了。因此，开源传统上甚至不是对话的一部分。为什么会是呢？
闭源工作流程
在实际的软件开发机制方面，合同可能要求采用抛掷围栏的工作流程，即机构甚至在代码投入生产后才看到代码，或者根本看不到代码——这与开源相去甚远。即使被问及，承包商也可能没有更现代的开源工作流程的经验，或者参与开源社区的经验，这给所有相关方都带来了糟糕的体验，并进一步打击了政府部门的开源努力。
将重复造轮子作为一种商业模式
我还怀疑联邦承包商不愿意开源他们的工作，考虑到各个机构的技术要求可能差异不大。一份 FOIA（信息自由法案）请求就是一份 FOIA 请求，一份新闻稿就是一份新闻稿，无论它是否使用 FAA 或 FDA 信头。第一次开源这些解决方案可能会减少对以纳税人费用第二次编写相同代码的需求。
“拒绝”的文化
一旦构建完成，就需要人为地使代码达到必要的逃逸速度，以克服机构的谨慎惰性。安全部门可能会说不。法律部门可能会说不。你必须获得代码托管平台的批准。你必须采购一份持续的维护合同来审查拉取请求。你必须制定一个开发者参与政策，说明如何接受他们。在各种优先事项竞争的世界中，政府雇员可能会选择继续进行下一个面向公民的项目，而不是花费可能数月的时间来对抗官僚机构对变革的免疫系统。
文化冲突
即使机构设法开源代码，开源社区遵循的一套规范也与政府僵化的等级制度大相径庭。政府机构并不总是知道如何最好地与开源社区互动，或者如何在他们自己的指挥和控制文化中整合开源工作流程。支持开源社区需要时间，而这正是政府雇员传统上所缺乏的。当机构不遵守开源社区的潜规则时，反对者的最坏担忧就会成为自我实现的预言。
透明度成为负担
开源代码使机构有可能受到数百万技术精湛、眼光锐利的评论家的批评，而从机构的角度来看，几乎没有感知到什么好处。非技术机构团队可能没有能力在内部评估代码的质量，而且通常最好是把事情掩盖起来，而不是可能将他们的丑事暴露给一些互联网上最熟练的网络喷子。更不用说，倡导者所宣扬的开源的好处往往没有实现，因此如果代码是专门构建的，以至于在政府部门之外无法使用，从而没有吸引外部贡献者，或者如果项目管理不善，以至于吓跑了这些贡献者，那么这些好处就无法起到制衡作用。
与此同时，在今天的政治气候下，未发布的源代码绝对不会带来任何责任。你会选择哪一个？
需要改变什么
要扭转这种默认状态，需要改变三件事
-
首先，需要让政府雇员更好地理解和欣赏开源的优点。那些已经开源代码的机构这样做是因为有个人拥护者带头冲锋。成功的项目从一开始就以开源为目标进行规划，并有助于重塑市场需求。像 18F 和 PIF 计划这样的举措可以旨在激励和教育政府内部下一代开源倡导者。
-
其次，即使机构没有明确要求，作为主题 matter 专家，政府承包商也有责任探索开源替代方案，并向市场宣传现代行业标准开发实践。任何随意的观察者都可以看到市场的发展方向，聪明的公司有机会走在市场的前面。围绕当今最热门的技术建立内部能力，并增加政府需求。使政府做正确的事情，而不是一直做的事情，变得更加实际。
-
最后，开源社区需要加强自身建设，无论是在其提供的服务方面（超越开源是由业余爱好者编写的这种看法），还是在政府代码所获得的接受度方面。在供应方面，成为互联网上最受欢迎的开源项目（Automattic、GitHub 和 Red Hat 就是几个例子）背后的商业推手，消除 FUD 并提供“企业级”支持，存在巨大的商业模式。在需求方面，社区需要使不发布代码成为一种责任（“你在隐藏什么？”），并通过打破“我们 vs. 他们”的心态，以及支持而不是批评政府学习开源的努力，使机构的投资回报清晰可见。
为什么不是所有的政府软件都是开源的？因为你有一个完整的价值链，旨在生产闭源软件，一个处于平衡状态的系统，几乎没有动力去反思自身。近年来，技术使开放协作变得更加容易，因此，开源生态系统蓬勃发展。然而，像所有技术一样，政府仍然落后于主流采用者几年。
希望在你的帮助下，这种情况能够改变。
最初发布于 Ben.Balter.com。根据 Creative Commons 重新发布。
15 条评论