This is Part I of a three part series. What is this Gov 2.0 stuff I’m writing about, and how is it even relevant to Madison? We’ll use Madison Metro as an example application.
Gov 2.0 means different things to different people, but in the context I’ll be describing today, it means Tim O’Reilly’s “Government as a Platform”. And to narrow it down a bit more, I mean Government as a Platform in the technological sense, not in other senses[1].
O’Reilly’s Government as a Platform vision is one of Government thinking about itself not as the complete supply chain and distribution network, right up to running its own “retail” website, but building its technology and data services such that it can be a wholesaler as well. Government can and should run front-end websites, but when it is building those websites and providing data to them, it should think about “how could we provide this data to someone else who wants to build this website.” There are some things that people and groups outside of government can do better than government, or that government just wasn’t going to do.
Yes, this gets dangerously close to the same intellectual underpinnings of outsourcing and privatization of core government functions, and to be clear, that’s not what I’m arguing for. Instead, I’m arguing for recognition that government can’t do everything, even if it wanted to. Furthermore, the world is not binary, with a clear line of “this should be public” and “this should be private”. In fact, the boundary layer can sometimes be a little bit fluid, and there can be space for multiple versions of the same thing. It should be permissible for government to do things that are valid for the private sector to do, and vice versa. If one side is doing it as well as could be expected, it may be the best thing is for the other to do is to stop spending time on it and focus on what it is best at or only it can do.
An example might make this more clear. Consider Madison Metro bus real-time location data, e.g. the GPS coordinates of every single Madison Metro bus right this instant. Metro wants this data for its own operational use, and the public wants a service that tells it when the next bus will arrive at a stop, which needs. Sure, a private company could have come in and contracted with Metro to outfit all buses with GPS trackers, and then sold the data to Metro, and created a subscription service to sell updates to the public. This didn’t happen for two reasons: one, the market for people willing to pay for bus updates is small, and two, Metro sees the real time bus updates as a public good and is willing to pay so anyone and everyone can have access to the updates.
Here’s where it gets relevant to Government as a Platform: Metro built (well, bought) a complete system to track and display the bus data on the web. Pretend for a moment that the web front is any good (it’s not) – for people with smart phones, it’s frustratingly unhelpful. The smart phone has built-in GPS, and knows exactly where it is, and in an ideal world, you’d just open up an app or a webpage and it would use the GPS from the phone, and the GPS data from Metro, and tell you what’s coming up with virtually no key strokes. And that’s exactly what people have done – BusRadar for Android Phones, Locomatix (as a demo project) or MadisonBus on the iPhone.
However, in order to build it, the smart phone developers spent more time trying to get the bus data than they did building their app running on the phone, because Metro doesn’t make the data easily available, except as a webpage designed for humans. This page is may be (somewhat) easy for humans to read, but it’s much more difficult for machines to “read”. Now, machines can find the data they’re looking for, but to do so is a process called “scraping” the data. And like the name suggests, it can be anything from mildly unpleasant to downright painful to “scrape” data from websites.
For Madison Metro data, an Application Programming Interface, or API, is preferable. An API is an easy way for a computer to say to another computer “please tell me this”. In fact, it’s such a preferable way to build a Madison Metro system that Greg Tracy, a local entrepreneur who also built a system for Madison Metro, built an API for it first. When he had his API, he then built SMSMyBus on top of that API. (And seriously, check it out. It’s my favorite of all the bus system services).
An API, however, was not something that Metro included in its requirements when it bought its tracking system, and that’s unfortunate. Metro could have insisted that its own tracking platform was built on top of an API that it could have made available to outside providers, or at least included an API as part of its requirements to make it easier for Metro to build alternative apps or for others in the city to build these apps. We can see that there has been substantial value added to the city with these apps – not necessarily monetary value, or at least quantifiable monetary value, but my bus riding experience is certainly better with these apps available. I never want to go back to using Metro without them, but there is still much to be desired with all of them. If the data was more easily available, it would be easier to write these apps, and we’d see more apps, more diversity of ideas and approaches, and hopefully better apps.
The government is required to collect much more data than just bus position data, and the potential for making this data available and to the world for valuable new services to be built is beginning to be understood beyond technology circles. In fact, one of the biggest blows to Madison moving forward in this area is the impending departure of Economic Development Director Tim Cooley, who absolutely got it and would have been a strong ally as we moved forward. Making this data available is sometimes referred to as “Open Government”, or “Open Government Data”, though open government is a much older and broader term, and historically has meant government transparency. For a better discussion of Open Government and Gov 2.0, see this post by Alex Howard on the relationship between the two, and how different people define the terms.
Government as a Platform, and making government data available and usable strongly compliments government transparency, and the same platform that makes it possible to build new applications to improve people’s lives also makes it possible to build applications that make it easier for people to participate in Government. In the next section, we will look at how Madison can better work towards building a platform that both increases transparency and enables new applications.
[1]. Tim O’Reilly likes to talk about “Government as a convener”, because Government is how we work together to solve common issues. In that sense, Gov 2.0 as a convener means bringing interested parties together to work closer together. As a local example, consider the Economic Development Committee’s work reviewing the process by which we evaluate and approve building projects in Madison. This has been the EDC soliciting comments, discussing those comments a bit, and trying to iterate on a report with its staff that makes recommendations on how to improve Madison. The comments from the community are limited to written comments, or 3 to 5 minutes of oral testimony (an important word, testimony) at the beginning of the meetings or public hearings. Explicitly missing – any way to have a serious conversation. As a community, we’re forced to have this conversation through an awkward process of speaking past each other and hoping the EDC connects the dots, and what could have been done in a few weeks is taking 9 months. We need to look for ways to ensure that the ability for all voices to be heard is preserved while finding a more efficient way to have a community conversation.
