The earthquake in Haiti can be an important reminder of role that communications technology plays in dealing with crises. I also think this is an opportunity to consider how our use of day to day technologies can better prepare us for responding intelligently when there is an emergency. As described by this Urban Omnibus story about the seemingly benign NYC steam system, there are cases where 311-like reporting has the potential to prevent disasters in the first place.
Within the software development field, there is rarely a distinction between the tool you would use to report a problem and the tool used to make a request for an enhancement. Additionally, there is rarely a distinction between the tool you would use for various severities of problems be it a minor user interface bug, a bug that causes a serious error, or even a bug that exposes a major security hole. For example, if I was going to report a new bug about the Firefox web browser, my options would look like this:
Since bug reports are usually made public I can first see if the issue has already been reported and add to the original report instead. This same open source philosophy is what underpins the concept of an open 311 and we were very conscious of this in adapting the Trac bug tracker into the GeoTrac issue tracker.
In this context, the difference between 311 and reporting software bugs is that 311 is explicitly meant to deal with non-emergencies. However, I am now beginning to wonder if this should always be the case. Emergency services stand to benefit from being interoperable with the ecosystem of 311 technology. That said, there are many good reasons why services like 911 and 311 are separately prioritized systems and I certainly don’t want to encourage 311 requests to go to 911 or vice versa. I do however advocate for 911 to integrate with and provide the same technologies that 311 systems offer. A person should be able to report on and follow-up on an issue the same way regardless of whether it’s a crime, an accident, or a non-emergency. Both 311 and 911 phone calls could even be followed by an SMS message containing a link or SMS script to allow you to update the issue with a precise location, photos, videos, and more information. Even though 311 and 911 are meant to serve different priorities, they have many of the same requirements, so it makes sense to utilize parts of the same platform for both contexts. Yet there are other reasons why emergency and non-emergency services might benefit from sharing the same platform.
In a major crisis there is some chance that communications for emergency services will not be able to serve the demand - either because of heavy call volume or because of compromised communications infrastructure. As reported in this Wall Street Journal story, the communications system in Haiti was not fully holding-up following the earthquake. Additionally, there are many crises, such as widespread disaster or politically fueled turmoil, where the authority responsible for emergency services has been compromised. In situations like these, you have to make use of self-serviced issue reporting, SMS if possible, and if all else fails - some kind of adhoc-communication system. When a cellphone network is under heavy load or has intermittent connectivity, SMS is a much more reliable way to communicate than voice phone calls. These types of environments are exactly what crowdsourced crisis mapping tools like Ushahidi were created for.
Ushahidi is the crisis mapping tool seen in use at the top of this post. It’s an open source platform that was originally created to receive SMS and web-based reports of violence and other issues during the fallout from the 2008 elections in Kenya. Shortly following the Haiti earthquake an instance of Ushahidi was made available to start collecting reports from the field. Reports can be sent via SMS, email, twitter or a web form. More details are available at http://haiti.ushahidi.com. This may look and sound familiar. On a technology level, there is very little differentiating this from a 311 issue-reporting system. And sure-enough Ushahidi is in use for more 311-like applications such as Atlanta Crime Reports shown here. Compared to traditional emergency communications systems, there is one major disadvantage to setting up an adhoc system like Ushahidi: familiarity. Since this instance of Ushahidi only came into existence following the earthquake, its use is probably stymied by lack of awareness more than anything else. Ideally, the word will spread, communications systems will stabilize, and it will offer a core utility for the process of recovering from the disaster. Furthermore, the tool will hopefully stay in place permanently and more people will become aware of it and relevant authorities will learn how to work with it. The next time an issue comes up people won’t have to learn about something new within a potentially chaotic and communications-troubled environment.
People in the U.S. and Canada have been familiar with 911 as a standard way to ask for help for about 40 years and many cities have become very familiar with 311 in more recent years. New Yorkers are incredibly familiar with the utility that 311 offers them. We are also constantly reminded, “See Something? Say Something,” (though surprisingly the posters that announce this instruct us to call neither 311 nor 911). It turns out that New Yorkers are so familiar with 311 that by 11am Wednesday morning the NYC 311 system had received over 10,000 calls regarding the crisis in Haiti. Teaching people how to use a system to deal with small problems on a daily basis is a good way to prepare them for using the system to deal with an emergency.
The challenge then is to provide a platform that people can be familiar with, that is accessible through a variety of means, and that routes information to the right place without fragmentation or duplication. This is the goal of the Open311 effort and it’s the goal of those working on crisis mapping technologies. Where ever I am I should be able to do something as intuitive as sending an SMS to 311 or using my favorite 311-like app and know that my report is being routed to the correct agency. This kind of infrastructure should be available everywhere so that it’s ready for a crisis. Like the internet it should be a robust, distributed, fault-tolerant system so that it can withstand a major catastrophe like an earthquake.
I hope to coordinate with the those developing emergency services and crisis mapping so that the technology built for the benefit of 311 can also be used in a time of emergency. There is clearly an opportunity to integrate or complement existing standards for emergency management (like the Common Alerting Protocol and IPAWS) with the emerging standards around 311. Additionally, Ushahidi is not alone in this space. Ushahidi uses FrontLine SMS for text messaging and there are other SMS platforms like RapidSMS and Slingshot SMS as well as tools like GeoChat and SwiftApp that contribute to this field. Using the best qualities of tools like Ushahidi with the increasing familiarity and ubiquity of 311 applications, we can provide a healthier and more interconnected immune system to help communities in need.
San Francisco is the city currently leading the charge in the Open311 effort and they are holding a public conference call to solicit feedback on the development of their API and I will quickly follow that up with updates here about their progress as well as new developments like GeoWeb DNS.
Please help support the enduring spirit of the people of Haiti and help build a better future for the poorest nation in the Western hemisphere: http://www.google.com/relief/haitiearthquake/
This follow-up is long overdue, but progress has certainly not slowed. My initial DevCamp follow-up pointed to most of the resources that came out of the event, but I’ll run through them again. The video stream of the DevCamp is available here. The IRC log is available here. Some of the main wiki pages created are:
So again, the main focus is still coordinating a standard API, but this group should also be leveraged for sharing best practices around 311 services in general. Please use the wiki and mailing list to help facilitate better communication between cities and other entities. If you are not already on the mailing list, please subscribe at: http://lists.open311.org/discuss
For a more full follow-up, let me review some of the things that left the strongest impression on me both during and following the DevCamp:
This issue comes up over and over again when one looks at the usability of service request systems currently in place in most cities. The problem is that most existing systems have a very cumbersome process of collecting a required set of fields in order to submit a request. The problem isn’t as apparent when speaking to a call center because the complexity of required fields is often completely curtailed by the operator, but with most on-screen interfaces the complexity of the required fields often makes the system unusable. This was one of the main topics of conversation when discussing a standard API and we couldn’t help but joke about the absurdity of some of the required fields for some service-request types in DC’s 311 API, like the list of available colors to identify an abandoned bike. Dmitry conceded that if an image is attached to a submission it can negate the majority of required fields for many service request types. In some cases, the problem is just identifying the service request type from the beginning. For example, try to navigate the ontology to report a pothole in NYC’s 311 list of request types. So the problem remains, how do you provide a user interface that makes it extremeley easy for someone to submit a request without too many required fields or a complex ontology of service request types? I think the answer is a two-tiered approach. First you allow submissions with the most basic core set of fields. The submissions then sit in a public holding bay where you or anyone else, including a city worker, can review the submission and help complete all the required fields. This two-tiered approach is the process we are currently using for our FixCity Bike Racks project.
When I talk about the value of opening and standardizing 311 systems, I tend to look at it from outside government and focus on the benefits of better connecting citizens and government. However, many of the people at the DevCamp from within city governments mentioned the value of improving inter-agency communications and I think that’s really important to keep it mind, so I’ll be sure to emphasize that in the future.
Something I tried to say whenever discussion of Twitter integration came up was that if you’re discussing short-from submissions, then you should also be talking about SMS integration. Since SMS provides much wider coverage to a much wider demographic than Twitter, I thought this was an important accessibility (and digital-divide) issue to raise. Having said that, I was reminded of how expensive SMS is for services to support (and there’s some discussion of this on the TOPP Labs blog today). The far more universal and far cheaper medium is voice (phone calls) and obviously that is how the vast majority of 311 communications occur. As I mentioned in my Gov 2.0 talk, we are now at a point where voice can seamlessly integrate with web APIs. I don’t think this is something that received nearly enough attention at the DevCamp. It turns out that on the day before the event, Mark Headd wrote an excellent post about voice and web APIs for 311 on the Vox Populi blog. I know Troy Davis from CloudVox participated in the DevCamp remotely, so maybe he has more to say on this as well. Ribbit just opened up their voice/web-api service and there are already some cool demos starting to come out of that.
This rough outline is the result of further considering how the different parts of the Open311 model must to fit together
There are at least three open source service request web apps that are available for anyone to implement a draft API spec.
An abstract and some of the terminology relating to an API was put into the wiki on the Open311.org Draft Spec page and I’ve started sketching out my interpretation of a possible schema in JSON on that discussion page. Syntax highlighting is enabled on the wiki if people want to put in snippets of code or structured data to discuss.
We should continue to help coordinate the details of the spec, but I think this should be done simultaneously with iterative reference implementations. I think slight variations of APIs and schema like this will emerge both experimentally and in-production. San Francisco’s 311 API will be a useful reference point since it will represent the second city (after DC) to provide a read/write API and the first real opportunity to consider interoperability. With continued coordination we can see what works best.
So there’s a bit of a brain dump for now. I look forward to hearing your feedback and continued coordination on the mailing list and wiki.
We’re still in the process of collecting all of the material from the DevCamp, structuring it on the wiki, and recharging the mailing list to coordinate next steps for developing the API. For now, this video provides a good summary of some of the things that were covered at the event. The video is broken into groups which have wiki pages to organize their further development:
The wiki was also seeded with other new content including descriptions of the 311 systems in the cities that people were representing. We’ll be sure to follow up with the rest of the video content, a full summary blog post, and further coordination on the mailing list.
On October 24th, The Open Planning Project will host Open311 DevCamp at their NYC office. Please register to attend either in-person or remotely via Eventbrite (it’s free). This is a DevCamp style un-conference to coordinate a standard specification for 311 services. Washington D.C’s 311 API will be a major case-study for developing a more universal 311 API. In general, this DevCamp will be an opportunity to discuss and develop what’s needed to make 311 services more accessible and for cities to share knowledge for mutual benefit. The event is intended for developers, project managers, and policy makers involved with 311 services. We encourage those involved with 311 services from all cities to take part. If you cannot attend in person, please sign up as a remote attendee and we’ll provide you with information about how to connect to the DevCamp remotely.
Please register at http://open311.eventbrite.com
The wiki page for the event is http://wiki.open311.org/Open311DevCamp
Last year Google created Project 10^100 as a call for ideas to change the world by helping as many people as possible. It took them a while to review all of the submissions because they received about 150,000 spanning 172 countries. A number of the submissions described similar ideas, so Google narrowed them down to 16 core ideas. Two of these ideas describe what we’re doing here with Open311. The more broad idea is to Collect and Organize the World’s Urban Data which includes the example of “creating a website where residents can text or upload photos that highlight city issues,” but the idea that is truly spot on is to create a real-world issue reporting system. Please vote for these ideas (before October 8th!) and let’s use Open311 as an organization to bring this to life.
Google’s Project 10^100: Create real-world issue reporting system
Build an issue-reporting website that lets people report problems to proper authorities. When software testers find errors, they generally submit them to a tool which automatically routes them to the right team to be fixed. Implementing proposals for this idea might involve creating an analogous system for the real world that lets anyone report a problem of any kind (e.g., a dangerous pothole), and routes problems it deems sufficiently important to the proper authorities (e.g., the relevant road agency). The aim would be to incorporate all the niche applications that users suggested, including reporting crimes to the police and environmental issues to local governments.
“Open 311″ has been used to refer to a few different things. To clarify, the intent of this website is to create a standard specification to turn 311 services into an open platform. I call this Open311, but really, it’s is a standard that does not yet exist. There won’t be any one specific app or API implementation that can be referred to as “The Open 311,” but as an open platform there will be a multitude of Open311-compliant apps that work with a multitude of Open311 API implementations. This is the architecture of an open platform.
Much of what distinguishes a platform from an open platform is covered in a recent post that describes the web and democracy as examples of open platforms, but the fundamental point is that an open platform can’t exist until an open standard does. In the context of 311, an open platform is one that makes service requests publicly available and enables participation through a read/write interface. Additionally, an open standard gives this platform complete accessibility, collective innovation, and a distributed model with scalability and stability.
Some of the ambiguity regarding “open 311″ was brought out at TechCrunch 50 during the launch of a new 311 service called CitySourced. After CitySourced founder Jason Kiesel presented the product a panel asked questions and offered feedback. Tim O’Reilly was one of the panelists and said:
I’m a huge fan of this type of application and ever since Thomas Steinberg built FixmyStreet.com in the UK it’s been pretty clear that this was the way to go. But I worry a little bit about the defensibility of the product. What’s your thinking about how you become a market leader? Is this something you just have to get out there and sell to a lot of people first? Because there’s so many people working in this area: SeeClickFix, a lot of app contests being run by cities are producing open 311 apps, there’s the open 311 API. What’s your competitive advantage and how are you going to go to market in such a way that you become a viable business?
Responding to Tim’s mention of open 311, Jason says:
Open 311: it’s great, I would say that the UI needs some work; overall, if a city adopts that platform, they’re locking themselves into their city alone. Our platform works nationwide, so if you download the app and you’re in the city of San Jose and you’re in LA and you report something in LA, it goes to LA. So that’s a big competitive advantage that we have.
Tim mentioned “the open 311 API”, but currently there are actually two drafts of APIs which call themselves “The Open311 API.” One is provided by a company, the SeeClickFix API, and one is provided by a city, the Washington D.C. 311 API. I’m not quite sure which UI Jason was referring to. In the case of D.C.’s 311 system, there are now a variety of different UIs. Much of the intent of opening 311 is to not be tied to any specific UI. As a standardized specification, Open311 would abstract the services of 311 systems into a consistent open platform that anyone can build a UI for.
Open311 is not meant to refer to a specific app or any one incarnation of 311 services. Instead Open311 intends to be a specification of an open platform for 311 services. This difference may seem subtle, but it’s an important one. It’s the difference between closed platforms like the iPhone and open platforms like Android or the web which are enabled by open standards: the Android operating system, HTML, and HTTP. The challenge we need to address is creating an open standard by looking at APIs like those offered by D.C. and SeeClickFix and coordinating the commonalities of different city infrastructure to distill core requirements for a universal 311 API. Once this core standard is defined, new user interfaces and custom workflows can be created by anyone and shared between cities to provide distributed innovation.

