Open Source @ Department of Defense

The report on:  

Open Technology Development (OTD):
Lessons Learned & Best Practices for Military Software

by John Scott, David A. Wheeler, Mark Lucas, and J.C. Herz.

and sponsored by 

The Assistant Secretary of Defense 
(Networks & Information Integration) (NII) / 
DoD Chief Information Officer (CIO) and 
the Under Secretary of Defense for Acquisition, Technology, and Logistics (AT&L)

 was recently published on May 16, 2011.

http://www.oss-institute.org/OTD2011/OTD-lessons-learned-military-FinalV1.pdf

This report contains a wealth of interesting material about the adoption of Open Source Software in the US Department of Defense.

The reading of the full report is highly recommended, but here I take the liberty of quoting some of the passages that I have found most interesting for the community that is already familiar with Open Source, but not familiar with FOSS use and adoption in the Department of Defense.

 The report above is distributed under the Creative Commons Attribution ShareAlike 3.0 (CCBY-SA) License, and therefore, this specific blog post is also distributed under that same license (to satisfy the requirement of ShareAlike).

Memorable quotes from the report:

“Software is the fabric that enables modern planning, weapons and logistics systems to function. It might be the only infinitely renewable military resource. Capabilities evolve as new software is created a new or builds on existing software. From ground sensors to satellites, software is pervasive; it is the final expression of military knowledge transformed into source code and deployed on the battlefield.”

“Imagine if only the manufacturer of a rifle were allowed to clean, fix, modify or upgrade that rifle. The military often finds itself in this position with taxpayer funded, contractor developed software: one contractor with a monopoly on the knowledge of a military software system and control of the software source code. This is optimal only for the monopoly contractor, but creates inefficiencies and ineffectiveness for the government, reduction of opportunities for the industrial base, severely limits competition for new software upgrades, depletes resources that can be used to better effect and wastes taxpayer-provided funds”

“To resolve these issues, a modern software intellectual property regime to broaden the defense industrial base needs to be defined that enables industry-wide access to defense knowledge, including software source code, documentation, hardware designs and interfaces. The result will be increased competition and a net lowering of the cost of innovation.”

 “Key Benefits of OTD are:…

Increased Innovation: With access to source code for existing capabilities, developers and contractors can focus on innovation and the new requirements that are not yet met by the existing source code capabilities. This agility is particularly important because of a projected shortfall in the number of U.S. citizens with engineering and computer science degrees who will be clearable to work on military projects in the coming decades [National Academies 2008].”

“Information Assurance & Security: One of the biggest values of open source development is enabling wider community access to software source. In this manner bugs become shallow and thus more easily found. Wider access to software source code also is key for forming and maintaining a software security posture from being able to review software source code to seeing what is actually present within that software.”

“Lower Cost: … The elimination of monopoly rent, combined with greater competition, will drive down costs and improve the quality of resulting deliverables, because any contractor who works on a system knows that they can be replaced by a competitor who has full access to the source code and documentation.

“As Defense Secretary Robert Gates has said “The gusher [of money] has been turned off and will stay off for a good period of time.” DoD needs a more efficient software development ecosystem – more innovation at lower cost. OTD squeezes financial waste out of the equation by reducing lock-in and increasing competition.”

“Previous studies have documented that open source software is currently used in many of DoD’s critical applications and is now an inseparable part of military infrastructure [MITRE2003] [OTD2006].”

“Note that by law and regulation, software licensed to the public and used for at least one non-government purpose is commercial software, even if it is maintained by the government.”
(More on this in a follow up blog…)

“Government Accountability Office (GAO) report GAO-06-839 of July 2006 [GAO 2006] reported that “The lack of technical data rights has limited the services’ flexibility to make changes to sustainment plans that are aimed at achieving cost savings and meeting legislative requirements regarding depot maintenance capabilities… Unless DOD assesses and secures its rights for the use of technical data early in the weapon system acquisition process when it has the greatest leverage to negotiate, DOD may face later challenges in sustaining weapon systems over their life cycle.”

