Open311

Blog

The following re-post was written by Daniel X. O’Neil of The Smart Chicago Collaborative. It captured all the awesomeness of the Open311 launch in Chicago so well that it deserved to be re-posted here. The original post can be found at http://www.smartchicagocollaborative.org/the-launch-of-open311-in-chicago/

This afternoon the Mayor’s Office released two new resources for the people of Chicago:

The Smart Chicago Collaborative helped write the application for Chicago to become a Code for America city focused on complying with the Open311 standard, and we have funded this project from the start.  John Tolva, Chicago CTO and Smart Chicago Advisory Committee member, has been deeply supportive of the project and has shepherded it through to completion. Chicago Chief Data Officer and Commissioner of the Department of Innovation and Technology (DoIT) Brett Goldstein, along with Director Danielle DuMerer, has been instrumental in getting this project done, as were others at DoIT and people at Motorola Solutions and Connected Bits. Audrey Mathis, Director of 311 Services, has been great to work with as well.

None of this would be possible without Code for America, the ground-breaking organization founded and led by Jennifer Pahlka. The amount of work achieved under this grant is kind of stunning:

  • 311Labs: A space where your dreams of the possiblities of 311 data can become a reality!
  • The Daily Brief:  Explore and filter 311 service requests by neighborhood, service name, and status
  • Open311 Status: a site that shows if Open311 APIs are down or have performance issues, and provides Public APIs uptime, comprehensiveness and citizen utilization
  • Civiz: A polyglot Platform as a Service civic application
  • Civics Garden: Reflect, record—and be reminded of—your civic deeds and contributions
  • And all the normal code, design, documentation, and logo contributions you’d expect when you suddenly find yourself in front of smart Web people who can get things done

The Chicago Code for America fellows— Jesse Bounds, Angel KittiyachavalitBen Sheldon, and Rob Brackett deserve a ton of credit for drilling down into a set of tools that make sense for the particularities of Chicago while being broadly useful as reusable code for other municipalities. They moved the 311 movement forward in ways that will be felt for years to come. They are technically top-notch, excellent communicators, and real-deal project managers, all of them. They listened to our needs and were able understand the unique technology setup that lied beneath a simple desire to see the current status of a pending service request.

So get out there and track your favorite service request:

311 Service Tracker

Elsewhere:

Online system to track 311 calls

By Fran Spielman, City Hall Reporter for the Chicago Sun-Times, September 14, 2012

The technology upgrade will make the process of calling 311 to get a pothole filled, a tree trimmed or a broken streetlight replaced like using FedEx to send a package, under the plan, first disclosed by the Chicago Sun-Times last spring.

0 Comments Filed under Uncategorized 2:55 pm on September 17, 2012

In May I had the wonderful opportunity to present Open311 at the annual conference for the Association of Government Contact Center Professionals. This group can be thought of almost like a government equivalent of an industry association for contact centers. While the majority of those who attended were involved with 311 call centers, the AGCCP as a whole includes those involved with 911 emergency services as well as 211 human services hotlines, but it’s not even limited to call centers. There’s clearly an increasing focus on newer and more diverse channels to connect people with government. The membership makeup is primarily focused on the city level, but the association is also open to those involved with state and federal contact centers. I think this kind of broad inclusion represents a great opportunity to facilitate cross-pollination and collaboration between contact centers and different solutions much like we’ve started to see with the emerging ecosystem around Open311.

This event was also a very useful opportunity for me to start shaping a presentation of Open311 to an audience that already has an intimate familiarity with 311-like services, but has less familiarity with technology. In all honesty, this is exactly the audience that Open311 needs to engage with, but is largely the opposite of the audiences I’ve presented to in the past where there tends to be a common understanding of technology, but less of an understanding of the dynamics and challenges of facilitating interactions with government. Over the years my Open311 presentations have gradually evolved as the the effort and the community has progressed and while this presentation builds on an existing slide deck, I made significant efforts to break down concepts and take a less technical approach. In general, the presentation was well received by the folks at the AGCCP and throughout the conference I was surprised to learn how many cities were actively aware of Open311 and were making significant strides to work with it. That said, I know a lot more is needed to help convey the concepts and the value proposition behind Open311 in a way that doesn’t assume an understanding of technology or even an understanding of government contact centers.

