开放政府很棒。至少，几个选举周期前是这样。信息自由法案请求、开放数据、了解你的政府如何运作——可以说，这揭示了很多不太好的做法，并且在许多情况下，激发了公民为中心的创新，而这些创新在信息发布之前是无法想象的。
过去，共享信息非常非常困难。几百年前，开放政府甚至是不可能的。纵观通信工具的历史——无论是印刷机、传真机还是软盘——新工具通常做了三件事：降低了传输信息的成本，增加了信息可以提供给的对象，并提高了信息分发的速度。但是，印刷机和传真机有两个局限性：它们是单向和异步的。它们让你更容易请求，并最终看到香肠是如何制作的，但不让你真正参与香肠的制作。你或许能看到哪里出了问题，但你没有机会把它变得更好。当你发现时，已经太晚了。
随着技术让我们能够以更高的频率和更高的保真度进行沟通，我们有机会使我们的政府不仅透明，而且真正具有协作性。
开源工作流程
开源软件——底层源代码不仅向公众开放，而且鼓励软件用户提交错误和建议改进的软件——最初也是这样开始的。最初，开源仅仅是发布的源代码，这主要是由于技术的限制。每个人都可以访问代码，但它是通过单向媒介发布的——通过邮件、FTP 或只读网站。在过去的二十年中，开源已经转向更分布式的工作流程，这种工作流程暴露了流程，依赖于 URL，并允许世界上任何人提交建议的改进，无论作者是否同意。今天，相比之下，技术使开源本质上具有协作性。
开源的原始工作流程可能听起来很熟悉。如果我对某个特定的软件有疑问，我会给作者发邮件。如果我使用的某个软件有错误，我会给作者发邮件。如果我有一个建议的修复方案，你猜对了，我会给作者发邮件。这种工作流程与公民致电当地国会议员办公室提出选民服务请求，或游说者安排与监管机构会面以倡导特定问题（就像他们今天所做的那样）非常相似。
无论是软件代码还是法律代码，当你没有能力自己向上游提交建议的更改时，你会被迫直接与发布者进行不透明的一对一互动。
超越中心辐射型模式
这种定制协作的中心辐射型模式存在两个问题。首先，这些一次性的对话通常发生在私下。没有 URL，没有更改历史记录，无法将最终结果追溯到其原始动因。在开源中，这意味着你并不总是知道代码的谱系或意图。谁知道这段代码？我应该问谁关于这个错误？在政府中，同样的情况通常更邪恶，典型的烟雾弥漫的密室和装满钱的手提箱。谁起草了这项法律？他们的利益是什么？
其次，当对话通过电子邮件（或通知和评论）或其他一对一的高度异步的方式进行时，存在垂直沟通（我和我的政府）的机会，但没有横向沟通（我和我的同胞公民）的机会，至少在官方上是这样。在软件世界中，这通常意味着多个遇到相同错误的用户多次提出相同的问题或提交相同的错误报告，更不用说，在没有自助系统的情况下，这会在项目维护者中造成瓶颈。没有机会让其他用户说，“我上周遇到了这个问题，这是我做的，”正如我们经常通过谷歌搜索许多常见问题所看到的那样。在政府中也是如此，而且还增加了阻碍思想市场的不利影响。“这里有一堆想法，政府，你们自己想办法”远不如公民之间为达成粗略共识而进行的持续对话更能有效地解决共同问题。
向开源学习
那么，我们如何鼓励政策制定者和官僚从开放政府转向协作政府，从而大规模地学习开源关于开放性和协作的经验教训呢？
首先，我们技术人员可以通过提高方程式的需求侧来帮助在政府内部创建透明和开放的文化。勇于表达，要求数据，期望看到流程，一旦发布，帮助构建轻量级应用程序。向政府中潜在的变革推动者表明，他们的努力将得到回报。
其次，这是一个工具问题。我们有很多很棒的工具——比如 Git，它可以跟踪谁在何时进行了哪些更改，以及像 CSV 或 JSON 这样的开放标准，它们不需要专有软件——但总的来说，它们在政府中是一个陌生的概念，至少在那些被授权进行更改的人中是这样。带有黑色背景和绿色文本的命令行界面对于习惯于桌面出版工具的政府官员来说可能令人生畏。让政府更容易做正确的事情，并选择开放标准而不是专有工具。
最后，成为一名优秀的开源大使。帮助你的家乡城市或州参与开源。鼓励他们迈出第一步（无论是消费开源、发布还是与公众协作），教导他们以开放的方式做事意味着什么，当他们确实将代码推送到防火墙之外时，最重要的是，要给予支持。我们在一起。
随着技术使协同工作变得更容易，技术人员可以帮助使我们的政府不仅开放，而且实际上是协作式的。政府是世界上最大、运行时间最长的开源项目（包括错误、喷子等等）。现在是我们开始像对待开源项目一样对待它的时候了。
2 条评论