# The Breakout-Repo Venture Read: Company, Watch, Feature, or Public Good

*Score one trending repo on six public-data dimensions in about two hours and name its verdict, plus the evidence that would flip it.*

- Canonical URL: https://www.refolk.ai/guides/breakout-repo-venture-read
- Pillar: Investing and deal sourcing
- Format: Framework
- Published: 2026-11-10
- Last reviewed: 2026-11-10
- Reading time: 21 min
- Keywords: is an open source project venture backable, how to evaluate an open source project for investment, open source startup due diligence checklist, github stars vs production adoption, open core vs managed cloud which fits, investing in open source maintainers before they incorporate

## Key takeaways

- Viral attention and contribution come apart: in a longitudinal study of agent frameworks, LangChain converted 41.2 code contributors per 1,000 stars against AutoGPT's 9.4, a 4.4x gap.
- A permissive license does not protect a project from capture: Valkey launched 8 days after Redis changed its license, and AWS sold Valkey as a managed service about 6.5 months later.
- A managed-cloud wedge can come to dominate revenue, as Atlas grew from 1% to 73% of MongoDB revenue, but it pulls subscription gross margin down because it resells compute.
- Never re-score a Watch verdict sooner than 60 days after the main star spike, because fake stars stop helping within about two months and contributor retention settles near day 90.
- A low GitHub dependents count means unknown, not zero, because GitHub only computes dependents for public repositories and the count is approximate.
- In Refolk's index, Germany shows 1.33 self-described open-source founders per self-described maintainer against 2.12 in the US, which suggests a deeper pool of maintainers who have not incorporated yet.

This guide covers the venture-fit read for one fast-rising open-source repository. It is the call you make after your sourcing pipeline has surfaced the repo and a star audit has confirmed the count is real, but before anyone messages the maintainers. It is written for early-stage investors, platform and talent partners at funds, and angels. It gives you six dimensions you can score from public data in about two hours, four verdicts, and for each verdict the evidence that would flip it.

## What are the four verdicts, and what flips each one?

Every breakout repo ends in one of four verdicts. Company means approach now. Watch means re-score on a set date. Feature means a platform will probably absorb it. Public Good means it is useful but nobody has a reason to pay. A verdict is only worth recording if it also names the evidence that would change it.

| Verdict | What it means | Do now | What flips it |
|---|---|---|---|
| Company | Wedge, control, and lasting use | Approach the maintainers | A cloud launches a managed service, or core committers join a platform |
| Watch | Real signal, incomplete evidence | Re-score 60+ days after the spike | Up: density holds and a buyer appears. Down: no wedge found |
| Feature | A platform will absorb it | Pass, but track the maintainers | Committers leave the platform and no cloud sells it |
| Public Good | No paid wedge | Pass | Running it at scale gets hard enough that someone would pay |

Why bother with a formal read? The outcomes in commercial open source (COSS, meaning companies built on an open-source project) are lopsided. The Linux Foundation, COSSA and Serena report puts the median COSS IPO valuation at $1.3B against $171M for closed-source peers, and the median M&A outcome at $482M against $34M. The same body of work says only 12% of COSS companies reach an exit. When the upside is large and the base rate is low, a repeatable read pays for itself. The honest answer to "is an open source project venture backable" is that popularity is necessary but nowhere near enough.

## The six dimensions and how to score them

Score each of the six dimensions 0, 1 or 2: production adoption depth, paid wedge, capture exposure, maintainer control and intent, category position, and durability of attention. A higher score is always better, so capture exposure scores 2 when the exposure is low.

| Dimension | Scores 2 when | Scores 0 when | Lies when |
|---|---|---|---|
| Production adoption depth | Public dependents ship products, and direct installs grow net of CI | No dependents and no direct installs | Downloads are transitive or come from CI |
| Paid wedge | You can name the wedge and the buyer | There is nothing to operate or govern | The wedge is assumed, not observed |
| Capture exposure (2 = low) | No cloud sells it, and none has a reason to | A hyperscaler already sells it | The license is read as protection |
| Maintainer control and intent | Top committers are independent or at their own company, and intent is visible | Top committers work for the platform that would absorb it | The headline says maintainer but the commits disagree |
| Category position | Densest of its peers, and others build on it | Trails a peer by a wide density gap | The density comes from salaried staff |
| Durability of attention | Flagged stars under 5% or confined to launch day, and retention holds to day 90 | Bursts keep recurring, and density is under 10 | A viral launch is mistaken for bought stars |