I would love to ultimately develop a compelling story to tell mayors in the towns and cities around the world that have never had a government contact center. We need a presentation of the concepts, potential, and real world examples of Open311 that can give civic leaders a rich understanding of what this means both in terms of service delivery and civic engagement. We need a message that will inspire them to leverage this community and its emerging technologies and even leapfrog many of the costs and challenges associated with traditional contact center operations.

There was a video recording of my presentation at the AGCCP which should be made available within the next few weeks and I will update this post when that is ready. In the meantime, I leave you with the slide deck that was used and welcome any thoughts and feedback on how to convey the value and potential of Open311 to civic leaders of all backgrounds.

0 Comments Filed under Uncategorized 5:54 pm on July 19, 2012

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 technickle.nicklin.info. 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.

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

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.

Interactive Documentation
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.

GeoWebDNS
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

More Cities
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).

More Companies
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.

More Apps
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.

Get Involved

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 Comments Filed under Uncategorized 4:22 am on January 6, 2012

Baltimore 311The new 311 Mobile App allows citizens to have real-time collaboration with their government.
– Mayor Rawlings-Blake

The City of Baltimore has a long history of leading the way with 311. In 1996 they were the first city to deploy the 311 short code and unified call center and in 1999 the city launched CitiStat pioneering the use of statistics based performance management. Now both of these innovations can be amplified by a much more open and collaborative relationship between Baltimoreans and their government through Open311.

This week Baltimore announced that they have deployed the Open311 API placing them among the select cities which have implemented the GeoReport v2 standard. The city also launched a mobile app to provide its citizens with a much richer and more engaging interaction with the 311 system and, by extension, with their neighborhoods.

The new Baltimore 311 app can be found on the App Store for iPhone as well as on the Android Marketplace. There’s also a simple web app which provides a Twitter-like newsfeed of other reports.

With the Open311 API any developer can create an app that can integrate directly with the city’s 311 system. If you’d like to start building an app that connects to the Open311 API in Baltimore you can get an API key and get connected to their staging server. The Baltimore endpoints have also been added to the full list of Open311 GeoReport v2 Servers.

The launch of Baltimore’s Open311 apps and API was aided by the fact that they were able to leverage the Open311 compliant solutions provided by Motorola CSR and Connected Bits. Baltimore CIO Rico Singleton went as far as to say that their choice of software solutions was influenced by the interoperability provided by the standard.

With these moves, Baltimore demonstrated it is still at the forefront of urban innovation. I’m eager to see how the city leverages Open311 and continues to build on these successful and influential models for civic engagement and management.

This post originally appeared on the Civic Commons blog.

0 Comments Filed under Uncategorized 1:41 pm on September 10, 2011

David Eaves wrote a great post today highlighting the opportunity for Open311 integration with the Ushahidi platform. I ended up responding with a long comment and figured I’d post it here as well – particularly since we’re long overdue for an update and because I’ve covered many of the cities, vendors, and companies working on Open311 implementation, but haven’t covered the recent wave of open source efforts. In any case, here’s my response to David’s post:

Thanks for writing this up David. I expressed a similar sentiment in a post I wrote last year called Reporting Issues for All Occasions and during the RHOK event you linked to I did in fact finish initial integration of the Open311 GeoReport v2 spec with Ushahidi. There’s a demo of it up at http://ushahidi.georeport.org with familiar GeoReport endpoints being

This isn’t complete though and it’s not packaged in a way that integrates well with the rest of the Ushahidi codebase. I’m long overdue in better coordinating this with folks like Erik and others on the Ushahidi developer list where I’ve been lurking, but there are a number of efforts underway which will surely bring more of full Open311 support to Ushahidi. If there are folks interested in this, please let us know on our respective mailing lists:

