Discover the main differences between COTS vs. GOTS

The basics of COTS vs. GOTS

Managers may wonder if it is better to use commercial off-the-shelf (COTS) software or government off-the-shelf (GOTS) software. For context, GOTS means that the government agency has bought and paid for the creation of a software product, which is then available to share, reuse or resell to other agencies.

The underlying issue here is efficiency. As governments sought to computerize operations back in the 1960s and 1970s, the most viable option was to build the software as needed. This usually involved contracting the work to independent developers.

But the computing industry evolved and grew rapidly the 1980s. As private businesses and individual users adopted computers, the resulting volume of users made commercial software viable. The commercial software industry flourished, and developers engaged in intense competition for market share by developing competitive new features and providing upgrade paths for users to have quickly changing computing technologies.

In 2020, government agencies face enormous pressure to modernize infrastructure, as well as to streamline and accelerate corresponding workflows and practices, in order to function more efficiently and cost-effectively.

Budget limitations are one important driver. But agency directors and IT staff all understand the potential of modern computing: the value of federating and sharing data between agencies, ease of use, user satisfaction and advanced computing technologies that face hurdles with contract-driven software development cycles. Such goals and potential benefits are difficult to achieve if an agency builds its own custom software.

All of this drives a renewed discussion within and among government agencies about the use of commercial software versus the continued use of government-funded software; there is not a single ubiquitous answer, but there are important pros and cons to consider.

Pros and cons of commercial software

The first benefit of COTS software is that the product reflects the developers' experience and expertise. The developer is responsible for all the necessary research and development to create the product -- usually gleaned from years of ongoing competition. Commercial software usually observes industry standards and practices, such as login security or user data encryption. This competition simultaneously promotes the evolution of alternative products that can support a greater variety of infrastructures, user types and use cases.

Second, COTS products are well proven and refined. For example, response times and performance are good; menus and dialogs are more intuitive and easier to understand; there are fewer significant software defects; and the time and effort needed to install and configure the software is relatively minimal. User expectations drive all of these factors.

Third, the large customer base that accompanies commercial products means that COTS software is well supported with documentation, how-to guides, troubleshooting advice and live help desk assistance. Popular COTS software might even have user-driven support such as Reddit or product forums to share tips and best practices, as well as suggestions for fixes or further improvements.

Finally, COTS software is relatively inexpensive because the total cost of the software is spread across the entire customer base. Comparatively, contracting a software project will place the entire cost burden (plus profit) on the contracting party such as a government agency.

However, COTS software always represents some form of compromise in features, functions or usability. Commercial software exists because a broad base of users is able and willing to do the same things in the same ways. The software makes certain assumptions about the users' operations and methodologies. Users often must make changes to their own practices and workflows in order to use the COTS software.

Such compromise can be a problem for government agencies that must accommodate specific goals. Plus, the prospect of an agency changing its workflows or practices to fit a COTS software product can be painful -- even impossible. Commercial software products are only a suitable alternative for government use when the COTS software features and functionality aligns with respective agency requirements.

GOTS: High-cost risk but high reward

The appeal of commercially developed and supported software products is unquestionably compelling, but there are countless tasks for which commercial software options simply don't exist. Consider software such as the Naval Simulation System used by the U.S. Navy and the SIMDIS 3D analysis and display tool set for the Department of Defense.

These large and complex applications have no commercial equivalent, so the software is custom-built to fit the respective agency's processes and requirements. In some cases, other agencies might reuse or purchase the developed software, where it is potentially tailored to specific requirements.

These GOTS products are custom-built because there is typically no reasonable alternative, but the software's overall quality and performance can be exceptionally high because it is designed and built from the ground up to fit the unique demands and infrastructure of the specific agency.

But custom-built software can carry some significant risks in terms of time, cost and roadmap. Consider that GOTS projects can be huge and complex -- difficult undertakings even with a large and talented development team on the contract. Agencies must also consider that the developers contracted to build a product are rarely experts in the agency's needs. The result is that GOTS products can take years to develop from scratch.

Because contractors who work on the project must be paid throughout development, deployment and post-deployment support, GOTS projects can be costly affairs. A commercial software developer spreads out the cost of the software product among many customers, but a single government agency must bear the entire cost of the project.

GOTS code can also be costly and time-consuming to maintain. Where commercial software is frequently updated and upgraded to foster the developer's competitive advantage, government software may face limitations in features or interoperability and is only updated or upgraded when the government agency requires.

In some cases, the contractor may include a period of maintenance and support in the contract. After that, however, there is no guarantee that the original contractor would even bid on subsequent work for that GOTS product, leaving the agency to find another contractor to analyze the code and attempt further maintenance or upgrade work.

Finally, the product roadmap for a GOTS product can be tenuous at best. The computing infrastructures used in some government agencies can be limited or highly specific to that agency. A change made to the infrastructure may have profound effects on the software, which might require updates or upgrades to accommodate.