By 2008, the tide was turning in DC. In his first year in office, mayor Adrian Fenty had restructured the city’s schools and expanded community policing, driving down crime. Technology played an important role, allowing informants to send text messages to the police department anonymously. After releasing hundreds of government data sets early that year on a new city website, the DC Data Catalog, Fenty’s chief technology officer Vivek Kundra worked with local tech community organizer Peter Corbett to design a contest around the site. Apps for Democracy, which launched in October, challenged the local tech community to create software that would exploit this new public resource. The city put up a $50,000 purse to sweeten the pot.
In just thirty days, local citizen-programmers created forty-seven different Web and smartphone apps that tapped the DC Data Catalog. Winning entries ranged from Point About, an iPhone app for receiving real-time alerts on crime, building permits, and other essential city operations, to DC Historic Tours, a Google Maps mash-up for making customized tourist itineraries out of Wikipedia entries and Flickr photos of historic places. Fenty cast the contest as a masterstroke of fiscal leveraging, announcing that “on the scale of how governments have traditionally done things, this is not an expensive program.”14 It was also blazingly fast. Kundra’s office estimated it would have taken over a year (and up to two) for the city to have bought the apps through normal procurement channels. In a clever bit of recession- proof public relations, Corbett and Kundra calculated that the apps represented $2 million worth of in-kind services—a more than 4,000 percent return on the city’s $50,000 investment.13 Based largely on the success of the Data Catalog and Apps for Democracy, Kundra was tapped for president-elect Barack Obama’s transition team and was appointed as the federal government’s first chief information officer just four months later.
Apps contests and open city data spread quickly after DCs initial success. The low-cost combination was an irresistible tool for mayors facing growing demand for interactive services from smartphone-toting citizens, and an economic recession that decimated their budgets. As stimulus funding ran out and fiscal austerity took hold, it was a model that could deliver innovation with nearly zero funding. The needed data was already mostly online in many cities, but scattered across a constellation of government websites. All a city had to do was assemble it in one place. Within a year, New York, San Francisco, and Portland, Oregon, all launched similar efforts, and DC held a second round of Apps for Democracy in 2009. Over the next several years the idea spread abroad as Edmonton, Canada (2010), Amsterdam (2011), and Dublin (2012) followed suit. Meanwhile, the World Bank was exporting the model to the developing world through its own Apps for Development contest held in 2010.
The success of apps contests comes from their ability to quickly assemble technical teams that can repackage government data in novel ways that are valuable to citizens and local businesses. Many of the submissions have been mundane, and some simply esoteric, but a handful have really stretched the idea of what smart cities could be. Consider, for example, “Trees Near You,” an entry in New York City’s first BigApps contest. Among the usual data exhaust of government that powered the contest—health inspection grades and noise complaints—lay an odd database, the Street Tree Census. To set a baseline for the city’s ambitious PlaNYC sustainability initiative, which included a drive to plant one million new trees, in 2005 the Parks Department had asked 1,100 volunteers to count every single sidewalk tree across the five boroughs and record each ones vital characteristics. From anywhere in the city, the Trees Near You app allowed iPhone owners to browse the database’s logs for nearby trees, learning about their species, age, and ecological benefits. No bureaucrat would have ever dreamed up (or justified spending money on) what tech entrepreneur Lane Becker called “a beautiful, almost meditative iPhone app.”
As good as they were for brainstorming and stretching the notion of the possible, apps contests have produced few scalable, sustainable successes over the long run. Of the hundreds of apps submitted in the first two BigApps contests in New York, just one received any significant venture-capital financing to continue its work—a clunky city guide called MyCityWay that was basically just a browser for many of the city’s newly public data sets. (And it was so-called dumb money, $5 million from BMW’s i Ventures arm, a newly launched strategic fund whose management lacks the deep industry knowledge and connections that entrepreneurs value highly in investors.) The winner from 2010, a crowdsourcing transit app called Roadify, has received some angel funding. Trees Near You developer Brett Camper moved on to other projects. The app sat there in the iTunes store, frozen, un-updated in its original state, until it was finally removed in late 2012. In fact, the vast majority of apps entered into contests are quickly abandoned. As John Geraci of DIYcity points out, city apps contests “are very good at producing version 1 apps, when what a city government needs is the rock-solid, full-featured version 7.”
The real problem with apps contests driven by new government data, as we have seen, is that they rely on programmers to define problems, instead of citizens or even government itself. The only requirements of that first wave of city apps contests, and a still-surprising share today, was that it use one of the data sets released by the city. But as New York-based interaction designer Hana Schank wrote in a scathing critique on the eve of New York’s third BigApps contest in 2011, “website and app development begins with a deep look at what the end users need, and how they are likely to use sites and apps in the course of their day. The problem with the BigApps contest is that it leaves both user needs and likely user behavior out of the equation, instead beginning with an enormous data dump and asking developers to make something cool out of it.”
The data-centrism of city apps contests is all the more curious because it ignores the key incentives of the wildly successful philanthropic grand challenges that inspired them. The Ansari X PRIZE, the granddaddy of modern innovation contests, challenged competitors to build a reusable spacecraft that could fly twice in one week, an unheard-of feat. By defining a single difficult problem, it captured the imagination of the nation’s brightest engineers and most ambitious entrepreneurs, leveraging $100 million in privately funded research with just $10 million in prize money. Less than eight years later, Burt Rutan’s SpaceShipOne touched down in the Mojave Desert to win the purse. The money mattered, but the prestige and breadth of accomplishment were the real motivators.
Subsequent rounds of the apps contests in Washington (in 2009) and New York (in 2012) did add a problem-definition round, challenging a larger group of citizens to tell developers the kind of apps they wanted. But beyond crowdsourced voting, there was no process to winnow the pool of ideas down to a few truly important problems. Programmers were encouraged to troll the discussions for app ideas, but not required to address them at all. Not until the fourth annual BigApps contest in 2013 did New York City finally engage a variety of partner organizations with deeper knowledge of its citizens’ most pressing problems to define briefs on what it called Biglssues in four categories—jobs, energy, education, and health.
In retrospect, Fenty s claim that the original Apps for Democracy campaign saved millions was also deeply misleading. None of the apps responded directly to a pressing civic need, which meant the city probably never would have spent the money to create them without the contest. And none of the apps contests to date have dictated that entrants hand their code over to government or even open-source it—in the end, it has been up to cash-strapped developers to maintain the software and any server infrastructure it requires.
Читать дальше