It’s also worth noting that there are a number of other open source systems much like Ushahidi which have been working on support for Open311 GeoReport v2. These include two of the FixMyStreet codebases and Mark-a-spot.

Also see more open source Open311 efforts on the wiki and broader context from my recent Civic Commons talk at OKCon.

I should also state two of the main shortcomings with Ushahidi in it’s current state which I hope can be addressed with more developer involvement. 1) Ushahidi is great for simple reporting of problems, but needs more robust features to triage, assign, and track them 2) Ushahidi doesn’t currently use a true geospatial database, so you are limited in your ability to do things like query reports by a “geo-fence” (a polygon).

Accommodating features like this was part of our thinking in providing the benefit of a geospatial database for the Trac issue tracking system with GeoTrac and I think things like that can be part of a diverse ecosystem of issue tracking systems and Open311 implementations.

Currently, Ushahidi has the broadest number of international deployments and developers, so in my mind it’s one of the best places to focus for Open311 integration and it’s where I plan to put a great deal of my attention this year, but ultimately the goal is to let a diverse ecosystem form on top of a common platform.

1 Comment Filed under Uncategorized 8:07 pm on July 6, 2011

It’s been a while since there’s been an update here, but if you’ve watched the mailing list you’ve seen that work has continued to help ensure that the GeoReport v2 spec is clearly defined and stabilized. We’re almost ready to officially freeze the spec and many cities, companies, and developers have already been implementing the spec as currently defined. This includes San Francisco, Washington D.C., Boston, and several systems including SeeClickFix, Lagan, Motorola PremierOne CSR, ISC HeyGov! (using Microsoft Dynamics CRM Online), and Connected Bits Citizens Connect. If you know of others working to implement the v2 spec please let us know on the mailing list or here in the comments.

Over the past few months there has been a lot of feedback on the spec to ensure that it’s consistent, complete, clearly documented, and is being aligned with best practices for API design. We’ve tried to make it clear that the spec is still in a beta testing phase to better inform implementers and to encourage”bug reports” and other feedback. While the spec is not perfect, it has stabilized and matured to reflect a healthy evolution from where this initiative began. This is meant to be an iterative process, so all feedback will help to continuously improve the spec.

We’ve also been working out better coordination among implementers to more effectively establish consensus about the stability and finalization of the spec. Part of this also relates to the way this initiative is structured and managed. We’re going to work to have this initiative more clearly defined and run based on the Apache/meritocratic model template from OSS Watch. We’ll also start bringing more of the issues regarding the spec into the bug tracker to help manage them through resolution.

As we approach finalization of this revision of the spec the next step is to make tools available to test compliance of implementations. A few of these tools are already being developed and we’ll be sure to make them easy to find here on the website when they’re complete.

Stay tuned, there will be more updates soon and in the meantime you can get more details on the mailing list.

0 Comments Filed under Uncategorized 2:44 pm on October 27, 2010

The Open311 specification and implementations have developed rapidly in recent months and several developers and service providers have already integrated the first version of the specification into their technology. San Francisco has also moved their API from just  being available for testing to being deployed as a live, in-production web service. A full list of services and applications using this version of the API will be made available shortly.

From the outset, the API development has been versioned so that new specifications can be advanced while coexisting with older ones. With this in mind, the developer community, cities, and companies have been moving the conversation forward to evolve and improve the first specification so that it can be used by a wider audience.  The mailing list has come alive with feedback on a wide variety of issues and the two cities currently driving this forward the most, San Francisco and Washington D.C., have come together to agree on and fully interoperate with a new Open311 GeoReport v2 specification. Both of these cities are accepting requests for API keys (San Francisco, Washington D.C.) to develop with the new specification. A full run down of the changes and advancements will be made available shortly, but one of the first things you might notice is that we are now referring to this specification as the Open311 GeoReport API. The reason for this name is to clarify the specific functionality provided within the umbrella of all things that 311 services provide. It’s also meant to make it more obvious that the specification applies to those who do not associate these services with the “311″ name or shortcode.

