10.12 Open source vs closed source¶

Overview and motivation¶

Almost every modern system is a blend of software you wrote, software you bought, and software you took for free. Two of those three come with a fundamental choice: is the software open source or closed source? Open-source software (OSS) is distributed under a license that grants everyone the right to use, study, modify, and redistribute the source code, the human-readable instructions that define the program. Closed-source software, also called proprietary software, is distributed as a finished product whose source code the vendor keeps private. You get the right to run it under a license, but not to inspect or change how it works. A middle category, source-available software, publishes the source for reading but restricts use, modification, or redistribution. It is visible but not open by the standard definition.

Two clarifications matter before you compare them. First, "free" is ambiguous. The community distinguishes free-as-in-freedom (the liberty to modify and share, sometimes written "libre") from free-as-in-price (zero cost, "gratis"). Open source is about freedom, not necessarily price. Second, open-source licenses divide into two families. Permissive licenses (such as MIT, BSD, and Apache 2.0) let you do almost anything, including embedding the code in a closed product. Copyleft licenses (such as the GNU General Public License, GPL) require that derivative works you distribute also be released under the same open terms, a reciprocity rule sometimes called "viral" by critics and "share-alike" by proponents.

This chapter looks at the choice from two sides. As a consumer, you decide whether to adopt an open-source or proprietary component. As a producer, you decide whether to open-source software you built. For large enterprises and especially government, both decisions carry weight far beyond the license file. They touch procurement (chapter 10.3), digital sovereignty (chapter 10.11), supply-chain security (chapter 4.2), interoperability (chapter 3.8), and the build-or-buy calculus (chapter 6.1).

Key principles¶

• License, not price, defines "open." Read the license; free-of-charge and open-source are different claims.
• Neither model is inherently more secure. Both can be excellent or negligent; the practices around the code matter more than its openness.
• Openness is a dependency-reduction lever. Access to source is the ultimate protection against vendor lock-in.
• You always own the operational burden. Free-to-acquire is never free-to-run; total cost of ownership tells the real story.
• Differentiators stay closed; commodities can open. Open-source what does not distinguish you; guard what does.
• Copyleft has consequences. Understand reciprocity obligations before you embed copyleft code in a product you distribute.
• A live community is an asset; an abandoned repository is a liability. Judge the project, not just the license.

Recommendations¶

Evaluate a component on the project, not just the license¶

Before you adopt any dependency, open-source or proprietary, assess its health: release cadence, number and diversity of maintainers, responsiveness to security reports, and breadth of adoption. A single-maintainer open-source library and a small proprietary vendor carry the same bus-factor risk (the danger that a project collapses if one or a few key people leave). Favor components with a broad contributor base or a financially sound vendor, and record the assessment as part of due diligence (chapters 10.2, 4.2).

Read and track licenses as a first-class obligation¶

Maintain an inventory of every component and its license, and enforce a policy on which license families are acceptable for which uses. The critical distinction is copyleft. Permissive code (MIT, Apache 2.0) can generally be embedded in closed products freely. Strong copyleft (GPL) can obligate you to release your own distributed derivative under the same terms. Use automated software composition analysis (SCA), tools that scan your dependencies to identify components, licenses, and known vulnerabilities, and generate a software bill of materials (SBOM), a formal list of every component in a product (chapters 10.3, 4.2).

Judge security by practice, not by openness¶