“Government Accountability Office (GAO) report GAO-10-833 of July 2010 [GAO2010] found that for “services supporting DOD weapons programs, the government’s lack of access to proprietary technical data and decades-long reliance on specific contractors for expertise limit—or even preclude the possibility of—competition.” This is a serious problem, because competition “is a critical tool for achieving the best return on the government’s investment.” In nearly 60 percent of 47 noncompetitive Defense contracts examined by the GAO, the department was essentially stuck with a certain contractor since it lacked technical data behind the goods and services it has been purchasing.”

“David M. Van Buren’s 2011 memo [Buren 2011] is the Air Force implementation of USD(AT&L) direction for a one-page competitive strategy. This Air Force memo requires that every Air Force program describe how it will “obtain technical data, computer software documentation, and associated intellectual property rights necessary for operation, maintenance, long-term sustainment, upgrades, and future competition” and a summary of the business case analysis if it is not obtaining them.”

“Since some people will struggle with the openness of an OTD project, it is important to stress the need for openness. Point to guidance such as the current administration guidelines and mandates on transparency, and on the DoD 2009 memo on open source software which mandates that software be treated as data and shared appropriately. To quote the 2009 memo: (f). Software source code and associated design documents are “data” as defined by DoD Directive 8320.02 (reference (h)), and therefore shall be shared across the DoD as widely as possible to support mission needs.”

“The government should also require contractors and software integrators to organize their projects so that they are continuously transparent and open to the government for remote inspection.”

“Since collaboration among widely-distributed contributors is key to OTD, projects must establish a project site with the technical infrastructure needed for collaboration. The project site must enable the shared development of the software, test suites, and documentation…”… “In DoD contract language this technical infrastructure is the set of “data repositories” (see DFARS 227.7108), but the need for collaboration means that these repositories must implement additional requirements not always mandated by contracts.”

“Projects should prefer to use widely-used OSS collaboration tools that work well with any standards-compliant web browser.”

“Contractors must expect that this technical infrastructure means that the government and other contractors will have continuous access to intermediate progress. This transparency is by design.”

“Software Configuration Management (SCM). The central project site must provide a mechanism for tracking changes, including at least the software and often test suites and some documentation. … There are two major types of SCM systems, centralized SCM (e.g., subversion aka SVN) and distributed SCM (e.g., git and mercurial). As discussed below, in a military environment distributed SCM systems (such as git) have significant advantages and should be preferred for SCM of OTD projects.”

“In many cases software development will occur that is intended to be available to the public as OSS, but must undergo classification and/or export control review first. This can be a significant barrier to collaboration, but in many cases it is a necessary step. Consider setting up an internal OGOTS project to “stage” these proposed changes until they can be released to the OSS project. Staging is especially important if it is determined that some changes are needed for government use and cannot be released to the public. Such proposals should ideally be set up as separate “branches” so that even if some are deemed to be unreleasable, other changes can still be independently released.”

“Projects should seriously consider using a distributed SCM (such as “git”) where there may be export control issues or varying levels of classification. Distributed SCM systems make it much easier to create separate external branches and later provide them to others for merging if approval is granted.”

“Don’t Fork OSS Solely for Government Use: A common mistake made by companies and government projects that begin to adopt OTD approaches is to start by creating a fork by taking a snapshot of the source code and modifying it for their own needs, in isolation from the community surrounding that code.This is a mistake because successful OTD projects are constantly evolving and improving. Creating a fork isolates all fork users from the main OTD project, including the improvements it makes. Refreshing OTD components is a very effective way of evolving the baseline for the project.”

And let’s close with a point that it so important that we will elaborate on it in a follow up blog post:

“Open Source Software must be considered as a commercial item for the purpose of Federal Acquisitions.”

or quoting the report:

“Existing open source software (OSS) is often neglected during AoA (Analysis of Alternatives) development. This is contrary to law and policy, which requires market research of commercial items (including publicly-available OSS). A program office must search out OSS alternatives for use, and if appropriate, experiment with these tools.”

The reading of the full report is strongly recommended: 

http://www.oss-institute.org/OTD2011/OTD-lessons-learned-military-FinalV1.pdf