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 govpulse.us. 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 forge.mil 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.