Ever see a photo of this beastie – the M1126 Stryker Infantry Carrier Vehicle? It’s a pretty imposing modern fighting vehicle and a ride that would certainly enliven one’s morning commute. When it first entered service in 2002, the pre-production vehicles had to be maintained by fixers from the contractor who manufactured it, General Dynamics Land Systems, at least for some major parts of the vehicle like the suspension.
This rather inconvenient arrangement ended when full-scale production began in 2005 and the Iraq War imposed its realities on the Stryker force. But imagine what would have happened had these limitations stayed in place, and only contractor personnel could have fixed anything that broke on the Stryker in the field? Not only would far fewer Strykers have been available to do the job, but any in-the-field modifications its crews found would not have been permitted to be added to the vehicle. The Stryker would have been less effective and less numerous – and would probably have been seen as a failure.
What does that have to do with software? Well, the Department of Defense has decided that, just as it can’t allow the maintenance of its armored vehicles to be a closed system, it shouldn’t permit a similar situation with software.
Katherine Noyes penned a piece in PCWorld last week about the DoD’s new publication Open Technology Development: Lessons Learned and Best Practices for Military Software, which is designed to aid government workers and contractors “implement open technology development (OTD) for software within government projects, particularly in defense.”
In other words, the DoD is not just approving the adoption of open technologies – it’s given its workers a guide to implement it. “By implementing OTD, DoD could help make software code an infinitely renewable military resource,” that guide concludes.
That’s an interesting point – although the more significant implication of this guide is that open source software has matured to a point that it’s considered robust enough to be used in fighting wars. Business writers often use the term “life-or-death” to describe matters of grave importance; military writers use it to describe actual life-or-death matters. And in those kinds of life-or-death matters, open source is now considered up to the task.
Contrast that to the traditional software vendors who wish to maintain a status quo similar to that of the early years of the Stryker, when development and maintenance was entirely controlled by a single contractor. The argument that they’ve always made is that open source is less reliable because it’s less expensive and less secure because it’s open – two arguments that have lost credence given the very existence of the DoD guide.
The military has long benefitted from a “community” approach to its weapons in the field. From the hedgerow cutters made from scrap steel that allowed U.S. tanks to move inland from Normandy in WWII, to the wooden and scrap metal improvised armor soldiers affixed to their Hummers to defeat rocket-propelled grenades in Iraq, good ideas tend to spread quickly – and the DoD is asserting that should not stop with hardware. Software, too, is now a crucial war-fighting asset and adapting to lessons learned in battle is not possible without open development.
The fight for customers may not be life-and-death, but it certainly is replete with lessons learned on the fly. Like the DoD, businesses are coming to the conclusion that proprietary, closed software systems are not only expensive and rigid – they’re also an impediment to adjusting for changing business conditions and customer behavior.
If you want to react quickly to changing conditions on the battlefield – even if it’s a metaphorical business battlefield – open approaches are critical. Building a business software infrastructure that’s based on open standards, open APIs and open source will enable you to react in time to claim victory.