Open Source Strategy That Actually Ships

The "free" myth died years ago

We all know this, but it bears repeating: open source is not free. It costs engineering time to evaluate, integrate, maintain, patch, and sometimes fork. It costs legal time to track licenses. It costs security time to monitor CVEs. And when a maintainer in Nebraska burns out and walks away from a critical library, it costs everyone downstream.

The real question isn't whether to use open source. Of course we use it — our entire stack depends on it. The question is whether we have a strategy for it or whether we're just consuming and hoping for the best.

Most of us are doing the latter.

Consumption is not a strategy

Here's the pattern we see across companies in Romandy and beyond: engineers pull in dependencies freely, nobody tracks what's actually in production, and the SBOM conversation only happens when a compliance audit forces it.

Then Log4Shell happens. Or xz-utils. And suddenly the CEO wants to know how exposed we are, and we're scrambling.

A real open source strategy covers three things:

1. Intake and governance

Not a bureaucratic approval board. Nobody wants that. But a lightweight process that answers basic questions before a dependency enters the codebase:

• What's the license? (AGPL in a SaaS product is a different conversation than MIT.)
• Who maintains it? One person? A foundation? A company that might change the license tomorrow?
• What's the bus factor?
• Is there a commercial support option if we need it?

Tools like FOSSA, Snyk, or even GitHub's built-in dependency graph make this tractable. The point isn't to block adoption. It's to make risk visible.

2. Contribution and participation

This is where most enterprise strategies stop short. We consume open source aggressively but contribute almost nothing back. That's shortsighted.

Contributing upstream — even small patches, documentation fixes, bug reports — builds engineering reputation, keeps our team close to the tools they depend on, and reduces the maintenance burden of carrying internal forks.

We don't need to sponsor foundations or hire full-time maintainers (though both are valid). We need a culture where contributing upstream is treated as real work, not side-project time.

3. Risk management as a continuous practice

Software composition analysis isn't a one-time scan. It's 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, license changes, and concentration risk.

The OpenSSF Scorecard project gives a quick health check on any GitHub repository. It's not perfect, but it surfaces the obvious red flags — no branch protection, no signed releases, no recent activity — in seconds.

The license landscape shifted under our feet

HashiCorp moved Terraform to BSL. Redis changed licenses. MongoDB did it years ago. Elastic went through it twice. The pattern is clear: venture-backed open source companies eventually restrict their licenses when cloud providers eat their lunch.

This isn't a moral judgment. It's a supply chain fact. If a critical infrastructure component is backed by a single company, we should assume the license may change and plan accordingly. That means evaluating forks (OpenTofu, Valkey), maintaining switching capability, or accepting the commercial terms.

Pretending it won't happen to the next project we depend on is not a strategy.

Open source as a talent signal

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, a visible open source presence (contributions, talks, published internal tools) is a genuine differentiator.

We've seen teams in Geneva attract senior distributed systems engineers specifically because they had public contributions to CNCF projects. That's hard to replicate with a careers page.

The takeaway

Open source strategy isn't about saying yes or no to individual projects. It's about treating open source as what it is: a critical supply chain that requires intake governance, active participation, and continuous risk management. The CTOs who build these muscles now won't be scrambling when the next license change or vulnerability hits. The rest will be writing incident reports.