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 really, really hard. Open government wasn't even a possibility a few hundred years ago. Throughout the history of communication tools—be it the printing press, fax machine, or floppy disks—new tools have generally done three things: lowered the cost to transmit information, increased who that information could be made available to, and increase how quickly that 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.
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 bugs and proposed 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 website. 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 submit proposed improvements with or without the author's consent. Today, in contrast, technology allows open source 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 use 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 disimilar from citizens calling their local congressperson's office with a constituent services request, or lobbyist scheduling a meeting with a regulator to advocate for a particular issue as they do today.
Whether software code or legal code, when you don't have the ability to submit a proposed change upstream yourself, you're forced to go directly to the publisher 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 was their interest?
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, it creates a bottleneck in the project maintainer. 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 dialog between citizens building towards a rough consensus.
Learning from open source
So, how do we encourage policy makers 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 change agents in government that their efforts will be rewarded.
Second, it's a matter of tooling. We've got great 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 over proprietary tooling.
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, And 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 in fact 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.
2 Comments