Having decided to hang around Portland for a couple days after the Open Source convention, I attended a hackathon sponsored by the City of Portland and a number of local high tech companies, and talked to Rick Nixon (program manager for technology initiatives in the Portland city government) about the two big problems faced by contests and challenges in government apps: encouraging developers to turn their cool apps into sustainable products, and getting the public to use them.
It’s now widely recognized that most of the apps produced by government challenges are quickly abandoned. None of the apps that won awards at the original government challenge–Vivek Kundra’s celebrated Apps for Democracy contest in Washington, DC–still exist.
Correction: Alex Howard tells me one of the Apps for Democracy
winners is still in use, and points out that other cities have found
strategies for sustainability.
And how could one expect a developer to put in the time to maintain an app, much less turn it into a robust, broadly useful tool for the general public? Productizing software requires a major investment. User interface design is a skill all its own, databases have to be maintained, APIs require documentation that nobody enjoys writing, and so forth. (Customer service is yet another burden–one that Nixon finds himself taking on for apps developed by private individuals for the city of Portland.) Developers quit their day jobs when they decide to pursue interesting products. The payoff for something in the public sphere just isn’t there.
If a government’s goal is just to let the commercial world know that a data set is available, a challenge may be just the thing to do, even if no direct long-term applications emerge. But as Nixon pointed out, award ceremonies create a very short blip in the public attention. Governments and private foundations may soon decide that the money sunk into challenges and awards is money wasted–especially as the number of challenges proliferate, as I’ve seen them do in the field of health.
Because traditional incentives can never bulk up enough muscle to make it worthwhile for a developer to productize a government app, the governments can try taking the exact opposite approach and require any winning app to be open source. That’s what Portland’s CivicApps does. Nixon says they also require a winning developer to offer the app online for at least a year after the contest. This gives the app time to gain some traction.
Because nearly any app that’s useful to one government is useful to many, open source should make support a trivial problem. For instance, take Portland’s city council agenda API, which lets programmers issue queries like “show me the votes on item 506” or “what was the disposition of item 95?” On the front end, a city developer named Oscar Godson created a nice wizard, with features such as prepopulated fields and picklists, that lets staff quickly create agendas. The data format for storing agendas is JSON and the API is so simple that I started retrieving fields in 5 minutes of Ruby coding. And at the session introducing the API, several people suggested enhancements. (I suggested a diff facility and a search facility, and someone else suggested that session times be coded in standard formats so that people could plan when to arrive.) Why couldn’t hundreds of governments chip in to support such a project?
Code for America, a public service organization for programmers supported by O’Reilly and many other institutions, combines a variety of strategies. All projects are open source, but developers are hooked up with projects for a long enough period to achieve real development milestones. But there may still be a role for the macho theatrics of a one-day hackathon or short-term challenge.
Enhancing the platform available to developers can also stimulate more apps. Nixon pointed out that, when Portland first released geographic data in the form of Shapefiles, a local developer created a site to serve them up more easily via an API, mobilizing others to create more apps. He is now part of the Code For America effort doing exactly the same thing–serving up geographic data–for other large municipalities.
Public acceptance is the other big problem. A few apps hit the big time, notably the Portland PDX bus app that tells you how soon a bus is coming so you can minimize the time you wait out in the rain. But most remain unknown and unappreciated. Nixon and I saw no way forward here, except perhaps that one must lead the way with increasing public involvement in government, and that this involvement will result in an increased use of software that facilitates it.
The wealth of simple APIs made a lot of people productive today. The applications presented at the end of the Portland hackathon were:
A mapping program that shows how much one’s friends know each other, clustering people together who know each other well
An information retrieval program that organizes movies to help you find one to watch
A natural language processing application that finds and displays activities related to a particular location
An event planner that lets you combine the users of many different social networks, as well as email and text messaging users (grand prize winner)
A JSON parser written in Lua communicating with a GTK user interface written in Scheme (just for the exercise)
A popularity sorter for the city council agenda, basing popularity on the number of comments posted
A geographic display of local institutions matching a search string, using the Twilio API
A visualization of votes among city council members
An aggregator for likes and comments on Facebook and (eventually) other sites
A resume generator using LinkedIn data
A tool for generating consistent location names for different parts of the world that call things by different terms
Approximately 130 man-and-woman hours went into today’s achievements. A project like Code for America multiplies that by hundreds.