Time to Get Tough with 311 Vendors

Big news recently in the Open311 world.

Lagan – a technology company that provides solutions for local government, including 311 systems – has announced the launch of an integration toolkit to allow “local government customers worldwide to receive and action service requests via social networks, mobile applications and third-party websites.”

This is good news for governments that want to utilize different communication channels to accept and respond to non-emergency service requests, or that want to stand up an API for outside developers to use.

Lagan’s announcement is based on some pioneering work done in the City of San Francisco to do both of these things – San Francisco was one of the first (if not the first) city to use social networking services to take 311 service requests, and they were an early adopter and enthusiastic advocate of the Open311 initiative.

Hopefully, this action by Lagan will catch on with other vendors. It’s worth noting that, according to the Pew Charitable Trusts (which conducted a study of Philadelphia’s 311 system earlier this year, and compared it to 14 other large cities with 311 service) that over 30 percent of large municipalities with 311 service share a common vendor – Motorola. It would be nice if Motorola would follow Lagan’s lead on this issue.

Whether or not they do is an open question. Certainly they have a customer that is as pioneering in their support of Open311 and alternative channels for 311 service as Lagan does (Motorola is the vendor for the District of Columbia).

I continue to believe (and have argued the point with other Open311 advocates) that the best way to “encourage” vendors to support integration toolkits like Lagan’s in their products is to make it a requirement in bidding on 311 projects.

Let’s be realistic – if even one of the large cities that utilize Motorola’s 311 solution made it a requirement during a contract renewal or an open bid that any 311 solution considered must support integration of multiple communication channels or have a generic interface for implementing an externally facing API it would get done. No question about it.

This position is actually strengthened by Lagan’s recent announcement. They have removed any possibility of responding to such a requirement in a bid by saying that no vendor supports such functionality. There is now a vendor that does – Lagan.

It’s time for governments with 311 services to get tough with their vendors and insist that they support alternate channels for servicing 311 requests and for implementing external API’s.

OpenGov APIs: Interfacing with Open Government

There has been lots of good talk (and a good deal of action) lately around open government APIs at events like Transparency Camp, Where 2.0 and on the Twitters.

So, as a prelude to a talk I’ll be giving at eComm next month, I wanted to write a post surveying the landscape of recent government API developments, and also to describe evolving efforts to construct standards for government APIs.

A Rundown of Recent State and Local API Developments

At Transparency Camp in DC last weekend, Socrata – a firm that hosts open data sets for governments – open sourced their API for accessing and querying public data. The Socrata Open Data API (or SODA) is a specification for running queries against public data sets. Currently, Socrata hosts data sets for the City of Seattle and others – code samples for working with the SODA spec can be found on Github.

The Open311 API recently implemented by the City of San Francisco (and being implemented by others) got some well deserved attention at the recent Where 2.0 conference. Other cities are starting to take note, and some (like Edmonton and Boston) look set to be next in line.

One of the early adopters of government APIs – the NY Senate – recently announced a new release for their OpenLeg API, which includes some important new changes. Today the NY Senate remains one of the few (if not the only) state legislative body to adopt an API to open up access to legislative information and proceedings, but other will hopeful soon follow. (Certainly the work done in Albany by NY Senate CIO Andrew Hoppin and his team has opened the door for work on other government APIs.)

That’s a lot of good stuff in just the last few weeks – I’ve probably missed some stuff, but I’m sure there is more to come in the weeks and months ahead.

Towards API Standards

The work being done on the Open311 API, the OpenMuni Project, and certainly the move by Socrata to open source the SODA spec will have significant implications for the open government data movement.

Standards for open data and APIs will make it easier for developers to build things – an app that works for one municipality can work for others if both adhere to a common standard that the app can run against. But they’ll also make it easier for governments to open up their data – standards will offer governments assurance that the time and effort they expend to maintain and publish data or stand up APIs will provide the most return on investment.

The move towards open data and government API standards is an important one that may influence the long-term success of the open government movement.

What’s Next?

As these standards develop, and as more and more municipalities start to embrace open data, we’ll move closer to the idea of government as a platform.

