The Open-Source Investability Standard: Fundable, Conditional, or Pass

You are looking at an open-source project as a possible deal and need to decide whether its repository clears the bar to build a venture-fundable company on it. This standard is for early-stage investors, platform and talent partners, and angels who write commercialization theses into memos. It gives you a fixed set of criteria and one repeatable verdict - Fundable, Conditional, or Pass - so that two investors grading the same repo reach the same grade.

Existing repo-diligence guides rate traction, fork risk, and code originality. None of them states the pass bar a repository must clear before you write a commercialization thesis. This is that definition of done: license headroom, governance and CLA, contributor concentration, real-versus-vendor adoption, and monetization-surface fit, combined into a grade you can defend in an IC meeting.

What the three verdicts mean

The verdict is a decision about whether a fundable company can be built on this repository, not a rating of the code. Fundable means the license, ownership, concentration, and adoption all support a coherent revenue thesis with no unresolved blocker. Conditional means the thesis is plausible but one input needs work before you commit. Pass means a structural blocker makes the commercialization case unwritable as it stands.

Grade the five dimensions, then let the weakest one govern. A repository is only as fundable as its most broken pillar, because each pillar can kill the thesis on its own. A permissive license cannot rescue a codebase with no CLA and a dual-licensing plan; a strong bus factor cannot rescue adoption that traces entirely back to the vendor's own CI bots.

Pillar 1: license headroom

The license sets the ceiling on what a commercial builder may legally do, so classify it first from the actual text. There are four buckets, and the difference between them is the difference between a proprietary product and a mandatory open derivative.

Permissive licenses - MIT, Apache 2.0, BSD - impose minimal obligations, usually just attribution, and let you incorporate the code into proprietary software without open-sourcing that software. Weak copyleft sits in the middle: you can link to the library in a proprietary application without open-sourcing the application, but modifications to the library itself must be released. Strong copyleft - GPL and AGPL - permits commercial use but requires derivative works to be open-sourced. AGPL was written specifically to close the GPL's cloud loophole, ensuring source stays open even for network and SaaS software.

The fourth bucket is source-available, and it is not OSI open source. SSPL prevents anyone but the licensor from offering the software as a service without a separate license. BSL restricts use in a competitive way against the vendor's products and converts to an open license only four years after each release. OSI in 2021 described SSPL and similar licenses as a fauxpen source license.

License headroom is not a pass/fail on its own. What it does is constrain which monetization models are legally available, which is the next pillar.

Pillar 2: monetization-surface fit

The revenue model is downstream of code ownership and license structure, not something you pick freely. A viable model has to be one the license and the ownership chain actually support, or the thesis is fiction. Documented commercial open-source models are paid support, hosting services, restrictive or dual licensing, open core, and hybrid combinations.

Two of these carry hard structural prerequisites. Open core requires the company to hold proprietary IP alongside the open project - it leverages an existing open-source base and builds a commercial version with proprietary features around it. Dual licensing requires the publisher to own, or hold CLA-assigned rights to, every part of the codebase, because it sells the same product under alternative rules. Legally the two differ: dual licensing is choice-based, one product under alternative rules; open core is boundary-based, two separate products from the start.

Model selection maps to what enterprises actually need. If they need compliance, governance, or security features, open core or dual licensing works. If users want to avoid running infrastructure, a hosted SaaS version creates a strong value exchange. If expert assistance is the biggest need, support and consulting is fastest to revenue but has the lowest ceiling.

One published data point on the upside of dual licensing: a single maintainer reported over $350K from the dual-licensed JS library lightGallery across four years. That is a small-scale proof, not a venture outcome, but it shows the mechanism works when ownership is clean.

Pillar 3: governance and the CLA

Governance decides whether the monetization thesis is even legally available, so grade it before you write a dual-licensing memo. The single most consequential question is whether a Contributor License Agreement or copyright assignment exists covering every contributor, because that determines whether the company can sell commercial exceptions or relicense in the future.

