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

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

* The better parts will get re-used and leveraged as much as possible (selective evolution), while the "buggy" or poorer parts will get replaced or fixed. This is a genetic evolution model of "survival of the fittest."

Examples of the types of software modules that could be shared amongst programs with great benefit to the DoD as a whole are sonar and radar signal processing, image processing, track management, phased-array beamforming, graphical user libraries, scene rendering, and data fusion. If even a small percentage of the software maintenance costs were reduced, the DoD cost savings would be significant.

PROBLEMS WITH AN OPEN-SOURCE MODEL FOR DEFENSE SYSTEMS

There are some potential problems with the use of open-source software in a defense system application, such as increased cost to national security. The problems must be balanced against the gains for each particular program and measured against the potential benefits. Some of the arguments are:

* This is expensive; co-developers are not really free. This is an important issue. A legion of co-developers capable of working on complex software systems is expensive. This is certainly true if a small project is viewed individually. When viewed generically, many company, laboratory, and university efforts are all relevant to big projects and are already funded. When a software module is used by four or five programs, however, the cost-per-program for the life-cycle support decrease (in aggregate) compared to duplicative efforts funded by multiple programs. The cost of debugging should become lower through repeated porting and broadened team support.

* The platform can be a big problem. The software may need a specific type of system on which to run. This problem has few simple solutions. Open-source methods and porting for other project use will tend to eliminate platform-specific nuances and allow deployment on less expensive commercial-equivalent systems as time goes by.

* National Security is threatened through widespread code release. In reality, National Security is threatened more by expensive and bug-ridden software. Technology transfer and secure vaulting and transfer rules can protect the national interests. The groups and companies participating are already developing military systems.

* Nothing is really gained; the algorithms are published in journals to publicize the state of the art, and the coding of the algorithm is trivial. This argument does not recognize the complexity of the software involved and the potential benefits and budget savings through use of a previously debugged version of the algorithm.

* Competitors will take advantage of "open-source" to develop preferred business positions. It is a bold move to register and provide software modules to competitors, some of whom may be large and aggressive. There have been notable examples of companies that obtained existing software from a competitor and leveraged it to their advantage. The use of a feedback system and "registry" web site should provide a means of identifying those companies that were obtaining open-source code but not contributing to the "open" efforts or identifying how they use the code. This imbalance could be used to justify a ban on a group from receiving further code developed by others. This would put financial pressure on such companies, since their proposals would become more expensive and receive less favorable financial and technical reviews.