Open-Source Complexity

Open-Source Complexity

Table of contents:-

A Long History, Still Being Written

The Security Tightrope

Licensing, Governance, and the Sustainability Puzzle

Open Hardware and the Road Ahead

Conclusion

There is something wonderfully audacious about the idea that a global community of volunteers, academics, corporations, and curious hobbyists can collectively build some of the most reliable, powerful, and widely deployed software on earth — and then give it away. That is, of course, exactly what the open-source world has been doing for decades. Yet as this ecosystem has matured into the backbone of the modern internet, enterprise infrastructure, embedded systems, and even spacecraft, its complexity has grown in ways that challenge everyone involved: from the solo weekend tinkerer running OpenBSD on a secondhand laptop, to the FTSE 100 company quietly depending on hundreds of open-source libraries it has never audited.

This article tries to map that complexity honestly — not to discourage anyone, but because understanding it is the first step to navigating it well.

---

A Long History, Still Being Written

To appreciate where open source stands today, it helps to know where it came from. The Berkeley Software Distribution (BSD) began in 1978 as a variant of Unix, mixing AT&T Unix code with innovations from Berkeley's labs and publicly sharing those improvements with the wider Unix community. That spirit of reciprocal sharing became a founding ethic of what we now call free and open-source software (FOSS).

FreeBSD, which released its first version in 1993, descended from 386BSD — one of the first fully functional and free Unix-like clones on affordable home-class hardware. Uniquely, FreeBSD maintains a complete system, delivering a kernel, device drivers, userland utilities, and documentation, in contrast to Linux, which delivers a kernel and drivers and relies on third parties such as the GNU project for system software.

OpenBSD, developed entirely by volunteers and funded through The OpenBSD Foundation, emphasises portability, standardisation, correctness, proactive security, and integrated cryptography. Its most well-known contribution to the wider world is OpenSSH, which secures the vast majority of remote server logins on the planet.

Meanwhile, Linux took a different path — a monolithic kernel married to a vast and sometimes fractious ecosystem of distributions, each making different choices about package management, init systems, desktop environments, and target audiences. Today it runs everything from Android handsets and Chromebooks to the world's top supercomputers and the infrastructure that serves this very web page.

The relationship the open-source community had with its software 20 to 30 years ago was fundamentally different from today. Back then, embracing open source meant embracing freedom — choosing Linux or the BSDs when Windows and commercial Unix systems dominated the market, not because things were simple or free as in free beer, but for freedom from technological and ideological impositions.

That mission has largely succeeded. A 2024 Harvard Business School study showed that 96% of commercial programmes rely on open source, and that the total value of open-source code comes to approximately $8.8 trillion. Open source did not merely survive the commercial world; it became indistinguishable from it.

---

The Security Tightrope

Success at that scale brings a very particular kind of problem. Powerful tools like package managers and containers have made it possible to assemble entire operating systems and applications from hundreds of thousands of external dependencies with just a few commands. On the other hand, this exposes users to a high level of complexity and risks that can be hidden by those tools, with the real danger of embarking on vulnerable or malicious code.

No event illustrated this more vividly than the 2024 XZ Utils incident. In March 2024, Andres Freund, a Postgres developer working at Microsoft, noticed that his Debian Linux system's SSH daemon was using more CPU than normal to handle the usual background brute-force traffic from the internet. What he had stumbled upon was a sophisticated, deliberately planted backdoor inside a widely used data compression library. Had the attack succeeded, it might have ended up in Red Hat Enterprise Linux and its clones, potentially causing the greatest Linux security disaster to date.

The attacker had spent roughly a year and a half building trust with the project's maintainer, making genuine improvements and doing important maintenance work before slowly taking over more and more development responsibility and laying the technical groundwork for the eventual attack in early 2024. Most speculation following the discovery focused on the likelihood of nation-state involvement, though no confirmation has been made.

The XZ affair was a wake-up call, but it was not an isolated one. In 2024, over 40,000 Common Vulnerabilities and Exposures (CVEs) were published — a 38% increase year-on-year. More than 20,000 carried CVSS scores of 7.0 or above (classed as high or critical), making it nearly impossible for security teams to manually triage every vulnerability. Nearly a quarter of known exploited vulnerabilities are now being exploited on or before their public disclosure date, meaning attackers are moving faster than defenders can respond.

Supply chain attacks have climbed dramatically: between 2021 and 2023, they increased by 431%, with projections pointing to continued sharp rises. In October 2025, supply chain attacks reached a new record high, 32% above the previous peak.