Do not assume open source is safe because of the "many eyes" argument (Linus's Law: "given enough eyeballs, all bugs are shallow"). And do not assume proprietary code is safe through security-through-obscurity (the flawed belief that hiding source hides flaws). Many eyes only help if qualified people actually look, and many widely used projects are thinly maintained. Both models carry supply-chain risk: open source through compromised or abandoned dependencies, proprietary through opaque code and update channels you cannot inspect. Pin versions, verify provenance, scan continuously, and monitor advisories regardless of model (chapter 4.2).

Design for exit and interoperability¶

Prefer components that speak open standards and portable data formats, so you can replace them later (chapters 3.8, 10.11). With open source you gain the ultimate exit: if a project stalls, you can fork it (create and maintain your own copy). With proprietary software, negotiate protections up front: data export in open formats, documented APIs, and source-code escrow (a legal arrangement where the vendor deposits source with a third party, released to you if the vendor fails). Design so that no single component, of either kind, can hold your system hostage.

Weigh total cost of ownership, not sticker price¶

Compare options on total cost of ownership (TCO), the full lifetime cost including acquisition, integration, operation, support, training, upgrades, and eventual replacement, rather than license fees alone. Open source often trades licensing cost for higher operational and staffing cost. Proprietary software often trades predictable subscription fees for lock-in and less control. Include the cost of the model itself: self-supporting open source needs in-house skill, while proprietary software needs vendor-management capacity.

As a producer, open-source what does not differentiate you¶

Classify your own software into what gives you competitive or mission advantage and what is undifferentiated plumbing. Keep the differentiators proprietary. Consider open-sourcing the commodity infrastructure, where a community can share maintenance and improvement. For government, weigh "public money, public code" (the principle that software funded by taxpayers should be publicly available by default) as a driver of transparency, reuse, and sovereignty (chapters 10.5, 10.11). Choose the license deliberately: permissive to maximize adoption, copyleft to keep the ecosystem open.

Trade-offs: pros and cons¶

The recurring tension is control versus convenience and accountability. Open source maximizes control, auditability, and freedom from lock-in, but it asks you to supply the capability, integration, and support yourself. Proprietary software delivers a supported, integrated, accountable product with a contract to enforce, but it concedes control and invites lock-in. The resolution is rarely all-or-nothing. Most mature estates mix open-source foundations with proprietary systems where support, accountability, or specialized capability justify the trade.

Examples¶

Startup. A three-founder startup builds its whole product on open-source foundations (Linux, an open-source database, a web framework) because it cannot afford license fees and wants the freedom to fork if a project stalls. Before shipping, one founder runs a composition-analysis scan and catches a strong-copyleft library that would have forced them to publish their proprietary matching algorithm, so they swap it for a permissively licensed equivalent. They keep that algorithm, their sole differentiator, strictly closed, and open-source only a small internal logging tool to build goodwill and attract engineers.

Enterprise. A large insurer runs its core platform on open-source foundations: Linux, a widely used open-source database, and a container orchestrator. But it buys a proprietary actuarial-modeling suite, because the vendor's domain expertise, regulatory certifications, and support contract are worth the fee and there is no comparable open alternative. It pays a subscription for commercial open source (vendor-supported distributions of the open components) to get accountability and patches on the plumbing, while keeping the pricing algorithm that differentiates it strictly proprietary and in-house. TCO analysis (chapter 10.10) drives each choice rather than ideology.

Government. A national tax agency, under a "public money, public code" policy, builds a new benefits-eligibility service on open-source components and open standards (chapter 3.8), so that other agencies can reuse it and citizens can audit the rules. It publishes the non-sensitive code in a public repository, retaining only fraud-detection heuristics as closed for security reasons. This reduces vendor lock-in and advances digital sovereignty (chapter 10.11). Procurement rules (chapter 10.3) require any proprietary component to provide data export in open formats and source-code escrow, to guarantee continuity if the supplier fails.

Business case: motivations, ROI, and TCO¶

The financial appeal of open source, its lack of a license fee, is the least reliable part of the case, because acquisition is a small fraction of TCO. The durable returns are strategic: freedom from lock-in (the ability to change or drop a supplier without re-architecting), auditability for security and compliance, faster adoption because engineers can try before committing, and shared maintenance of commodity code across a whole industry. The offsetting costs are real. You must supply integration, operations, security response, and often paid support, and a poorly chosen unmaintained project can cost more in incidents than any license would have.

Proprietary software's business case is accountability and convenience: a single vendor responsible for the product, a support contract you can enforce, integrated features, and predictable budgeting. Its hidden cost is lock-in, the switching costs that let a vendor raise prices or degrade service with little recourse, plus dependency on the vendor's solvency and roadmap. Common business models blur the line: open core (an open base with proprietary paid add-ons), dual licensing (the same code offered under both a copyleft and a paid commercial license), software as a service (SaaS) (the software runs as a hosted service you rent, where the source may be irrelevant because you never possess the binary), and support/subscription models that sell service around otherwise free code.

For a producer, the ROI of open-sourcing your own non-differentiating software can be substantial. Outside contributors reduce your maintenance load. The project becomes a recruiting and reputation asset. External adoption makes your standard the de facto one. For government, it delivers transparency and reuse across the public sector. The strategic rule is simple: open-source the commodity to share its cost and grow an ecosystem, and keep the differentiator closed to protect the advantage that funds everything else.

Anti-patterns and pitfalls¶

• "Free means free": treating zero acquisition cost as zero TCO, then under-funding operation and support.
• License blindness: embedding strong-copyleft code in a distributed proprietary product and triggering obligations you never planned for.
• Faith in "many eyes": assuming an open project is audited when it has one overworked maintainer and no security review.
• Security-through-obscurity: believing closed source is safe simply because attackers cannot read it.
• Ideological absolutism: mandating "all open" or "all proprietary" instead of choosing per component on merit and TCO.
• Ignoring provenance: pulling dependencies with no SBOM, version pinning, or supply-chain verification (chapter 4.2).
• Open-sourcing the crown jewels: releasing the very code that differentiates you, giving away your advantage.
• Fork-and-forget: forking an abandoned project without the capacity to actually maintain the fork.

Maturity model¶

Level 1 (Initial). Open-source and proprietary components enter the estate ad hoc. Licenses are unread, there is no inventory or SBOM, and the choice between models is made by habit or price alone. Abandonment and license risk surface only when something breaks.

Level 2 (Managed). The organization maintains a component and license inventory, has a policy on acceptable licenses, and runs basic software composition analysis. Build-or-buy and open-or-closed decisions are documented, but reactively and inconsistently.

Level 3 (Defined). A standard framework governs both consumption and production: components are chosen on TCO and project health, licenses are enforced automatically in the pipeline, SBOMs are generated, and there is an explicit policy for what the organization open-sources versus keeps closed. Exit protections (open formats, escrow) are standard in procurement.

Level 4 (Optimizing). Open-source strategy is a deliberate business capability. The organization contributes to and sometimes stewards projects it depends on, open-sources its non-differentiating software as a matter of course, tracks the health of critical dependencies proactively, and continuously tunes its portfolio of open and proprietary software against cost, risk, sovereignty, and strategic advantage.

Ideas for discussion¶

• Where in your estate would losing a single vendor or maintainer be existential, and what is your exit plan?
• Which of your own systems are commodities you could open-source, and which are true differentiators to protect?
• Does your organization treat "many eyes" as a real security control or an unexamined assumption?
• For public-sector readers: what would a "public money, public code" default change in your next procurement?
• How well do your TCO comparisons capture the operational and support costs that open source shifts onto you?

Key takeaways¶

• Open vs. closed is defined by the license, not by price; know the difference between free-as-in-freedom and free-as-in-price, and between permissive and copyleft.
• Neither model is inherently more secure or cheaper. Judge the project's practices and its full TCO, not the openness label.
• Openness is the strongest antidote to lock-in, delivering auditability, portability, and the ability to fork; proprietary software offers accountability and convenience in exchange for control.
• Decide per component on merit, and mix models deliberately rather than by ideology.
• As a producer, open-source the commodity and keep the differentiator closed, and in government, weigh "public money, public code" for transparency, reuse, and sovereignty.

References and further reading¶

• Eric S. Raymond, The Cathedral and the Bazaar
• Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
• Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
• Adrian Cockcroft and others, various O'Reilly titles on open-source strategy and operations
• Free Software Foundation, The Free Software Definition (and the GNU General Public License texts)
• Open Source Initiative, The Open Source Definition and approved-license list
• Free Software Foundation Europe, Public Money, Public Code campaign materials
• Yochai Benkler, The Wealth of Networks