Turn the scores into a verdict with these rules, in this order:

1. **Paid wedge scores 0:** Public Good, whatever else scores well.
2. **Capture exposure scores 0, or maintainer control scores 0 because the platform that would absorb the repo employs its core committers:** Feature.
3. **Durability scores 0, or any dimension is "unknown" because the spike is under 60 days old:** Watch, with a date.
4. **Total of 10 or more out of 12, with no zero anywhere:** Company. Anything else: Watch.

These cut-offs are my working convention, not a published benchmark. The State of Commercial Open Source report draws on 800+ companies and 13 community health indicators, scored with the OpenSSF Criticality Score, and concludes that strong community health is closely linked to higher valuations. A secondary summary says contributor diversity, GitHub activity and the Criticality Score correlate strongly with valuation. I could not confirm which indicators carry how much weight. If you want to weight one dimension above the others, read the coefficients in the report's PDF first.

#### Evidence depth beneath a star count

1. **Stars** - Attention, cheap to inflate, fades within about two months if bought
2. **Contributors** - People who can change the code, measured per 1,000 stars
3. **Public dependents** - Public projects that build on it, approximate and blind to private repos
4. **Direct installs** - Downloads net of mirrors, with CI and transitive pulls separated out
5. **Paid use** - Someone pays for an edition, a service, or a feature

*Each layer down is harder to fake and closer to revenue, so score from the deepest layer you can actually see.*

## GitHub stars vs production adoption: scoring attention, position, and use

Stars show attention. Contributors, dependents, and direct installs show use. Score durability, category position, and adoption from the layers beneath the stars, because viral attention brings in spectators much faster than it brings in people who can contribute.

### Durability of attention

This dimension asks whether the attention will still be there after the spike. Start with the star audit. The longitudinal study from Cisco and Indiana University flags three kinds of suspect star: accounts created on the day they starred, empty profiles, and stars that arrive in burst hours. It treats rates below 5% as baseline noise. The scale of the problem is real. The StarScout work found 3.1 million fake stars, spread by 278,000 accounts across 15,835 repositories, and found that fake stars only promote a repo in the short term (less than two months) before they become a liability.

Then check retention. In the same study, contributor retention drops most steeply in the first 30 days after someone's first contribution and settles near day 90. For a repo whose spike is younger than 60 days, you cannot score this dimension, and that alone makes the verdict Watch.

- **What it proves:** people stay engaged after the launch is over.
- **How it lies:** a genuine viral launch produces the same flagged-star pattern as a bought one. AutoGPT's flagged stars are concentrated around its launch, which fits launch-amplified activity. What matters is whether the flags cluster on launch day or keep recurring.

### Category position

This dimension asks whether the repo is the one its category builds on, or one of several. The best public proxy is contributor density, meaning code contributors per 1,000 stars. Compute it for the repo and for its two or three nearest peers.

| Repo | Code contributors per 1,000 stars |
|---|---|
| Pydantic-AI | 42 |
| LangChain | 41.2 |
| Mid cluster (unnamed) | 22.1 to 23.1 |
| AutoGPT | 9.4 |

**4.4x - LangChain's contributor density over AutoGPT's**

AutoGPT gained 111,967 stars in one month, yet converted far fewer of them into code contributors.

The second signal is gravity. The same study found LangChain acts as shared infrastructure, attracting 82.5% of the contributors who work across ecosystems. If developers who contribute to rival projects also contribute to this one, it is becoming the hub of its category.

- **What it proves:** builders choose this repo over the alternatives.
- **How it lies:** a high ratio can come from salaried staff doing the work. The study links high retention in some projects to a managed engineering effort rather than a community that stayed on its own. Check who employs the committers before you credit the density.
- **Limit:** these benchmarks come from one study of multi-agent frameworks. Use them as reference points, and judge position against the repo's own peers, not against these numbers in the abstract.

### Production adoption depth

This dimension asks whether anyone is running the project in production. Two public sources help, and both have known blind spots.

