How to Pick an Open Source Product

Cătălin Lichi · Sugau · June 2026

Why This Matters

The open source landscape is not a level playing field. Some projects are battle-hardened, foundation-governed, and structurally protected from ever going closed source. Others are one acquisition or one bad quarter away from a license switch that leaves you stranded. The difference is not always obvious from the outside.

This document gives you a repeatable framework for evaluating any open source project before committing it to production infrastructure. The goal is not to avoid open source — the goal is to adopt it with eyes open.

The Core Principle

A project’s governance structure is more important than its feature list. Features can be added. A license switch, an acquisition, or a maintainer exodus cannot be undone after you have built a production system on top of it.

Ask one question before anything else: if the company behind this project disappeared tomorrow, what would happen to the project?

If the answer is “the project continues under foundation governance with a diverse contributor base” — proceed. If the answer is “the project would stall or go dark” — treat it as commercial software with a free tier, not open source, and plan accordingly.

The Maturity Tiers

Not all projects should be evaluated the same way. Apply the framework relative to the project’s age and track record.

Tier 1 — Established (15+ years, clean history)

Track record IS the governance. A project that has shipped regular releases for 15+ years without betraying its users, switching its license, or going dark has demonstrated structural integrity that no checklist can confer. Weight longevity and CVE history heavily. Governance formality matters less.

HAProxy is the canonical example. 24 years, GPL since inception, 27 CVEs total, active LTS branches maintained in parallel. No foundation certificate needed. The record speaks.

Tier 2 — Mature (5–15 years)

Balance track record against governance structure. Check contributor diversity, license history, and whether a foundation or community would survive the loss of the primary maintainer or company.

Tier 3 — New (under 5 years)

Apply the full checklist without shortcuts. No track record means governance structure is the only signal you have. Sandbox projects in this tier should never reach production.

The Evaluation Checklist

1. Governance

Is the project foundation-governed?

Foundation governance means a non-profit entity — CNCF, Linux Foundation, Apache Software Foundation, or equivalent — legally controls the project. No single company can relicense it, fork it closed, or kill it. This is the strongest structural protection available.

Projects under company governance are not automatically disqualified, but you must ask the follow-up question: what happens if that company is acquired, pivots, or fails? If you cannot answer that confidently, document it as a risk.

Acceptable foundations: CNCF, Linux Foundation, Apache Software Foundation, Eclipse Foundation, Software Freedom Conservancy. Independent non-profits with long track records (PostgreSQL Global Development Group) are equally valid.

Not acceptable as governance: a company-controlled foundation created specifically to give the appearance of independence.

Does any single company control more than 50% of commits?

Check the contributor graph on GitHub or the canonical repository. Look at the employing organisations of the top 20 contributors, not just their names. A project where one company employs the majority of active contributors is dependent on that company’s continued interest regardless of what the governance documents say.

Kubernetes is the model: Google, Red Hat, Microsoft, VMware, and dozens of others all contribute significantly. No single entity controls the direction.

Are governance decisions made publicly?

Design proposals, RFC processes, and architectural decisions should be documented and accessible. If the project is steered in private Slack channels or internal meetings, the governance is theatre.

2. License

Is the license stable and enterprise-appropriate?

The following licenses are safe for enterprise production use:

• Apache 2.0 — permissive, patent protection included
• MIT / BSD — permissive, minimal obligations
• MPL 2.0 — weak copyleft, file-level, manageable
• GPL v2 / v3 — strong copyleft, requires source release on distribution, paradoxically protective against AWS-style capture
• AGPL v3 — strongest copyleft, closes the hosted-service loophole, check your legal team’s appetite
• PostgreSQL License — BSD-equivalent, used by PostgreSQL itself

The following are not open source regardless of marketing:

• BSL (Business Source License) — HashiCorp model, converts to open source after delay but company controls the terms
• SSPL (Server Side Public License) — MongoDB’s creation, rejected by OSI as not open source
• Custom “community” licenses — read them carefully, they almost always contain restrictions

Has the license been switched before?

