Open government is so ‘08, or why collaborative government is the next big thing

TL;DR: As technology allows us to communicate with greater frequency and greater fidelity, we have the chance to make our government not only transparent, but truly collaborative.

3 minute read

Open government is great. At least, it was a few election cycles ago. FOIA requests, open data, seeing how your government works — it’s arguably brought light to a lot of not-so-great practices, and in many cases, has spurred citizen-centric innovation not otherwise imagined before the information’s release.

It used to be that sharing information was exceedingly difficult. Open government wasn’t even a possibility during FDR’s time. As communication tools – tools like the printing press, telegraph, and fax machine – have evolved over time, newer tools have generally done three things: lowered the cost of transmitting information, increased to whom information could be made available, and increased the pace at which information could be distributed.

But printing presses and fax machines have two limitations: they are one-way and asynchronous. They let you more easily request, and eventually see how the sausage was made, but don’t let you actually take part in the sausage-making. You may be able to see what’s wrong, but you don’t have the chance to make it better. By the time you find out, it’s already too late, and reactive rather than proactive work must be done to correct issues and implement improvements. If you could take part in the sausage-making process, you could fix problems in the sausage before they were sent out to the supermarkets and diners of the world.

As technology allows us to communicate with greater frequency and greater fidelity, we have the chance to make our government not only transparent, but truly collaborative.

The open source workflow

Open source software — software for which the underlying source code is not only made available to the public, but to which users of the software are encouraged to submit bug reports and propose improvements — started out the same way. Originally, open source was merely published source, mostly due to the limitations of technology. Everyone had access to the code, but it was published in a one-way medium — by mail, via FTP, or via a read-only site. Over the past two decades, open source has moved to a more distributed workflow, one that exposes process, lives and dies by the URL, and allows anyone in the world to propose improvements, free from the shackles of the original author’s foreknowledge and consent. Today, in contrast, technology allows the process of building open source software to be inherently collaborative.

Open source’s original workflow may sound familiar. If I had a question about a particular piece of software, I’d email the author. If a piece of software I used had a bug, I’d email the author. If I had a proposed fix – you guessed it! – I’d email the author. This workflow isn’t too dissimilar to citizens calling their local congresspersons’ offices with Constituent Services Request, or a lobbyist scheduling a meeting with a regulator to advocate for a particular issue, as the process stands today.

From software code to legal code, lack of access to the creation process of these kinds of code forces one to go to the publisher, rather than the content, in an opaque, one-to-one interaction.

Beyond hub and spoke

There are two problems with this hub-and-spoke model of bespoke collaboration. First, those one-off conversations generally happen in private. No URL, no change history, no way to trace back the eventual outcome to its original impetus. In open source, this means you don’t always know a code’s pedigree or intent. Who knows this code and who should I ask about this bug? In government, the same scenario is stereotypically more nefarious, with quintessential smoke-filled back rooms and briefcases of money. Who authored this law? What were their interests and objectives?

Second, when conversations are transacted via email (or notice and comment) or other one-to-one, highly asynchronous means, there’s an opportunity for vertical communication (me and my government), but no opportunity for horizontal communication (me and my fellow citizens), at least not officially.

In the software world, this often means that multiple users experiencing the same bug ask the same question or file the same bug report multiple times, not to mention, absent a system of self–help, the bottleneck it creates in time required to respond to these issues. There’s no opportunity for a fellow user to say “I had the problem last week, here’s what I did”, as we often see by Googling many common problems. In government that’s also true, with the added harm of hindering the marketplace of ideas. “Here’s a bunch of ideas, government. You figure them out” is a lot less effective at solving shared problems then an ongoing dialogue between citizens building towards a rough consensus.

Learning from open source

So how do we encourage policymakers and bureaucrats to move from open government to collaborative government, to learn open source’s lessons about openness and collaboration at scale?

For one, we geeks can help to create a culture of transparency and openness within government by driving up the demand side of the equation. Be vocal, demand data, expect to see process, and once released, help build lightweight apps. Show potential agents of change in government that their efforts will be rewarded.

Second, it’s a matter of tooling. There are great, free, and readily-available tools out there — things like Git that can track who made what change when and open standards like CSV or JSON that don’t require proprietary software — but by-and-large they’re a foreign concept in government, at least among those empowered to make change. Command-line interfaces with black background and green text can be intimidating to government bureaucrats used to desktop publishing tools. Make it easier for government to do the right thing and choose open standards and tools over proprietary ones.

Last, be a good open source ambassador. Help your home city or state get involved with open source. Encourage them to take their first step (be it consuming open source, publishing, or collaborating with the public), teach them what it means to do things in the open. When they do push code outside the firewall, above all, be supportive. We’re in this together.

As technology makes it easier to work together, geeks can help make our government not just open, but collaborative. Government is the world’s largest and longest-running open source project (bugs, trolls, and all). It’s time we start treating it like one.

This post originally published on opensource.com.

Originally published June 2, 2014 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit