Crowdsourcing At The U.S. Army

Crowdsourcing has permeated almost every industry, including the government. Notable examples of success in government include the community development of a 17-acre plot of land in Bristol Connecticut, a contest for community improvement in Birmingham Alabama, and user generated iPhone applications for San Jose city.

Even the secretive and highly bureaucratic Department of Defense has used crowdsourcing to their advantage. In 2010 the U.S. Army called upon military service members and civilian staff to enter the “Apps for the Army” competition. The purpose of the competition was to improve the Army’s ability to reach young and technologically savvy Soldiers using modern distribution channels – apps.

The initiative was a success. In two years, they generated 53 applications, five of which received prizes and seven of which received notable mentions. Without crowdsourcing, the Army would have taken close to two years to develop each application – and most likely at an exorbitant price. I’ve used several of the apps developed and directly benefited from the competition.

The majority of submitted apps can be placed into two buckets: 1) utilizing open source technology and 2) simplifying complicated information.


Bucket 1: Open Source Technology

Many of the 53 applications submitted to the competition attempt to supersede the outdated US Army mapping systems, and instead, utilize the Google maps and Google earth API. Government systems are typically outdated because they are closed-source, and any improvements are expensive and require a huge bureaucratic struggle.

Government organizations are remiss to allow employees access to outside technology for security reasons. Proprietary systems are considered safer – and limit manager liability in the even of complications. Unfortunately, using government technology created in the 1980s limits user functionality and destroys any chance of innovation.

By encouraging the use of open source technology and promoting the crowdsourcing of ideas, the US Army was able to rapidly innovate and customize.

However, I surmise that the need for enhanced security in an age of cyber warfare will eventually nullify any effort to continue crowdsourcing. In addition, highly connected defense contractors will fight crowdsourcing because their revenues rely on long and complicated production cycles.


Bucket 2: Simplify Important Information

All government organizations release standard operating procedures (SOPs), which are extremely complex, lack a comprehensible structure, and are unimaginably long and boring. Typical U.S. Army SOPs include “How To Conduct Physical Exercise,” “How To Respond To Natural Disasters,” and “How To Respond To Enemy Activity.” Typically, these several hundred page SOPs can be summarized in 20-30 pages. However, for liability and bureaucratic reasons, governments need to cover their bases.

The apps submitted to the competition simplified the information and synthesized It in a way that ground level employees could understand. People on the ground know which information is actually useful, and which information is less relevant. By crowdsourcing, we’re able to avoid the bureaucratic mess of government employees and empower those who actually need the information.



Crowdsourcing Fails (Durex, Mountain Dew, and NASA): Avoiding Internet Trolls


FOOD52 Makes Every Food Enthusiast Feel like Emeril

Student comments on Crowdsourcing At The U.S. Army

  1. Cool post – I had never thought about the government leveraging crowdsourcing before.

    I completely agree with your point that cybersecurity is going to be one huge obstacle in the way of more crowdsourcing by the government. This seems to apply at a few different levels. First, there’s the obvious concern that if the government crowdsources the development of an app, developers could theoretically insert “backdoors” that can be used to compromise the app in the future (these backdoors could be intentional, or even the result of oversight in development). Second, there’s the concern that if you rely on a third party’s API (e.g. Google for Maps), you’re essentially giving Google some of the usage data for the apps, so perhaps there’s a concern of security leakage there. Third, perhaps there’s also the concern that posting a prompt for the crowdsourced development of an app is itself a leakage of information about what the military is working on and what strategy it’s using.

    I think another major obstacle to using crowdsourcing to develop an app is the question of maintenance. Who is the best party to make future updates and fixes to a crowdsourced app? Locking the original developer into a long-term contract doesn’t seem to be the right answer. But, it might also be unrealistic to expect the government to develop these capabilities just to maintain a handful of crowdsourced apps. Perhaps future work can be crowdsourced again, but I imagine that would really compound the cybersecurity concerns above.

  2. Very interesting post, thank you for sharing. It is great that the army is experimenting with technology and tries to tap into recent trends. Completely agree with the previous comment that security and maintenance would eliminate any crowd sourcing elements from army proprietary technology. Given the importance of technology army will have to develop in-house capabilities to leverage existing solutions and brainstorm new ones. However, the second avenue of simplifying already existing SOPs sounds promising. To engage the public, the army could not only have the most crucial information simplified, there is also room to create apps that would aid when a disaster happens. For instance, when a hurricane hits a city, it would be great if an army-enabled app would serve as a platform for citizens to report losses, emergencies and state of their neighborhoods. That way using crowds army could get an accurate picture of the situation.

  3. Great post and thanks for highlighting something that I’d guess most of us know nothing about. This is an enlightening use case that I haven’t really thought of before – using crowdsourcing within highly bureaucratic or regulated organizations to break through the high cost or lengthy delays of developing services. One question that would fall out of this, however, is whether these services are harmed by not going through a more rigorous process. While I definitely agree that many organizations have way too much bureaucracy and some industries are overburdened by regulation, presumably there was some reason for this development. With the case of the US military, are you at all concerned that using external, crowdsourced developers could cut corners in unknown ways and potentially become a liability?

    Thanks again, great post.

  4. Great post. When I was in boot camp the Army’s idea of crowdsourcing was a small box for suggestions that each company commander had outside their office. Needless to say that box was mostly filled by anonymous complaints…
    I really wonder if big bulky governmental organizations can utilize crowdsourcing to start moving faster or as you say the security requirements will lead them to overpay for bug bulky systems.

Leave a comment