In our recent post on the Open Data Policy, we mentioned Project Open Data as an exciting manifestation of collaborative government concepts put into practice. To learn more, we reached out to GitHubber Ben Balter, former Presidential Innovation Fellow and previous contributor to the Commons Lab. Ben also provided input on agile development for our paper on the National Broadband Map.
How did GitHub become a part of this project?
I was working as a Presidential Innovation Fellow when the process to create the Open Data Policy began. Anyone within government is used to seeing documents circulate with no real idea of when it was edited, by whom, whether it was the most current version, and so on. This is very opaque. So while we’re working on open data policy, the process itself was very not open. Open source developers within the Innovation Fellows started talking about using GitHub to create the actual document. Lowering the barrier to entry was always the idea—we want people editing this and sharing their perspectives.
GitHub is often a code repository for private use. Are their structural or practical differences into applying for government?
You can’t snap your fingers and chance policy tomorrow. Not everything could go through the collaborative policy. There was a private repository on a GSA account. The end-deliverable website was built (“the bucket”) and then the content was filled out as time went by. The hard part was to build the cultural technology. Instead of circulating a case study by email, you post it on the hub and let the discussion begin immediately. It’s the concept of doing things in the open—experimenting, capturing things. You create a hub to solve a problem and working forward.
There are four key tenets: 1) Electronic; 2) Available; 3) Asynchronous (people don’t have to be in the same place at the same time doing the same thing); 4) Lock-free (don’t have to ask permission, experimentation encouraged). As new members came into the community they could quickly get up to speed and see where the editing had happened so far. Already there are a lot of good conversations going on from big issues to small ones. Biggest deliverable is the conversation around a shared problem.
What kind of feedback have you received so far on the project?
Well, there are 44 suggested corrections already. 5 are adding new resources, 10 are minor fixes and corrections, 6 are open questions, 2 are pretty huge adjustments. Someone has already retooled the site and reformatted it completely, something we didn’t have the resources to do on our own.
One of the more exciting features is Kickstart, which lists existing Open Data sets and gives people an opportunity to give input on future priorities. How would you like to see that tool develop? Where do you see the biggest opportunities to open government data?
A big priority was decentralization, so this was designed to crawl all the different existing datasets. Now that it’s listed, the conversation can begin and we can get feedback on the data itself and what data’s not out there. We want to open source the process itself, giving the public opportunities for feedback. It’s tough to tell what datasets are going to make an impact in government, and this gives a new way to gauge it.
What will it take to move this effort to the next level? This resource creates a lot of opportunities, but what to agencies need to do to take advantage?
Agencies are going to feel growing pains in implementation. The litmus test will be how they approach it. Do they implement the policy the way they normally do, a closed and opaque process with traditional contracting methods? Or will they find new mechanisms? For example, can agencies find an open source way to set up APIs to pump out their data? A lot of these processes are similar despite the different data sets. There will be distinctions, but there should be many repeatable lessons. Most of all, you don’t want people to go it alone.
From a policy perspective, the case studies are an essential inclusion, allowing agencies to develop best practices. Are there some key points you’ve been able to distill from your work on the issue thus far?
The easy part is technology—the hard part is culture. The policy memo itself is the typical “thou shalt” declaration of how we’re pushing government. The second half is the technology issues—technical requirements—how you meet the parameters of the policy. The toughest part is what you can’t quite put down on paper. It’s the culture of realizing that the public is not the enemy, and that doing things publicly can work to your advantage. If people have problems with this, I hope they go to the site and begin a discussion on how we can improve. Because that’s the idea: Opening up an issue, finding out what shared things are going on, and working together. The cultural technology will be a real challenge. Time will tell.
About the Author
Zachary Bastian is an Early Career Scholar with the Commons Lab and the Science and Technology Innovation Program at the Wilson Center, a member of the New York State Bar Association and a graduate of George Washington University Law School. He previously worked in the United States Senate studying policy and supporting the work of personal and subcommittee offices. His interests include intellectual property, communications and leveraging technology to support better government.