Developers for Glory

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.

I’m the Chief Technology 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 was recently named co-chair of Open Source for America and one of Federal Computer Week’s Fed 100 for 2010. I’m an active member of the Military Open Source working group, the RHCE Loopback, and a GTO-21 commissioner. I also help run Red Hat’s gov-sec mailing list. I perk up when people talk about cross-domain security, edge innovation, and interagency collaboration through the open source model. Prior to joining Red Hat, I worked as a developer, systems administrator, and IT director for a series of internet businesses. I’ve also been a business and IT consultant to not-for-profit organizations in New York City. During that time, I spearheaded the reform of safety regulations for New York State’s electrical utilities following the tragic death of Jodie Lane. When I’m not spreading the Good News about open source, I’m wishing I had a dog. You can find what I’m reading on Goodreads, what I’m saying on Twitter, and what I’m listening to on last.fm.

 

Comment

  • http://www.istrategylabs.com Peter Corbett

    Great post Gunner. I’m going to provide some context and comments so folks reading this can hear a bit about these efforts from an insider’s perspective:

    Context:

    1) I’m the CEO of iStrategyLabs – we co-created Apps for Democracy with the DC Government, and Apps for the Army for the Army.

    2) I was a judge of Apps for America 1

    Note: My thoughts and opinions are my own and do not represent the thoughts and options of the US Army

    Comments:

    I think your assessment of various “Apps for” contests is accurate – as well as your analysis of what motivates developers and/or demotivates them.

    Regarding Apps for the Army:

    ”Rather than gathering the collective wisdom an initiative of thousands of interested developers, they’ll be picking 100 volunteers, seemingly at random.”

    There are so many regulations that get in the way of creating something like Apps for the Army that tapping the wisdom of thousands (non-Army folks) was not possible at this time. We pushed hard to make Apps for the Army open to all – but it wouldn’t fly. We will continue to push hard to open this up in the future.

    Also, 100 volunteers aren’t being picked at random. The best, brightest and most interested Army developers are raising their hands to participate. We have a hard limit on the number of participants for a number of reasons:

    1) It costs the Army hard dollars to use the RACE environment – and money is finite so we can’t have unlimited machines/participants.

    2) This is a pilot and the team needs to have a manageable work load.

    “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?”

    1) Without RACE we don’t have a way to run Apps for the Army in a secure end-to-end way.

    2) Forge.mil is a meant to serve as a collaborative software repository…I don’t see why checking in code to Forge would discourage people for iterating on that code post contest.

    3) Yes our reach is diminished compared to Apps for Democracy/America – but we have to run this program in such as way that it will work within the constraints of the Army.

    4) All of our choices were made by asking the following: What is our ideal? What are our legal/security/other constraints? What can we actually do based on all that we know? We don’t have the benefit of running Apps for the Army in the open web!

    “I can’t help but wonder what would happen if the doors were flung open, and the bar was lowered for participation.”

    You, me, and everyone involved in Apps for the Army can’t help but wonder either. We tried – and on the next turn (if there is one after the pilot) we’ll continue to push for more inclusion and openness.

    Last two thoughts:

    1) I’m pretty well known for getting difficult things done – and let me tell you…bringing Apps for the Army to life was really really hard. I’m glad we made it through with our philosophy/methodology largely in tact – and while I lament the fact that we had to make some sacrifices to create a viable innovation program for the Army, I’m confident that we’ll do good job this time around, and make it even better moving forward.

    2) I don’t claim to have all the answers, or even know the best possible way to deliver technology innovation writ large. We’re experimenting here. What I challenge you and anyone reading this to do is this: show us a better way. Do it. I’ll support you – I’ll promote your stuff – whatever is necessary to help the world do what it needs to do through smarter, better, faster, cheaper means is cool with me.

  • http://blogs.open.collab.net/oncollabnet/guymartin Guy Martin

    Since Peter chimed in here, I’ll weigh in a bit too. :)

    For those that don’t know, I was one of the original community management team leads for Forge.mil. I continue to be involved in the project, but am now focused more on community strategy as opposed to day-to-day running of the site.

    I agree with Peter that there is nothing preventing post-contest access and iteration of the code checked into software.forge.mil. As a matter of fact, I lobbied hard for the projects on the site to be ‘internally-open’ within DoD, as all of the other projects there are. However, as Peter has alluded to, there are/were regulations that required some compromises to be made in terms of legal issues, and until the contest is over, most of the content will be ‘private’ to just the project teams involved. After the contest, we’ll re-open those projects to view access for all site users & having them already on what is becoming the centralized place for open collaboration within the DoD is a good thing (IMO).

    Frankly, my big beef here is the notion that software.forge.mil is ‘just a code repository’. I felt (and still feel) strongly, that attempting to host the ‘generic collaboration’ on AKO, while relegating the forge.mil environment to just ‘the code’ was a detriment, because the integrated collaboration tools such as trackers/wikis/discussion forums/document repositories and file releases are critical to helping foster better collaboration.

    I know there are some political hot potatoes in there because of sunk costs in AKO, but I’m going to continue to encourage Apps 4 Army developers to take full advantage of the forge.mil tool suite, as I think it makes the most sense.

    Finally, I’ll concur with Peter that this was REALLY REALLY hard (and he had it much worse than our team), but that it is a first step. I think sometimes that the Open Source community feels (as do I) that everything should be perfectly designed and ready to go up front.

    Now, we know that isn’t reality, but I think we’ve at least stuck an oar into the water, and given ourselves a place to start. Hopefully we can build upon whatever momentum comes out of this.

  • http://kitplummer.github.com Kit Plummer

    Peter and Guy are missing the “social coding” piece.

    Github is the “right” model…for individuals to self-service problem solve and facilitate “real”, not imagined, collaboration.

    And the whole RACE thing is fracking bs. The Army has to pay to use DoD resources? WTF is that?

    Forge.mil is just a code repository. Why would I, developing an iPhone app, use all of the other pseudo-collaboration pieces when it is just me? And, how would I, the developer, monitor/control the code that has been checked out of my repository? We’re not talking about contractors and sub-contractors and customers collaborating under a program.

    Ok, ok – I get that this is hard and I applaud everyone for the effort to this point. Seriously. However, just because it is hard doesn’t mean that shortcuts and sideways dancing is going to do the real ideas justice (read Jim Stogdill’s Radar post on emergence and innovation).

  • http://blogs.open.collab.net/oncollabnet/guymartin Guy Martin

    Kit,

    Can you explain to me how you can reference ‘social coding’ in one sentence, yet denigrate all of the ‘pseudo-collaboration pieces when it is just me’ in another? Which is it, social coding or one-man bobsled? :)

    I don’t disagree that there needs to be a more ‘github-like’ social layer in forge.mil, and, as a matter of fact, that has been the topic of a lot of discussions lately. If things hold according to plan, a prototype of something like that might make it into the tail end of Release 6 of Forge.mil (we are in the first iteration of Release 6 now).

    I think you’ve missed the point I was trying to make, which was that once the contest is over, having the code and other project artifacts in a place that supports that ‘corporate’ collaboration that you seem to abhor will help make sure that these efforts have a chance to live beyond the initial ‘hey, I built and app and won a contest’ mode.

  • http://onepeople.org/ Gunnar Hellekson

    Peter — thanks for some great insight on the “back room” of Apps for Army! I think everyone understands the importance of promoting innovation and creativity in the DOD, especially the warfighters. As you say, I’m not sure everyone appreciates how hard it is to get that done. Apps for Army is a great example, as Jim Stogdill has written, of the potential and the challenge of encouraging innovation like this. With all the rules and restrictions you have to work with, this is probably a “worst case” scenario. I think if Army can make a success of the contest, almost anyone can.

    I’m also on the same page as Kit — it’s my strong preference to encourage ongoing communities of developers, rather than a loose affiliation of mercenaries. The choice of tools has a profound effect on what kind of communities are going to be built.

    Guy, I’m not sure the open source community needs everything to be perfect the first time around. In fact, I think the OSS community is pretty comfortable with first steps and, famously, failing quickly. For good or for ill, the OSS community is also comfortable with vigorous, full-throated, and not always polite debate on what’s right and what’s wrong. But I wouldn’t confuse the lively discussion (here and elsewhere) of the forge.mil model with an indictment. I think you’re right that having the artefacts from the contest stored on forge.mil is much better than having them disappear forever.

  • http://kitplummer.github.com Kit Plummer

    @Guy

    The delta is social-coding as inter-project collaboration versus your Forge.mil intra-project collaboration.

    It doesn’t take a whole lot of energy to see the innovation that is happening within the Github construct versus what’s happening in non-DVCS-based project repos.

    Believe it or not, developers are social creatures. And most software engineering work is done by developers, in isolation. Projects are just frameworks. Projects don’t need collaboration – people do.

    Your point about “life” is well understood. So how much does DISA charge for a production RACE instance per month?