Because this is timely, I reserve the right to say some presumptuous/incorrect things that I never would have said had I had time to think it over, as I usually do when I post things here.

The Washington, DC Chief Technology Officer just launched a project called Apps for Democracy, a contest to create apps with DC’s data catalog.

I love this project. DC doesn’t get much revenue to work with, so this project makes a lot of economic sense–the tools they will get out of this contest would, through the standard contracting route, cost about 40 times the $20,000 in prize money they’re giving away.

But the economics, I’m guessing, is what sold the mayor on the project. I bet the initial motivation was much different: the CTO’s office understands that the public will create better tools, and more quickly, than government contractors can. They know that the benefits of opening their data far outweigh the speculated, yet unproven, pitfalls.

Also, I can tell the CTO likes to experiment. That’s really gutsy, because an inevitable byproduct of experimentation is failure. This is why most bureaucrats hate experimentation and would prefer to coast: sure, you won’t make progress by doing things the same way, but at least you can’t screw up!

This CTO (Vivek Kundra is his name) gets it. This is exactly the kind of stuff a CTO should be doing. There are rumblings of such a position being created under a presumptive President Obama. If it happens, I hope they use Apps for Democracy as a model for this title: more technology, less chief officer. Technology is about experimentation, not red tape. A new bureaucratic position should have an eye for counteracting the increased bureaucracy it will inevitably engender. Projects that delegate power to the public are a great way to do that.

I’m excited about Apps for Democracy, but I have some reservations, which I voice below. As a segue, here are a few possibilities for app submissions:

  • Use the Speed Detector GIS data to build an iPhone app that alerts drivers to their presence (though that won’t go over well with the mayor’s budget office)
  • Use the Bicycle Lane and Bike Routes GIS data to build a Google or Yahoo! Maps mashup that creates cycling-friendly directions
  • Use the Trails, Trails NPS, and Crime Incidents data to create safe jogging routes
  • Mash any public safety data–Crime Incidents, Juvenile Arrests, etc–with a SIMILE timeline to spot trends
  • Use that same public safety data to spot correlations between incidents and the proximity of other facilities; for example, maybe juvenile arrests near banks spike in June, while arrests near current construction projects spike in December. (Whether the revelations would be valuable, we cannot say. But I’m sure sociologists and criminologists would find it interesting.)
  • Use any number of the tourism- and transportation-oriented data files to make the ultimate online day planner for washington.org.

I guess some of those ideas are decent. The problem is, I’m just a citizen. So most of my ideas are for public-facing tools. Only one or two would improve District operations. Public-facing tools are great, and the project is accepting them, but is that really the spirit of this project? I see it differently. The goal here is to help government, and I imagine Kundra is hoping people will create tools that do that. As the CTO, his job is to “develop and implement the District’s IT infrastructure” and provide “technology solutions to improve services.” What he really wants are tools that help the DC Government do its job better. This project can yield a slew of neat-o iPhone apps, but remember: projects like Apps for Democracy ultimately happen because of the possible budget savings, and if the project doesn’t deliver on that front by cutting internal IT costs, there may not be an Apps for Democracy ’09. So he has to deliver at least one great new tool for the inside.

What to build, what to build…there are surely countless opportunities for improving DC’s systems and data management. The problem is, people like me don’t have the good ideas, because we don’t experience the day-to-day frustrations of the problems we’d be fixing. We don’t understand the environment. We don’t know what’s lacking.

The most beneficial tools will probably never be thought of by the general public. People with no understanding of municipal water systems can’t (or don’t) ponder ways to revolutionize the DC Water Authority. Even more important, even if I did have the idea, I would have little incentive to build it on my own. Unless I understand the good that will come from creating that tool, I’m not going to spend time on it. Someone at the Water Authority needs to say, “We need a tool that will do X, Y, and Z, and it would help us because _____.” The _____ is the most important part. I’d love to help DC, but only if I know I’m helping. That’s why there needs to be a way for DC employees to share ideas with developers. Has this project been promoted to District employees? The project site is not targeted at them: it grabs the attention of tech firms and indy developers, but there’s no mention of the end user. Do they have a forum for voicing ideas? Whip up a way for those developers to team with District employees so we can put together something that really changes your business. What do you say, Mr. Kundra?

UPDATE 10/25 11:57 PM: After posting this, I sent an email to Apps for Democracy project manager Peter Corbett to tell him about it. He wrote back in less than an hour saying he’d already read it:

I just read that, Matt and it’s a really good post. I just sent it to Vivek. We have http://apps08.ning.com up for collaboration purposes and I suggested to Vivek that he broadcast to dc.gov that we need ideas from them about what they need built!

I often complain that although the federal government is finally abandoning clunky enterprise software for more modern Web tools, their procurement model has not changed: they still rely on the slow, expensive, clunky contracting route instead of trying the more agile, release early-release often approach that makes Web tools great in the first place. But the speed and content of Peter’s response, and his allowing me to post it here, are all signs that this is a much different DC software project. I like it.

Related: Why I Help “The Man,” and Why You Should Too