The open-source security community has not stood still in response. The Open Source Security Foundation (OpenSSF), a Linux Foundation project, is focused on safeguarding software supply chain integrity, improving vulnerability reporting and communication, and helping people understand the provenance of the code they maintain, produce, and use. Tools like SLSA (Supply-chain Levels for Software Artifacts), Sigstore, and the Alpha-Omega initiative are among the frameworks being developed to make the chain of custody for open-source software far more transparent. In early 2026, GitHub joined Anthropic, Amazon Web Services, Google, and OpenAI with a combined commitment of $12.5 million to support the Linux Foundation's Alpha-Omega initiative, aimed at advancing open-source security and making AI-assisted security tooling accessible to maintainers.

---

Licensing, Governance, and the Sustainability Puzzle

Security is not the only dimension of open-source complexity that keeps practitioners up at night. Governance and licensing can be equally thorny, especially as the legal and regulatory landscape evolves rapidly around the world.

The open-source ecosystem is primarily governed by two broad categories of licence: permissive licences (such as the BSD, MIT, and Apache licences), which allow recipients to use and redistribute software with minimal obligations; and copyleft licences (such as the GNU General Public Licence), which require derivative works to carry the same licence. Several grey areas exist within software regulation that affect open-source software significantly, including questions about what constitutes a modification, governance through contract versus licence, and ownership versus right of use.

The stakes around these questions have risen sharply. A trend that observers have called "the open-source bait and switch" has become increasingly visible: organisations leverage open-source licensing to drive adoption, only to switch to more restrictive licences once they want to capture the commercial value of that user base. The community has pushed back — most notably by launching Valkey as an open alternative after Redis changed its licensing terms, and by pressuring Elastic to re-adopt an open-source model.

At the same time, regulators are arriving on the scene. The European Union's Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847 — represents perhaps the most significant piece of open-source-adjacent legislation in history. From 11 December 2027, manufacturers must generate a machine-readable Software Bill of Materials (SBOM) covering at least top-level dependencies for every product with digital elements placed on the EU market, keep it up to date, and supply it to market-surveillance authorities on request. Non-compliance can trigger fines of up to €15 million or 2.5% of global turnover.

An SBOM is, in essence, a structured ingredients list for software — cataloguing the components, versions, licences, and dependencies that make up a product. The global SBOM ecosystem is underpinned by two major open standards: SPDX (an ISO standard, ISO/IEC 5962, maintained under the Linux Foundation) and CycloneDX (an ECMA International standard). Both formats are internationally recognised, supported by major tooling, and designed for automated processing. Choosing between them is less a matter of correctness and more a matter of use case: SPDX is particularly strong for licence compliance and provenance tracking, while CycloneDX excels in security automation and vulnerability management.

Sustainability is perhaps the quietest but most persistent of the structural challenges facing the ecosystem. According to Tidelift's latest research, 60% of open-source maintainers are unpaid. As an open letter signed by ten open-source foundations and published in September 2025 noted, most open-source systems operate under a dangerously fragile premise, relying on goodwill rather than mechanisms that align responsibility with usage. A small number of organisations absorb the majority of infrastructure costs, while the overwhelming majority of large-scale users — including commercial entities that generate demand and extract economic value — consume these services without contributing to their sustainability.

The Linux Foundation's State of Global Open Source 2025 report confirmed that while organisations now treat open-source technologies as business-critical infrastructure, only 34% of organisations have defined a clear open-source strategy, and only 26% have implemented an Open Source Programme Office (OSPO) to manage compliance, security, and contribution workflows. The governance gap is real, and it creates risk exposure at precisely the moment when open-source components are most deeply embedded in critical systems.

---

Open Hardware and the Road Ahead

It would be incomplete to discuss open-source complexity without acknowledging that the phenomenon has moved decisively beyond software into silicon itself.

RISC-V, maintained by RISC-V International, is a completely open Instruction Set Architecture (ISA), meaning anyone can design, manufacture, and sell RISC-V chips without paying royalties. This freedom from licensing fees and vendor lock-in is a powerful incentive for adoption, particularly in emerging markets and for specialised applications where cost and customisation are paramount.

RISC-V offers a modular architecture with a simple base ISA and optional extensions for multiplication, atomic operations, floating-point mathematics, and more, allowing engineers to include only the features required for a specific application. In 2025, major industry players including Western Digital, NVIDIA, and Google are investing heavily in RISC-V development, with compilers like GCC and LLVM now offering robust RISC-V support.

The RISC-V Software Ecosystem (RISE) Project, hosted by Linux Foundation Europe and supported by a governing board that includes Andes, Google, Intel, MediaTek, NVIDIA, Qualcomm Technologies, Red Hat, Samsung, and SiFive, is focused specifically on commercial software readiness for application processors across mobile, consumer electronics, datacentre, and automotive market segments.

