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.