Collect this post as an NFT.
Over 1.2k subscribers
(cross-posted on the MIT Center for Civic Media blog, the PBS IdeaLab blog, and the Harvard Data-Smart City Solutions blog)
A few years ago when I was working on the Civic Commons project with Code for America and OpenPlans, I did a presentation at Living Cities called “Cities that Work Like the Web” which discussed using open standards and internet architectures to build a foundation for open innovation.
At the time, we were doing a lot of work to advance the Open311 web standard, and had already done a ton of work around open transit data, including organizing developers to lobby NYC’s transit authority to open their data and then building out NYC’s real-time bus data platform.
My favorite story from this era is the story of how transit agencies came to adopt open data. Now, in 2013, it seems obvious that transit agencies would publish schedule, route, and real-time data in a machine-readable format for developers to build apps with. But back in 2008 & 2009, it was actually a huge struggle. There were two prevailing forces: 1) agencies not wanting to publish data at all, and going after developers who were scraping / using it anyway and 2) very slow-moving internal discussions around the development of an industry-led standard.
Those two forces were enough to basically keep the open transit data movement grounded. A little known fact outside the civic data world is that what made open transit data work was an outside force: Google. When Google Transit launched in 2005, they worked with Portland’s TriMet to design a new, lightweight, web-friendly open transit data spec: GTFS. That data was not only available to Google Transit, but also to anyone else who wanted to build with it.
Over time, more and more agencies began publishing their data in GTFS, drawn by the traffic that Google Transit saw. In effect, Google had created a “data magnet” — powered by their audience and by a lightweight web standard:
This was a tough lesson to learn but eventually more and more agencies got it: it was more powerful to have their data in Google’s app than to have visitors to their website. Or, as Steven Van Roekel, then US CIO and former FCC managing director said in 2011: “In a perfect world, no one should have to visit the FCC website.”
The big idea in all of this is that through open data and standards & api-based interoperability, it’s possible not just to build more “civic apps”, but to make all apps more civic:
So in a perfect world, I’d not only be able to get my transit information from anywhere (say, Citymapper), I’d be able to read restaurant inspection data from anywhere (say, Foursquare), be able to submit a 311 request from anywhere (say, Twitter), etc.
These examples only scratch the surface of how apps can “become more civic” (i.e., integrate with government / civic information & services). And that’s only really describing one direction: apps tapping into government information and services.
Another, even more powerful direction is the reverse: helping government tap into the people-power in web networks. In fact, I heard an amazing stat earlier this year:
http://t.co/y8HpNsFw has more potholes reported than all of the civic startups combined. @osalazar at #gpis #gov20
— Nick Grossman (@nickgrossman)
It’s incredible to think about how web-enabled networks can extend the reach and increase the leverage of public-interest programs and government services, even when (perhaps especially when) that is not their primary function. I.e., Waze is a traffic avoidance app, not a “civic” app. Other examples include the Airbnb community coming together to provide emergency housing after Sandy, and the Etsy community helping to “craft a comeback” in Rockford, IL.
In other words, helping all apps “be more civic”, rather than just building more civic apps. I think there is a ton of leverage there, and it’s a direction that has just barely begun to be explored.