MTA Developers Unconference

mtadev-breakout

Just got home from the first MTA Developers Unconference.  I had the honor of speaking on the panel, which was moderated by Anil Dash and included some really great folks: MTA Chairman Jay Walder, Deputy US CTO for Open Government Beth Noveck, Derek Gotfrid from the NY Times, Anthony Shorris from the Rudin Center, and Bernhard Seefeld from Google Maps.  It was a fun event, and showed how far the MTA has come in building a relationship with the developer community.

Here are a few quick notes:

New data is available.
Chairman Walder made it rain, and new datasets were released as he was on stage. Check them out here: http://mta.info/developers/download.html.  I haven’t taken a close look yet, but here’s what seems to be new:

Some of these datasets will be useful immediately (service & elevator status), and some will provide the basis for interesting analysis, the way that CabSense produced something useful from historical taxi pickup/dropoff data.  It’s particularly cool and weird that B&T toll plaza data is available; I’ll be interested to see what people make of that.  Also, if you love transit turnstile data geekery (and you know you do!), check out this great post by Mike Frumin that visualizes station usage over time, dating back to 1905.

Chairman Walder said all the right stuff.
He gave a 10-min talk, describing his approach to innovation and collaboration.  We’ll update this with the link to the video once it’s posted.  Walder wants to make it easy for developers to help the MTA, and acknowledged the “culture change” required to embrace an approach that produces innovative results, but also reduces the level of the agency’s control.  Or, to phrase it more eloquently: “Ok, jay walder is actually pretty cool.”  Of course, talk is cheap and we’ll have to see how much these ideas and practices persist and expand, but I’m optimistic.

Developer outreach is citizen engagement.
The MTA dev outreach team has done a nice job nurturing this community.  In just a few short months, they’ve launched their developer program, engaged with the dev community on the Google Group, and iterated based on feedback.  I also give a lot of credit here to the MassDOT dev team for setting such an easy-to-follow model.

We talk a lot about government-citizen engagement, and, at least in the transit space, that usually means the riding public.  But I’d just like to point out that the developer outreach that has happened thus far is a great example of a government agency connecting in a meaningful way with (at least one group of) its constituents.  Their approach (and MassDOT’s) has been direct, plain-spoken and honest.  Not bureaucratic, defensive, or complicated.  If you look back through the archives on the MTA Developers Google Group, you’ll see an extended dialogue, with straightforward discussions of opportunities, issues and constraints.  Most importantly, it’s been a responsive process taking place in real-time.

And here are some ideas for what could happen next:

There’s still a big opportunity to develop tools for more seamless transportation.
Chairman Walder talked about the “national border” between NY and NJ.  Anthony Shorris discussed the change from a “mainframe model” of commuting in and out of the CBD, to a networked model where radial transportation out of the city center is not adequate.  I’m looking for the developer community to start building apps that abstract out the inconvenient distinctions between modes and jurisdictions.  I should be able to plan my mobility seamlessly across modes: subway to a PATH train to a taxi in Hoboken to a Ferry, etc. (Developers out there, if you’re into this problem, you should check out the OpenTripPlanner project.)   If we had had more time on the panel, I would have asked for a show of hands who in the audience is working on apps that cross jurisdictions and modes (here’s looking at you, RouteFriend).

The MTA should post a list of software projects they wish they could build, but don’t have the time or resources.
This “wish list” should be fodder for independent developers, and could ideally, in the long run, be the basis for open source development and collaboration among agencies.  On the panel, I asked Chairman Walder what some of those projects would be. My point being that the developer community has come up with some great ideas (ideas that would never have been developed internally at the agency), but there’s still an opportunity for the agency to try and harness some of that energy to solve some of the issues they’re struggling to solve internally.  The issues he mentioned were:

  • Weekend service visualization / explanation. The NYC Subway schedule gets crazy on the weekend, mostly due to construction and maintenance.  It’s super confusing.  This is a hard problem to visualize, though some people have already started working on it.
  • Real-time bus info. This data is not yet available everywhere (only a pilot on 34th St. so far), but it’s clearly some of the most valuable and useful information out there.  Of course, it’s up to the agency to get these data sets out there to the developer community (ahem, L and 6 trains) to make this possible.
  • Working with smart card tech.  I honestly don’t remember exactly what he said here, but the gist is that the MTA will be introducing new farebox systems that will work directly with RFID-enabled credit cards.  Please fill in the blanks from my memory here.
  • Building apps for all mobile devices. He stressed that it will be important to build apps that don’t just work on iPhones and Android phones, but are useful for anyone with any phone.  Yes.

This is a start, but I’d still like to see MTA publish a wish list for software projects on its website.  This idea of a “list of 1000 projects we’d like to do” is a theme I’ve heard from other agencies, and publishing that list would be a good start.

Furthermore, the “wish list” should be included in the app contest. In the fall, the MTA will be having an app contest with prizes for a) best customer service app, b) best visualization and c) best mashup.  I would also encourage them to add a fourth category, which is: best solution to a problem on the wish list.  Bonus points if it’s open source.  Maybe OpenPlans can co-sponsor and offer to integrate the winning tool into another city’s transit stack.

Lastly, the MTA should keep internal metrics on the usage of these datasets, to make sure they’re investing in data that developers (and journalists!) actually find useful.   What you don’t want is to spend time and effort (and political capital) liberating datasets that aren’t of interest to the public, and that don’t produce interesting or useful products.

So, that’s it — I know I sound like an MTA fanboy now, but it really has been nice working with them (full disclosure: OpenPlans co-sponsored the event and helped MTA with the planning), and it’s great to see this case study of Gov2.0 collaboration unfolding in front of us.

// photo is actually my own, taken of the sweet breakout session sign I got to take home as a souvenir.  The signs are actually metal, with visuals licensed from the MTA.  Produced by Underground Signs.