Open-source hardware faces its own flavour of the same sustainability and fragmentation challenges that affect software. Because RISC-V is modular and open, different companies may implement different extensions, creating a risk of fragmentation. Without a unified software target, developers may hesitate to optimise for RISC-V, which could slow broader adoption. The open-hardware community is keenly aware of this tension and working to address it through standards, shared toolchains, and community governance — the same remedies that the open-source software world has been refining for decades.

---

Conclusion

Open-source complexity is not a flaw in the model. It is, in many ways, the natural consequence of extraordinary success. A technology that began as a philosophical statement about the freedom to share and modify code has grown into the connective tissue of global digital infrastructure, running in datacentres, on your smartphone, in your car, and quite possibly in the hardware inside the satellite overhead. That reach demands maturity: structured governance, honest security practices, sustainable funding models, regulatory engagement, and an honest reckoning with the human cost placed on the maintainers who make it all possible.

For every BSD user prizing stability and proactive security, every Linux administrator managing a fleet of enterprise servers, every embedded engineer building on RISC-V cores, and every organisation quietly depending on libraries it has never meaningfully contributed to — the complexity is shared, and so must be the responsibility. The open-source community has always been at its best when it treats problems as collective puzzles rather than someone else's burden.

---

Disclaimer

All trade names, trademarks, and registered marks mentioned or referenced in this article — including but not limited to Linux, FreeBSD, OpenBSD, NetBSD, RISC-V, GNU, OpenSSH, Kubernetes, Red Hat, and all associated logos and product names — remain the exclusive intellectual property of their respective owners. The Distrowrite Project makes no claim of ownership over any such marks and references them solely for educational and informational purposes. We strive at all times for accuracy, currency, and factual integrity in everything we publish, and we welcome corrections or clarifications from the community. Nothing in this article constitutes an endorsement or promotion of any activity involving malware, viruses, exploits, backdoors, or any harmful content that may compromise the integrity of networks, devices, or other infrastructure.

---

References

1. OpenBSD Project — https://www.openbsd.org/

2. FreeBSD — Wikipedia — https://en.wikipedia.org/wiki/FreeBSD

3. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software

4. The State of Open Source Software in 2025 — Linux Foundation — https://www.linuxfoundation.org/blog/the-state-of-open-source-software-in-2025

5. Open Source's Complexities in 2025: From Sustainability to Security — LinuxInsider — https://www.linuxinsider.com/story/open-sources-complexities-in-2025-from-sustainability-to-security-177480.html

6. Open Source: Inside 2025's 4 Biggest Trends — The New Stack — https://thenewstack.io/open-source-inside-2025s-4-biggest-trends/

7. 83% of organisations see value in adopting open source — Canonical — https://canonical.com/blog/state-of-global-open-source-2025

8. Open Source Supply Chain Security — FINOS — https://osr.finos.org/docs/bok/activities/level-2/supply-chain-security

9. The Rising Threat of Software Supply Chain Attacks — Linux Foundation Europe — https://linuxfoundation.eu/newsroom/the-rising-threat-of-software-supply-chain-attacks-managing-dependencies-of-open-source-projects

10. Fifty Years of Open Source Software Supply Chain Security — ACM Queue — https://queue.acm.org/detail.cfm?id=3722542

11. Open Source Security Foundation (OpenSSF) — https://openssf.org/

12. EU Cyber Resilience Act — OpenSSF SBOM Overview — https://openssf.org/category/policy/cra/

13. SBOM and the EU Cyber Resilience Act — SafeDep — https://safedep.io/sbom-and-eu-cra-cyber-resilience-act/

14. Investing in the People Shaping Open Source — GitHub Blog — https://github.blog/security/supply-chain-security/investing-in-the-people-shaping-open-source-and-securing-the-future-together/

15. OSDay 2025 — Why Choose the BSDs in 2025 — IT Notes — https://it-notes.dragas.net/2025/03/23/osday-2025-why-choose-bsd-in-2025/

16. RISC-V International — https://riscv.org/

17. RISE Project — Linux Foundation Europe — https://linuxfoundation.eu/newsroom/rise-project-launches-to-accelerate-development-of-risc-v

18. RISC-V in 2025: The Open-Source Future of Embedded Design — Tessolve — https://embedded.tessolve.com/blogs/risc-v-in-2025-the-open-source-shift-in-embedded-system-design/

19. lowRISC — Open-Source Silicon — https://lowrisc.org/

20. Linux Foundation Research — https://www.linuxfoundation.org/research

---

䷾

Back to top