The Department of Defense earlier this week released its most recent open source guide, Open Technology Development: Lessons Learned & Best Practices for Military Software.
The document, sponsored by the Assistant Secretary of Defense for Networks & Information Integration, the DoD CIO and the Under Secretary of Defense for Acquisition, Technology and Logistics, is aimed at helping U.S. government personnel and contractors implement open technology development (OTD) for software within government projects, particularly in defense.
Overview (full guide below):
- 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 ones. 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.
Advertisement
