On his first day in office in 2009, U.S. President Barack Obama signed the "Memorandum on Transparency and Open Government," asking government agencies to make their data open and available to the public.4 The aim was to provide transparency in government and improve provision of services through new technologies developed on the backbone of civic open data.5 Transparency was achieved through a public data catalog that was the most comprehensive at the time, providing such information as real-time crime feeds, school test scores, and air-quality metrics. However, as of May 2010, only one year later, few citizens had make the effort to comb through the more than 272,000 datasets they had been provided.6
In response, leaders of the open data movement sought to engage code developers to make the information not only more digestible for greater transparency but also incorporate it into applications, services, and businesses that could better serve the public and foster economic growth.
U.S. chief information officer Vivek Kundra led the effort, enlisting the help of iStrategyLabs (https://isl.co/), a digital creative agency based in Washington, D.C. To spur interest in the data.gov repository, iStrategyLabs then launched the "Apps for Democracy" contest with cash prizes to stimulate development of civic apps. With an investment of only $50,000 provided for prize-winning solutions, 47 apps were created with an estimated value of $2.3 million based on the cost to develop them through more traditional means.1 Moreover, the 30-day contest significantly compressed the amount of time otherwise needed to launch the government down this innovative path, estimated at two years through conventional methods. The strategy was thus deemed a success; New York and San Francisco soon followed with similar contests. Indeed, as momentum increased in the open data movement, cities, rather than the federal government, took control of publishing and promoting open data initiatives. In the following three years, these strategies were replicated in cities worldwide.
However, by 2011, much of the initial enthusiasm behind the open data movement had waned. The adoption, impact, and value creation of apps developed through open civic data was far less than anticipated. The open data repository was accessed through downloads of more than two million datasets, though few applications based on the data were widely used, nor did they have high quality ratings;2 for instance, none of them appeared in the top 100 overall applications in either the Apple or Android appstores. While there is a huge potential market for civic apps, these initiatives had failed to create the social or economic value that was projected.
In this article, we examine early strategies behind the open data movement. We interviewed application developers and civic organizers in eight cities in the U.S. and Europe: Amsterdam, Barcelona, Berlin, Boston, Helsinki, New York, Philadelphia, and Rome. Through the course of these interviews we tried to identify some of the reasons the initiatives failed to meet expectations. We conclude by examining more recent adaptations to the strategies that offer pathways toward greater civic benefit.
Bold vision, meager results. Following the apparent success of the Apps for Democracy contest in 2009, cities worldwide began hosting application contests to capitalize on their own newly open data catalogs. These contests continue to be the predominant strategy for fostering transparency and economic development provided through civic open data. However, early initiatives suffered from a lack of civic benefit, in both government and the public. Though efforts were made to open data throughout all types of government, developers tended to incorporate only a small range of it, including overuse of certain datasets. A multitude of apps targeted similar solution categories (such as transportation and mobility) with only limited use or civic benefit. Organizers began to realize neither data quality nor general interest was the cause of the meager impact. Rather, limited public knowledge of the significant operational challenges facing city governments generated a portfolio of somewhat anemic apps targeting a predominantly consumer market. Developers, with similar social demographics, were guided by personal experience or interest to develop apps centered on restaurants, parks, and public transportation. Betsy Scherzer, an organizer of New York City's Big Apps Contest, explained it like this: "I think a lot of it depends on what developers are interested in and what seems useful. For example, we get a lot of data from the Office of Management and Budget. That data does not match or lend itself easily to apps. Not too many people want a municipal budget app. Whereas the Parks Department, which has all the info on park Wi-Fi and stuff you can see, pull out your phone and use the info; those datasets get used first."
Even within the datasets that did receive attention, developers often failed to envision solutions that would greatly complement provision of municipal services. Tourism apps, for example, represented almost 12% of the apps in Amsterdam's 2013 "Apps for Amsterdam" contest (http://www.appsforamsterdam.nl/), but the utility of the solutions was anchored in mobility and consumption, not increased service provided by the city. Applications that had real impact for citizens or government were few. The app DontEat. at (http://www.donteat.at/) is an exception, demonstrating better integration of open data and civic services. DontEat.at was created as part of the New York Big Apps competition, integrating restaurant-health-inspection information provided by the New York City Department of Sanitation with restaurant location and ratings data. Upon entering an eatery, DontEat.at would recognize the locale and determine its inspection status. If that restaurant had been flagged for a sanitation- or heath-inspection violation, the app would send patrons a text message alerting them to the notice. In addition to providing a service to citizens that would greatly affect their actions, the app also affected the role of the Department of Sanitation. Previously, health inspections would go virtually unnoticed until egregious and final violations called for public notices and restaurant closure. DontEat.at reinforced even minor violations by making the public more aware of infractions. Health inspectors began to see cleanup more quickly, and without repeated visits because patrons were leaving after receiving the alerts. The app demonstrates time and cost savings civic apps can provide a city and its citizens, though few apps developed through the contests delivered such civic benefit.
Apps developed in city-sponsored contests failed to have an impact because developers often arrived with ready-made solutions. Contest organizers hoped the range of datasets would spur new and innovative apps to improve internal city processes, provide better civic services, or facilitate government-to-citizen interaction. But because the requirement for contest participation was often the simple inclusion of a city-provided open dataset, most developers submitted previously developed apps with minor adjustments to accommodate civic data. So even where numerous recycled apps exploited civic datasets, novel business innovations or improvements in the provision of civic services were rare.
Failure to provide value capture. In addition to lack of impact, the open data initiatives were not managed in ways to guarantee value capture. Contest organizers did not fully understand the motivations of external participants to ensure their continued involvement, nor did they expect real savings to be accounted for in city hall. Initially, contest organizers reasoned prize money would be a strong motivator for developer participation, providing a foundation for them to jump-start and sustain development of their apps. Some contests included tens of thousands of dollars for prize winners. However, though money was never refused, most developers believed the amount was not enough to provide application support, maintenance, and sustainability over time. They were instead looking for much more. As Jonathan McKinney of Cab Corner, an app providing a cab-sharing utility, said, "Our reason for participating is to be recognized enough to get serious funding. Not $10,000 or $20,000, but someone who will give you a quarter of a million dollars or so and really get involved and bring more people in. The prize money is not a game changer. The real reward is when someone calls you out of the blue and says they have real venture capital for you. Then you can get things done."
So even where numerous recycled apps exploited civic datasets, novel business innovations or improvements in the provision of civic services were rare.
Developers did not chase the prize money but rather participated as they would any non-city-sponsored contests—for exposure, reputation, and evaluation. Coders sought exposure to potential funders that, unlike one-time winnings, would represent a sustained source of income for those looking to start a business from their apps.
As contest organizers became more aware of developer motivations, greater effort was made to include entrepreneurs and venture capitalists on the panels of judges. They also hosted events and closing ceremonies that included potential funders, and some developers found success through this model. MyCityWay (http://www.mycityway.com/) was an app and platform developed to allow businesses to connect to their customers in real time when on the move throughout a city. MyCityWay's exposure in New York City's Big Apps Contest won its developers more than $7 million in venture capital. News of that success spread through the developer community, increasing participation by others looking for funding through contest exposure. However, MyCityWay was an exception, and, overall, developers could not expect such funding to be the norm in city-sponsored contests. This left them struggling with financial constraints that often led them to abandon their apps.
Aside from external funding, participants still hoped to capture value through contest participation—not to potential investors but to a larger citizen market for their apps. Developers hoped citizens would become aware of the civic apps through municipal websites or the city organizers to showcase participating solutions. However, such efforts fell short of expectations. Marco Cavalli, a developer in the Apps for Italy contest, said, "If only we had more exposure leading to more users who eventually paid for the premium version. We hoped to get more subscribers just to start so that we could continue with our development. But without more initial awareness through the city or other advertising, we were not able to grow."
Moreover, cities did little to advertise their new apps collections, and, not surprisingly, citizens did not flock to city websites to discover them. The usual outlets for finding apps—the Apple and Android app stores—do not feature categories highlighting city apps, making it difficult to gain awareness in the largest markets. Instead, creating awareness was left mostly to the developers, who found it difficult without additional funding. Though the market for city services remains more than enough to provide continued value to thousands of civic apps, actual adoption remains low and fails to sustain development.
Failures within government. Failures in early open data challenges also stemmed from internal issues within city governments and expectations of participating departments. The first step in these initiatives involved persuading agencies to open their data and provide it in usable formats. With strained budgets, overworked employees, and other, more critical responsibilities expected on a daily basis, releasing data was not only a chore with no tangible benefit but also subjected municipal departments to unwanted scrutiny. Employee reluctance delayed city halls in opening data repositories to the public. Most cities eventually introduced legislation to force data publication, but their departments were still slow to move.
Moreover, the managing department for most open data contests was usually the innovation, IT, or economic development department. Beyond data publication, the managing department had little interaction with more core city agencies regarding the apps challenges championed by the organizational periphery. This disconnect between city operations and open data initiatives greatly hampered their potential success.
Involvement by civic departments directly requesting specific solutions beneficial to city operations was sometimes prohibited by procurement legislation. Betsy Scherzer from New York's Department of Economic Development said, "We had a few agencies that came to us and said, 'We are from the Department of X and we would love to have the following guide made for us that does XYZ.' But that's actually a specific enough request that it would be considered something you would have to procure for, and so we're not allowed to accept them, because, if we did, it would be like procuring something for free."
Not only were agencies prohibited from requesting focused solutions, general communication between the relevant departments and developers was limited. If city departments were stifled in the development phases, their potential for adoption or support further into the app life cycle was highly unlikely. There were no instances of popular or useful apps being adopted or partially managed by a city agency. As such, civic apps suffered because the departments for which they were created failed to integrate them into the central services provided by the city (see Table 1).
First-generation failures. Because management of open data initiatives was handled outside core city departments, these agencies were not asked to make financial investment in the solutions. Likewise, accountability for the impact of the open data and the success of the resulting apps was also dispersed. Managers did not expect dramatic returns from the contests, especially in terms of savings that might directly accrue to their department. Central organizers sought to quantify the value saved by a contest with metrics measuring the comparable cost of in-house development. But, as these savings were not accounted for in any departmental budget, there were no reviews or measurements of actual benefits. Instead, the rationale provided for contests became focused outside city hall on economic development within the community, stemming from new businesses based on the apps. Not surprisingly, few sustainable businesses have materialized. The number of participants, datasets opened, and apps developed have become the metrics by which contests are evaluated. However, these numbers poorly reflect municipal savings or entrepreneurial or social value.
As open data initiatives continued to gain popularity, cities and developers began to recognize which strategies were most effective and how to improve on others. Though many of the initial efforts continue, some second-generation initiatives incorporate new mechanisms and include additional actors to increase the impact of civic open data and provide value capture for those involved. These improvements represent some best practices and lessons to encourage the momentum behind the open data movement.
Increased exposure to civic needs. Early challenges often lacked impact because developers had limited experience with the full suite of civic services and instead created an abundance of solutions with what they thought would be popular consumer appeal. In order to redirect developer focus, organizers sought to educate developers about struggles in government or the plight of other citizen groups. "Hack-at-Home" is a strategy that exemplifies the improvements built into apps contests to enlighten developers about the need and potential for solutions.
Hack-at-Home is an apps-contest model developed by DotOpen (http://dotopen.com/), an open innovation and digital media company based in Barcelona, Spain, giving developers more information about problems that could be better addressed through open data solutions by increasing the involvement of civic agencies early on. Instead of simply requesting governments' open data, DotOpen works closely with departments needing solutions to formulate the issues relevant and solvable through information and apps. The result, in addition to data repositories, is developers are presented "problem statements," or short descriptions including a "crisis statement" on the current situation or process that is failing; a "needs statement" on, generally, what utility an app would provide, without specifically detailing a developed solution; and an "impact statement" on the expected outcome and benefit the solution would provide to citizens and government alike. These 500-to-1,000-word outlines add significant impact simply by guiding developer attention to problems genuinely faced by governments. Apps developed through these challenges have, for example, increased awareness of sanitation problems while educating citizens about access to available resources and solutions.7
Another method for increasing the impact of open data also involves working with intermediaries to better educate developers about the situation faced in city hall.3 This strategy, developed by nonprofit organization Code for America (http://www.codeforamerica.org/), abandons the contest model and greatly enhances the direct relationship between coders and civil servants. Code for America chooses approximately 30 developers and eight to 10 cities per year to create solutions based on open civic data. These developers must make a full-time commitment to Code for America for an 11-month period during which they relocate to San Francisco, CA. Developers engage directly with relevant city workers to better understand civic needs from their perspectives, as well as engage with citizens affected by the related problems. This model has also spread internationally through Code for Europe, Code for Africa, Code for the Caribbean, and others.
Stronger management. Second-generation open data initiatives have also increased civic benefit through better and stronger management. Where simple contest-driven strategies were disappointing in the first generation, the increased involvement of internal agencies and external partners has yielded superior results in the second wave. Boston's Office of New Urban Mechanics (NUM) is an example of an internal agency with strong management of its open data initiatives. NUM is an internal innovation department within the mayor's office, creating technological solutions that increase provision of civic services and value to government. NUM invites all actors to report their needs and suggestions for improvement, including citizens, government employees, academic institutions, nonprofit organizations, and private businesses. NUM then evaluates them based on their potential for improving civic services, filtering them on targeted areas like urban development and education. NUM follows a five-to-seven-month timeline for development of solutions, whether for a mobile app or more complete business based on the technological solution. This model of top-down management, unlike the early apps contests, has demonstrated lasting civic benefit, value capture, and solution sustainability.
One example of a NUM-developed app is Street Bump, which collects data about road conditions as users drive the roads (http://www.street-bump.org/). The city aggregates the data on real-time road deficiencies that can be fixed more quickly, reducing the cost of deploying civil servants to comb the streets for places needing repair. However, the app's success would not have been possible without NUM's involvement. Expertise was needed to develop a solution with an algorithm sophisticated enough to translate data from smartphones into physical bumps on a street (see Figure 1). NUM partnered with software company Connected Bits and design company IDEO to come up with the innovative product, an example of sophisticated collaborations that can have real impact in a city.
Common platforms. The market for civic apps is virtually limitless, as civic needs are shared across municipal, regional, and national borders. However, most apps are designed for specific cities. This problem is due mainly to managers within government choosing to procure their solutions, whether developed in-house or through open innovation initiatives, as custom-tailored for their own cities. They imagine their needs are unique and want to showcase equally bespoke solutions. Yet starting from scratch takes time and resources well beyond those needed to adapt existing apps. And targeting software for a specific city decreases the potential commercial market available for the app. Small cities, in particular, lack populations large enough to support a community of civic app developers on their own, let alone justify investment in redundant functionality offered through existing software.
Application repositories, or marketplaces, provide a venue for civil servants or developers for sourcing existing solutions. The Civic Commons is such a marketplace, created to facilitate code sharing (http://the-civiccommons.com/). This collection of civic apps promotes their use and reuse, providing value capture for developers as their markets increase and savings for cities as they choose to adapt, rather than create, completely new solutions. Other repositories have been developed (such as Europe Commons; http://commonsforeurope.net/) that showcase civic apps and offer best practices and case studies to provide more value capture to developers and savings to cities.
FixMyStreet is a solution hosted on Civic Commons that exemplifies the benefits of city-sharing and modularized solutions.8 Developed by MySociety (https://www.mysociety.org/), a U.K.-based charity promoting e-democracy, FixMyStreet was originally developed to allow U.K. citizens to monitor and report street and road problems to their local councils. Recognizing its potential universal applicability, MySociety developed the solution as an easy-to-adapt platform for others. The FixMyStreet website (https://www.fixmystreet.com/) provides simple instructions for citizens looking to implement the solution locally.
FixMyStreet makes a case not only for city sharing and modularization but demonstrates the potential for real bottom-up, citizen-led impact. Unlike government-led initiatives, FixMyStreet requires few resources from city governments to be enabled. Citizens interested in hosting FixMyStreet in their locality need only the email addresses of civil servants or departments responsible for the issues on which a local citizen might report. A greatly enhanced channel of communication between cities and their constituents is thus created through citizens being able to adapt the platform or recruit others with the basic technical skills to customize the code and run the site. FixMyStreet has been used to report broken streetlamps, potholes, garbage collection, and even crime. It has been implemented in more than 15 counties.
With strained budgets, overworked employees, and other, more critical responsibilities expected on a daily basis, releasing data was not only a chore with no tangible benefit but also subjected municipal departments to unwanted scrutiny.
FixMyStreet also provides an easy-to-implement platform, with the same functionality and customization, along with training, maintenance, support, and Web and mobile app options. Average installation cost to a metropolitan area in the U.K is £15,000, with an annual maintenance and support fee averaging £2,500.9 FixMyStreet demonstrates how an adapted, modularized solution can provide benefits at relatively modest cost. U.K. councils reported up to a 300% shift from phone calls to online reporting following integration. FixMyStreet also reaches a new demographic that would have been less likely to report through traditional channels. Further, its customization allows some cities (such as Zurich, Switzerland) to respond directly to each citizen report and track its progress through completion.
OpenStreetMap is another open data platform that crowdsources the original content rather than working from city-provided open data. Frustrated by the restrictions on proprietary map data yet inspired by the success of Wikipedia, Steve Coast, a British entrepreneur, developed OpenStreetMap in the U.K. in 200410 to encourage its more than 2.2 million registered users (as of August 2015) to contribute, augment, and edit geographical map data. However, OpenStreetMap's greatest value is not the output of a crowdsourced map but an open data platform from which other applications, including FixMyStreet, can source their map data. Initiatives like FIxMyStreet and OpenStreetMap show how engaged communities, and open, crowdsourced content repositories can support civic app development.
Data standardization among cities is an area in need of improvement, restricting the potential market for a given developer's app and limiting potential value capture. Progress has been made, however, especially considering the early efforts of open data were in the form of static .pdf files published on a city's website. Civic departments have caught up and are adopting standards established by the World Wide Web Consortium (W3C; http://www.w3.org/) promoting the semantic Web and linked data, allowing not only machine-readable formats but information to be connected, queried, and shared more easily.11 The data can then be used and collated across borders in ways envisioned by developers, independent of the original structure or intention of the data provider. However, until these standards are more universal, coders must write numerous interfaces for each city and maintain them individually.
The transportation app Roadify, for example, provides transit schedules for New York commuters (http://www.roadify.com/). Interested in increasing app adoption, the developers realized other cities would need the same information provided through local open data repositories. However, co-creator Dylan Goelz said, "The trouble is that data is provided differently in every market. Google tried to standardize the data, but there are still discrepancies. San Francisco may do something that Boston doesn't, and it makes aggregating the data difficult. We had to develop our own solutions to be able to shift and adapt, which has cost time and money."
As most city managers do not yet realize the benefit of sharing apps among cities, they also fail to understand government databases can grow beyond a city's borders (see Table 2). Data standardization requires coordination and procedural changes that are both technical and political. W3C standards greatly enhance developers' potential to more readily integrate information from multiple cities. Such efforts promote standardization and not only further sustain the solutions but also leverage network effects toward greater developer participation and user adoption (see Figure 2).
Momentum continues behind open data and its potential to provide cost savings to cities and better service to citizens. Early efforts focusing on application contests with low governance failed to produce the results most cities hoped for, though they did provide insights into potential fixes. Second-generation initiatives have incorporated better management and knowledge transfer to increase value capture and impact. Bottom-up initiatives, crowdsourced content, and shared open data repositories and apps also support these efforts.
The main problems involve mechanism coordination. Progress thus needs to continue toward standardization of data formats and APIs to allow effective sharing in app markets. Application discovery remains problematic, as there are no effective discovery and diffusion channels beyond the most popular 100 apps. Also needed is efficient code reuse among public organizations that would allow not only better use of taxpayers' money but leverage network effects toward incremental and cumulative innovation.
Incentive management for all actors in such heterogeneous ecosystems is certainly more complex than in traditional markets. Three main problems remain. First, market fragmentation renders standard business models based on advertising or usage fees impractical, forcing app developers to resort to reputation or signaling as alternative modes of value capture. Second, trust is needed in the stability, continuity, and availability of open data streams and APIs that are not always secure in politically turbulent municipalities. And third, the inherent tension between collaboration and competition represents a managerial challenge in these complex and diverse ecosystems.
Open data strategies in the public sector should continue to evolve, and, with continued ingenuity, greater efficacy, impact, and social value. What open data and civic-app contest designers have learned is not special to the world of government data but extendible to other spheres of distributed, collective creativity common in other software development platforms.
1. Apps.Gov. Federal Government Mobile Apps Directory; https://www.usa.gov/mobile-apps
2. Bakici, T., Almirall, E., and Wareham, J. The role of public open innovation intermediaries in local government and the public sector. Technology Analysis & Strategic Management 25, 3 (2013), 311–327.
3. FixMyStreet. FixMyStreet for Councils; https://www.fixmystreet.com/council
4. FixMyStreet. FixMyStreet Platform; http://fixmystreet.org/
6. Lakhani, K.R., Austin, R.D., and Yi, Y. Data.gov. Harvard Business School, Cambridge, MA, 2010; http://www.hbs.edu/faculty/Pages/item.aspx?num=38841
7. Open Government Initiative. About Open Government; https://www.whitehouse.gov/open/about
8. Opsahl, A. Washington, D.C. reloads Apps for Democracy. Government Technology (June 2, 2009); http://www.govtech.com/pcio/Washington-DC-Reloads-Apps-for-Democracy.html
10. White House Status Report. The Obama Administration's Commitment to Open Government; https://www.whitehouse.gov/sites/default/files/opengov_report.pdf
11. World Bank Sanitation Hackathon. Sanitation App Challenge; http://sanitation.hackathome.com/
The Digital Library is published by the Association for Computing Machinery. Copyright © 2016 ACM, Inc.
Another very intriguing potential for acquiring more context in non-emergency issue reporting applications, is to harvest the opinion of social users and combine this with open data provided by the municipality. Given that a non-trivial number of the submitted issues/suggestions/initiatives maybe of general interest, it may be likely that a relevant discussion is taking place among the users of social networks. Thus, it could be an interesting additional source of information if we could spot the relevant discussions and analyze them with respect to their sentiment or prevailing topics. The analytics component of ImproveMyCity (http://www.improve-my-city.com/) relies on the contextually-rich nature of foursquare data, that are used establish the connection between a certain issue/suggestion/initiative and a set of user contributed discussions in an implicit manner. The foursquare application, apart from checking-in and categorizing a venue, offers also the option of providing “tips” (i.e. opinions) about a certain venue. Thus, if the issue/suggestion/initiative that has been reported by the citizen can be tightly linked to an existing foursquare venue (e.g. geographical proximity, or explicit reference of the venue name), then the “tips” that have been contributed by the foursquare users to characterize this venue can be consider to form a set of discussions related to the initial issue/suggestion/initiative. Based on this implicit interlinking we have been able to harvest the opinion of social users by performing sentiment analysis on the venue “tips”. A prototype version of ImproveMyCity-Analytics that is able to combine in a spatio-temporal setting the issues submitted by citizens, with open governmental data and foursquare data is accessible at http://lganalytics.mklab.iti.gr/.
Displaying 1 comment