Guidelines and Best Practices for Using Open Source Software in Large‑Scale System Engineering

Definition

Open source software (OSS) is a type of commercial software that can be used by agreeing to the accompanying OSS license, granting full ownership without immediate third‑party verification. The license permits individuals, companies, or government entities to copy, distribute, and run OSS applications as often and as widely as needed, access the human‑readable source code, and extend or modify the software according to various release requirements.

Keywords

FOSS, free and open source software, open source software, OSS

MITRE SE Roles and Expectations

MITRE system engineers should understand the benefits, risks, and constraints of applying OSS and related support processes to large‑scale systems, know how OSS compares to proprietary software in cost, support, scalability, adaptability, security, and resilience, be aware of OSS security attributes, certification status, and effective interaction with OSS communities.

Background

Open source software provokes strong reactions in system‑engineered, information‑intensive enterprises because its community‑owned model gives every license‑compliant user the same ownership rights, challenging the traditional assumption that only centrally controlled, authority‑centric development can produce high‑quality, reliable software. OSS distributes control to developers, encouraging local innovation and making human‑readable results easy to inspect and analyze.

Government Benefits and Use

In October 2009 the U.S. Department of Defense (DoD) issued an updated policy on OSS, stating that OSS is a form of commercial software with legal standing under U.S. law (10 USC 2377) and must be considered when evaluating cost‑effective solutions for DoD systems. The White House developer site directs developers to open‑source projects on GitHub and to the Drupal open‑source blog.

Best Practices and Lessons Learned

Read and understand the DoD FOSS webpages. The DoD has produced three documents describing OSS’s role in DoD systems, policy, legal status, and FAQs. System engineers should review the 2009 policy statement.

The larger the OSS support community, the lower the long‑term support cost. A large community can provide world‑class experts and reduce the risk of a small, immature project breaking the system.

Avoid proliferating OSS licenses. Four main license families are usually sufficient: GPL, LGPL, BSD/Apache, and government‑code (no license). GPL requires derivative works to be licensed under GPL. LGPL allows GPL components to be used as libraries within non‑GPL code. BSD/Apache are permissive licenses that let companies treat copies as proprietary. No license (government code) applies to code developed by government employees.

Do not assume lawyers understand OSS licenses. BSD and Apache are easier for lawyers to grasp than GPL/LGPL.

Use OSS to stabilize shared infrastructure. Leveraging OSS for basic networking and data‑sharing functions reduces vendor lock‑in and frees resources for innovation.

Use OSS to concentrate expensive resources on innovation. By moving solved problems into OSS, organizations can reassign designers and developers to higher‑value tasks.

Encourage an OSS liaison role. An experienced programmer tracks, participates in, and uses relevant OSS suites, ensuring organizational needs are understood by the community.

Understand OSS advantages in exploratory prototyping. OSS provides tools that translate between unexpected data and communication protocols, helping simulate legacy components safely.

Treat OSS licenses like any other commercial license. Violating OSS licenses is both illegal and detrimental to the collaborative model.

Minimize new software requirements when building large systems. Prefer stable, well‑supported OSS components over writing new code whenever possible.

Strongly oppose the view that OSS is “free source code” that accelerates internal development. Using OSS without proper support can become a hidden cost bomb. First, try the executable version of OSS. Use binary releases when they meet the need. Next, submit non‑sensitive changes to the support community. This reduces long‑term maintenance burden. Only as a last resort develop your own module. Avoid embedding OSS source code unless absolutely necessary.

Avoid indiscriminately releasing government code as OSS. Community support is valuable only when the community is genuinely interested.

Encourage realistic understanding of security for all software. Source availability does not inherently make software more or less secure; rigorous review processes matter.

Figure 1

Figure 1. The I‑4 Architecture Pyramid