The fortress and the bazaar: open-source and DOD software

Defense AR Journal, Dec, 2005 by David Lechner, Harold Kaiser

THE CLOAK OF NATIONAL SECURITY SCREENS DOD SOFTWARE CODE FROM CO-DEVELOPERS SO WELL THAT RESOLVING PROBLEMS IS DIFFICULT AND TIME CONSUMING

Since the original developing group is the only group to get effective exposure to the source code, there are actually no co-developers. Thus a very biased group of developers (i.e., the proud "parents" of the "baby") can only see the problem from their singular perspective. This keeps the code from getting wider peer review, more thorough testing, unbiased discussion, or more diverse usage. In order to prevent the dissemination of software source code to threatening nations, some form of continued security around the software investment made within the weapons systems is essential. To say that no other vendor or R&D group is patriotic enough to protect the software, however, is ludicrous.

CONTRACTORS AND LABORATORIES ARE MOTIVATED TO WITHHOLD THE SOFTWARE SOURCE CODE AT ALL COSTS TO PROTECT THEIR PROPRIETARY OR BUSINESS INTERESTS

This motivation is due in large part to the desire of the DoD companies to justify sole-source contracts or establish a favored business position. The possession and working knowledge of the applications software is one of the best ways to maintain a privileged "insider" position on a program, normally securing years of business revenue when successful. The developer is normally funded to fix software bugs, revise the user interfaces, provide training and logistics support, and continue integrating hardware and resolving hardware obsolescence problems. This can amount to considerable business revenue that continues long after the system is delivered. One classic approach to maintaining the best business position for all this work is to minimize disclosure of the software source code.

Normally, software documentation, carefully crafted in true cathedral or fortress style, is eventually delivered in order for the Government to exercise their rights to full ownership. This typically involves sending the boxes of paper and computer disks to a Government engineering laboratory. These laboratories, often lacking the equipment or expertise to really use the source code, are often unable to do more than lock up the code in a secure vault, ultimately to be discarded many years later. Sometimes the Government itself acts to protect the developer's monopoly by limiting distribution of the code. The rationale is that the code has been paid for and now works, so that paying any other vendor to work on it is a waste of scarce resources and unnecessary. This logic fails in several aspects, failing to recognize key issues:

1. Secondary benefits arise from the distribution of knowledge to other projects, disciplines, or programs as code is re-written and re-used in ways never expected. Other program managers (PMs) can decide how best to utilize the code as their own program needs and budget dictates.

2. Maintenance benefits occur with open-source as other organizations or developers review and utilize the code and discover and remove bugs. The larger number of developers will have different and new perspectives and suggestions for improvement. The original owners of the code can then take advantage.