The Commercial Open Source Readiness Standard

This is the finish line, not the traction meter. You are an early-stage investor looking at an open-source project, and before you spend a founder call and a partner's afternoon on it, you need to know one thing: can this project be a company at all? This guide gives you a fixed pass/fail standard covering adoption depth, community structure, monetization surface, and license posture, written so two partners grade the same project the same way instead of arguing over stars.

Other references grade whether repo traction is genuine or run technical diligence on the code. This one draws the line between "popular project" and "venture-backable company," which are different questions with different failure modes. A project can be beloved by a million developers and still have nothing to sell.

Why does a readiness standard exist for open source at all?

Because scarcity, not traction, is the real filter, and scarcity is easy to misread as either abundance or noise. In the top 10,000 GitHub repositories ranked by contributor activity, fewer than 500 show what Bessemer would call large-scale community engagement, which works out to roughly one project in 80,000. Rarer still: of that top 500, fewer than 100 have a venture-backed company commercializing them.

That second number is the one that matters. The bottleneck is not adoption. The bottleneck is a commercializable surface sitting on top of adoption. Most projects that clear the community bar still fail the company bar, and a standard exists so you fail them fast and consistently rather than talking yourself into each one.

The category rewards getting this right. Commercial open source, or COSS, averaged around 250 deals per year and roughly 9 billion dollars deployed annually by investors from 2019 through 2024, and aggregate COSS funding totalled 26.4 billion dollars in a single recent year. At that volume, partners see too many repos to adjudicate by taste. A written rubric is the only thing that keeps two people from disagreeing over the same project because one anchored on stars and the other on license.

What is the shape of the COSS exit premium?

The valuation premium is real, concentrated, and drawn almost entirely from infrastructure software. The 2025 Linux Foundation, COSSA, and Serena report found COSS companies reaching materially higher exit valuations than closed-source peers, and reaching funding milestones faster. Treat the multiples as a reason the category is worth a standard, not as comps you can paste onto any project.

Valuations are from the report; the multiples are computed from those figures; velocity is from the summary of the report. One caveat carries weight: around 90 percent of COSS companies operate in infrastructure software rather than business applications. The premium and the population overlap almost entirely, so if the project in front of you is app-layer, do not underwrite it on these numbers. Find app-layer comparables instead.

What does adoption depth actually look like?

Adoption depth is contributor scale and diversity measured against the OpenSSF Criticality Score, not download counts and not stars. The Criticality Score is a single number between 0 (least critical) and 1 (most critical), computed by averaging the logarithmically normalized scores of factors including project age, contributor and organization count, commit frequency, releases in the past year, and closed issues in the last 90 days. Log normalization keeps any one inflated metric from dominating.

The report backs this choice directly: contributor diversity, GitHub activity, and the OpenSSF Criticality Score strongly correlate with valuation. Downloads and stars do not carry that signal. Bessemer, which analyzed the top 10,000 repos, focuses on users and contributors and pays little attention to stars, which spike with press releases and can be gamed.

So the adoption question is not "how many people know about this," it is "how many organizations depend on this and contribute back." A project passes adoption depth when it has a computed Criticality Score and either sits in the top-tier large-scale set or shows a clean trajectory toward it: contributor count rising, organizations rising, releases shipping on a cadence.

How do you read community structure without fooling yourself?

Community structure is contributor growth spread across multiple employers, verified by email domain and organization affiliation rather than raw headcount. A project can post a healthy contributor count where every top committer shares one company's domain, which is a single-employer project wearing a community costume. Diversity of organizations is the load-bearing signal because it proves adoption survives any one company's priorities.

There is a talent angle here that most diligence misses, and it is where Refolk's own index is instructive. Maintainer-grade talent is thin and geographically concentrated, which is a hiring risk even when a project's adoption looks strong.

All counts are from Refolk's index; the multiples are derived from those counts. Two facts jump out. First, in Refolk's index, maintainer-titled talent is roughly 10 times more concentrated in the US than in Germany, so a project whose community lives outside the main talent pool faces a harder hire even with strong adoption. Second, developer-advocate profiles outnumber maintainer profiles about 7.6 to 1, and there were zero Director or VP-level DevRel profiles in the index, meaning the role is overwhelmingly individual-contributor. A founder banking on a ready "VP of Community" hire is chasing a role that barely exists at that level.

When you want to check the maintainer bench around a project before the call, the cleanest move is to look at who actually maintains projects at that scale and where they work.

What counts as a monetization surface?

A monetization surface is a specific, repo-observable way the company captures revenue on top of distribution, and open source alone is distribution, not revenue. There are four proven models, and each leaves evidence you can point to.

Companies like HashiCorp, Elastic, and MongoDB succeed by layering monetization on top of adoption. The load-bearing requirement is proprietary IP: open-core companies must have proprietary IP to monetize. Open core is visible in the repo as a split edition. GitLab's Community Edition is a fully functional MIT-licensed open-source project, while features like vulnerability management and AI code suggestions are exclusive to its proprietary Enterprise Edition. That split is the monetization surface made concrete.

Support-only is the trap that reads as COSS but is not the same asset. Support and services companies only produce open-source code and charge subscriptions for support, training, and implementation, which caps gross margins below software gross margins. It can still be a business, but do not underwrite it on open-core comps.

