Today, representatives from dozens of countries are coming together at the United Nations in New York for the Open Government Partnership. They will discuss shared commitments to making government more accountable, efficient, and participatory. (See their lovely overview video below.) As I believe open data will need to be a centerpiece of that effort and others, I wanted to share some thoughts on the benefits of opening data in a proactive, structured, and engaging way.
Platforms for open data are effectively avenues for citizens — or rather developer — engagement. Many cities now feature open data catalogs, which tend to list the available data sets the city has opened up, linking to the raw files for developers to download and use. Others have deployed more sophisticated data hosting and management solutions, which not only list the data sets but provide direct access for developers via an API, and often provide visualizations. In either case, though, from what we’re learning from developers we’re talking to, ease of access to the data itself is key. That is, governments should aim to eliminate the roadblocks that stand between a data set and a good idea.
Open Data = Unlocking Good Ideas
Why? Because no one has a monopoly on good ideas. Openness allows for the unexpected, the unlikely, the unforeseeable; instead of just asking, what is needed, you can ask, what is possible. And you can mobilize a community of developers to build on top of your platform. This is critical in an era when governments don’t have the resources to explore every possible use of their data.
Consider the EPA, which recently opened up access to its API filled with location-based listing of pollution areas, danger zones, etc. During an one-day weekend hackathon, developers from across the country coded up multiple apps like where’s the closest swimmable lake or what’s quality of my drinking water. These apps came at the cost of a couple of pizzas and some coffee, thanks to the hard work of EPA staffers and their willingness the engage the community.
And the examples continue from the FCC, HHS, and numerous states and cities. The most prevalent one coming from transit agencies deploying the Google Transit Feed System. Developed initially as a partnership with Portland’s TriMet, led by Bibiana McHugh, and Google, GTFS is now a growing and common standard for transit data, which has enabled the use of not only Google Maps in many major cities, but also a host of other apps, like NextBus or the OpenTripPlanner. Now, transit agencies that adopt the GTFS standard unlock both a host of existing apps but enable more local development, customized for their city.
Bring Down the Barrier to Access
These work not only because the data was out there but also because the government leveraged some developer tools — that is, APIs, standards, wrappers, and gems — that made the API easy to use. Code for America is working actively on making many civic APIs easier to access, but governments could take an “API First” approach to ensure that from the outset. A popular phrase in the tech world is “eat your own dogfood.” Translated out of geek speak, this means that you should — whenever possible — actually use for yourself the technology you’re building for others. With an “API First” approach, your app “eats” your own API. That is, you make the data feeding your application independent of the application itself. Put in more practical terms, that means you should structure your data in an open way so that not only your app can leverage it, but others can as well, unlocking the opportunity for innovation from the start.
API-first kills many birds with one stone: with this approach “opening your data” isn’t an afterthought with additional cost, but rather just a part of building your tool in a smart way in the first place. This means from Day 1, outside developers can be hacking on your data — or even (gasp!) — developing with you, if you choose to be opensource from the start as well. Just as importantly, if when you eat your own dogfood you know how it tastes; you are more likely to create a good data platform if you’re actually using it yourself. And that’s exactly what the New York Senate did this with their website redesign.
Overall, when the data is open, and it’s easy to access, then you give the community the opportunity to innovate far beyond what your internal staff might be able to create. Consider the example of Twitter (which incidentally “eats its own API”). Instead of building a closed environment, where all tweets were posted and read through only its app, it built a top-notch, well-documented API, and now thousands of apps exist — and that number continues to grow. More to the point, Twitter is now increasingly baked into other platforms (like iOS soon), which means it is independently sustaining and growing. Reaching that level of integration would be a real win for government as a platform — where the data is so useful, the infrastructure so strong, that it comes laced inside consumer technologies.
Twitter and other consumer platforms are everywhere because they’re open. They went with a data-first model, and that allowed them to reach a massive audience and integrate with everything. This is a powerful approach, and one that it’s good to hear that our newly-minted Federal CIO Steve Van Roekel understands. As Alex Howard said, “Van Roekel is the man who told me in April that ‘the experiences that live outside of FCC.gov should interact back into it. In a perfect world, no one should have to visit the FCC website.’ Instead, he said, you’d go to your favorite search engine or favorite app and open data from the FCC’s platform would be baked into it.” There’s a certainly humility in that sentiment and approach, but it seems like exactly the right one for a government acting as a platform.
What’s Next?
Of course, these are just some of the known advantages to opening up data in a thoughtful, structured way. The real benefits remain to be seen, and that’s by design. The underlying value of open government — just like the web itself — is never the expected, prescribed, or planned outcome; instead, it’s the unexpected mashup or the innovative app. It’s what comes next.
Open Government from The Academy on Vimeo.
(Image credit: OpenSource.com)
(Note: This post initially misattributed the quotation from Van Roekel to Nick Grossman; it Alex Howard on O’Reilly Radar. The post has been updated accordingly.)
Open Data: Bringing Down the Barriers to Innovation
Posted on September 20, 2011 by Abhi Nemani in Commentary
Today, representatives from dozens of countries are coming together at the United Nations in New York for the Open Government Partnership. They will discuss shared commitments to making government more accountable, efficient, and participatory. (See their lovely overview video below.) As I believe open data will need to be a centerpiece of that effort and others, I wanted to share some thoughts on the benefits of opening data in a proactive, structured, and engaging way.
Platforms for open data are effectively avenues for citizens — or rather developer — engagement. Many cities now feature open data catalogs, which tend to list the available data sets the city has opened up, linking to the raw files for developers to download and use. Others have deployed more sophisticated data hosting and management solutions, which not only list the data sets but provide direct access for developers via an API, and often provide visualizations. In either case, though, from what we’re learning from developers we’re talking to, ease of access to the data itself is key. That is, governments should aim to eliminate the roadblocks that stand between a data set and a good idea.
Open Data = Unlocking Good Ideas
Why? Because no one has a monopoly on good ideas. Openness allows for the unexpected, the unlikely, the unforeseeable; instead of just asking, what is needed, you can ask, what is possible. And you can mobilize a community of developers to build on top of your platform. This is critical in an era when governments don’t have the resources to explore every possible use of their data.
Consider the EPA, which recently opened up access to its API filled with location-based listing of pollution areas, danger zones, etc. During an one-day weekend hackathon, developers from across the country coded up multiple apps like where’s the closest swimmable lake or what’s quality of my drinking water. These apps came at the cost of a couple of pizzas and some coffee, thanks to the hard work of EPA staffers and their willingness the engage the community.
And the examples continue from the FCC, HHS, and numerous states and cities. The most prevalent one coming from transit agencies deploying the Google Transit Feed System. Developed initially as a partnership with Portland’s TriMet, led by Bibiana McHugh, and Google, GTFS is now a growing and common standard for transit data, which has enabled the use of not only Google Maps in many major cities, but also a host of other apps, like NextBus or the OpenTripPlanner. Now, transit agencies that adopt the GTFS standard unlock both a host of existing apps but enable more local development, customized for their city.
Bring Down the Barrier to Access
These work not only because the data was out there but also because the government leveraged some developer tools — that is, APIs, standards, wrappers, and gems — that made the API easy to use. Code for America is working actively on making many civic APIs easier to access, but governments could take an “API First” approach to ensure that from the outset. A popular phrase in the tech world is “eat your own dogfood.” Translated out of geek speak, this means that you should — whenever possible — actually use for yourself the technology you’re building for others. With an “API First” approach, your app “eats” your own API. That is, you make the data feeding your application independent of the application itself. Put in more practical terms, that means you should structure your data in an open way so that not only your app can leverage it, but others can as well, unlocking the opportunity for innovation from the start.
API-first kills many birds with one stone: with this approach “opening your data” isn’t an afterthought with additional cost, but rather just a part of building your tool in a smart way in the first place. This means from Day 1, outside developers can be hacking on your data — or even (gasp!) — developing with you, if you choose to be opensource from the start as well. Just as importantly, if when you eat your own dogfood you know how it tastes; you are more likely to create a good data platform if you’re actually using it yourself. And that’s exactly what the New York Senate did this with their website redesign.
Overall, when the data is open, and it’s easy to access, then you give the community the opportunity to innovate far beyond what your internal staff might be able to create. Consider the example of Twitter (which incidentally “eats its own API”). Instead of building a closed environment, where all tweets were posted and read through only its app, it built a top-notch, well-documented API, and now thousands of apps exist — and that number continues to grow. More to the point, Twitter is now increasingly baked into other platforms (like iOS soon), which means it is independently sustaining and growing. Reaching that level of integration would be a real win for government as a platform — where the data is so useful, the infrastructure so strong, that it comes laced inside consumer technologies.
Twitter and other consumer platforms are everywhere because they’re open. They went with a data-first model, and that allowed them to reach a massive audience and integrate with everything. This is a powerful approach, and one that it’s good to hear that our newly-minted Federal CIO Steve Van Roekel understands. As Alex Howard said, “Van Roekel is the man who told me in April that ‘the experiences that live outside of FCC.gov should interact back into it. In a perfect world, no one should have to visit the FCC website.’ Instead, he said, you’d go to your favorite search engine or favorite app and open data from the FCC’s platform would be baked into it.” There’s a certainly humility in that sentiment and approach, but it seems like exactly the right one for a government acting as a platform.
What’s Next?
Of course, these are just some of the known advantages to opening up data in a thoughtful, structured way. The real benefits remain to be seen, and that’s by design. The underlying value of open government — just like the web itself — is never the expected, prescribed, or planned outcome; instead, it’s the unexpected mashup or the innovative app. It’s what comes next.
Open Government from The Academy on Vimeo.
(Image credit: OpenSource.com)
(Note: This post initially misattributed the quotation from Van Roekel to Nick Grossman; it Alex Howard on O’Reilly Radar. The post has been updated accordingly.)
Tags: DataCouch, Open311, opendata
About Abhi Nemani