On April 9th of last year, someone called Iceeey proposed a change to an obscure document written by the federal government's Consumer Financial Protection Bureau.
The document wasn't that important. It was a form for transit subsidy requests. And the change was tiny, a typo fix. Iceeey suggested the agency change the line "Daily rountrip cost" to "Daily roundtrip cost." But this small request was a very big deal.
For the first time, the Consumer Protection Bureau was accepting a direct change to one of its internal documents not from someone inside the agency but from an average citizen somewhere across the country. The document had been published on the software code collaboration website GitHub, with the express idea that it could be hacked, commented on, and improved in public just like open source software.
"Power to the people!" Iceeey added. "We are the 99%!"
With this simple bug fix -- called a "pull request" in GitHub parlance -- a longstanding wall between the government and its citizens crumbled. "That was a really awesome moment, because -- in as much as it's old hat for us in the open source movement to consider code as ephemeral and that it's always changing -- seeing that in the context of government is a really huge shift," says Brian Doll, a marketing manager with GitHub.
This shift encompasses not just government documents but software too. GitHub and other tools are allowing agencies to openly collaborate with outside programmers in ways they rarely have in the past. In 2009, there were just nine government-backed source code projects hosted on GitHub. Today, there are more than 350.
"You're starting to see a lot of the activity that I think has been happening more quietly and will be talked about more publicly now," says GitHub's Doll. "I've seen cross-agency pull requests where one agency will notice that there is this project that another agency is working on, and in sort of an adorable way, they're asking: 'Gee, can I use this?' In the open source ethos, it's: 'Of course, you can use this.'"
Today, a new generation of technology leaders and software developers are coming up in Washington, slowly transforming the government, project by project. And it's a natural fit. The federal government spends nearly $80 billion on technology every year. More money than Apple. More than Google. More than Microsoft. And because it's the government, every piece of code it creates is by definition copyright-free. Government software just needs a way of reaching the outside world.
About two years ago, Chris Kemp had the germ of a great idea. He was working at the National Aeronautics and Space Administration (NASA), and he wanted to build an open source alternative to Amazon's cloud service platform. But he wasn't sure if he could get NASA to let him launch the project in a way that would appeal to open source developers. The space agency had released open source code in the past, but it wasn't set up to do the kind of iterative software development that has become the hallmark of today's open-source projects.
NASA wanted Kemp to only release software that met the agency's cumbersome standards, but he wanted to do something more along the lines of a typical GitHub project: release some interesting code, encourage others to hack it, and then gradually improve it until it was good enough to be used. But would that pass muster with NASA's engineering, legal, export control, and quality assurance people?
So, in July 2010, he met with NASA lawyers, engineers, and executives and he figured out a way to hack NASA's policy. He did this by asking them a simple question: "Do you look at the code?"
The answer, unanimously it turned out, was "No."
When NASA decided whether to approve or stop open source projects, it didn't look at the software itself. Instead, it based the decision on descriptions the developers wrote up, explaining what their code was supposed to do.
So Kemp proposed a slight change to the NASA's software release process. Since everyone was looking at descriptions rather than the software itself, why not define in advance where the software was going to go, and then work with the developer community build it? It wasn't exactly the typical open-source way, but it kept NASA's lawyers and policy people happy.
"The only way to make any progress within the bureaucracy was to work within the constraints of the policies that we had," says Kemp, now the CEO of a Silicon Valley startup called Nebula.
From that first nudge by NASA, OpenStack has now taken on a life of its own. Today, NASA is a minor player in the project, which has been swept up by big technology companies, including RackSpace, Red Hat, and IBM.
OpenStack was an early example, but in the past year, the federal government has put on the full-court press on software developers, says Steven VanRoekel, the federal government's chief information officer.
The White House released a digital strategy last May that outlined a more open, interactive, hackable way of working with the government. It calls for open APIs, developer resources on each agency's website, and a more forward-thinking, collaborative approach to software and data. The White House itself has active accounts on GitHub and Drupal.org, and within the next few months, it will ship code that lets other agencies set up their own versions of its We the People online comment and petitioning system -- software that's already under development on GitHub.
"The stuff that's happened in the past year has really been the embracing of relationships with developers at the agency level," VanRoekel says. "You're starging to see agencies put developer pages on their website. If you go to whitehouse.gov/developer, you'll see a repository there."
At the Consumer Financial Protection Bureau, they're developing a new system for posting public notices and receiving comments -- called the E-Regulations system -- that will use a more GitHub-like interface. There, it's already official policy to prefer open-source projects ahead of closed-source software. And it's OK to post code to GitHub. "There's just a general spirit of: 'We need to start afresh,'" says the bureau's CIO, Chris Willey. "We're creating a new IT group. We're creating new policies, new procedures new systems. We're looking at ways of running this agency that may never have been tried before."
VanRoekel hopes that the renewed developer efforts are just a start. "We think the government is actually sitting on a treasure trove of locked-up data," he says. Engaged developers who can actually get at this data through useful APIs could build some amazing new applications. The trick, however, is to release the data in a format that developers can use.
That's been a problem for many government agencies so far, but VanRoekel has high hopes for the future. "We're going to see a massive change in the way we interact with citizens," he says.
