Contents
A Landmark Document for Government Open Source
In May 2011, the United States Department of Defense released “Open Technology Development: Lessons Learned and Best Practices,” a document that quickly became one of the most thorough and authoritative guides to using and producing open source software in government. Sponsored by the Secretary of Defense, the guide provided practical advice on policy, procurement, and community governance, all published under a Creative Commons license.
The significance of this publication extended well beyond the Defense Department. While the guide was written for a military audience, its careful analysis of contracting policies, intellectual property rights, community dynamics, and organizational governance applied equally to any government agency considering open source adoption. The document’s thoroughness and the weight of its sponsoring institution gave it credibility across the entire federal government and beyond.
What the Guide Covered
The Open Technology Development guide was remarkable for its breadth and depth. Rather than offering superficial encouragement to “consider open source,” the document dug into the practical details that determine whether open source adoption succeeds or fails in government settings.
Policy and Procurement
Government procurement of open source software presents unique challenges because acquisition frameworks are designed primarily for purchasing proprietary products from commercial vendors. The guide addressed these challenges head-on, examining how existing acquisition regulations already accommodate open source software and where agencies might need to adjust their processes.
The document systematically addressed common misconceptions about open source and government procurement, providing specific references to policies and regulations that support open source adoption. This was particularly valuable because procurement officials often cite regulatory concerns as reasons to avoid open source, sometimes based on misunderstandings that the guide carefully corrected.
Intellectual Property and Rights
Government acquisition of intellectual property rights is a complex area, and the intersection of government IP policy with open source licensing adds additional nuance. The guide provided detailed analysis of how government intellectual property rights frameworks interact with common open source licenses, helping agencies understand what rights they acquire and what obligations they assume when using open source software.
Community Governance
Perhaps the most forward-thinking sections of the guide dealt with open source community governance: how projects are organized, how decisions are made, how contributions are managed, and how the health of a project community can be assessed.
The guide recognized that open source software is as much a social phenomenon as a technical one. The quality and sustainability of open source software depends heavily on the community that produces and maintains it, and agencies evaluating open source options need to assess community health alongside technical capabilities.
Forkability as Governance
One particularly insightful section discussed the concept of “forkability,” the ability of anyone to take the source code and create a competing version of the project. Far from being a threat, the guide argued that forkability is a critical governance mechanism:
Forkability ensures that project leadership remains responsive to users and developers. If leaders make decisions that are sufficiently harmful to the project, the community can create a fork under better governance. This possibility, even when rarely exercised, creates accountability that proprietary software projects lack.
The guide further noted that easy forkability actually reduces the likelihood of forks occurring, because leadership knows that unresponsive governance will lead to a viable alternative. It also increases the likelihood of contributions, because contributors know they have recourse if the project’s direction changes in ways they disagree with.
Why This Mattered
Institutional Credibility
When the Department of Defense endorses a software development methodology, it carries weight. The DoD is one of the largest IT consumers in the world, and its procurement decisions influence the entire government IT market. The Open Technology Development guide gave other agencies political cover to pursue open source approaches, backed by the analysis of an institution that no one could dismiss as naive about security, reliability, or operational requirements.
Addressing Fear and Uncertainty
Many government agencies were held back from open source adoption not by genuine technical concerns but by fear, uncertainty, and doubt, often amplified by incumbent proprietary vendors with obvious commercial interests in maintaining the status quo. The guide’s careful, evidence-based analysis provided ammunition for open source advocates within agencies who needed to counter these arguments.
Practical Utility
Unlike many government policy documents, the Open Technology Development guide was genuinely useful. A program manager or procurement official could read it and come away with specific, actionable guidance on how to evaluate, acquire, deploy, and contribute to open source software within their existing regulatory framework.
Impact on Government Open Source
The guide contributed to a growing body of evidence and guidance that has supported open source adoption across the federal government and at state and local levels. Subsequent initiatives including the federal source code policy, the creation of Code.gov, and expanded use of platforms like GitHub by government agencies all built on the foundation that documents like this guide helped establish.
The publication also reinforced an important principle: open source adoption in government is not a matter of ideology but of practical engineering and management. The guide treated open source as a tool to be evaluated on its merits, subject to the same analysis of cost, risk, performance, and sustainability that any technology decision requires. This pragmatic framing helped move the conversation beyond philosophical debates and toward practical implementation.