U.S. DOD releases “Open Technology Development Guide”.

The U.S. Department of Defense has just released a pretty amazing document: “Open Technology Development: Lessons Learned and Best Practices”. (Warning: if you don’t like reading rave reviews, stop now.)

In the words of RedHat’s Gunnar Hellekson:

It’s a handbook for using and making open source in the DOD and the US Government, sponsored by the Secretary of Defense. It provides practical advice on policy, procurement, and good community governance, all under a Creative Commons license. I’ll be providing some more commentary later, but this is a huge step forward in the adoption of open source in the US Government.

He’s absolutely right. This document is about as thorough as one could hope for, and hopefully will carry weight throughout the federal government, not just in DOD. The authors dig deeply into contracting policies, government acquisition of intellectual rights, etc, gently but methodically demolishing common misconceptions as they go. They also devote a lot of space to open source social dynamics, the importance of building a technical community, governance structures, vendor participation, etc. For example, from page 10:

2.1.4.1   Forkability

A fork is a competing project established using a copy of an existing project’s software.

It is critically necessary that an [Open Technology Development] project be forkable. That is, it must be possible to create a viable competing project using a copy of the existing project’s software source code. Creating a fork is similar to a call for a “vote of no confidence” in a parliament. [...] Forkability is a necessary part of OTD governance. As long as a project is forkable, project leadership will strive to be responsive to users and developers. This is because if leadership decisions are particularly egregious, a forked project can be started under more responsive stewardship. Easy forkability actually reduces the risk of a fork, because leadership will be forced to listen to users and developers (because if they do not, a viable fork will emerge). In addition, easy forkability increases the likelihood of contributions; easy forkability provides significant protection to would-be contributors, because if they later disagree with project governance, they can create a fork. [...]

Even where the acronym- and citation-heavy nature of the subject matter cannot be avoided, they’ve managed to keep it readable, which is no small accomplishment. A typical passage on procurement, from page 6, shows the care they’ve taken to anticipate precisely the questions government project managers and decision makers are likely to have:

A key issue in any [Open Technology Development] project is to work out the intellectual rights so that the software can be used, examined, modified, and redistributed among the community.

When done correctly, requiring the intellectual rights necessary for an OTD approach does not conflict with DoD policy. DoD Federal Acquisition Regulation (FAR) Supplement (DFARS) 227.7203 could be misunderstood as forbidding an OTD approach, but when closely examined it does not forbid OTD at all. DFARS 227.7203-1(c) (as revised on January 20, 2011) says that “Offerors shall not be required, either as a condition of being responsive to a solicitation or as a condition for award, to sell or otherwise relinquish to the Government any rights in computer software developed exclusively at private expense except for the software identified at 227.7203-5(a)(3) through (6).” Similarly, DFARS 227.7203-1(d) states that “Offerors and contractors shall not be prohibited or discouraged from furnishing or offering to furnish computer software developed exclusively at private expense solely because the Government’s rights to use, modify, release, reproduce, perform, display, or disclose the software may be restricted.” Note, however, that these policies only apply to software developed exclusively at private expense. The government can require that it receive rights to software that the taxpayer paid to develop (in part or in whole), and such software is the focus of this document.

The entire document is 34 pages (68 with appendices). It’s under a free, share-alike license, and I expect we’ll see distillations and other derivatives coming out soon, as the open government world realizes what a gold mine this is.

The main portion concludes with a great checklist:

4.6   OTD Success Checklist

The following is a suggested checklist for an OTD development projects:

  • Community first, technology second. Often the military will focus on creating technology solutions when stakeholders aren’t onboard or are non-existent. Technologist must be controlled and not allowed to build and/or deploy software until a community and user base is identified.
  • Default to open, closed only when required.
  • Your program is not special. Yes, the military has special warfighting needs and capabilities, but (especially in IT) we are not. Search for existing IT projects and industries and use their solutions.
  • Set simple rules about how to share and how to access GOTS. Creating a software source code sharing scheme that works and is to the governments advantage is important.
  • 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.
  • Co-mingling 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.
  • Continue and encourage vigorous debates and discussion about the software among users, and among developers.
  • Do not forget to document. This includes user, installation, administration, and design documentation. It also includes guidelines on how to install and maintain the software in a way that provides security.
  • Configuration management: Information is maintained about what external tools/evaluations have been run, on what version of the software, and what the results were.
  • Run the project as a guild: users occasionally become developers, at least for small defects.

The appendices are as valuable as the main document. For example, Appendix A “…presents pertinent U.S. Government guidance and policies related to Open Technology Development (OTD)”, and then spends the next 10 pages listing every federal policy, memo, circular, and standards document they could find related to open source and open technology.

Congratulations to the sponsors and authors. They deserve to be listed out in full — quoting from the document’s acknowledgements section:

Development of this document was sponsored by Dan Risacher of the Assistant Secretary of Defense (Networks & Information Integration) (NII) / DoD Chief Information Officer (CIO), Fritz Schulz of the Under Secretary of Defense for Acquisition, Technology and Logistics (AT&L) Rapid Fielding Directorate, the AT&L Cross-cutting Studies Group and Heather Burke of SPAWAR Systems Center Atlantic (SSC LANT).

This document was authored by John Scott, David A. Wheeler, Mark Lucas, and J.C. Herz. The authors would like to thank the following groups and individuals for their edits, inputs, help and guidance: John Weathersby, Kane McLean, Gunnar Hellekson, Josh Davis, Deb Bryant, Scott Goodwin, the MIL-OSS working group (http://mil-oss.org & http://groups.google.com/group/mil-oss) and many others.

The full document is at cio-nii.defense.gov/sites/oss/, together with some other excellent DOD open source software resources.

[ Disclaimer: The document cites and quotes from my book "Producing Open Source Software" in several places. I assure you I would have raved about the doc even if they hadn't cited me, however! ]

About Karl Fogel

See http://www.red-bean.com/kfogel for more information.
  • Spence_m

    This should be mandatory treading by other agencies. The whole health industry could cut costs if it shared software instead of paid for licenses. Proprietary systems are impediments to information sharing. Supply chains need low impedance systems.