We look forward to hearing your feedback so that we can better clarify the Open311 GeoReport v2 specification and give everyone a better sense of the current state of the Open311 effort. Please speak up here in the comments or on the mailing list. Also feel free to contact me directly. We hope to hear from anyone interested in innovating around this common foundation to help improve our cities and all communities.

0 Comments Filed under announcements 8:44 pm on May 6, 2010

Here’s the announcement from SFgov.org:

We are pleased to announce the release of our Open311 API. The design is a result of a collaborative effort between cities, non-profits and developers. We look forward to seeing what you produce.

You can request an API key from their website and read-up on the Open311 API spec and developer resources here on this website. If you have any questions or comments, please leave them here or on the mailing list. We look forward to working with the developer community and seeing some amazing Open311 apps!

2 Comments Filed under Uncategorized 8:57 pm on March 10, 2010

As White House CIO Vivek Kundra joined San Francisco Mayor Gavin Newsom, CIO Chris Vein, and Tim O’Reilly to signal the launch of the Open311 API in San Francisco the work towards spreading an open standard gained huge momentum. Yet we still need continued coordination and collaboration to deliver the vision of a distributed open platform that can be used in communities everywhere.

Both San Francisco and Washington D.C. are preparing to deploy their Open311 APIs within the next week and we will continue to provide updated information on API methods, registering API keys, and the distinction between using the API as a sandbox for testing and using it for full deployment. We will also be sure to clarify any nuances regarding the API implementation in these different cities – such as XML versus JSON output.

This is also a good opportunity to provide more background on the development of Open311. First, the history of the open model:

FixMyStreet was launched in the UK by MySociety almost exactly 3 years ago. This was followed by similar projects in other countries like Verbeter De Buurt in The Netherlands and SeeClickFix in the U.S.. About a year ago John Geraci started a dialog on DIYCity about providing this capability for the 311 system in NYC. This conversation caught the attention of The Open Planning Project which had been developing the idea too. The conversation also caught the attention of Dmitry Kachaev in Washington D.C. who was preparing to launch the second round of the Apps for Democracy contest. As D.C. prepared to open their 311 API, The Open Planning Project began to coordinate this as something that could be made into an open standard and created Open311.org to facilitate this.

Working towards an open standard: In mid 2009 D.C. developed their initial 311 API spec and SeeClickFix also released a draft spec. D.C. launched their API in the summer of 2009 and had many apps developed around it as part of their Apps for Democracy contest. In October of 2009, we held the Open311 DevCamp to help coordinate the development of this standard and related technologies with many different cities and companies. This also signaled the initial development of the Open311 API spec in San Francisco. The team in San Francisco led by Alissa Black and Jay Nath continued to facilitate development of the spec over several months with the input of many people involved in this effort like Dmitry in D.C., Kam Lasater at SeeClickFix, and myself. The current spec in San Francisco reflects this collaboration and their leadership to convene others. The D.C. API spec has also been undergoing a revision to bring it more inline with the spec that has been developed in San Francisco. The specification will continue to evolve through incremental iterations to allow greater interoperability and a better experience for developers and citizens using Open311 services.

The Open311 API spec coordinated by San Francisco is available on the wiki. Despite the fact that the APIs have not quite yet been deployed and some details of the spec have yet to be fully documented, we can already see some examples of the developer community preparing to work with it.

We look forward to working with other cities in support of this standard. Some cities like Boston and Edmonton are set to open their APIs in the near future and other cities like Seattle and Portland do not yet have a call center and should stand to gain a lot by being involved with this initiative from a fresh start. We also look forward to closer involvement with international efforts like Ushahidi. Ushahidi is a collaborative issue tracker which played a crucial role in the response to the earthquake in Haiti.

Stay tuned for more details about the deployment of the APIs, the release of reference implementations, and code libraries that can help provide integration with existing 311 systems.

Please leave us with your questions and comments and let’s continue to work together.

0 Comments Filed under Uncategorized 7:20 pm on March 5, 2010