Use this before adding a GitHub or open-source field to the firm's company records, and again at each annual review of the field. Fill it from the firm's own records and the public archive, not from a vendor's description. The definitions follow Conti, Peukert, and Roche (Organization Science 36, no. 4, 2025, pages 1551 to 1573; figures from the authors' November 2024 manuscript on SSRN); the lookback is the firm's own evidence.
Firm / scope (funds, stages, sectors covered):
Prepared by / date:
Field owner (who can explain any value it shows):
Source: built from GH Archive and the GitHub API / bought from a vendor (name):
Definition
- [ ] The field counts a company organization's activity on repositories it does not own (forks, pushed commits, pull requests), per quarter.
- [ ] Stars and README or documentation edits are excluded, or shown separately and never summed into the count.
- [ ] The field shows the change over the last two quarters, not only a lifetime total.
- [ ] A company with no linked organization reads "no public record," never zero.
- [ ] The field notes that open source pulled in through package managers (pip, npm) leaves no public event, so a low count is not evidence of low use.
- [ ] The field covers organization accounts only. Tracking individual developers is out of scope unless decided separately and recorded here:
Event types counted:
Event types excluded, and why:
Linkage
| Check | Method | Result |
|---|---|---|
| Organization linked to company by the website domain on the GitHub organization | ||
| Sample of 20 linked records checked by hand for a wrong match | Wrong matches found: | |
| Link method shown on the record (domain match / manual / vendor) | ||
| Companies with more than one organization handled (summed / primary only) |
Vendor questions (if bought)
| Question | Vendor's answer | Evidence seen | Acceptable? |
|---|---|---|---|
| Which event types feed the number? | |||
| Do stars or documentation edits count? | |||
| How are accounts linked to companies, and can the firm see each link? | |||
| How current is the data, and how is a missing account shown? |
Lookback
Run on companies the firm met in the past two to three years, before the field is shown to the team.
Companies in the lookback / period:
Share with any linked organization:
Share with outside-repository activity:
| Company | Segment (novel / crowded / other) | Engagement began (quarter) | First round (quarter) | How the firm first met it (quarter) | Would the field have prompted an earlier look? |
|---|---|---|---|---|---|
- [ ] Results are read by segment. Crowded-market companies without public activity are not treated as weaker.
- [ ] At least one decision the field would have changed is named, or the field is not built.
Decisions the field would have changed:
Placement
- [ ] The field appears on the company record with its date, link method, and a link to the underlying events.
- [ ] It is presented as a prompt to look, not a score, and is not used to rank or filter out companies.
- [ ] It is reviewed on the same cadence as the rest of the pipeline.
Where it appears (record view, pipeline report, alert):
Decision: build / buy / run the lookback again later / do not add
Approved by / date:
Next review (at least annually, and after any change in data source or link method):
Common failure modes
- "Has a GitHub organization" is shipped as the signal, which the study found weaker than working with outside code.
- Stars are counted, and the field measures attention instead of building.
- A blank is stored as zero and pushes companies without public code down a sorted list.
- A company is matched to someone else's organization by name, and nobody checks the domain.
- The field is never tested against the firm's own history, so no one knows whether it would have changed a decision.
This review decides whether a signal belongs in the firm's records and how it is defined. It does not assess a company's technology, and it does not replace diligence.