Without a CLA, a project with anonymous, non-CLA contributors cannot later sell commercial licenses. The thesis is then capped at support or hosting, whatever the license label says. This is why the ordering matters: a dual-licensing thesis with no CLA is one of the most common false positives in this work.

Beyond the CLA, confirm who controls the trademark and the roadmap. A relicense - MongoDB to SSPL, HashiCorp to BSL, Redis to SSPL - is only possible for a party that owns the rights. The ability to relicense is an asset when you hold it and a threat when a fork holds it.

That ratio is a structural signal. In Refolk's index, commercial evangelism headcount outnumbers formal open-source governance headcount by roughly 25.7x. Heavy promotion with thin neutral stewardship is exactly the single-vendor pattern that relicensing risk feeds on, so treat a loud DevRel presence with no OSPO or governance function as a caution flag, not reassurance.

To pressure-test governance, talk to people who run it for a living.

Finding Refolk useful here is the point: naming eleven OSPO leads across a market by hand is slow, and these are exactly the operators who can tell you whether a target's governance is real or cosmetic.

Pillar 4: contributor concentration

Contributor concentration measures how many people the project would lose to stall, and the standard metric is the bus factor: the smallest integer k such that the top k contributors account for at least 80% of all commits. A common tool convention also computes it at the 50% threshold and flags any single contributor over 50% as critical. Compute both.

The trap is that repo-level numbers mislead. A bus factor of 3 across the whole repo is meaningless if all three only touch one layer, because risk concentrates at the file and module level, not the repo level. Audit per-file single-author concentration. A project can show a healthy aggregate and still have one person who is the only author of the critical subsystem.

Even good-looking numbers deserve suspicion. Practitioners class a bus factor of 2 as still high risk, because losing either person severely impacts the other and you are immediately back at bus factor 1. One academic method that measured this across a sampled project set found a median bus factor of 1.0 - most projects are one departure from stalling.

There is no publicly established universal cutoff for percent of commits from one organization. Practitioners cite the measure but not one agreed number. So set your fund's own threshold, write it into this standard, and apply it uniformly - that is what makes the grade reproducible.

Pillar 5: real versus vendor-only adoption

Adoption has to be separable from the vendor's own usage, or the traction is inflated. Repo-observable proxies include the number of dependent repos and downstream packages, third-party forks in production use, release frequency, and the count of distinct contributing organizations. Health checks worth running include number of maintainers and contributors, release cadence, and mean time to remediate vulnerabilities.

The false positive is thousands of stars and dependents that trace back to the vendor's own repos, CI bots, or demo forks. The corrective is to count distinct contributing organizations and confirm third-party production forks. One organization can manufacture activity; a dozen unrelated ones cannot.

The strongest adoption stress-test comes from the relicensing record. When a hyperscaler runs a managed offering on the OSS, a license fork triggers a fast re-fork. When the SaaS vendor is the only commercial counterweight, an open replacement emerges only from independent communities and takes years to mature.

That speed is the whole point of the defensibility test. A source-available license is not a durable moat where a hyperscaler counterweight exists.

The relicense and fork stress test

Ask one question before you underwrite defensibility: if this project relicensed tomorrow, is there a hyperscaler or independent party who would fund a fork? The relicensing record answers it with precedent, and the pattern is consistent enough to underwrite against.

The lesson is that a restrictive relicense by a project with a hyperscaler-dependent workload predictably produces a well-funded open fork that resets the incumbent's moat. MongoDB produced no comparable fork because no hyperscaler ran the workload the way AWS ran Elasticsearch or the way the cloud vendors ran Redis. Both Redis and Elastic later re-added open licenses - Redis via AGPLv3 in Redis 8, Elastic via AGPLv3 - after the source-available moves damaged community relations.

A source-available license is not a moat where a hyperscaler runs the workload. It is a fork trigger with a fuse measured in weeks.

