Open Source on the Battlefield

Two soldiers in a hastily built watchtower.

In Iraq, Sergeant 1st Class Martin Stadtler had nothing. He was stationed near Mosul, at a base that covers 24 square kilometers. Surrounding the base was a wall, and at intervals along that wall stood watchtowers. Those towers were improvised; they were large concrete water pipes, stood on their ends.

Inside each tower is a pair of soldiers. They’re watching for insurgents. To communicate with the home base, they had standard-issue tactical radios. Unfortunately, these radios couldn’t reach home base — the base was too big. Soldiers had to play a game of Telephone to reach the base: one tower radios the next until they are finally in range of the home base. Obviously, this would not do.

Fortunately, SFC Stadtler knew how to use open source software. Using found hardware, like a laptop pulled from the trash, and wires pulled from collapsed buildings, he was able to establish a wireless network between the towers and the home base. He was able to install freely available voice-over-ip software on this recycled hardware, which turned the computer into a wireless telephone. The soldiers were now able to communicate with each other and the home base. At no cost.

An improved wireless device, in an ammo can.

An improved wireless device, in an ammo can.

If SFC Stadtler had instead asked the Pentagon for a wireless communication system that suited his needs, he would have gone through the traditional Department of Defense procurement process. The solution to his problem would have cost hundreds of thousands or millions of dollars, and would never have been delivered before Stadtler’s tour was over.

Later, Stadtler had a problem with his Forward-Looking Infra Red cameras. The FLIR system allows soldiers to see in the dark, so they can see if a bomb is being planted in the middle of the night. Unfortunately, the FLIR system requires monitoring: a soldier needs to be watching for activity all night. Soldiers get tired, though, and soldiers get distracted. So he needed a way to monitor the FLIR without relying on a person.

Fortunately, the FLIR runs on open source software. Stadtler was able to open up the FLIR system and install some software that could help him. The software, invented by a young man in Germany who wanted to watch his cat while he was away from home, was perfectly suited to the FLIR problem. Instead of a cat, they would watch for insurgents.

SFC Martin Stadtler

What made SFC Stadtler’s clever ideas possible was the availability of commodity computer parts, and the availability of open source software. Computing power is now everywhere on the battlefield. Every tactical vehicle is filled with personal computers. Soldiers have ready access to laptops. At the same time, Internet connections are now common at the average base, which puts hundreds of thousands of open source projects in reach of the soldiers in the field. Add a smart soldier who’s experienced with open source software, and the battlefield is now a rich environment for innovative improvisations.

These improvised solutions aren’t perfect, of course. There are real and valid concerns about these ad hoc solutions, like security and reliability. But just as the improvised watchtowers that surround SFC Stadtler’s base would never be reviewed by an architect or a building safety official, these software hacks are too useful to the warfighter to be discouraged. The solutions are temporary and very specific to their situation. If there was time and money available, something better could be produced — but in Iraq, Stadtler had to make do with what he had.

It’s important to encourage this kind of innovation on the battlefield. One can never anticipate what a soldier might need when they arrive in theater. That’s why it’s important to provide soldiers tools, rather than expensive and inflexible products. Increasingly, the most important tools are software, and open source software is both easier to obtain and more easily changed to meet the situation at hand.

So SFC Stadtler’s experience presents an opportunity for three specific improvements that would institutionalize this kind of innovation.

First, let’s consider why this kind of innovation is not more widespread. The federal procurement system, and especially the DOD procurement system, is designed to acquire materiel and the cheapest price and the lowest risk. This is a procurement system for battleships and toilet paper. It does not accommodate the dynamic nature of software, and how it changes over time. It is specifically designed to limit risk. The inflexibility of the system introduces overhead and costs that are inappropriate for tactical environments. So Stadtler was forced to work around the system. Other soldiers would be afraid of disciplinary action for fielding these improvised solutions — a strange circumstance, since improvising around physical products like the concrete water pipes is perfectly ordinary. Soldiers should be encouraged to experiment with software in the field.