Check the git history and the project’s Wikipedia page. Redis, Elasticsearch, HashiCorp Terraform, MongoDB — all switched licenses when commercial pressure hit. A single switch in a project’s history is a strong predictor of future switching. Two switches means the project has no real commitment to open source, regardless of current claims.

Do contributors sign a CLA or use DCO?

A Contributor License Agreement (CLA) grants the company broad rights over contributed code, including the right to relicense it. This is the legal mechanism used for every major open source to proprietary switch in the last decade. The Developer Certificate of Origin (DCO) does not grant these rights.

CLA alone is not a disqualifier, but combined with company governance and a commercial enterprise tier, it is a significant risk indicator.

Is the open source version the real product?

Some companies release a deliberately crippled open source core while keeping meaningful features in a paid enterprise tier. Over time, development focus shifts to the paid product. The open source version stagnates. This is not open source in any meaningful sense — it is a marketing funnel.

Signs of a crippled core: features described as “enterprise only” that are fundamental to production use, observability features paywalled, clustering or high availability behind a commercial license.

3. Community

What is the project’s maturity tier in its governing body?

For CNCF projects specifically:

• Sandbox — early stage, experimental, explicitly not recommended for production. CNCF is providing a home, not an endorsement. Never use sandbox projects in production infrastructure.
• Incubating — gaining traction, growing community, not yet stable. Evaluate carefully. Check whether graduation is being actively pursued and whether the contributor base is diversifying.
• Graduated — production proven, stable API, large and diverse community, multiple independent production adopters documented. The appropriate tier for infrastructure you depend on.

For projects outside CNCF — Apache Incubator graduation, Linux Foundation project membership, or simply age and production adoption evidence are equivalent signals.

Is the release cadence active and predictable?

Regular releases with public changelogs indicate a healthy, functioning project. Irregular releases, long gaps between versions, or releases that only happen when a commercial customer demands them indicate a project in decline or one where open source is not the priority.

Look for: named LTS branches with documented support timelines, patch releases that address CVEs promptly, changelogs that explain what changed and why.

Is there documented production use at scale?

Conference talks from known organisations, engineering blog posts describing production deployments, and case studies from credible companies are the signals you want. Marketing copy on the vendor’s own website is not evidence.

Specifically look for: organisations you recognise running the project at significant scale, evidence of the project surviving incidents and being improved as a result, community members who are not employed by the primary vendor contributing meaningfully.

Could the community sustain a fork if needed?

If the primary maintainer or company disappeared or went hostile to the community, is there enough knowledge, contributor diversity, and institutional interest to fork and continue the project? This does not require a fork to be imminent — it requires the fork to be viable.

OpenTofu forked Terraform within months of the BSL switch because the community was large enough and motivated enough. That is the model. A project where all meaningful knowledge lives in one company’s engineers is not forkable in any practical sense.

4. Security

What is the OpenSSF Scorecard rating?

The Open Source Security Foundation publishes automated security scorecards for projects. Available at deps.dev and scorecard.dev. The score is automated and objective — it assesses branch protection, code review practices, dependency update tooling, vulnerability disclosure processes, and other security hygiene factors.

Target score above 6 out of 10 for production infrastructure. Below 5 is a red flag regardless of other factors.

Note: projects that predate GitHub or that use non-GitHub hosting may not have a scorecard. Apply manual equivalents — check whether there is a documented security disclosure process, whether maintainers respond to security reports, and whether the project has a SECURITY.md.

How fast are CVEs patched?

Check the project’s security advisories and cross-reference with the CVE database. For production infrastructure, critical CVEs should be patched within 30 days. High severity within 60 days. Projects that sit on known vulnerabilities for months are not safe to run in regulated or sensitive environments.

Also look at the total CVE count relative to project age and exposure. A low CVE count for a project that has been running production internet traffic for a decade is a strong signal of code quality. It is not evidence of absence of vulnerabilities — it is evidence of a disciplined engineering culture.

Is there a public security disclosure policy?

A SECURITY.md file, a documented responsible disclosure process, and a dedicated security contact are table stakes for any project you run in production. The absence of these does not mean the project is insecure, but it means security reports go to the wrong place and patches take longer.