A project fails the monetization-surface test when it is a permissive-licensed library with no proprietary edition, no hosted offering, and no CLA-backed dual license. High downloads on a project like that read as revenue potential, but there is nothing to sell and nothing to withhold.

What does license posture tell you, and what does it hide?

License posture tells you how the company intends to defend its revenue, and the direction of travel matters more than the current license. Permissive OSI-approved licenses dominate COSS because they serve a top-of-funnel goal of broad adoption, and per Serena the prevalence of non-OSI licenses is under 10 percent. So a permissive license is the default and signals a wide adoption funnel.

The interesting cases are the relicensing moves. HashiCorp switched from the Mozilla Public License to the Business Source License, which does not meet the Open Source Initiative's definition of open source; BSL 1.1 is source-available and permits commercial use only under specific conditions. MongoDB started on AGPL and moved to SSPL in 2018, a stricter copyleft designed to force cloud providers that resold MongoDB as a managed service to either pay or stop. Both moves defend margin against unpaid rehosting.

Both also carry a cost. Relicensing after a community has adopted a project breaks trust and can spawn a fork, as Terraform's relicensing spawned OpenTofu. A project that must relicense to defend its margin was arguably never a clean open-core thesis, because the monetization surface was too thin to hold without changing the rules on adopters. So read license history, not just the current license, and check whether a CLA even exists that would permit a future relicense.

The grading procedure

This is the procedure that produces a pursue-or-pass verdict two partners would reach independently. Run it in order. One honest disagreement in the field: Bessemer front-loads community measurement, while Serena and Open Core Ventures front-load monetization and license posture. This sequence measures adoption first because it is the cheapest to falsify, then tests whether adoption can convert.

The governance step is quick but not skippable. Engagement with foundations is often seen as a positive factor by investors and can lead to more successful outcomes, and knowing who controls the trademark and release process tells you whether the company can actually withhold anything.

How this goes wrong: failure modes and false positives

Most bad COSS verdicts come from a small set of repeatable mistakes. Each has a tell and a cross-check. This is the part of the standard that saves the most partner time, because it catches the projects that look investable and are not.

• Star-count vanity. A repo spikes to tens of thousands of stars off one launch and reads as investable. Stars spike with press releases and can be gamed. Cross-check contributor growth and organizational diversity; if the star curve went vertical while contributors stayed flat, it fails.
• Single-employer contributor base. Raw contributor count looks diverse, but every top committer shares one email domain. Check organization affiliation, not headcount. A community that is one company's payroll dies if that company pivots.
• Adoption without a monetization surface. A beloved permissive library with no proprietary edition and no hosted product. High downloads read as revenue potential, but open-core companies must have proprietary IP to monetize. If there is nothing to withhold, there is nothing to price.
• Relicensing landmine. OSI-approved today, but founder economics push toward BSL or SSPL later, triggering a fork. Check license history and CLA presence before you assume the current license is stable.
• Support-only ceiling. It looks like COSS but is a Red Hat-style services model that only produces open-source code and charges for support and training, which caps gross margins. Check for proprietary IP before applying software comps.
• Criticality Score gaming. Commit and issue frequency can be inflated by bots or a tiny core team. Cross-check the score against dependent count and independent adopters so a self-referential project cannot fake importance.
• Category mismatch. An application-layer project benchmarked against infrastructure multiples. Around 90 percent of COSS is infrastructure, so app-layer comps are weaker; import the wrong comps and you overpay.

The pursue quadrant is deliberately small. It matches the scarcity in the data: with fewer than 100 of the top 500 projects venture-backed, most projects live in the other three quadrants, and the standard's job is to route them there quickly.

The verification checklist

Run this before you write a verdict. Every item is a binary you can defend to a partner, and the project passes only when it clears the adoption, community, monetization, and license gates together. A miss on any single-vendor, monetization, or license item is disqualifying on its own; a miss on the softer items is a caution to note in the memo.

For an investment note that captures the verdict in a form another partner can grade against, use this skeleton.

Project / repo:
Maintaining entity:
Single-vendor driven (Y/N):
OpenSSF Criticality Score + tier:
Contributor growth + org diversity:
Monetization surface (open core / dual / hosted / support-only):
Proprietary IP identified (Y/N):
Current license + history + CLA:
Relicensing / fork risk:
Governance + foundation engagement:
Category + comps used:
Verdict (PURSUE / PASS / WATCHLIST):

Keeping the standard current

The criteria hold, but the inputs move, so re-check the mechanisms rather than memorizing values. Two things drift. First, the Criticality Score methodology evolves; the 2.0 version added releases per year, closed issues in the last 90 days, and comment frequency, so re-read the scoring factors before you rely on an old mental model of what the number weighs. Second, license posture is a moving target because founder economics change: a project that was permissive when you first screened it may relicense, so re-audit license and CLA status before you re-engage.

Two data points are worth refreshing on a cadence rather than trusting from memory: the maintainer talent supply near a project, since a thin bench is a hiring risk even under strong adoption, and whether a fork has appeared, since a live fork changes the monetization surface overnight. Refolk pulls both in plain English, so you can check who maintains a project and where the maintainer talent sits without leaving the diligence. When you keep the mechanisms live and the values fresh, the verdict stays gradeable, and two partners keep reaching the same call.