If we believe it’s important to encourage this innovation in the field, soldiers must be trained to do so. SFC Stadtler was able to take advantage of these skills only because he was trained as a Red Hat Certified Engineer. The specific certification is unimportant, but based on Stadtler’s experience, it seems that a force that has been trained to safely find, acquire, and alter open source software would be more agile and responsive on the battlefield.

Finally, and most important, is the need for a repository of these good ideas. There are thousands of soldiers in Iraq, Afghanistan, and elsewhere with problems just like SFC Stadtler. True to the open source model, there is no reason that Stadtler’s good idea should not be shared elsewhere in the DOD. At the moment, there is no forum for this sharing. If the DOD were to create a central location where tactical open source tools and stories could be shared, it would not only solve these soldier’s problems, but encourage other soldiers to improvise. Having these tools stored centrally would allow for proper review, and constant improvements to the tools as more users take advantage of them.

With proper encouragement, training, and a “home” for their work, the collective ingenuity of the warfighter could be used much more effectively. Once again, open source software allows communities to build around common problems, and gives them tools to solve the problems as a group. On the battlefield, we would never provide a Humvee with the hood sealed shut, yet every day we deliver software that is opaque and cannot be adapted to a changing battlefield. Permitting the warfighter to solve their own problems, and share their wisdom with others, will become a critical issue as more and more of the battlefield is governed by software. Open source software makes this possible.

[Update: You can see me talking about this, and other open source in government stories, in my talk at OSCON 2009.]

  • kitplummer

    Very good story. We know there are many others out there (like COIN mentioned here: http://kitplummer.github.com/2009/07/02/social-coding-in-the-dod.html)

    The Army is very interested in composability, and the “home” you mentioned is in a stage of deep thought. I’m currently trying to build out a prototype – and am I’m sure we’ll discuss further at http://mil-oss.org in the near future. ;)

  • http://www.forge.mil vietmeyer

    In addition to kitplummer’s work, there’s also Forge.mil which went live in April in the unclass environment and in July on SIRPNet. It’s designed to enable the collaborative development and distribution of open source and community source software within the DoD. Go to http://www.forge.mil for more information. We’d love your feedback.

  • https://creativecommons.net/ghelleks/ gunnar

    Rob — I’ve been watching forge.mil for a while now. I don’t have an ECA, so I can’t tell, but is it set up for quick projects like SFC Stadtler’s? I’m under the impression it’s more appropriate for less-improvised, more-planned projects.

  • kitplummer

    It looks like NASA has figured it out, with NEBULA. A very interesting “platform” to accommodate what they call “self-service” development and hosting. Very cool.

    http://nebula.nasa.gov/services

    Now, imagine if troops had access to something like NEBULA, a version on both SIPR and NIPR. One of the fundamental issues we need to battle is the “long-term” maintenance of a “battlefield” developed application – so it has life after the problem solver moves on, which includes runtime management. I like the way NASA has put together their package. Though I’m not a fan of Trac(Subversion), I can see why they’ve made the decision to go in that direction. Still, as Gunnar pointed out in his comment, there’s a need to accommodate a quick-hit, individual-centric project – which is provided by a platform like Github.com.

  • http://emailtoid.net/i/63ae221a/fe35d88d/ emailtoid.net/i/63ae221a/…

    Gunnar,

    To your question about Forge.mil being able to handle quick projects – absolutely. In fact, the kind of work that SFC Stadtler is doing is exactly the kind of thing I’d like to see us do more of on Software.Forge.mil. We already have a ‘Utility Library’ project to collect smaller utility type efforts, but even some of the comms stuff that SFC Stadtler did could be hosted on Forge.mil.

    Let’s catch up at MIL-OSS in a couple of weeks, or barring that, the Red Hat Summit in September. Is SFC Stadtler going to speak at either conference?

    -Guy Martin