Off-the-shelf (OTS) Software Development Approaches, including Open Government OTS (OGOTS) and Open Source Software (OSS)
Military programs must adapt and move its software and technologies away from passively managed and closed GOTS (Government Off-the-Shelf) programs toward Open Government Off-the-Shelf (OGOTS) and ultimately toward Open Source Software (OSS) for maximum flexibility and agility.
Open Technology Development involves community development among government users, and thus includes both OSS and OGOTS. An OTD strategy allows organizations to develop and maintain software in a collaborative way. To maximize collaboration, software should be developed to use off-the-shelf (OTS) components and to be itself OTS to the maximum practical extent.
Off-the-shelf (OTS) software is simply software that is ready-made and available for use. The rationale for developing OTS software is to create software that can be used for multiple purposes, instead of using custom-built software for a single purpose and use. OTS software has the potential to save time, save money, increase quality, and increase innovation through resource pooling. Even when a custom system is needed, building it from many OTS components has many advantages.
There are many different ways that off-the-shelf (OTS) software can be maintained. Some OTS may be retained and maintained inside the U.S. government (e.g., because it is classified or export controlled); such software is termed government OTS (GOTS). Off-the-shelf items that are commercial items (e.g., by being sold, licensed, or leased to the public for non-governmental use) are commercial OTS (COTS). Note that by law and regulation, software licensed to the public and used for at least one non-government purpose is COTS software, even if it is maintained by the government. Figure 1 illustrates these different kinds of OTS maintenance approaches.There are two kinds of commercial OTS (COTS) software: Open Source Software (OSS) and proprietary software. In either case they may be maintained by a single maintainer or by a community. In community maintenance there is often a single organization who determines if proposals should be accepted, but the key here is that the work tends to be distributed among those affected.
Today, where there is GOTS software at all, it tends to be developed and maintained by a single maintainer. This tends to reduce GOTS’ applicability. Many government programs might potentially use a GOTS component if certain changes were made, but cannot make the changes to the GOTS component directly, and even if they did, there is no structure by which those changes could be merged back into the main GOTS product for all to use. In contrast, most OSS projects are maintained by communities, where different organizations actively work together to develop software that is useful to them all. Single-maintainer OSS project exist, but they are less common.
Figure 1: Off-the-Shelf (OTS) Maintenance Strategies
An Open GOTS (OGOTS) project is a GOTS project which uses multiple-organization collaborative development approaches to develop and maintain software, in a manner similar to OSS. Such a project within the DoD is sometimes termed “DoD community source software.” One goal of this paper is to increase the number of GOTS projects that are OGOTS projects. A project may become OGOTS instead of OSS because its leaders want the innovation, speed of development, and lowered cost that can come from co-development by many parties, yet:
- The government lacks the intellectual rights to make it more open (e.g., the government may have government-purpose rights (GPR) and not unlimited rights), and/or
- The government wishes to maintain a national security advantage by not making that software available to potential adversaries (typically such software will be classified and/or export controlled).
In addition, GOTS projects should determine when they should become COTS (e.g., as community-supported OSS projects). In particular, GOTS projects should seriously consider switching to OSS maintenance after a system has been deployed. There are various reasons why the government should keep certain software in-house, e.g., because sole possession of the software gives the U.S. a distinct advantage over its adversaries. However, technological advantage is usually fleeting. Often there is a commercially-developed item available to the public that begins to perform similar functions. As it matures, other organizations begin using this non-GOTS solution, potentially rendering the GOTS solution obsolete. Such cases often impose difficult decisions, as the government must determine if it will pay the heavy asymmetrical cost to switch, or if it will continue “as usual” with its now-obsolete GOTS systems (with high annual costs and limitations that may risk lives or missions). This means that there is considerable risk to the government if it tries to privately hold GOTS software within the government for too long.
As Defense Secretary Robert Gates said “The gusher has been turned off and will stay off for a good period of time.” DoD needs a more efficient software development ecosystem – more innovation at lower cost – and OTD squeezes financial waste out of the equation by reducing lock-in and increasing competition.