More and more open data will be published by governments in this country and others. These newly opened data sets may be hosted on infrastructure maintained by governments, or by third parties like Socrata. Enterprising governments in different regions or states may decide to team up and jointly host data that is of interest or value to constituents served by multiple governments or jurisdictions.

The applications that allow citizens to communicate with governments and consume public services will increasingly be built outside of government. (By outside, I mean outside the control of government and the government procurement framework.) Governments will increasingly become the collectors and maintainers of data and information and will focus less on building applications that use such data (or contracting for such applications to be built).

The applications built to consume public data and communicate with government will increasingly be designed as multitenant applications, able to service constituents in multiple jurisdictions that adhere to common data or API standards. They will also be built using more open source components and Web 2.0 technologies.

And (hopefully) the ranks of civic coders will continue to swell, as technologists looking to “scratch their own itch” are empowered to make a difference far beyond their own wants or needs.

All hail the transformative power of standards!

Twitter, Facebook, Geotagging and 311

Several weeks back, I wrote a quick post about the new locational functionality being rolled out in Twitter. Now that this new functionality is being supported by more and more Twitter clients, I think its time for an object lesson in how Twitter’s new locational feature (and soon Facebook’s) can be used to engage citizens to submit 311 service requests.

Consider the following Tweet (sent using TweetDeck for iPhone):

311 Service Request Tweet

Here is the data behind this Tweet in XML format, courtesy of the Twitter API:

Does this Tweet contain enough information to start a 311 Service request (and by “start” I mean via some application logic that automatically parses 311 tweets and requires no human intervention)?

It has a hashtag describing the nature of the request (#pothole), a URL to a picture of the offending pothole (admittedly a pretty wimpy one) and it also has the lat/long of the location where I took the picture. All together, it took me about 15-20 seconds to take the photo, geotag the Tweet and compose the message.

The Twitter API provides some background information on me, in the event that the government handling this kind of a service request wants or needs it. If there was really a need for more, it wouldn’t be all that hard to build a Twitter BOT to interact with the person Tweeting the service request and get any additional information that was required.

One of the primary benefits for governments from deploying a 311 API, or working with companies like CitySourced or SeeClickFix is that it can help engage (and empower) citizens to report service requests. If it’s quick, easy and convenient to report 311 requests, people will do it and they are more likely to be satisfied with the experience (something that doesn’t always happen when citizens interact with government).

The new locational feature of Twitter (and soon of Facebook) will provide governments with a very effective way of empowering citizens to report 311 service requests.

It will be interesting to see how many of the them leverage this as part of their 311 services.

Command Line GeoTwitter

A few months back I wrote a quick post about tweeting from the command line. With the recent announcement that Twitter’s location feature is starting to go live, I decided to revisit this idea, with an eye toward adding locational information.

(I am, at heart, a cheapskate – I could have bought one of the existing Twitter clients that support locational Tweets but I really just want to play around with this new feature for now. The command line is free, baby!)

Twitter’s API methods now support adding geographic coordinates with a status update. Sending out a GeoTweet using the command line is easy (note, this example assumes you know the lat/long of the location you want to associate with your Tweet).

Open up your favorite editor and drop the following into it:

curl -s -u user:password -d status="$1" -d lat="$2" -d long="$3" http://twitter.com/statuses/update.xml > /dev/null

Save the file and make sure it is executable (chmod u+x fileName). You can execute this file at the command line like this:

$ ./fileName "Testing twitter geolocation feature" "+39.754571" "-75.571985"

When you examine the properties of this tweet, you will see that it now has geographic information associated with it:

<geo xmlns:georss="http://www.georss.org/georss">
  <georss :point>39.754571 -75.571985</georss>
</geo>

How cool is that!

As more Twitter applications (and the Twitter website itself) roll out support for this new feature, a host of new Gov 2.0 potential is going to be unlocked. I think this will have huge implications for services like 311, where location is critical to service requests.

Municipalities like New York City and San Francisco that have already incorporated Twitter into their 311 service will have a big head start in this regard.