Developers for glory: the Apps for Army competition |

Developers for glory: the Apps for Army competition

Posted 03 Mar 2010 by 

Gunnar Hellekson (Red Hat)
(2 votes)
Image by :

Although it may be simple to conflate the Apps for Democracy and Apps for America contests with the exciting new Apps for Army contest, they really couldn't be more different. Together they represent an exciting experiment in what it takes to pull communities together around a problem. Though they all offer cash prizes to the winners, they each took a slightly different approach, with different results.

Cash incentives are somewhat controversial in open source circles. Most old-school advocates for open source development strongly prefer developers who are personally invested -- famously, those that "scratch their own itch." Developers who are paid a salary to work on software are also invested, but perhaps less zealously than those who are solving a problem they are afflicted with themselves. Developers who are working for glory and cash prizes, the model used by the "Apps for..." competitions, is yet another class of developer, and despite the excellent submissions to the previous contests, there are valid concerns that the quality and sustainability of the code is not as good as it could be with a different set of incentives. Time will tell, of course.

If I'm a developer for glory, I may compete for the cash prize, or for altruistic reasons, but I'm also competing for the notoriety I'll get if I win. If I don't win, what will I do with the code I've developed? Even if I win, what are my incentives to continue working on the project? Put another way: how can we ensure that all of this good work and goodwill turns into viable, and active software projects once the contest is over?

Apps for Democracy is instructive. The contest encouraged developers to provide services on top of the "platform" of Washington, D.C.'s IT infrastructure. This platform includes 270 public data feeds and the city's newly unveiled 311 API. 47 submissions were collected in 30 days, and the winner was an iPhone and Facebook application that enabled users to take snapshots of potholes, broken windows, and so forth, have them tagged with GPS coordinates, and submitted to the city's 311 service. Very handy. Unfortunately, the ongoing care and feeding for the application doesn't seem to be there. The Washington City Paper found in a January 25th, 2010 followup on the contest:

The "Touch City's Heart" Social DC 311 Web site seems to have been abandoned—it hasn't been updated for months—saying the “IPhone” app is still waiting for approval from Apple (Apple approved it long ago). Some members of the D.C. 311 team had never laid eyes on the Web site until City Desk asked about it. “I’ve never even heard of it,” said one 311 operator. It has only 27 active monthly users on its Facebook Fan page and 40 followers on Twitter.

I'll also note that after some cursory research, the source code doesn't seem to be disclosed to the public yet, which I understand was one of the intents of the contest. Now, to be fair, there seem to be bigger plans afoot:

The dismal following is not a sign of failure, Sivak says. The District intends to take Social DC 311 and revamp the current model into an app that’s “enterprise-ready and robust for a large volume of users,” Sivak says. “Think of this first step as a pilot.”

Fair enough, but I would think that one of the desired outcomes was an ongoing community of developers that are producing and maintaining applications like this -- whether it's for love, money, or fame. It would be a shame to see hard work like this die on the vine because we've lost the carrot of a cash prize.

The first Apps for America contest winner was Filibusted, a tool for outing Senate obstructionists. It measures obstruction by the Senator's votes on cloture motions. You can find the source on GitHub, but there doesn't seem to be much activity since the initial checkin. One bug was opened 8 months ago, and doesn't appear to have been addressed. The last blog post was in December. At the same time, there's not much to work on -- the site has a single purpose, which it seems to fulfil even without much of a community around it. It doesn't really need a large community, I'd guess, because it's "done."

The second Apps for America yielded DataMasher. This tools allows you to compare Federal data sets with each other. Once you have the data and visualization you like, you can share it with others on the site. The source code was released, per the terms of the contest, but doesn't seem to have much of a community around it. In fact, the DataMasher website doesn't seem to link to the code from their own site. That hasn't made the application less popular, though -- the community isn't working on the code, it's working on the datasets. There's a steady stream of new mashups that other users rate and comment on. In all, a healthy community that relies on user-generated content to ensure it remains a useful tool.

The second Apps for America contest also produced the strikingly elegant It's a vastly improved interfact to the Federal Register developed by the gifted team at GravyCones. The code for this application is available to the public, and seems actively developed to this day. This is, I think, exactly what the organizers had in mind when they started this contest: the tool is popular, the development community is active, and the project continues to improve.

Which brings us to Apps for Army, which is a serious departure from the other contests. First, it's available only to Army soldiers and civilian employees, nobody from the public -- not even reservists. In fact, you need a DoD ID card to go to the official contest website. Second, it seems that only the first 100 teams can participate. From a community standpoint, the project is wading into very unfamiliar territory. Rather than gathering the collective wisdom an initiative of thousands of interested developers, they'll be picking 100 volunteers, seemingly at random.

The Apps for Army contest further diminishes its potential reach by dictating the tools developers will use: the DISA RACE environment to host the project, and the repository for code. Since these resources are being paid for by the Army's CIO, who is sponsoring the contest, what will happen to the competitors once the competition's over? There are, of course, excellent reasons for asking folks to use the existing DoD infrastructure, but I can't help but wonder what would happen if the doors were flung open, and the bar was lowered for participation.

This isn't to say that I'm less enthusiastic about these experiments. I'm very excited at the idea of encouraging employees -- in the Army, or anywhere else -- to solve their own problems. That's a goodness in and of itself. We just can't forget that software isn't a product -- it's a process that requires nurturing. The best way to nurture is to build a community, and that requires transparency and a low barrier to entry for participants. The larger and more active the community, the more likely the software will be better. The more closed, prescriptive, and limited the project, I think, the less likely that it will be viable in the long-term.

So these "Apps for..." competitions are instructive. Each project is building its own kind of community, and I'm eager to see how these projects fare in the months and years ahead.

I'm the Chief Strategist for Red Hat's US Public Sector group, where I work with systems integrators and government agencies to encourage the use of open source software in government. I'm a founder of Open Source for America, one of Federal Computer Week's Fed 100 for 2010, and I've