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

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

WHAT IS "OPEN-SOURCE?"

The principal trait of an Open-Source (es) project is simply stated in the name, but it involves more than just open-source code. "Open-source" projects are collaborative, rapidly updated and rapidly released, and pushed by highly motivated volunteers working with a diversity of interests, skills, and hardware sets. Some people work on open-source projects and are paid for it. Some projects move more slowly. Some only target one OS platform, and some many. This article will focus on how a generic open-source approach could be applied to DoD projects.

DEFENSE PROJECT SOFTWARE DEVELOPMENT: AN HISTORICAL OVERVIEW

Since the earliest use of computers, all the rigidity of process and formalized methods that the military systems engineers could muster have been applied to software projects, making them extremely rigid and well documented (e.g., DoD Standard-1467 and MIL-STD-2168). Several arguments for this are listed below, but we discuss how they do not stand up well.

THE CURRENT DOD SOFTWARE METHODS ILLUSTRATE AND EMBODY THE CATHEDRAL BUILDING METHODS

The DoD processes evolved due to several factors, some of which can win instant sympathy from the reader as being not only reasonably justified, but critically important. Some examples are:

* The system-fired missiles and munitions needed every safeguard possible to prevent accidental firing or targeting.

* The lives of the soldiers depended on the project. They deserved all the care and testing that could be applied in order to produce the best possible product.

* The taxpayers' dollars were at work; reducing the possibility of mistakes or bugs was paramount.

* National security depended on the software program being perfect. To protect the country, we could spare no possible pain to make it so.

Typical military software projects in the 1970s and 1980s required formally documented and carefully detailed designs, involving "waterfall" builds with incremental steps for adding functions and exhaustive testing at each step. The code had to be well documented, with interface design documents, requirements definition documents, system design documents, database design documents, program development folders, and test plans and reports. Usually the code was documented to transition it to a government organization. Once the "cathedral" was completely built, the government team was to "move in" and take on ownership and maintenance.

Systems that actually fired munitions were even more carefully tested. The live-fire testing and certification processes for missile and munitions-type projects are still very extensive. These testing and certification processes often evolved in a reactionary way to resolve problems associated with the previous fielding of poorly designed systems and were intended to provide a valuable check on the work of vendors developing weapons systems that are dangerous by design. In fact, the nature of military software is critically enabling in terms of achieving functional performance. This made the DoD software project much more than a cathedral in style. It became a "fortress," and its details had to be constructed and managed as any good military fortress was: in secrecy.