For the next few Tuesdays, we will be excerpting sections from Beyond Transparency: Open Data and the Future of Civic Innovation“, an anthology edited by Brett Goldstein with Lauren Dyson and published by Code for America.
I wrote a chapter titled, “Building a Smarter Chicago“, which I call “an illustrative, incomplete, and idiosyncratic look at the ecosystem in Chicago. It is meant to provide a thumbnail take on how the ecosystem developed here, while sparking fires elsewhere”. Here’s the introduction and the first section, which gives a short history of the ecosystem:
Introduction
As the open data and open government movement continues, there is a lot of talk about building local ecosystems for the work. The general idea is that there has to be a mildly magic combination of data, policy, developers, capital, and products to enable the kind of growth that is necessary to take the movement to the next level—where there is a mature market for open government products that serve real community needs and lead to sustainable revenue.
The thing about building an ecosystem is that when it is done deliberately, it can be a slog. Building a developer community from scratch, convincing local government to publish data, getting venture capitalists to take a look at open government projects—all of this is tough work that takes time.
By looking at the Chicago example, however, we can see that there’s often more built than it first seems. The components can be found, in varying degrees, in any unit of government. The trick is to find, cobble, and congeal these pieces together.
What follows is an illustrative, incomplete, and idiosyncratic look at the ecosystem in Chicago. It is meant to provide a thumbnail take on how the ecosystem developed here, while sparking fires elsewhere.
Data: An Era of Incidental Transparency
The story starts with Citizen ICAM (Information Collection for Automated Mapping), the granddaddy of all crime mapping applications, created by the Chicago Police Department in May 1995. I wrote about this system back in 2006 because I wanted to understand the archaeology of this distinctly unique (and relatively difficult to use) interface (O’Neil, 2006). You can learn a lot about software by its backstory. Here’s the first sentence of a July 1996 National Institute of Justice report on Citizen ICAM:
To better understand the nature and extent of criminal and social problems in the community and improve allocation of resources, a growing number of crime control and prevention organizations are turning to computerized mapping. (Rich, 1996)
The impetus behind the project (“Citizen” is the first word in its name) was the Chicago Alternative Policing Strategy (CAPS) program. Here’s another snip from the 1996 report:
ICAM was developed as part of CPD’s far-reaching and ambitious community policing strategy. Unlike many other community-policing programs that are limited to a single unit in the department, the Chicago Alternative Policing Strategy (CAPS) is department-wide. The strategic plan for reinventing CPD describes CAPS as a “wholesale transformation of the department, from a largely centralized, incident-driven, crime suppression agency to a more decentralized, customer-driven organization dedicated to solving problems, preventing crime, and improving the quality of life in each of Chicago’s neighborhoods.
In fact, CAPS is really a city program with strong support from the Mayor’s office and close involvement of city agencies, which have been directed to give top priority to “CAPS service requests” that affect crime and neighborhood safety. (Rich, 1996)
This twenty-year-old project is a model for where we need to be now—and where the movement seems to be heading. It starts with deep input from residents to form a “customer-driven organization.”
In the technology world, we call these people “users.”
Adrian Holovaty’s ChicagoCrime.org—widely considered a major impetus in the open data movement—simply would not have existed without Citizen ICAM (Holovaty, 2008). At the same time, ChicagoCrime.org was certainly not well-formed public data. For instance, all data was retrieved by scraping with obscure URL calls that ignored the user interface, which limited searches to a quarter-mile radius.
Another example is transit data “published” by the Chicago Transit Authority in the context of their proprietary Bus Tracker system. I covered this extensively in a January 2009 blog post (O’Neil, 2009). The upshot is that Harper Reed scraped all data driving the app, cached it, and served it to developers. This led to a blossoming of transit-focused apps.
The culmination of this work is the publication of the CTA’s own API, a document wherein Harper and I are explicitly called out for helping them develop it:
Special thanks go to Harper Reed and Dan O’Neil for their support and encouragement, and to the independent development community, for showing such great interest in developing applications with CTA data, leading to the creation of this official API. Thank you. (Chicago Transit Authority, 2011)
This is the kind of inside/outside game that is also essential to the ecosystem. You have to work with government institutions to make their data fluency and data policy better.
A last example of early data in Chicago (and perhaps the first explicitly conscious publication of data in the city) is the wealth of Geographic Information Systems (GIS) data published by the City of Chicago. This was another early reason why ChicagoCrime (and, by extension, EveryBlock) could exist. Their policy was formalized in July 2007, but the data had been available long before that (City of Chicago, 2007).
The first section of their documentation, “Data Sharing Principles,” has the idea that public information should be public: “Wherever possible, direct requestors to publicly available internet sources of map information.”
This is the moment when the governmental provision of data goes from incidental to essential. Before that magic moment, it’s important for developers and citizens to look harder for data published in plain sight.
