US Defence purchasing emphasises Open Technology Development

The United States secretary of Defence has released the guide, Lessons Learned & Best Practices for Military Software. It provides some of the most practical software purchasing guidelines for governments to date, and strongly emphasises the use of Open Standards, Open Source, and associated development practices.
Below are some highlights from the paper:

Definition of Open Technology Development:

OTD is an approach to software/system development in which developers collaboratively develop and maintain software or a system in a decentralized fashion. OTD depends on open standards and interfaces, open source software and designs, collaborative and distributed online tools, and technological agility.

Key Benefits:

• Increased Agility/Flexibility: Because the government has unrestricted access and rights to the source code developed with taxpayer funds, ...
• Faster delivery: Because developers only need to focus on changes to, existing software capabilities instead of having to redevelop entire systems, ...
• Increased Innovation:...
• Reduced Risk: creating new capabilities from scratch is riskier than re-using existing capabilities...
  
• Information Assurance & Security: ...
  
• Lower cost: The first cost to fall by the wayside with OTD is the monopoly rent the government pays to contractors ...
  

Wise spending:

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.

Innovation is fleeting:

... sole possession of the software gives the U.S. a distinct advantage over its adversaries. However, technological advantage is usually fleeting. Often there is a commercially-developed item available to the public that begins to perform similar functions. As it matures, other organizations begin using this non-GOTS solution, potentially rendering the GOTS solution obsolete. Such cases often impose difficult decisions, as the government must determine if it will pay the heavy asymmetrical cost to switch, or if it will continue “as usual” with its now-obsolete GOTS systems.

Sample questions provided for:

• Analysis of Alternatives (AoA) ...
  
• Request for Information (RFI) ...
  
• Request for Proposal (RFP) ...
  

Success Checklist:

• Community first, technology second. Often the military will focus on creating technology solutions when stakeholders aren't onboard or are non-existent. ...
• Default to open, closed only when required.
• Your program is not special. ... Search for existing IT projects and industries and use their solutions.
• Set simple rules about how to share and how to access GOTS. ...
• Intellectual rights. Using open source software licenses greatly simplify rights management for the government.
• Negotiate and demand unlimited rights in software and source code. Government purpose rights are basically crippled license scheme that should be avoided.
• Do not create new software licenses, use existing licenses – they are understood in commercial industry and have been approved by corporate counsels.
• Greatly limit co-mingling of government-funded software with privately-funded software (especially if it is patented). If co-mingling is required develop in a modular fashion and require unlimited rights.
• [Don't] co-mingle export-controlled and classified software with other software. Developers should instead devise a “plug-in” architecture (where possible) that allows use and sharing of software not restricted by export controls or classification.
• Limit incorporating proprietary (especially non-OTS) components that incur licensing fees, especially if the system is designed to depend these components.
• Plan and fund management of the project's community and maintenance of source code as an O&M transition element.
• ...
• Use/modify/create open standards, in that order. Verify that the standards used are open; a simple test for openness is to determine if the standard is implemented by open source software.
  

Federal government and the DoD policy documents:

• Office of Management and Budget (OMB) M-04-16’s Software Acquisition. This memo simply states that the existing federal policies on software acquisition apply equally to both proprietary and open source software. Note that there is no preference for proprietary software over OSS.
• DoD CIO’s Clarifying Guidance Regarding Open Source Software (OSS) of October 2009. This policy memo specifically notes that “There are positive aspects of OSS that should be considered when conducting market research on software for DoD use”. It even states conditions under which “Software items, including code fixes and enhancements, developed for the Government should be released to the public (such as under an open source license)”.

License Selection Criteria:

When picking an OSS license, keep the following criteria in mind:
1. Use an existing OSS license;
2. Make sure it is actually OSS. certified as OSS by the Open Source Initiative (OSI) and as Free Software by the Free Software Foundation (FSF).
3. Use a GPL-compatible license. Most OSS is released using the GNU General Public License (GPL) version 2 or version 3. This does not mean that all OSS must be released using the GPL, but choosing a license incompatible with the GPL (both versions) is very unwise.
...
6. Use a common OSS license.

This article is released under the CC-By-SA 3.0 License.
Image sourced from Open Technology Development paper.