Innovation and infrastructure is distributed in an open platform. Diagram is based on PuSH and the internet's architecture.
Jason Kiesel provided a good point, in order to guarantee that the platform actually connects to all cities and can provide a UI that works anywhere requires coordination with each city. Tom Steinberg put this eloquently when he asked us to build FixMyStreet in this country:
Your citizens deserve services that have that kind of usability of a single national service; that hides the splinter of federalism. And it’s challenging because of the federalism; which is precisely why you should do it. Because if you can overcome that you will have done something amazing and you will have a really simple example that will give legitimacy to investment in loads of other things.
It could be beneficial to have government coordinate this routing on a national level, but we don’t necessarily need higher level government to provide a single unifying force. Tim O’Reilly alluded to this in mentioning the government’s role in providing root DNS servers within the context of 311 services:
Can gov get in the business of providing some minimal services (a la the root servers of the DNS, originally govt chartered) in such a way that the public takes the ball and does everything from there.
Like DNS and the web, a distributed 311 platform can be facilitated with not only multiple inputs and endpoints, but also multiple hubs that route information. This is the underlying architecture of the internet and it’s the model now making its way to web technologies using an open stack that distributes streams with real-time methods like PuSH feeds. It’s no accident that I mimicked the diagram of the PuSH model to use as a visualization for distributed 311 services in my Gov 2.0 talk.
By not depending on a central server, or even a central router, distributed systems are more stable and more scalable. Imagine if multiple major cities relied on one single centralized service to provide their 311 platform. What would happen if this service suffered catastrophic hardware failure or if it were run by a business that wasn’t financially sustainable? These are things that happen on the web. Ma.gnolia is a social bookmarking service that competes with Delicious, but recently their infrastructure suffered a catastrophic hardware failure and all of the users’ bookmarks were lost. Similarly, Tr.im is a URL-shortening service that competes with Bit.ly, but recently they announced that they would be shutting down the service (and breaking all of their links) at the end of the year because they are not profitable. Even Twitter demonstrates its lack of stability on a regular basis and they’ve yet to prove that they are financially sustainable. Fortunately, there are signs of new life at Ma.gnolia and Tr.im, but preventing these types of systemic failures is exactly why the internet is designed with a distributed architecture.
Additionally, the internet has proven that the distributed model helps foster new innovation and new business while providing a better user experience by guaranteeing interoperability. A distributed model does not preclude software as a service just as the internet did not prevent companies from leasing infrastructure and selling hosting services. This is a model that simultaneously promotes growth and prevents systemic problems, but it’s only possible with cooperation.
This is a crucial opportunity to think globally and act locally. Please join the effort to establish an Open311 standard; speak up on our mailing list or edit the wiki. For this to work, we really need to hear from cities. Describe your city’s 311 infrastructure and how collective action can improve these city services. We have organized an Open311 DevCamp on October 24th in New York City with developers of 311 systems from both inside and outside city governments, so please come to that and help move this forward. As a proactive developer community we can help build better communities for all.
I presented Open311 and the need for a standard at the Gov 2.0 Expo and it turned out that providing 311-like services as platforms was a continuous thread throughout both the Expo and the Summit that followed. Ben Berkowitz also gave a presentation at the Gov 2.0 Expo talking about SeeClickFix.
Tim O’Reilly’s opening keynote emphasized the role of government as the provider of open platforms, platforms that we the people could build applications on top of:
Government as a platform means an end to the design of only complete, closed “applications.” Instead the government should provide fundamental services on which we, the people, (also known as “the market”) build the applications.
Twitter co-founder Jack Dorsey mentioned his background in dispatch communications and cited the utility of something like Twitter for 311 services. When asked if there’s anything government does that could exploit Twitter, Jack responded:
I think we’re making some steps in the 311 services. You have people roaming all over these metropolises, all over this country, all over the world, reporting what they’re doing and what they’re seeing in front of them. And being able to quickly amass some narrative or some knowledge from those updates is really interesting. You have a pulse of what’s happening in very specific locations around very specific topic. And I think that’s one of the challenges of the developer community, of our users, and of the company to build something that really captures that and makes it intelligible.
Tom Steinberg of MySociety described the experience providing FixMyStreet in the UK, the very first instance of an open 311 service. Tom’s talk then went on to express the opportunity and the challenge of bringing this to the US:
Build FixMyStreet in this country. Your citizens deserve services that have that kind of usability of a single national service; that hides the splinter of federalism. And it’s challenging because of the federalism; which is precisely why you should do it. Because if you can overcome that you will have done something amazing and you will have a really simple example that will give legitimacy to investment in loads of other things. People understand potholes and getting them fixed. If you can make that measurably better so they say, “Do you remember the time before that?” then the likelihood that they’ll say, please can we have some more of that and that the money and the energy will flow in that direction just goes up a lot. You can even have the name FixMyStreet.gov if you want, we won’t sue.
Here’s the video of my presentation:
Since the last update here on 311 technology, a number of new apps have been released from different cities and services. Here’s a quick rundown:
SeeClickFix released an iPhone app to interface with their service.
New York City released their first official mobile 311 app with the 311 Pix iPhone app.
Pittsburg launched their first mobile 311 app as an iPhone app called iBurgh with suggestions of spreading their technology to other cities.
DC announced the winner of the final round of the Apps for Democracy contest. The DC 311 iPhone and Facebook app created by Victor Shilo was the winner. Other DC 311 apps and links to their source code can be found in the D.C. apps section of the wiki.
CitySourced launched as a new software-as-a-service offering similar to SeeClickFix with a presentation at TechCrunch 50. CitySourced is starting with iPhone based input and Palm Pre, Blackberry, Android, and Windows Mobile versions on their way (video). The TechCrunch pitch also included their first client on stage, city council member Pete Constant from San Jose (press release).
A running list of 311 apps and services is maintained on the wiki. Please add or update the listing if you know of more.
To further discuss the issues and opportunities surrounding Open 311, we’d like to extend an open invitation to the developer, government, and interested citizen communities to the first Open 311 Summit.
At this point, the agenda and format are open for discussion, as are the exact dates, but we are thinking about sometime in late October, 2009 in NYC. If you’re interested in attending or have any suggestions, please drop a note in the comments or head over to the Open 311 Discussion List.
Thanks!
In a few minutes, Philip Ashlock from The Open Planning Project will be discussing Open311 at the Gov 2.0 Expo Showcase.
Phil will be presenting as part of the “Government as a Partner” panel, along with representatives from Arkansas Recovery Portal, Neighbors for Neighbors, SeeClickFix, and BART. You can view his slides below or download them here (PDF).
The Expo has been great so far, and Tim O’Reilly’s opening remarks definitely set the stage for a discussion of 311 as an open civic platform. You can follow the live tweeting here.