In May 2024, the maintainer of an obscure compression library called xz-utils — a piece of plumbing baked into nearly every Linux distribution and therefore into a significant fraction of the world's server infrastructure — quietly attempted to merge a multi-year backdoor implanted by a contributor patient enough to have spent two years building trust before striking.1 The exploit was caught by an unrelated Microsoft engineer named Andres Freund who noticed an unusual delay during an SSH benchmark. The story is now a standard cautionary tale in security circles.
The detail that should detain a CTO is the governance shape of the project. xz-utils, until shortly before the incident, was effectively maintained by a single overstretched person. The attacker did not need to compromise a build server, steal a signing key, or breach a corporate network. They needed only to be persistent and helpful enough to be granted commit access.
This is the modern open source supply chain. And it is the actual subject of any serious "open source strategy" conversation.
The "free" myth died years ago
It bears repeating because boards still hear it: open source is not free. It costs engineering time to evaluate, integrate, maintain, patch, and sometimes fork. It costs legal time to track licences. It costs security time to monitor vulnerabilities. And when a maintainer burns out and walks away from a critical library, it costs everyone downstream — sometimes immediately, sometimes years later.
The real question is not whether to use open source. Of course it gets used; the modern enterprise stack is open source held together by glue. The question is whether an organisation has a strategy for it, or whether it is consuming and hoping for the best.
Most are doing the latter. That is a defensible position when nothing has gone wrong yet. It is an expensive position once something has.
Consumption is not a strategy
The pattern observable across mid-sized European enterprises is consistent: engineers pull in dependencies freely, nobody tracks what is actually in production, and the Software Bill of Materials conversation only happens when a compliance audit or a CVE forces it. Then Log4Shell happens.2 Or xz-utils. Or the next as-yet-unnamed incident in the long queue. Suddenly the CEO wants to know how exposed the company is, and the engineering organisation is reading dependency manifests under emergency conditions instead of in a planned review.
A real open source strategy covers three things, in roughly this order of neglect.
The first is intake and governance — not a bureaucratic approval board, which nobody wants and which slows everything down. A lightweight process that answers basic questions before a dependency enters the codebase. What is the licence? AGPL in a SaaS product is a different conversation than MIT. Who maintains it — one person, a foundation, or a venture-backed company that might change the licence next quarter? What is the bus factor? Is there a commercial support option for the moments when it matters? Tools like FOSSA, Snyk, Dependabot, and GitHub's built-in dependency graph make this tractable. The OpenSSF Scorecard project3 gives a quick health check on any GitHub repository — no branch protection, no signed releases, no recent activity, fewer than two maintainers — in seconds. The point is not to block adoption. The point is to make risk visible before it is urgent.
The second is contribution and participation. This is where most enterprise strategies stop short. Companies consume open source aggressively and contribute almost nothing back. That is shortsighted on multiple axes. Contributing upstream — even small patches, documentation fixes, bug reports — builds engineering reputation, keeps the team close to the tools they depend on, and reduces the maintenance burden of carrying internal forks indefinitely. There is no requirement to sponsor foundations or hire full-time maintainers, though both are legitimate. What is required is a culture where contributing upstream is treated as real work, not as side-project time tolerated grudgingly.
The third is risk management as a continuous practice. Software composition analysis is not a one-time scan. It is a pipeline stage. Every build should know what it contains and flag known vulnerabilities. Every quarter, someone should review the dependency tree for abandoned projects, licence changes, and concentration risk. The European Union's Cyber Resilience Act, which entered into force in December 2024 and starts imposing meaningful obligations from 2026 onwards, makes much of this no longer optional for vendors serving the EU market.4 For Swiss firms with EU customers, the obligation flows through.
The license landscape shifted under our feet
The commercial-open-source license-change cadence is now predictable enough to plan around. MongoDB moved from AGPL to the Server Side Public License in 2018. Elastic followed in 2021 with the Elastic License v2, and again revised its posture in 2024.5 Redis went through it twice — to SSPL in March 2024, then to AGPLv3 in May 2025, an unusually reversed trajectory that produced Valkey, the Linux Foundation-backed fork, in March 2024.6 HashiCorp moved Terraform to the Business Source License in August 2023, producing OpenTofu under the Linux Foundation in 2024.7
The pattern is structural, not moral. Venture-backed open source companies face a recurring pressure to monetise once cloud hyperscalers begin reselling their software at scale. The licence is the lever they have. A CTO whose architecture depends on a single-vendor open source project — particularly one with venture funding and a recent Series C or D — should assume the licence will change at some point in the project's life, and plan accordingly. That means evaluating forks early, maintaining switching capability, or making a deliberate commercial commitment. Pretending the next project will be different is not a strategy. It is a forecast contradicted by every comparable case in the past six years.
Open source as a talent signal
There is a secondary effect that compounds slowly and is easy to miss in any single quarter. Engineers want to work where open source is taken seriously — not just consumed, but understood, contributed to, and respected. In a tight Swiss hiring market, where a senior backend role on jobs.ch attracts hundreds of applications with a dismal signal-to-noise ratio, a visible open source presence is a genuine differentiator. Public contributions to CNCF projects, talks at FOSDEM or Swiss conferences, internal tools published as proper repositories — these are signals senior candidates read.
LatticeFlow AI, the Zurich-based ETH spinoff that has become Europe's leading AI Act conformity tooling vendor, has open-sourced significant components of its model-evaluation infrastructure precisely because it understands the recruiting and credibility math.8 Apertus, the fully-open Swiss frontier-scale language model released by EPFL, ETH, and CSCS in September 2025, is the highest-profile recent example of openness as positioning rather than charity.9
What this means operationally
A defensible open source posture has roughly five components, and none of them require a dedicated open source program office in the early stages. Treat every new dependency as a small architectural decision with a one-page record: licence, maintainer health, bus factor, switching cost. Make software composition analysis a CI stage with budgeted remediation time. Track licence changes in your critical dependencies as a quarterly review, not an emergency. Allocate a measurable fraction of engineering time — even five percent — to upstream contribution on the projects the company most depends on. And maintain at least one fork-readiness exercise per year on a critical dependency: not because the fork will happen, but because if it does, the exercise of having thought about it converts a six-month migration scramble into a three-week project.
The open source decision is no longer at the level of "do we use it." That decision was made long ago and is not contested. The decision is at the level of "how aware are we of what we are using, and how prepared are we for the next incident to happen to one of our own dependencies." The companies that build this muscle now will not be the ones writing post-mortems in 2027. The rest will.