Apps for Metro Chicago (A4MC) was two years in the making. Several groups, including the Chicago Tribune Apps Development team, the Open Government Data Meetup, and the Metro Chicago Information Center (MCIC), had been pushing the city to publish data and host an associated apps competition for two years with no luck.
Executive Director of MCIC, Virginia Carlson, had agreed to have MCIC take on the task of running the competition, especially given that many wanted Chicago’s app contest to specifically reach out to community organizations and be able to offer technical assistance to teams. MCIC had even received funding to run the competition from the John D. and Catherine T. MacArthur Foundation, but the MCIC was holding on to it until Mayor Richard Daley pulled the trigger or a new mayor was elected.
So everyone was thrilled sideways when Mayor Rahm Emanuel made open government data and an associated Civic Apps Competition (CAC) a priority. Kate Eyler-Werve became the competition project manager a month before the launch and we were off. A4MC was launched in June of 2011.
The first government competition, “Apps for Democracy,” was sponsored by Washington D.C. in 2008. The contest was initiated by Vivek Kundra, then chief technology officer for the District of Columbia (he later became the first-ever Federal Chief Information Officer), and designed and executed by digital marketing agency iStrategyLabs. Participants had one month to build apps that addressed a range of citizen needs, like bike routes, crime hot spots, and neighborhood amenities. Apps for Democracy attracted 47 entries, thus demonstrating that software developers would donate their time and energy to build engaging web and mobile applications that used municipal data feeds.
The success of Apps for Democracy inspired a host of state and municipal governments to launch their own competitions, including San Francisco, Portland, New York City, and Chicago of course, as well as the states of California and Illinois. Several Federal government departments, including the USDA and the EPA, have launched their own challenges, and the Federal government created an online challenge platform, Challenge.gov, in 2010 to support smaller challenges.
Now, four years into a flurry of apps competitions and a lot of public interest, some question whether or not CACs actually deliver increased transparency, government efficiency, and innovation. Let’s unpack these critiques.
Open data is often criticized for not delivering on government accountability goals. But making data available is only one part of the accountability process. Open data needs to be tied to an accountability “mechanism” in order to achieve accountability. For example, if a government provides a data stream about planned infrastructure improvements, but there’s no way for citizens to weigh in on priorities, you perhaps have transparency but not accountability.
From our perspective, the accountability mechanism doesn’t have to be “new.” One of the themes upon which conducted our Apps Competition and that we’ll stress in this guide is that there’s an existing multitude set of orgs that have traditionally used government data to scrutinize government. These orgs should intentionally be made part of open government contests and campaigns: journalists, community organizers, better-government associations, civic watchdog groups, etc.
Having software developers and data analysts working directly with such civic stakeholder groups increases the possibility that what’s revealed by the data will get used for accountability. What A4MC did to address this was to give additional judging points to apps that came from partnerships that included a civic stakeholder groups. We also set up what we termed “Hack Salons” which brought together community orgs with software developers around specific issues. We learned that there is mutual suspicion –civic coders expected the community organizations wanted “something for free” and community organizations were loath to give time to something that they thought was a “gimmick.” It took effort to learn to speak both languages and find common ground. The idea lives on in Code for America-sponsored Chicago Civic Idea Hack (ideahackchicago.com).
Yet even where an accountability mechanism exists, the data sometimes could be more complete in terms of contributing to transparency. Such was the case in Chicago when Mayor Daley opened one of the first data sets, a list of all Freedom of Information Act (FOIA) requests submitted to the city. However, the data did not include a field noting whether or not the request had been fulfilled. So everyone could see what people were requesting, but there was no way to determine if the city was actually fulfilling those requests. Incomplete data. The City of Chicago addressed that problem to some extent by hiring a Chief Data Officer (Brett Goldstein) whose job it was to proactively participate in “citizen data” sessions and otherwise listen for what was missing in data. Goldstein took it upon himself to attend hackathons, Hack Salons, tech conferences, Meetup groups and the like to hear what folks were saying about the City’s data.
The potential for accountability also depends on the kind of data that is made available. We’ll discuss different kinds of data in Ch. 6, but in short, sometimes data just doesn’t lend itself to citizen engagement. Consider geographic data like elevations or census tract boundaries—this information might be necessary to build apps, but in itself doesn’t engage citizens on any particular issue.
A common critique of CACs is that apps created by competitions face hurdles to long-run sustainability and thus struggle to affect government efficiency. It’s tough to know the extent of the drop-off, however because contest coordinators have not required app developers to run or submit analytics. As Peter Corbett has suggested “One lesson I’ve learned is we don’t really know [how many are still functional two years later] because we don’t have the analytics for each of the apps. If you’re running an application development challenge, it would be great to give your developers individual Google Analytics codes so you can track usage. We didn’t do that.”[1]
A major challenge is that government procurement rules prevent apps created by CACs to be quickly adopted by government agencies. For example, “truck route finder,” a cool app developed for A4MC, was meant to be adopted by the city’s industrial corridors as a way to help trucks avoid low viaducts and street closures, find gasoline stations, and generally assist truck drivers as they navigate the city. Such an app would be a tremendous help to the city in terms of competing for industrial jobs. Yet the software, although developed with input from the industrial corridor managers, had not been acquired through the official procurement process and therefore could not be brought in-house.
In addition, there is pressure on CTOs and CIOs to concentrate their efforts on opening up government data and leaving the development of the apps themselves to (non-governmental) local developers. There’s tension between the goals of government efficiency and spurring innovation. If government builds the app and it addresses an efficiency goal, it might be at the (perceived or real) expense of supporting innovation among local software developers. A heated argument ensured in the winter of 2011-12 when the City of Chicago for Chicago released an app for snowplow tracking.[2] A debate about the role of government and government workers among local open civic data enthusiasts ensued. Some argued that the City was right to take the lead on some app generation; others argued for a more government-hands-off approach.
Logan Kleier, Portland’s CISO, supports the notion that one way to make open government data competitions more sustainable is by engaging the government workforce. “Starting with a small group of departments who might not know that their data could be useful to each other would be a good first step,” Kleier said in an interview.[3] In addition, state law usually prevents government workers from entering a competition itself because the government is a partner in the CAC. We had to disqualify a fabulous app for manufacturing site locators because it was developed by an agency associated with the City.
The right balance has to be found between “gov development” and “civic coder development” to get usable apps with potential for government adaption.
More recently there’s been some discussion about the problem of bringing apps to a scale which would create broader governmental efficiencies. As Mike Mathieu suggests, “[s]imply put, civic apps don’t roam across political jurisdictions.”[4] Just think, for example, how much more useful the A4MC “truck route finder” could be if the developer was able to integrate data from across regional governments—viaduct clearances not just in Chicago, but also in cities between the highway and Chicago industrial areas.
Still others have pointed out that few private sector businesses have been built as a result of an apps competition. Although open government data has been conceived as a platform upon which to build “a rising tide of entrepreneurship,”[5] so far the number of businesses arising out of a CAC is small. NYC BigApps 1.0 winner MyCityWay won millions in venture capital and now covers 70 cities. A4MC winner SpotHero won a place in Excelerate, a tech incubator that provides mentorship and funding to promising start-ups. Nevertheless, there is no guarantee CACs themselves will launch new businesses.
One private sector success related to Civic Apps Competitions is the increased usage and popularity of Socrata, Inc., based in Seattle Washington which provides the technology backbone for governments to release open data. It powers a plethora of local initiatives including Chicago, Portland, San Francisco and New York (it also powers many of the federal government’s open data websites including data.gov).
Apps for Democracy famously cost Washington D.C.’s Office of the Chief Technology Officer $50,000. D.C.’s CTO estimated that the value of the apps created was $2.3 million, a 4000% return on investment.[6]
These numbers have doubtless been cited in support of hosting apps competitions launched since then—we certainly included them in our Apps for Metro Chicago proposal. However, a closer analysis of the ROI claim reveals flaws in calculating both the value of the apps created and the cost of hosting a competition
The CTO calculated the value of apps by estimating the market value of the hours worked, then adding the external contracting costs and internal time that procuring the apps would have required. But there is no reason to think that DC would have procured every single one of the apps submitted to the competition. Furthermore, this calculation assumed that all the apps would be sustained over time. Thus, the value of the submitted apps to Washington DC was over-stated.
And then there is the question of the “investment” —the cost of hosting the month-long competition. Apps for Democracy was hosted by Washington D.C.’s office of the Chief Technology Officer, but it was actually run by digital marketing firm iStrategyLabs. A close read of the reports on the outcomes of the competition shows that the only costs counted are those borne by the Office of the Chief Technology Officer. As MCIC found, there is a great potential for hidden “in kind” costs in a competition (hosting civic hackathons, media engagement, venues for awards ceremonies, etc.) so that the “real” budget could have been over $50,000.
What is at issue here is the trade-off between a quick ROI and a long-run payoff. Real development of apps that are effective and sustainable and build a community of users is, as we discuss in the following chapters, difficult and expensive. When Bryan Sivak took the CTO office in 2009 he declined to run Apps for Democracy for what would have been its third year. At the time he was reported to not have “[given] up on the idea of engaging smart and creative software developers for the public good; he simply wants a more meaningful relationship with them.”[7] What MCIC learned from trying to do just that—develop a meaningful relationship with software developers—is that that approach ran us $300,000 (we discuss our costs in Chapter 4). Outreach to community groups, sustaining public interest through three rounds meant to build time for continued app improvement, partner coordination and all the rest is time-consuming.
As we’ve seen, the traditional goals of CACs—supporting transparency, efficiency and economic growth—are problematic. But problematic isn’t the same as wrong. In the next chapter we’ll show how CACs do help governments meet those goals.
Get Civic Apps Competition Handbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
