Tackling the long-term strategy of Open311

by Philip Ashlock

The following post was written by Andrew Nicklin of NYC DoITT, a long time member of the Open311 community. It’s a cross-post from the original at The points Andrew raise about the challenges of scaling Open311 as an open platform are spot on and the whole post seemed important enough to re-post here. Andrew also thought it’d be best to get feedback about these issues here on the main Open311 website.

As Open311 adoption grows rapidly, with more endpoints on the way, it’s time to start developing a broader strategy to solve some new problems that will emerge. I think one of the first of those problems will be recognizing where someone is, and connecting them automatically to the right Open311 endpoints (yes, I do mean plural- more on this in a moment). In his Open311 Wish List, Philip Ashlock starts to tackle this:

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.

So with that goal in mind, here are a few issues that I think need to be tackled in order to have a sustainable future.

  1. API Keys. At present, 8 of the Open311 endpoints (Baltimore, Bloomington, Boston, Brookline, Grand Rapids, San Francisco, Toronto, Washington DC) have distinct API key request mechanisms and key management solutions. The rest of the endpoints leverage a common SeeClickFix solution. (SeeClickFix also offers a proprietary API). As more endpoints are added, having to manage an array of endpoint keys is going to become untenable for the developer community.
  2. Authentication/Authorization. Although there isn’t yet clear consensus from the members of the Open311 community about how authentication/authorization fits in to the drafted specifications, one thing that is clear is that having to manage a customer identity at each endpoint will not make it easy for a customer to request services.
  3. Terms of Service. Along with requiring the independent provisioning of API keys and customer identities, each endpoint also has different terms of service which a developer must explicitly agree to, and a customer must implicitly agree to. Having to comply with multiple, differing terms of service is going to become untenable for the developer community.
  4. Geographic overlap. 311 as a telephone service is constrained to one call center/answering point per geographic region; this is imposed by the very one-to-one nature of a phone system. While following the same model has served the Open311 mission very well to-date, this isn’t the reality of how service providers work in the real world, and I think it will reduce the long-term sustainability of Open311 to stay with a one customer-to-one provider model. A customer can only be in one location when making a request, but they could be making a request to their local town/city, to their local county, their state/territory, their nation, or even to the world (e.g. the United Nations). Each of those tiers offers a distinct set of services, and in the ideal scenario, all of those services should be presented to a customer in a unified manner, regardless of who is offering them. At the moment, we all get around that problem by providing information which, technically speaking, is really the responsibility of others to maintain. For example, you can contact NYC 311 and ask how to obtain a driver’s license, and you’ll get an answer - but that’s a New York state-provided service, and they should own it.Incidentally, tackling this issue might eventually drive official 311 systems to leverage Open311 to make calls to other overlapping service provider systems.

    A final note on this: neither GeoWeb DNS, nor LoST (IETF RFC 5222) seem to support returning multiple services per query.

The good news is that I believe there are solutions to all of these challenges. Before we start digging into those, however, I invite the community to comment on these and, more importantly, identify other challenges which I have missed or am unable to see from my perspective.

Filed under Uncategorized 5:58 pm on February 1, 2012

No comments yet.

Leave a comment

RSS feed for these comments TrackBack URL
Open311 GeoReport API
spacer View the GeoReport v2 API Specification
Open311 Cities
The following are some of the cities which have implemented the GeoReport v2 standard:
  • Toronto, Ontario
  • San Francisco, California
  • Washington D.C.
  • Boston, Massachusetts
  • Baltimore, Maryland
  • Bloomington, Indiana
  • New Haven, Connecticut
  • Tuscon, Arizona
  • Darwin, Australia
  • Manor, Texas
See full list
Open311 Apps & Services
There is a burgeoning ecosystem of apps and services which work with the Open311 GeoReport v2 standard. This includes a number of solutions with Commercial Support and a variety of Open Source options.
About is meant to facilitate an international effort to build open interoperable systems that allow citizens to more directly interact with their cities. Learn more →

The Open311 initiative was established by OpenPlans and is managed by Civic Commons.



Activity Stream
Tag your tweets with #open311 • Follow @open311
Recent Posts
  • Tackling the long-term strategy of Open311
  • An Open311 Wish List
  • 311 Pioneering Baltimore Continues to Lead with Open311
  • Ushahidi and the Open311 Ecosystem
  • The Open311 GeoReport v2 Spec Stabilizes
  • February 2012
  • January 2012
  • September 2011
  • July 2011
  • October 2010
  • May 2010
  • March 2010
  • February 2010
  • January 2010
  • November 2009
  • October 2009
  • September 2009
  • July 2009
  • June 2009 is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.