Civic Innovations

Fresh off a week in San Diego for the annual Accela Engage conference (where Tim O’Reilly gave a keynote presentation) and some stolen hours over the weekend for hacking together an entry in the Boston HubHacks Civic Hackathon, I’ve got government APIs front of mind.

Getting to hear the Godfather of “Government as a Platform” speak in person is always a treat, and Tim was kind enough to share the awesome slide deck he used for his talk. The chance to follow up on an event like Engage with some heads down time to bang out a quick prototype for the City of Boston was a great opportunity to frame some of the ideas discussed at the conference.

For me, this quick succession of events got me thinking about both the promise and the pitfalls of government APIs.

APIs: The Promise

The thing I love the most about the Boston Civic Hackathon is the way the city approached it. Prior to the event, the organizers took time to clearly articulate issues the city was trying to address. Materials given in advance to participants provided exhaustive information about the permitting process and clearly listed the things the city needed help with. Additionally, a few experimental API endpoints were stood up for participants to use during the event.

These APIs weren’t the easiest to use but they were helpful in creating prototypes that would allow city leaders to see the possibilities of collaborating with outside developers. It should be noted that Code for Boston – the local Code for America Brigade – was heavily involved in the event. This was a smart move by the city to include the leadership in the local civic hacking movement in the event right from the start.

So, out of the gate, this event provided immediate tangible benefits for the city – without even one line of code being written. The city benefits immensely from the time and effort that went into describing and documenting the current permitting system and the many shortcomings it has. This is a process that far too few governments undertake, even when they are crafting expensive and elaborate RFPs.

There appeared to be a healthy level of participation, despite the fact that there was another hackathon happening in Boston on the same weekend, indicating that the message from City Hall was being taken seriously by the local technology community. In all, nine apps (including one of my own) were submitted for review – each of these submissions provides powerful insights for city officials into what is possible when governments leverage the talents of outside developers using an API.

But at the same time, I think this event helps to highlight some of the pitfalls that governments (particularly municipal governments) face when deploying APIs and moving towards government as a platform. These challenges can derail efforts to collaborate with local civic hackers to improve the quality of services that governments provide, so its important to understand what they are.

APIs: The Pitfalls

To it’s credit, the City of Boston took steps to create new APIs for it’s legacy permitting system – to allow civic hackers to create prototypes that can help illustrate what is possible. And, as it turns out, a good people want to take them up on this.

Boston is one of the most progressive cities in the country when it comes to engaging civic technologists. But building and managing a custom API can be a challenge for any government and it is an endeavor not to be undertaken lightly. In addition, along with the new role of managing a production-grade API for external development, governments face the relatively new challenge of building and managing developer communities around them. To put it lightly, this ain’t easy – particularly for governments that haven’t done it before.

It looks like Boston’s current vendor doesn’t supply a baked-in API for their permitting system, so the city stood up a few custom endpoints for developers to work with over the weekend. This is a great approach to support a weekend hacking event, but if the city is serious about coaxing developers into investing time and money building new civic apps on top of an API, the demands can increase dramatically.

Production APIs done right require stewardship – this includes ensuring adequate reliability, authentication, versioning and a host of other things that building a demo API does not. If developers perceive that an API is unstable or lacks proper stewardship, they won’t invest the time building services that take advantage of it.

Another potential issue for Boston is that – even if they are able to create and manage a robust API for developers – the API for their permitting system will likely differ from the APIs of other cities. So, they may not be able to leverage talent outside of those interested in building an app specifically for the City of Boston.

The more that cities can share common platforms and APIs, the more they can amplify the benefits of collaborating with outside developers – an app built in one city can more easily be deployed to another, making the benefits to developers that build apps exponentially greater.

It’s great to see the City of Boston actively organizing hackathons to solicit ideas for how government service can be improved. I hope this event, and others to come, can help focus attention on the significant issues governments face in developing and managing open APIs for civic hackers.