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

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

3. The laziness (or greed) of other activities or vendors gives incentives to leverage existing work as much as possible if given the access. Open-source code re-use can work to significantly lower new project costs and improve schedule performance.

4. Some companies will invest their own funds to upgrade existing code under Internal Research and Development (IRAD).

5. Sometimes Government PMs may invest funding to build on the existing work in a new way with other vendors.

6. The policy does not recognize the public ownership already established by using the taxpayers' funding, and that the application is already owned collectively by the public and other companies, not by a department or a single vendor.

7. The value to other projects can only be judged by their developing teams.

COMMON SOFTWARE WAS HISTORICALLY NOT "OPEN-SOURCE"

Commonality was often championed as a cost savings, but actually promoted a business position. Commonality was resisted by others to defend their business positions.

Historically, commonality tended to be championed by the vendors that owned and benefited from selling the common product or solution. The goal was simple: take over the business content of the other "non-common" vendors. In reality, there are differences in mission, environment, and interfaces that exist from ship-to-ship or use-to-use. Adapting existing software to a new platform or environment takes familiarity with both the new environment and the software.

Typically, an incumbent organization is more familiar with the mission and platform, while the "common" software team knows the new software code. Both of the organizations have good claims to being able to efficiently adapt the code to the new mission. The interfaces and mission needs involve more complex integration issues, whereas the new code is probably well documented and evolutionary. The benefits of a having several groups using the software code and working out its bugs are fairly certain, but the ability of a single organization to support multiple customers with different missions is questionable.

SINGLE-MAINTENANCE ENTITLES WERE JUSTIFIED TO CONTAIN COSTS, BUT THE CODE SUFFERED FROM A REDUCED KNOWLEDGE BASE

Raymond says several times that multiple sets of eyes can find software bugs faster. The original development team is unlikely to even recognize some problems. They are emotionally biased towards the design they created. The Fast Fourier Transform, as an example, can be coded hundreds of ways, but all are essentially the same algorithm. Some of these methods are significantly faster than others and some depend more on the use of a specific machine. Many groups use the original algorithm, while others were intrigued and developed new implementations. This would not have happened if a group had declared a single method as "best" and "common" (or worse yet, kept it a secret!).

The DoD offices are often challenged to fund a single software maintenance team. Long-term software maintenance can be enormously expensive. The DoD Users provide long lists of complaints and suggestions, but no licensing fees or support service payments. Would the software maintenance costs be higher if the code was supported by multiple groups? With only one support agent each, correction comes slower and with greater expense. Problems that take one group months to find may be quickly found by other organizations. Collaborative debugging versus isolationist debugging is what the open-source community claims will make projects more successful. Only experimentation can decide if the collaborative support is less expensive, but if it is, the net savings could be directed into new functionality and improvements.