The Open311 GeoReport v2 spec was finalized on 3-11-11. That date was historic instead for the heartbreaking Tōhoku earthquake and tsunami. I think that disaster revealed a great deal of civic minded compassion and heroism in Japan so it all may be interrelated in the end. With dozens of cities now implementing the spec, Open311 has come a long way since last March and so has Japan. The transition to a new year is always a time of reflection and list making so I thought I’d make a wish list for Open311.
Throughout the course of the year we’ve seen many implementations emerge and more recently there have been impressive examples of cities and counties developing their own open source Open311 software stacks. To compliment their homegrown Open311 CRM, the city of Bloomington, Indiana has developed GeoReporter, an Open311 iPhone app which also works with other cities and Miami-Dade County has also developed a CRM middleware server which can be used with other governments. Yet even with all this activity, there’s always more that can be done.
In September, we started a substantial effort to identify how the next version of the spec would evolve, but feedback about the state of the current spec has led me to focus more on improving the documentation and infrastructure of GeoReport v2 before focusing on the next iteration. We’ve recently started discussing a redesign of the website, I’ve started working on an improved version of the docs, we’re trying to better manage bugs and feature requests, and also to track implementation issues. Even after all of that, a wish list has been emerging for things that I think would really give the current specification better footing and more reach: the documentation needs to be clearer and easier to use, we need to do a better job of ensuring compliance and interoperability, and we simply need to bring more diversity and scale to the ecosystem and demonstrate the value proposition of this platform. There’s more we can do.
The rumor is that this year Code for America will make a big impact on Open311 by continuing to build off of their already impressive contributions and by working with new cities. The Code for America fellows will be working with the city of Chicago as well as a number of cities who are interested in implementing the standard and the ecosystem of tools that come with it. With that on my mind, I thought I would lay out a wish list and invite the 2012 Code for America fellows and everyone else to help us build an even more solid foundation for the Open311 platform. What follows is that wish list.
Documentation & Infrastructure
An Open311 Validator
Build a web-based validator to test implementations
The easiest way to track compliance and interoperability of GeoReport implementations would be to have a web based validator that can be used as a simple web form much like the W3C validator, but for more complex API interactions rather than just validating a schema. From there, you might as well have it occasionally run tests on known endpoints to show the status of the all endpoints in one place. Over the past year or so there’s been some work on a validator. An early version was developed by DC OCTO in Python and SeeClickFix has more recently been developing one in Ruby. I’ve also recently started to play with an API testing tool called api-easy in node.js (Mark Headd has a node.js client library too). Currently, these are all just command line tools, but the next step is to make them web based and make it very easy to see how compliant an endpoint is when you’re building a client app or want to connect to it.
Implement I/O Docs or similar interactive API documentation framework.
We’d love to provide a way for people to experiment with the API while they’re reviewing the documentation. This can be done with open source tools like iodocs and aided with web-based consoles like the one Twitter uses from Apigee. Setting up the configuration for iodocs could also go hand in hand with setting up the validator (iodocs and api-easy are also both node.js). Furthermore, making sure something like iodocs is working properly should also help us consider how to provide better written documentation.
Build off of the GeoWebDNS concept with an administration interface to manage new endpoints.
As more cities stand up their endpoints, it becomes more of a challenge to know they all exist and make sure client applications can discover them. Several years ago we started thinking about an idea called GeoWebDNS that would essentially act as a geospatial lookup service for geographically bound web services. Ian Bicking, built a proof of concept and I later discovered that the FCC was evaluating a similar, albeit more robust, proposal called LoST (see reference implementation) to be used for the same purpose on Next Generation 911 services. So far, these are merely proposals, but we’re increasingly in need of one of these systems to be put to use as a real world pilot and eventually to act as a critical piece of civic infrastructure.
More, More, More
Help more cities implement the spec
There are currently over two dozen cities that are implementing the Open311 GeoReport v2 API, but there should be more. One thing that would be really helpful would be to identify what’s preventing a city from implementing and then help focus on solutions to address that. These reasons can span a wide range from the small towns that can’t afford a CRM offering to the large cities that have too complex of a 311 system to be able to easily integrate an API that works for the whole city (and which might benefit from starting with a more targeted pilot project approach).
Inspire more companies to build and support apps
There’s currently somewhere between five and ten companies that provide support for the Open311 GeoReport v2 API in different applications and services, but there should be more. These companies range from the early supporters like SeeClickFix and Connected Bits to the well established CRM vendors like Motorola and Kana Lagan and even to companies like Mark-a-Spot and Joget which can support their open source offerings. In the next year, I look forward to seeing more support from the prevalent CRMs (including Microsoft, SAP, and others) and I also look forward to more entrepreneurial start-ups in the spirit of SeeClickFix and Connected Bits making a huge impact across numerous cities. There’s clearly an opportunity for people to step up and start new companies or provide support for the growing ecosystem of technology in this space and I think efforts like the Code for America Accelerator are on the right track to harness that opportunity.
Help grow the ecosystem of Open311 compliant apps, particularly mobile apps
Between the supported apps & services and the emerging open source projects, there are currently about 20 different pieces of software that implement Open311 GeoReport v2. To my surprise, the majority of these have turned out to be more focused on the server side rather than the client side. I think we need more client apps, particularly mobile apps, as well as things that provide better visualization and contextualization. Apps like the mobile app from SeeClickFix have been around for a while to hook into GeoReport APIs and Bloomington is releasing an open source iPhone app that can work with any compliant city, but I think there should be more choices on more mobile platforms. I also think it’d be great to see Open311 support as an added feature for an existing app. Perhaps an app that integrates with Twitter or Foursquare could also work with Open311 endpoints and know how and when to make that connection.
Open Source Ecosystem & Community
Open311 support for the Ushahidi web platform
Implement the GeoReport v2 API in Ushahidi to act as a server endpoint. For bonus points, also implement it as a client that routes to other endpoints.
I’ve often heard Ushahidi referred to as the “WordPress of web mapping.” It has been used far and wide, especially after gaining attention for the major role it played in mapping the aftermath of the 2010 Haiti Earthquake. Because Ushahidi has developed as an international open source project, it is implemented in a broad number of places. Often times these implementations are ad-hoc unofficial systems that serve as the only reporting and coordination platform available. Other times they’re used in more of an official way, as we saw with NYC during Irene. In either case, there are problems with connecting the platform with those who need it. When it’s implemented only in response to a problem, it can be difficult to get people familiar with it and let them know it exists in the same way they might be familiar with a more permanent everyday 311-type of system. Even when used officially or permanently, Ushahidi instances are often not integrated with the established communication and response processes like any kind of 911 or 311 system. For all these reasons Ushahidi is an ideal platform to integrate the Open311 standards. Some of this has already begun with a proof of concept to connect the Ushahidi data model with the Open311 API and the beginings of an Ushahidi plugin. To learn more about what has already been developed, see this project page from RHoK. I’m happy to help coordinate this and Heather Leson has offered to help act as a point person for the Ushahidi Team.
An end to end open source stack
Mash-up an end-to-end open source stack by building off of existing mobile apps, CRMs, workflow tools, and visualization dashboards.
Bloomington, Indiana has single-handedly built out a substantial portion of an Open311 software stack with both a mobile app and a CRM, but a more complete open source stack has yet to be pieced together. Fortunately, there is a lot of code available out there, with projects like the Open311 Dashboard and Joget Workflow from Code for America as well as the code from Miami-Dade County, Mark-a-Spot, FixMyStreet, and even planned support in new projects like Shareabouts. There’s also a wiki page to highlight visualization libraries that you might want to put to use. Libraries like Raphael have been put to good use for things like the Birmingham Civic Dashboard.
That’s all I’ve got for now. If you’d like to hack on any of these projects please be sure to join the mailing list to ask questions, tell us what you’re thinking, and find out if there are others working on the same thing you’re interested in.
5 responses to “An Open311 Wish List”
Great list. I’d add one more item: Open311 Literacy.
By “Literacy”, I mean more people inside and outside government who see the potential for Open311 to transform civic processes. We need more people outside the technical implementation community who understand that 311 services are much more than just a way to report potholes or other civic issues. People who get that this is a new framework for empowered citizens and progressive cities. We need more people speaking the Open311 language, not at the level of specs and validators, but at the higher level of implementation and social benefits.
This literacy and wider acceptance probably comes from evangelism — story telling, case studies, targeted blog posts written for certain audiences. For example, planning staff at a transportation department likely need a pitch that’s tuned to their specific issues. Those local pitches are something that many of us can contribute to — perhaps in the form of a cookbook to be used alongside the other documentation.
Such a great wish list!
The last year has been exciting for us. It is amazing how many agencies are excited about going mobile and using open data.
Keep up the great work!
Somewhat surprised not to see the Inquiry API mentioned. Did I miss it?
I think 2012 could be a huge year for the Inquiry API. In fact, I think it could be something that cities look to adopt sooner than the standard GeoReport API.
Yeah, the title of the post should really have been “Open311 GeoReport v2 Wish List.” I sort of made that point in the post, but it’s not clear with the title of the post. There’s been too much unfinished business with GeoReport v2 and infrastructure for me to be able to put attention elsewhere just yet.
If this was really a wish list for the whole Open311 effort, the top of the list would be some actual funding or human resources to help move the effort along.
Surprisingly enough, there’s no funding or revenue source for me to work on Open311 at all right now, but we’re working on it.
As far as the Inquiry API, I think it just needs some proposals building on NYC’s draft, so that the spec isn’t as NYC specific as it is now. Though ultimately, I think there’s an opportunity to do more to integrate GeoReport and Inquiry so you could have a ticket for requesting a service and you could have a ticket for requesting an answer.
Thanks for the clarification Phil.
i’d love to help raise awareness of and interest in the Inquiry API. I think there is so much potential there for innovation and improved efficiencies.
Going to blog about this soon. Will link back here.
Thanks, as always, for all of your hard work on this!