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 developed 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.

As San Francisco and Washington D.C. prepare to launch their new APIs we’d like to have other cities and managers of 311 services show their support for implementing an interoperable standard for these APIs. The more cities get behind this effort, the better for developers, for city budgets, and for citizens. Showing a critical mass of support for using this standard will help encourage developers, other cities, and existing 311 services to become more invested in the potential of an interoperable system.

A standard means that people can use their favorite app in every city and developers can focus on new features rather than different requirements for each city. Everyone can then benefit from new innovations built from a common foundation. Additionally, interoperability is helpful not only to simplify the offering of citizen interfaces, but also to help unify and better facilitate inter-agency coordination for city managers.

To date, the people who have joined San Francisco and Washington D.C. by showing their support for implementing a standard API include directors of these services and CIO or CTOs in cities like Boston, Portland, Edmonton, Seattle, and Los Angeles as well as those from services like SeeClickFix and Ushahidi.

Please take the pledge and show your support.

Both San Francisco and Washington D.C.are preparing to release their Open311 APIs next month.

Over the past several months, Alissa Black and Jay Nath  having been working within the technology team in San Francisco to incorporate public feedback for the development of the Open311 API. The current proposal can be seen on the wiki.

Dmitry Kachaev in Washington D.C. is also preparing to relaunch the D.C. API incorporating the changes of their v2 draft while paying attention to the API spec that San Francisco has worked on in an attempt to start working out interoperability between cities.

Progress has also been made on ways to provide integration between geographically disparate APIs. The current proposal is an approach modeled after DNS and reverse-geocoding called GeoWeb DNS. The way this fits in with the Open311 API is illustrated in this system architecture diagram. There’s a description of the GeoWeb DNS service on the wiki and a reference implementation is available at: http://geodns.open311.org

The San Francisco team is holding their final public conference call before they launch their Open311 API. The call is open for all to join and provide feedback, comments, and ideas as they move from their development phase to the actual launch. The invitation for the call as posted on the sfgov.org website:

Public Conf Call 2/25 @ 10AM PST

Please join our public conference call this Thursday @ 10AM Pacific.

Dial in: 641.715.3625
Pin: 813951#

The topics to be discussed are:

• design spec
• other cities pledge to use standard Open311 protocol
• feedback on a few modifications we may make to spec (addition of metadata call)
• open questions
• mailing list Please join!

Please join the conversation and help ensure that the APIs are well equipped to serve these cities and the developers working with them.

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:

• Documentation of existing 311 systems in cities (Cities, please edit these. Thanks for adding yours Toronto!)
• Creating a universal Open311 API
• Pitching cities on Open311
• Usage and analysis ideas for 311 data

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:

The need for a two-tiered model for submitting service requests

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.

The value of improved inter-agency communications

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.

The cost of SMS and the value of voice

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.

The layers of the Open311 model:

This rough outline is the result of further considering how the different parts of the Open311 model must to fit together

• End user
• Client application
• Open311 API - decentralized read/write web APIs. 2 step submission:
  • Simple and easily accessible (minimum fields required, status: “submitted”)
  • Crowdsourced validation (city requirements, status: “validated”)
• Adapter to translate existing systems for Open311 web APIs
• Existing CRM/311 system
• Government

Open source implementations

There are at least three open source service request web apps that are available for anyone to implement a draft API spec.

• FixMyStreet (source code)
• FixMyStreet.ca (Django source code)
• GeoTrac (installation and source code)

Developing the Open311 Spec and API

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.

Action Items

1. Get everyone on the mailing list
2. Continued coordination among those working directly with API implementations.
3. Release reference implementations, client apps, and web API adapters for existing systems

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:

1. 311 usage and analysis brainstorm: Video bookmark / Wiki page
2. Documentation and resources to explain the value of open 311 systems: Video bookmark / Wiki page
3. Technical spec working group, creating a standard API: Video bookmark / Wiki page
4. Final closing remarks: Video bookmark

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.

Project 10^100 - Create real-world issue reporting system

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.

An Open Platform

The web and democracy as open platforms

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.

The Many Faces of Open311

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.

Open Platforms are Distributed

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.

A Call to Action

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:

This website is meant to facilitate an international effort to build open interoperable systems that allow citizens to more directly interact with their cities. Many 311 systems provide a broad range of information and services, but currently the primary focus here is coordinating a standardized, open-access, read/write model for citizens to report non-emergency issues.

The Open 311 community is emerging during two exciting developments: One is the nearly complete Apps for Democracy Contest (Community Edition) which is guiding the trial-by-fire development of Washington D.C.’s Open 311 API. D.C. is the first municipality in the U.S. to develop an open 311 system.  Secondly, several New York City council members have proposed legislation that would mandate open [read] access to most of the city’s data in a standardized or raw form, as feeds if possible. NYC has the largest 311 system, so this change could really catalyze innovation around 311 services. As law, this would be a first for a U.S. city, but it follows the lead of Vancouver B.C. and the precedent set on the U.S. Federal level with data.gov. Even without mandates, we’ve seen this on the state level with open.nysenate.gov and of course the model Vivek Kundra spearheaded in D.C. by demonstrating the innovative value and cost-savings of open data. On Monday, June 29th there will be the first public hearing for New York City’s proposed open data law. Two days later on July 1st the Apps for Democracy contest concludes initial development with D.C.’s Open 311 API. This is an exciting time.

While much of this work has just begun, it’s important to acknowledge what’s already been done to demonstrate the importance of open 311 systems. MySociety’s FixMyStreet in the UK was the first to really push this model into the world. The same source code has also been recently put to use in Canada with FixMyStreet.ca. A similar approach has been making an impact in the U.S. with SeeClickFix which recently provided a draft of their API and a demo that interfaces with D.C.’s API. There’s even an effort to apply this model with bug tracking software like Trac, see GeoTrac.

Open311.org provides the basic toolset for collaboratively building an open standard: mailing list, wiki, and blog. The mailing list was actually started a few weeks ago and there’s already some useful information on the wiki (like NYC’s 311 usage stats). Please ask questions, provide suggestions, and get involved.

Additionally, on June 27 (tomorrow) ParticipationCamp in NYC will be hosting a code sprint for 311 projects. Considering the timing, the focus will mainly be on contributing to the last leg of the Apps for Democracy contest. Please join us if you can.