- **Dependents.** GitHub only computes dependents for public repositories, and its own documentation says the counts are approximate. One study measured roughly 20% error in dependency detection. A tool such as github-dependents-info will list the dependents, so you can look at who they are rather than relying on the number.
- **Downloads.** pypistats excludes mirror traffic from bandersnatch, z3c.pypimirror, Artifactory and devpi, but it includes CI/CD downloads in every metric. Wagtail's maintainers reported CI accounting for between 10% and 30% of monthly downloads. Downloads also inherit volume through dependencies: a package that other packages depend on picks up installs from every one of them, recursively.

> **Rule:** A low dependents count means unknown, not zero
>
> Private repositories never show up in the public dependents graph, so a small "Used by" number cannot score adoption 0 on its own. Score 0 only when dependents and direct installs are both absent.

## Paid wedge and capture exposure: open core vs managed cloud

The paid wedge is the thing a buyer pays for that the free project does not give them. Capture exposure is the risk that a bigger platform sells that thing first. Score the two together, because the most attractive wedge, managed cloud, is also the one a hyperscaler can most easily take.

### Choosing the wedge

There are three wedges, and each fits a different kind of project. The fit criteria below are my judgement, not sourced figures.

- **Managed cloud:** you run the project as a service. It fits stateful software that is hard to operate well, where the buyer is paying to stop running it themselves.
- **Self-managed enterprise:** a paid edition that customers deploy on their own infrastructure. It fits buyers who cannot send their data outside.
- **Open core:** a free core plus paid features. It fits when organisations need governance, security or admin features that individual users never ask for.

MongoDB is the reference point. Atlas, its managed cloud, went from 1% of revenue in its early fiscal years to 73% in the latest one, up from 66% and 70% in the two years before. The same filing says subscription gross margin fell to 76% because of the growth in Atlas revenue. A cloud wedge compounds, but it is partly reselling hyperscaler compute, so expect its margin to sit below a pure license business.

If you cannot name the wedge and a plausible buyer, score it 0. Public Good is a legitimate verdict. It just is not a venture verdict.

### Capture exposure

Capture depends on who could sell the managed service, not on what the license says. When cloud revenue is at stake, a relicense on a permissive codebase produces a fork, usually with cloud providers backing it.

| Case (original license) | Fork launched | First stable / parity | Cloud managed service |
|---|---|---|---|
| Redis to Valkey (BSD-3) | 8 days after the change | 7.2.5 in about 2 months, 8.0 in about 6 months | AWS, about 6.5 months after the change |
| Terraform to OpenTofu (MPL-2.0) | 41 days after the change | 1.6.0 GA in about 5 months | Not verified |
| Elasticsearch to OpenSearch (Apache-2.0) | About 3 months after the change | Not verified | AWS, date not verified |

#### How a relicense became a fork with a managed service

1. **Relicense** - Redis moves from BSD-3 to source-available licenses
2. **Fork in 8 days** - Valkey launches with cloud-provider backing
3. **First release** - Valkey 7.2.5 ships within about two months
4. **Parity release** - Valkey 8.0 ships about six months after the change
5. **Managed service** - AWS ElastiCache and MemoryDB add Valkey at lower prices

*Redis relicensed and, within about 6.5 months, AWS was selling the fork at lower prices.*

The Redis CEO later described the result in his own words: "This achieved our goal - AWS and Google now maintain their own fork". Some Linux distributions and cloud providers dropped Redis after the change. OpenTofu was backed by Gruntwork, Spacelift, Harness, env0 and Scalr, all vendors whose own businesses depended on the tool. Elastic later added AGPL v3.0 as an option alongside its other licenses.

> Capture depends on who could sell the managed service, not on what the license says.

Score capture exposure like this:

- **2 (low):** no cloud or platform sells the project, and the operational burden is too small, or too specialised, for one to bother.
- **1:** the license is permissive and a managed offering is plausible, but none exists yet.
- **0 (high):** a hyperscaler already sells it, or the project is an obvious feature of a platform its users already pay for.

> **Watch out:** A permissive license is not a safe license
>
> A CLA (contributor license agreement, which gives one entity the rights to relicense contributions) lets the company relicense later. The precedents show that using that option starts a fork within days. Treat a CLA as an option, never as protection.

#### Wedge strength against capture exposure

Horizontal axis runs from Weak paid wedge to Strong paid wedge. Vertical axis runs from Low capture exposure to High capture exposure.

