Code for America solves a maddening problem that cities everywhere face when they try to institutionalize the guerrilla innovation methods of civic hackers. The projects come together too fast and are too small to fit into the painstaking procurement process that governs public contracts, put in place during past reforms to fight corruption. By the time cities can farm out a software project for competitive bidding, pick a winner, and issue a contract, a year or more might have gone by. They might not even need the app anymore. The winning bidder, most likely a freelancer or tiny independent software shop, might be swamped with other work or have gone out of business.
To augment cities’ ability to source small software projects, Code for America acts as an intermediary. For a $180,000 annual fee, the organization provides each participating city with three fellows. After a month of training at the group’s headquarters in San Francisco, followed by a month-long local immersion in their sponsor cities, the fellows return to California to work on projects directed by the sponsoring city. They receive a modest stipend of $35,000 plus health benefits for eleven months of service.
By 2012, when Pahlka’s team put out the call for their third class of fellows, it was clear that Code for America was having a positive impact on the participating cities. When we spoke, she was traveling in Boston, and was buoyant about one of the projects completed there during the previous summer. Like many urban school districts that are trying to offer greater choice for parents, Boston has a maddeningly complex process for enrollment. Parents must study a twenty-eight-page pamphlet and manually map the radius of eligibility around their home (from one mile for elementary to up to two miles for high school), to find out which schools their children can apply to. As Nigel Jacob of the Office of New Urban Mechanics told me, “it unfolds into this strange map kind of a thing, very dense, very scary looking, very wordy.” The Boston school district had launched its own Web app a few years earlier, called “What Are My Schools?,” that would spit out a simple list of schools based on a family’s street address. It wasn’t helping much, and by the summer of 2011, the Boston Globe turned the screws on Mayor Menino, running a series of scathing articles bashing the entire school assignment scheme.19
Schools were central to Menino’s quality of life focus, and he made it clear to schools officials that something had to be done to address the problem quickly—“they got a very clear message from parents and the mayor,” according to Jacob. The Office of New Urban Mechanics stepped in, tasking one of its Code for America fellows to build a better tool for assessing school options. The result, a web app called Discover BPS, allowed parents to browse and sort a map of eligible schools that took into account all of the nagging and complex details of school selection, like a sibling’s current school assignment.
Discover BPS was a big win for both Code for America and the Office of New Urban Mechanics’ approach to innovation. The entire project, built by one fellow with assistance from two others, took less than four months from start to finish—an almost instant response, compared to the traditional way cities buy software. As Pahlka explains, the status quo “requires writing a specification, soliciting bids, qualifying contractors, and a lot of things that take a lot of time. Generally in city governments, a project like that will take about two years.”
By comparison, in the private sector Web apps today can be put together in a week or less. The first version of Twitter was built in a month. The first version of Gmail was built in a day. From there, they evolve. Most Web start-ups now push out new code on a weekly basis, tweaking interfaces and debugging as they grow. As Pahlka describes, “Successful applications these days aren’t completely spec’d out from the beginning and coded to that spec. They are built in a more agile process, more iteratively.”
At least in Boston, Code for America is helping change the way people in city government think about creating new software for citizens. Discover BPS took “this complicated process, put it up on the Web, and made it work in such a way that the process is now simple, beautiful, and easy to use,” Palhka says. But more importantly, “It proved that you could do it quickly, you could do it well, and you could do it relatively cheaply. If that’s the case,” she argues, “you start to create political will to question the traditional process.” Top school officials were skeptical about Discover BPS in the beginning, according to Jacob. “Now they are ‘big fans’” he says.
Pahlka’s enthusiasm about the future is hard to resist. But when I first learned about Code for America, soon after its first call for fellows in 2010,1 was skeptical. Gov 2.0 struck me as a vehicle for O’Reilly to promote his idea of “government as a platform,” an ambitious but somewhat naive proposal that seemed to want to dismantle the federal government and rebuild it with open-source software and open data. Let entrepreneurs, hackers, whoever step up and do the actual service delivery, the argument went, and make government a mere infrastructure provider. For someone so publicly identified with the progressive left, it sounded like a techno-libertarian call to arms. “Government 2.0 is not a new kind of government; it is government stripped down to its core, rediscovered and reimagined as if for the first time,” he wrote in a widely circulated essay. O’Reilly’s tenacious support of open-source software made me suspect that Code for America was really just a ploy to box big software companies out of the government market. Governments all around the world were shifting to Linux, and pushing out Microsoft and IBM. Was O’Reilly plotting to bring the open-source fight back to the homeland?
Pahlka denies any ambition to go head-to-head with IBM, Oracle, or any of the other tech titans who have locked up the government software market. “We’re too small—and going to stay small—to rewrite the technology landscape ourselves,” she insists. To her, Code for America’s work in cities is a demonstration, a disruption to business as usual. “We are not going to reconfigure IT systems at the city level from soup to nuts. We’re not about a wholesale transition. We’re about creating the stories and the examples other people can use to say, ‘We can do it differently as well. How else can we apply this model? How can we get those results in that kind of time? What do we need to do to transform the way we work?’
But projects like the Discover BPS Web app are clearly direct replacements for software the city would previously have hired a contractor to build. And even as Pahlka claims to want to lead by inspiration alone, Code for America has used part of a $1.5 million grant received from Google in 2012 to fund what she describes as a “civic accelerator” in San Francisco. Its purpose? To incubate startups that disrupt the marketplace for government software. But by creating new companies that may end up competing directly with existing vendors for government contracts, the move could undermine Code for Americas whole agenda around agile innovation. As Nigel Jacob at Bostons Office of New Urban Mechanics (who now sits on the Code for America board) put it, “Government as a platform ... very much does sound like replacing one set of vendors with another set of vendors. The new set of vendors might be more lightweight, but eventually, once they have to start dealing with government contracting, they’ll have to bulk up. At this point, they’ll have to end up behaving a lot like some of these larger companies.”24
In Pahlka’s defense, a shake-up in the government tech business is long overdue, and the innovations the accelerator incubates might open up markets the technology giants have never even imagined. While “the accelerator’s purpose is to create businesses that will disrupt the current government technology ecosystem,” she told me, “the more disruptive ones will actually just go direct to citizens.”
Читать дальше