Is an SBOM or dependency audit available?

For government, defence, and regulated industry deployments, you need to know what is inside the project — every dependency, its version, its license, and its own CVE status. Software Bill of Materials (SBOM) generation is increasingly standard. For projects without formal SBOM support, verify that dependency management is automated and that outdated dependencies are flagged.

5. Sustainability

Do multiple independent organisations have a commercial interest in the project’s health?

The most durable open source projects are ones where multiple competing companies all need the project to succeed. Kubernetes is the canonical example — Google, Microsoft, Red Hat, and dozens of others all have business models that depend on Kubernetes being healthy. None of them can afford to let it die or capture it for exclusive advantage.

A project where only one company benefits commercially from its success is a project that depends entirely on that company’s continued goodwill and financial health.

Has the project survived adversity?

A project that has been through a major contributor departure, a governance crisis, a security incident, or a significant fork attempt — and come out the other side healthier — has demonstrated that its governance actually works under pressure. Untested governance is an unknown quantity.

What is the funding model and acquisition risk?

Single-VC-funded companies behind open source projects carry specific risk: the investors eventually need returns, and open source rarely delivers VC-scale returns without a monetisation event. That event is either an IPO, an acquisition, or a license switch. Know which of these is the most likely outcome for the company behind your chosen project.

Independently owned companies with sustainable commercial models around open source — support, training, managed services, enterprise features — are lower risk than VC-backed companies racing toward an exit.

The License Trap: Why AWS Does Not Release Their Code

A common misconception is that using open source obligates you to release your own code. The reality depends entirely on which license.

Copyleft licenses (GPL, AGPL) require you to release modifications if you distribute the software. GPL v2 and v3 apply when you distribute binaries. AGPL additionally applies when you run modified software as a network service — this was specifically designed to close the “we host it but don’t distribute” loophole.

Permissive licenses (Apache 2.0, MIT, BSD) carry no such obligation. You can take the code, modify it, run it commercially at any scale, and release nothing. This is precisely why AWS, Google, and Microsoft prefer projects under permissive licenses. They can take the value without contributing back, and they are legally entitled to do so.

This is also why Elasticsearch switched to SSPL, why HashiCorp switched to BSL, and why Redis changed its license — each was a direct response to cloud vendors extracting commercial value without contribution. AWS’s response in each case was to fork the project under the old permissive license and maintain the fork themselves, which they are legally entitled to do.

The practical implication for your organisation: permissive licensed projects are more at risk of cloud vendor capture than copyleft projects. GPL-licensed HAProxy has never had this problem. Apache 2.0 Elasticsearch did.

The Recommended Stack

The following projects pass every criterion in this framework. All are safe for production use in regulated and sensitive environments.

The One-Page Summary

Before adopting any open source project, answer these questions. A single critical failure is sufficient reason to stop.

Critical — any failure here means do not adopt:

• Is the project foundation-governed or does it have a 15+ year clean track record?
• Is the license stable with no history of switching?
• Is the project CNCF Graduated or equivalent maturity?

High — failures here require documented mitigation:

• Does any single company control more than 50% of commits?
• Do contributors use DCO rather than CLA?
• Is the open source version the real product, not a crippled core?
• Are CVEs patched within 30 days historically?
• Do multiple independent organisations have a commercial interest in project health?

Medium — failures here require annual review:

• Are governance decisions made publicly?
• Is the release cadence active and predictable?
• Is there documented production use at scale by known organisations?
• Is the OpenSSF Scorecard above 6/10?
• Is there a public security disclosure policy?
• Could the community sustain a fork if needed?
• Is acquisition risk low?

If all critical boxes pass and the majority of high boxes pass — adopt with confidence. If critical boxes pass but multiple high boxes fail — adopt with documented mitigations and annual review. If any critical box fails — treat it as commercial software, budget for the exit, and plan the migration before you need it.

Cătălin Lichi is the founder of Sugau — bare-metal Kubernetes, sovereign infrastructure, and private AI built on the open source stack above.