There are a lot of people who are passionate advocates for “crowdsourcing” as a solution to everything from software (such as “Linus’ Law” https://en.wikipedia.org/wiki/Linus%27s_Law ) to military culture (see point number 3 from: https://mwi.usma.edu/learning-disrupt-army-needs-experimental-culture-create/ ).
Actually, it’s that second link that inspired this whole post, as I’m not sure that “crowdsourcing” is necessarily part of the “right mix” of techniques that will make the Army better. Nor am I convinced that an “experimental culture” is appropriate for an organization that has a core mission function of conducting large scale combined arms maneuver warfare. The most obvious problem with crowdsourcing is illustrated by a thought experiment that has played out many times in reality: if we take a look at the problems presented by a crowdsourced game of chess. If you take a chessmaster, and pit him or her against a thousand, or ten thousand, random Americans in a one versus “crowdsource” you’ll see the chessmaster win time and time again. The outcome will never be in doubt, as every time this experiment has been executed, the outcome is the same. The wisdom of the crowds is irrelevant to the expertise of an individual.
So why does crowdsourcing work with projects such as Free Open Source Software such as Linux, but not work with a game of chess? Here is my first real attempt to show why “crowdsourcing” works for Linux, but not for chess.
- Linux is a project with highly structured approval for changes and version control that allows a team of experts to pick the best contributions for inclusion. Chess is a game where “democracy wins” on the most popular next move has no real review structure, and if there were a review structure of experts, the opinion of non-experts would be irrelevant to their choice.
- Linux is a project that has no defined end state, which means bad input can be rolled back through version control, or patched in the the future. Chess is a linear game where the consequences of past choices determine the outcome of the game, so there is no opportunity to “patch in” a lost piece at a critical time (unless you are playing a variation like bug house, but that’s a game for hard core chess nerds).
- The people contributing to Linux are experts, or passionate amateurs gaining expertise, within the realm of computer science and engineering. The random crowd of chess players against the expert are largely not experts, and will never spend the “ten thousand hours” focusing on becoming experts at chess.
- Linux as a project came into a lot of external support early on from academia and established projects such as GNU, and Linux as a project continues to receive external support because it is the “goose that lays the golden egg” for a lot of tech companies. There really is no parallel for crowd sourced chess.
So, given these scenarios, do you want a military that embraces “crowdsourcing” as a function? Honestly, no. You want a military that effectively applies combat power to problems to advance the interests of the Nation. As much as we talk about wanting a military that is flexible, adaptable, and able to achieve positive outcomes with minimal guidance and intelligence, in reality we need a military that can bring forth violence and death at a moments notice. I hate to quote Clausewitz but he did point out the “dual nature” of war, the violence and the politics.
In 2003, the United States and the “Coalition of the Willing” crushed the Iraqi military for the second time in just over a decade. The culture of training to “task/condition/standard” and force on force exercises worked. Unfortunately it did not create a military force that was able to forestall an insurgency (a task never even identified for training) or work effectively with the US State Department to rebuild a country (despite have a lot of doctrine written to do just that). And that should be a stark reminder to people that crowdsourcing is not a smart way to wage a war, as the passionate but uninformed will likely say “Just bomb ’em like we did in WWII!” which ended up being the same strategy in Vietnam which turned into a failure. War adapts to local conditions, and without expertise on those actual conditions, we are all uninformed idiots who shouldn’t offer opinions on what the military ought or ought not do in a given situation.
Getting back to the Linux example, companies that capitalize off of open source software usually do not stay on the “cutting edge” of the release cycle. FOSS has a habit of “breaking stuff” with patches and upgrades. Libraries, versions, and dependencies cause things to not work right that worked just fine the day prior (I’m looking right at you Python). Microsoft had the exact same problem with Windows to the point where they require new programs to run without external dependencies (other than approved ones of course, such as .net) because version control for software between different generations of Windows was becoming a royal ass pain for Microsoft. At one point you had “windows on windows” emulators to keep legacy third party software running on the boxes because people wanted their favorite program from ten or fifteen years ago to run on the latest Windows release.
So, if you are going to see benefits of crowdsourcing you seem to need the following:
- A community of experts who contribute from their expertise.
- A review process that controls what inputs get synthesized into the outputs.
- A cohesive vision that allows everyone to work in a common direction and understand how each contributing effort works towards overall success.
You know what that sounds like, right? It sounds like a military staff conducting mission planning using a planning process or design methodology. I have issues with every single one of those planning methods as they will always come up with a plan of military action, but won’t necessarily give you the right plan for the nation.