Skip to content
Published on

Total Cost of Ownership for Test Automation - Part IV


This fourth blog in our series on Total Cost of Owner examines costs for Support and Maintenance, Downtime, Compliance and End of Life.

Support and Maintenance

Supporting open source project code offers greater freedom of choice and reduced lock-in to a single vendor. In many cases, the organization responsible for launching, distributing and/or maintaining the project code also offers commercial-quality distributions of that software and professional support for it. Such support can include an SLA (service level agreement) and warranties and indemnification for the code in source and binary forms. Examples include Red Hat with RHEL, Cloud Bees and Jenkins, MongoDB from MongoDB, Inc. and others.

Third-party Support

Another maintenance option looks to third parties, who may or may not be directly involved in the development and maintenance of a project, productizing and/or supporting it. Examples include embedded Linux from MontaVista, Wind River and others; Git-based public and private SaaS repositories from GitHub, GitLab and Bitbucket, and a whole ecosystem of support and SaaS vendors for OpenStack, Kubernetes and other cloud infrastructure services and platforms.

Community Support

Organizations that integrate open source into their software portfolios and application stacks can also choose to forego commercial support, relying instead on community and internal resources. This approach can be highly cost-effective but may present greater risk, especially for business-critical and mission-critical use cases, scenarios that cannot tolerate unbounded response times.


Downtime, when software and systems based upon it are unavailable, comes to two flavors: planned and unplanned. If an organization does a reasonably good job of tracking and segmenting the cost of operations, then planned downtime costs can be anticipated and minimized. By contrast, unplanned downtime is typically more costly and can have ripple effects across an organization.


An area where using open source software incurs costs not present with proprietary software lies in license compliance to meet the terms of open source licenses that govern the OSS components in use.

The cost of compliance can include acquisition/licensing of Software Composition Analysis (SCA) tools, third-party scanning, auditing and remediation, and headcount to support compliance staff or an Open Source Program Office (OSPO).

“Open source compliance is the process by which users, integrators, and developers of open source software observe copyright notices and satisfy license obligations for their open source software components”
– The Linux Foundation

Most test automation software never leaves the premises of engineering/QA/QC organizations, making compliance a trivial (or non-existent) task.  Required compliance activities are triggered by two types of action: redistribution or in some cases, provision of an online service.

Examples of triggering activities include:

  • Embedding open source test automation code in a product

  • Presenting an application or APIs online (e.g., in a SaaS)

  • Sharing a test automation SDK with a partner ecosystem or with customers

In all scenarios, the cost of compliance is usually minimal – source code and license attribution are not expensive activities.  Last-minute clearance of disclosure with legal departments can be costly, especially in impact to schedule.

Failure to comply with OSS licenses can be costly.  As with other types of IPR (Intellectual Property Rights), failing to observe compliance requirements can expose you to bad PR,  litigation and loss of rights to use or distribute the OSS in question.

When the OpenTAP project was launched, project founders took pains to choose a license with straightforward compliance requirements and interoperability/compatibility with many other OSS licenses – the Mozilla Public License version 2.0.  This license choice will minimize compliance issues for OpenTAP developers and users.

End of Life

Proprietary, open source and internally-developed software that has reached or passed its end-of-life (EOL) can be very costly – no bug fixes, security updates and patches and commercial support expose integrators and users to miasma of risk and resultant costs.

In planning for EOL, there are a number of key costs to include in a TCO model:

  • Cost for internal or alternate contracted commercial support (if even available)

  • Bumps in coverage for liability and security insurance

  • Acquiring or developing alternative solutions

  • Costs for migration, integration, operationalization, etc.

Next Time

In our next and final blog on TCO, we'll highlight actual methods for cost calculation and offer readers tools they can actually use.