Where the project sits geographically matters too. DevRel supply is roughly 9.8x thicker in the US than in Germany in Refolk's index, so a European-headquartered project's community-defense capacity may be structurally thinner. Weigh that when you grade fork-survivability.

title: Defensibility of a source-available moat
caption: Fork survivability turns on whether a hyperscaler depends on the workload and whether independent community capacity exists.
x: No hyperscaler dependency :: Hyperscaler runs the workload
y: Thin independent community :: Deep independent community
quadrant: Fragile but unforked :: Moat holds by default; monitor for a challenger
quadrant: Fork imminent :: Do not underwrite the moat; expect a funded fork in weeks
quadrant: Slow open replacement :: Moat holds for years; re-underwrite on community shifts
quadrant: Community-defended :: Moat is contestable; grade Conditional pending fork readiness

The grading procedure

Run these seven steps in order and record the output of each; the last step produces the verdict. Roles and rough times are noted so a team can adopt the sequence as policy. Sources disagree on whether to run concentration or governance first; I put governance before concentration because a missing CLA can void the thesis before contributor counts matter.

To test whether contribution breadth is real rather than vendor-manufactured, look at who contributed to comparable forks from outside the sponsoring company. Engineers who contributed to OpenTofu or OpenSearch outside their employer are the multi-org signal you want, and mapping them tells you whether a target's community is genuinely distributed.

How this goes wrong: the seven false positives

Most bad grades come from a small set of predictable errors, each of which makes a broken repository look fundable. Learn the false positive for each pillar and check for it explicitly.

• License looks permissive but carries an added restriction. An Apache 2.0 repo may actually be Apache plus Commons Clause, as Redis Labs once used. Check the full LICENSE text and headers, not the GitHub label.
• Bus factor healthy at repo level, fatal at module level. A bus factor of 3 or 4 where all owners touch one subsystem. Check per-file single-author concentration.
• Adoption is vendor-inflated. Thousands of stars and dependents that trace to the vendor's own repos, CI bots, or demo forks. Check distinct contributing organizations and third-party production forks.
• Dual-licensing thesis with no CLA. A memo assuming the company can sell commercial licenses when it never collected contributor rights. Check for a CLA or CAA covering every contributor.
• Open core with nothing proprietary. A pure support-and-services business labelled open core. Open Core Ventures explicitly excludes support and services from the definition, so check for actual proprietary IP behind a paywall.
• BSL four-year conversion mistaken for permanence. A moat that legally evaporates on a schedule. Terraform's August 2023 code converts to open in 2027; check each release's change date.
• Ignoring the hyperscaler counterweight. A defensibility narrative for a project whose workload a cloud provider depends on. The OpenSearch and Valkey precedents show a funded fork appears within weeks; check whether a hyperscaler runs a managed offering.

Roughly 60 to 80% of modern code bases are composed of open-source software, so the discipline of grading these repositories is not a niche exercise. The volume is why a fixed standard beats a scattered legal checklist.

The pre-verdict checklist

Before you write Fundable, Conditional, or Pass into the memo, confirm every input is recorded and defensible. This is the verify step that makes two investors grade the same case the same way.

Keeping the standard current

This standard stays useful only if you re-check the moving parts, because licenses convert and forks mature on schedules. Re-underwrite BSL-based theses against each release's conversion date rather than treating the moat as fixed, and re-run the fork stress test whenever a hyperscaler changes its managed-offering footprint.

Two mechanisms are worth watching over the life of a deal. First, community health can shift after a relicense in either direction: Redis and Elastic both re-added open licenses after source-available moves hurt community relations, which changes the defensibility picture. Second, contributor concentration drifts as maintainers leave, so a repository graded Fundable on a bus factor of four can slide toward Conditional without a single line of the license changing. Set a cadence to re-measure concentration and re-count contributing organizations, and note the date of each grade so the next investor knows how fresh the verdict is.