Open source doesn’t remove risk. It redistributes it - often back to you.

Open source is increasingly becoming a default requirement in public sector tenders.

The logic is straightforward:

• Transparency → “we can inspect the code”
• Control → “we avoid vendor lock-in”
• Continuity → “we can continue if a vendor stops”

It sounds rational. In some cases, it is.

But in many cases, it’s based on assumptions that don’t hold under scrutiny.

Transparency only works if someone is actually looking

Open source gives you access to the code.

But access ≠ assurance.

To translate transparency into actual security, you need:

• skilled engineers reviewing code
• structured security processes
• continuous monitoring and patching

And here’s the asymmetry that’s often overlooked:

Attackers have strong incentives to analyze widely used open source components.

Most organizations don’t.

This dynamic has been highlighted repeatedly in incidents like:

• Log4j (Log4Shell vulnerability) – widely analyzed, e.g. by CISA: https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance
• OpenSSL (Heartbleed vulnerability) – explained by NIST: https://nvd.nist.gov/vuln/detail/CVE-2014-0160

In both cases, widely used open source components contained critical vulnerabilities that went unnoticed for years ... until they didn’t.

Transparency didn’t prevent the issue.

It only made it visible ... eventually.

“We can always continue ourselves” ... can you really?

Another common argument:

“If the vendor disappears, we can take over.”

Technically correct.

Operationally unrealistic for most organizations.

Maintaining production-grade software requires:

• experienced developers
• secure development lifecycle practices
• vulnerability management
• release engineering

And importantly: speed and budget.

Security is not about fixing issues eventually—it’s about fixing them fast enough.

For most organizations, this capability does not exist at the level required.

The MinIO case: what actually happened and why it matters

A recent example that triggered a lot of discussion:

MinIO, one of the most widely used S3-compatible open source object storage solutions, was “archived” as per April 25 2026.

While the situation is nuanced (the company behind MinIO continues commercial development), the signal it sent to users was clear:

• uncertainty about long-term open source availability
• questions around governance and control
• dependency risk for self-hosted deployments

The reaction across developer communities (e.g. Reddit, GitHub discussions such as: https://www.reddit.com/r/selfhosted/ ) was telling:

Teams running critical workloads suddenly had to ask:

• What is our migration path?
• Who is responsible for future patches?
• Are we exposed if the model changes further?

This is the real issue:

Your dependency is not just the code. It’s the people, funding, and strategy behind it.

And those can change—quickly.

This is not an isolated signal

The broader open source ecosystem has been raising similar concerns for years:

• Maintainer burnout and underfunding (OpenSSF): https://openssf.org
• Increasing supply chain risks (CISA guidance): https://www.cisa.gov/supply-chain
• NIST Secure Software Development Framework (SSDF): https://csrc.nist.gov/Projects/ssdf
• Executive Order 14028 driving SBOM adoption: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

Regulators are starting to catch up.

But procurement practices often lag behind, still treating “open source” as a proxy for lower risk.

“Open source is free” — one of the most persistent myths

Open source can be free to use.

But it is never free to depend on.

Behind every viable open source project, there is:

• funding (commercial or foundation-based)
• a core team of developers
• governance structures
• security processes

Without those, sustainability becomes fragile.

Some projects thrive because they monetize services or enterprise features.

Others struggle quietly—until something breaks.

So what should organizations actually assess?

Instead of starting with “must be open source,” start with outcomes.

Security

• How are vulnerabilities discovered and disclosed?
• What is the track record for patch speed?
• Is there coordinated vulnerability management?

Continuity

• What is the funding model?
• Is there a commercial entity or foundation backing it?
• What happens if key maintainers leave?

Control

• Can we realistically operate, maintain, and secure this ourselves?
• Do we have the internal capability—or are we assuming we do?

Governance

• Who decides on roadmap and priorities?
• Is the project actively maintained?
• How strong is the contributor base?

Exit strategy

• Do we have a migration path?
• How portable is our data and architecture?

In practice, many organizations can only answer a few of these with confidence.

That gap is where risk lives.

Open source vs proprietary is the wrong debate

This is not about being “for” or “against” open source.

Open source can absolutely be the best choice—when it is:

• actively maintained
• well-funded
• supported by a strong ecosystem

We actively support this approach ourselves.

At Kiteworks, we’ve recently strengthened our open source commitment by relaunching our program around ownCloud, with dedicated teams contributing to development, security, and long-term support: https://owncloud.com/blogs/a-re-introduction-to-the-owncloud-community/

This is exactly the point: sustainable open source requires more than code availability. It requires funding, accountability, and committed engineering capacity behind it.

That’s the difference between open source as an idea—and open source as a reliable foundation for enterprise use.

But the inverse is also true:

A well-governed proprietary solution can sometimes offer:

• stronger accountability
• faster security response
• contractual guarantees (SLAs, escrow, audit rights)

Meanwhile, poorly governed open source can create:

the illusion of control without the capability to act on it.

A shift in how we ask the question

If open source becomes a checkbox in procurement, organizations risk optimizing for ideology over outcomes.

A better starting point:

• Do we have certainty around security?
• Do we have assurance of continuity?
• Do we have real operational control?

Only then should the delivery model be evaluated.

Final thought

Open source doesn’t inherently reduce risk.

It redistributes it.

And unless that redistribution is matched with capability, funding, and governance…

…it places the burden exactly where many organizations are least prepared to carry it.

Closing question

How is your organization assessing the continuity, security, and governance risk of its open source dependencies—and do you have a plan if one of them changes direction tomorrow?