| Quadrant | What it means |
| --- | --- |
| Feature | A platform absorbs it, so pass and track the maintainers |
| Contested | Watch unless the maintainers clearly control the category |
| Public Good | No buyer, so pass |
| Company candidate | Confirm control and intent, then approach |

*A strong wedge only becomes a Company verdict when no platform is positioned to sell the same thing first.*

## Maintainer control and intent: investing in maintainers before they incorporate

Maintainer control asks who employs the people who merge the code. Intent asks whether those people want to build a company. A repo whose top committers work for the platform most likely to absorb it scores 0 on control, however good the code is.

Start with the commit history and list the top committers by merged code. Then find each person's current employer. This is the slow part by hand, and it is where [Refolk](/) removes the friction: you ask for the people in plain English and get back profiles with current employers across GitHub, LinkedIn and the open web. Then confirm each person against their commits.

Refolk's index shows why the employer check matters. Among US profiles with "open source maintainer" in the headline, current employers include AWS, Microsoft, Docker, Okta and the CNCF. Hyperscaler-employed maintainers show up directly in the sample. A brilliant maintainer whose salary comes from a cloud provider is a hiring signal for that provider, not a founder signal for you.

| Segment (Refolk's index) | US | Germany | US:DE |
|---|---|---|---|
| Headline "open source maintainer" | 126 | 49 | 2.6x |
| Founder or co-founder + "open source" | 267 | 65 | 4.1x |
| Founders per maintainer | 2.12 | 1.33 | - |

**1.33 - Open-source founders per self-described maintainer in Germany, vs 2.12 in the US**

In Refolk's index, this points to proportionally more maintainers in Germany who have not incorporated yet.

Treat the German ratio as a hypothesis, not a finding. It comes from headline keyword matching, with titles and companies checked on a 25-profile sample. The German founder sample includes deepset (Haystack) and dltHub, which shows the pool does turn into companies. If you invest in open-source maintainers before they incorporate, the ratio suggests one place to look.

Timing matters too. A ROSS Index listing (Runa Capital's quarterly ranking of fast-growing open-source startups) already means a company exists, because Runa's team manually checks for a startup founded less than ten years ago. ROSS ranks on maximum star growth over a 90-day window, and a repo must reach 1,000 stars by the end of the quarter. Runa adopted that threshold because AI-era projects often reach 1,000 stars in days. By one annual report, 225 unique startups had appeared in the index. In one annual review, 44% of the 50 fastest-growing had raised venture funding in the period covered. If you find a repo through a leaderboard, assume the round may already be under way.

For intent, check:

- Does any top committer already hold a founder or co-founder title connected to the project?
- Have the maintainers registered a company, a domain, or a commercial edition?
- Do the core committers stay independent of any single large employer?

I ran this search: `Maintainers of fast-growing open-source vector databases in Germany who have not founded a company yet` - [see the full result list](https://www.refolk.ai/s/zhqpc9eyz0).

*Returns named maintainers with their current employers and roles, so you can score control and intent before a leaderboard puts them in front of every other fund.*

## Step-by-step: the two-hour venture read

Run seven steps in order, split across an analyst, a partner and a talent partner. The whole read takes about two hours of desk time. That is my estimate, not a measured figure. The sources disagree on order: ROSS ranks on stars first and verifies the company afterwards, while the Cisco study treats stars as unreliable and puts density first. I audit stars first only to date the spike and filter out noise, and I never score on them.

#### The breakout-repo read

1. **Audit the stars and date the spike** - Analyst, about 15 minutes. Measure same-day new-account, empty-profile and burst-hour shares against the 5% noise floor, note whether flagged stars sit on launch day or recur, and date the main spike.
2. **Compute density, retention, and peer position** - Analyst, about 20 minutes. Count code contributors per 1,000 stars for the repo and two or three nearest peers, and check how many first-time contributors are still active at 30 and 90 days.
3. **Check production adoption** - Analyst, about 20 minutes. Pull public dependents and downloads with mirrors excluded and CI noted, separate direct from transitive installs, and write down every blind spot.
4. **Map license and capture exposure** - Partner, about 15 minutes. Record the license, any CLA, and whether a hyperscaler already sells a managed service, then match the repo to its nearest fork precedent.
5. **Name the paid wedge** - Partner, about 20 minutes. Choose managed cloud, self-managed enterprise or open core, using MongoDB's revenue mix as the reference, and name the buyer or record that there is none.
6. **Map maintainer control and intent** - Talent partner, about 20 minutes. List the top committers, their current employers, and any sign that they already lead or plan a company.
7. **Score, call the verdict, set a re-score date** - Partner, about 10 minutes. Score all six dimensions, apply the verdict rules, write the evidence that would flip the call, and set a re-score date at least 60 days after the spike.

Write the result into one memo per repo. A memo with blanks is worse than one that says "unknown", because "unknown" tells the next reader what to check.

**Breakout-repo venture read memo**

```
Repo:
Read date:                 Main spike date:
Analyst:                   Partner:            Talent partner:

1. Durability of attention (0-2):
   Flagged-star share vs 5% floor:
   Flagged stars launch-only or recurring:
   First-time contributors active at 30 / 90 days:
2. Category position (0-2):
   Density (contributors per 1,000 stars), repo vs nearest peers:
   Cross-ecosystem contributors seen:
3. Production adoption depth (0-2):
   Public dependents (approximate) and notable names:
   Direct installs, mirrors excluded, CI share noted:
   Blind spots:
4. Capture exposure (0-2, 2 = low):
   License:            CLA:          Managed service sold by a cloud:
   Nearest fork precedent:
5. Paid wedge (0-2):
   Wedge (managed cloud / self-managed enterprise / open core / none):
   Named buyer:
6. Maintainer control and intent (0-2):
   Top committers and current employers:
   Already leading a company:

Total (of 12):
Verdict (Company / Watch / Feature / Public Good):
Evidence that would flip it:
Re-score date (no earlier than spike + 60 days):
```

*One memo per repo. Fill every line, and write "unknown" rather than leaving a blank.*

## How the venture read goes wrong

Most wrong verdicts come from one of seven false readings, and each of them looks like strong evidence at first glance. This section is the main reason a scored read beats a gut call, so check every item before you trust a verdict.

1. **A viral launch read as bought stars, or the reverse.** A genuine viral launch and a bought burst produce the same flags. AutoGPT's flagged stars clustered around its launch, which fits real amplification. Check whether the flags cluster on launch day (more likely real) or keep coming back in later bursts (more likely bought).
2. **Density that is really payroll.** A high contributor ratio can come from one company's salaried engineers. The study ties some high retention to a managed engineering effort rather than a community that stayed on its own. Check committers' employers before crediting category position.
3. **Missing dependents read as missing adoption.** Private repositories are invisible to the dependents graph, and the "Used by" number is approximate. A low count is unknown, not zero.
4. **Transitive downloads read as demand.** A package that others depend on inherits download volume from all of them, recursively, and CI traffic is counted too. Check whether people install the package directly or only get it pulled in by something else, and subtract an estimate for CI.
5. **A leaderboard read as an early signal.** A ROSS listing means a company already exists, because of the manual startup check. A "trending" signal can arrive after the round has closed. Check for an existing entity and funding history before you treat the repo as early.
6. **A permissive license read as safe.** It feels low-risk, but the precedents show a relicense triggers a fork within days when cloud revenue is at stake. Score capture by who could sell the managed service.
7. **A headline read as a maintainer.** Headline keyword matches in Refolk's index pick up advocates as well as maintainers. The US sample includes an "Ambassador". Confirm maintainer status against commit history before scoring control or intent.

> **Tip:** Two flags at once means Watch
>
> If any two of these failure modes apply to the same repo, record Watch with a dated re-score instead of forcing Company or Feature. The cost of waiting 60 days is lower than the cost of a confident wrong call.

## Keeping the read current

A verdict is a dated judgement, not a permanent label. Re-score every Watch no earlier than 60 days after the main spike, ideally at day 90. Re-check any Company or Feature verdict whenever the flip evidence in its memo shows up.

Insight from the evidence drives the schedule. Fake stars stop helping within about two months, and contributor retention settles near day 90, so a re-score before then measures hype. Between re-scores, watch the facts most likely to move:

- **Managed-service listings.** A hyperscaler adding the project to its catalogue moves capture exposure to 0 overnight.
- **Committer affiliations.** A core maintainer joining a platform, or leaving one to go independent, changes control. Running the same plain-English query in Refolk on each re-score date shows who has moved since your last read.
- **License files and CLAs.** Any relicense restarts the fork clock in the table above.
- **Leaderboard rules.** ROSS has changed its entry rules before. Re-read its methodology page before you compare a repo's ranking across quarters.
- **Benchmarks.** The density reference points come from one study in one category. Recompute peers on every re-score instead of carrying old numbers forward.

When the verdict is Company, approach with the specific evidence that convinced you, not the star count. Maintainers of breakout repos get a lot of investor mail, and a note that shows you understood their adoption and their wedge stands out.

**First note to a maintainer after a Company verdict**

```
Hi [first name],

I have been following [repo] since [spike month]. What caught my attention was not the stars but [specific adoption evidence, e.g. the public projects building on it].

I invest in commercial open source at the earliest stage, often before there is a company. There is one thing I could not answer from the outside: [the open question from your read, e.g. how teams running it in production handle upgrades].

If it would help, I can share my notes on how comparable projects chose between a managed service and a self-managed enterprise edition. No deck needed.

[your name]
```

*Replace the bracketed parts with what your read actually found. Never send it before the verdict.*

#### Before you call the verdict

- [ ] The main star spike is dated, and the flagged-star share is recorded against the 5% floor.
- [ ] Contributor density is computed for the repo and at least two nearest peers.
- [ ] Retention at 30 and 90 days is recorded, or marked unknown because the spike is too young.
- [ ] Every adoption number has its blind spot written next to it (private repos, CI, transitive installs).
- [ ] The license, the CLA status, and any existing cloud managed service are recorded.
- [ ] The paid wedge and its buyer are named, or the memo says "none".
- [ ] Every top committer has a current employer that has been checked against commit history.
- [ ] The memo names the evidence that would flip the verdict.
- [ ] A re-score date at least 60 days after the spike is in the calendar.

## Frequently asked questions

### Is an open source project venture backable if it has a lot of GitHub stars?

No. Stars alone cannot tell you, because they measure attention, not use. AutoGPT gained 111,967 stars in one month but converted only about 9 code contributors per 1,000 stars, against LangChain's 41. Before you treat a repo as backable, look for production adoption, a paid wedge you can name, and maintainers who control the code. Stars are useful for one thing: dating the spike, so you know when the evidence beneath them has had time to settle.

### Open core vs managed cloud: which fits a young open-source project?

Managed cloud fits projects that are hard to run in production, because the buyer is paying you to take on the operational work. Open core fits projects where companies need governance or admin features that individual users never ask for. Managed cloud can grow very large: Atlas went from 1% to 73% of MongoDB revenue. But it pulls gross margin down, and it is the wedge a hyperscaler is most likely to copy.

### How long should I wait before re-scoring a Watch verdict?

Wait at least 60 days after the main star spike, and ideally until day 90. Research on fake stars found they only promote a repo for less than two months, and a longitudinal study found contributor retention drops most steeply in the first 30 days and settles near day 90. If you re-score earlier, you are measuring launch noise. Put the date in the memo when you make the call, so the re-score actually gets done.

### Does a permissive license make an open-source startup safer to back?

No. A permissive license makes capture easier, not harder. When Redis moved off BSD-3, the Valkey fork launched eight days later, and AWS was selling Valkey as a managed service about 6.5 months after that. Terraform's move off MPL-2.0 produced OpenTofu, backed by vendors whose own revenue depended on the tool. Capture risk depends on who could sell the managed service, not on what the license says.

### How do I find open-source maintainers before they incorporate?

Search people, not company lists. A ROSS Index listing means a company already exists, because Runa Capital manually checks for a startup. Find committers through the public commit history, then check their current employers and titles. In Refolk's index, Germany has proportionally more self-described maintainers per founder than the US, which suggests more maintainers there who have not incorporated. Confirm each person against their commits, because headline keywords also pick up advocates.

### Which open-source community metrics actually predict startup valuation?

Nobody has published the correlations in a form I could check. The Linux Foundation, COSSA and Serena report covers 800+ companies and 13 community health indicators and links strong community health to higher valuations. A secondary summary says contributor diversity, GitHub activity and the OpenSSF Criticality Score correlate strongly. Read the report's PDF for the actual figures before you weight any one metric above another.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/breakout-repo-venture-read*