DOD does Open Source

July 18, 2006

Open source in the national interest

Filed under: Open Source

Computer Business Review has an interesting review of the United States Department of Defense report "Open Technology Development". [PDF] If you haven't read it, you need to take a look. It is one of the most clear-sighted documents on open source that I've yet read, and should banish CIO doubts as to the core benefits of open source: cost savings, security, speed of development, robustness of development, etc.

SCO and others have been crying 'Foul' on the US government's increasing adoption of open source, suggesting (as Darl McBride writes here in his letter to the US Senate and House)

"I assert that open source software - available widely through the Internet - has the potential to provide our nation's enemies or potential enemies with computing capabilities that are restricted by US law."

Think that's a bit silly? Try this one, from the CEO of Green Hills Software:

"Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software that will soon be incorporated into our most advanced defense systems."

Apparently O'Dowd (Green Hills CEO) has never actually taken the time to learn how open source and, specifically, Linux, operates. But we'll forgive his abject ignorance on the condition that someone pays his tuition to head back to school at some point. He needs it.

Anyway, back to the Department of Defense's report. It has a treasure trove of insight, nicely counterbalancing the ignorance noted above:

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department.

Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems....

Software code has become central to the warfighter's ability to conduct missions. If this shift is going to be an advantage, rather than an Achilles' heel, DoD must pursue an active strategy to manage its software knowledge base and foster an internal culture of open interfaces, modularity and reuse. This entails a parallel shift in acquisitions methodologies and business process to facilitate discovery and re-use of software code across DoD.

The national security implications of open technology development (OTD) are clear: increased technological agility for warfighters, more robust and competitive options for program managers, and higher levels of accountability in the defense industrial base....

DoD needs to use open technology design and development methodologies to increase the speed at which military systems are delivered to the warfighter, and accelerate the development of new, adaptive capabilities that leverage DoD's massive investments in software infrastructure.

To be fair, the DoD is not talking about open source exclusively in this report. It is talking more broadly about open development:

In the private sector, changes in design methodologies for software development are enabling enormous gains in productivity and efficiency. Individuals and companies are able to leverage open technology platforms to rapidly deploy new solutions and capabilities to improve their competitive advantage. These open technology platforms may be open source or proprietary software applications with open standards and published interfaces that allow the rapid development of new capabilities by third parties without coordination agreements.

It's the mash-up mentality, in some ways, that seems to appeal most to the DoD. But it's not just about "Web 2.0" thinking. It's about how to make the DoD a participant in the wider software community, thereby saving development cycles and development dollars, as this fascinating excerpt indicates:

DoD has two competing interests:

1. Provide for the defense of the U.S., and;
2. Support and grow the U.S. industrial base, which provides materiel and systems so that DoD can accomplish its mission.

These trade-offs are well understood for physical goods and services, but not as well understood for digital ones. DoD can easily calculate the cost difference between developing or acquiring a physical good or service by simply comparing make or buy costs. There is however a fundamental difference between physical and digital products. Digital goods (software code, music, movies, etc.) once created can be copied perfectly with relative ease: limiting distribution enforces scarcity, but that scarcity is arbitrary and negotiated, rather than an innate property of the product. Software's ability to be replicated also means it can be incorporated into other software systems without "using up" the original component, as one would with physical components.

The business model of purchasing physical goods and services has served DoD well in the past; but it falls short when applied to software acquisition. By treating DoD-developed software code as a physical good, DoD is limiting and restricting the ability of the market to compete for the provision of new and innovative solutions and capabilities. By enabling industry to leverage an open code development model, DoD would provide the market incentives to increase the agility and competitiveness of the industrial base.

Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department. Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems.

DoD needs to evaluate the impact that locking into one set of proprietary standards or products may have to its ability to react and respond to adversaries and more importantly, to technological change that is accelerating regardless of military conflict. In order to remain competitive in a rapidly shifting technological landscape (including the disruptive technologies leveraged by our adversaries), DoD's software development and business processes must break out of the industrial-era acquisitions mold.

Amazing stuff. The DoD summarizes as follows, and shows a clear understanding of open source's benefits:

To summarize: OSS and open source development methodologies are important to the National Security and National Interest of the U.S. for the following reasons:

• Enhances agility of IT industries to more rapidly adapt and change to user needed capabilities.
• Strengthens the industrial base by not protecting industry from competition. Makes industry more likely to compete on ideas and execution versus product lock-in.
• Adoption recognizes a change in our position with regard to balance of trade of IT.
• Enables DoD to secure the infrastructure and increase security by understanding what is actually in the source code of software installed in DoD networks.
• Rapidly respond to adversary actions as well as rapid changes in the technology industrial base.

Amen. Now if you're a CIO tasked with saving money and resources for a large or small enterprise, wouldn't it seem prudent to follow the lead of an organization tasked with saving taxpayers' money and lives? Yeah. Me, too.

Posted by Matt Asay on July 18, 2006 08:52 AM