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