Sooner or later someone on the investment team asks whether the CRM could flag companies whose GitHub activity is picking up. The request sounds small. What it actually asks for is a pipeline of public data, a matching step against the firm's company records, and a field that people will glance at before a pipeline meeting. Once that field exists it shapes who gets a call, so it deserves the same care as any other input to a decision.
The question is not whether GitHub is interesting. It is what the field should count, what a blank means, and how the firm will know the signal earned its place. I went looking for evidence before writing a definition, and found a paper that does much of the definitional work.
Source
What the study measured
Annamaria Conti (IE Business School), Christian Peukert (HEC Lausanne), and Maria Roche (Harvard Business School) published "Beefing IT Up for Your Investor? Engagement with Open Source Communities, Innovation, and Startup Funding: Evidence from GitHub" in Organization Science (volume 36, issue 4, pages 1551 to 1573, 2025). The typeset article is behind a paywall. I read its published abstract and, in full, the authors' manuscript on SSRN, dated November 21, 2024, which carries the published title and the published abstract word for word. The figures below come from that manuscript, and the page and table numbers refer to it; the printed article may paginate differently.
The researchers took 160,065 U.S. startups founded between 2005 and 2020 from Crunchbase. They linked 14,881 of them to GitHub organization accounts through the website each account lists, pulled the public record of activity from GH Archive, and added product launches from Product Hunt (pages 10 to 14).
The event they studied is narrow on purpose: a startup interacting with a repository it does not own. Each startup that did so was compared with up to five startups founded in the same state and year, with a similar share of software-related industry categories and a similar standing for their founders and executives on Crunchbase's ranking. The outcome was whether a startup had raised its first round by a given quarter (page 15).
Source
What it found
In the simplest model, startups that began engaging with outside repositories were 15 percentage points more likely to have raised a first round than their matched peers, against a baseline of 23 percent. With the most demanding controls, including ones for the startup's age, the difference was 8 points, which the authors describe as a 36 percent increase (page 18, Table 4). In the quarters before engagement began, the two groups did not differ in any meaningful way; after, the gap opened at once and persisted (page 20, Figure 3).
Engagement usually came first. Among startups that both engaged and raised a round, 80 percent engaged before the round, on average five months before it, though the two events overlap a good deal (page 17, Figure 2). The association was larger where engagement preceded funding (page 18, Table 5).
Owning code on GitHub was not the same thing. The association for startups working with outside repositories was 9 points larger than for startups using GitHub only for their own repositories (page 20, Table 6). The published abstract states it directly: the relationship is weaker for firms that use GitHub for internal development only.
The engagement was mostly forks. Copying another project in order to build on it made up 96 percent of startups' outside activity. Starring a repository was 2 percent, and pushing code to someone else's project 1 percent (page 13).
Cosmetic work did not register. Creating or editing README files, the documentation a visitor sees first, was not significantly related to funding (page 25, Table 9). The authors read that as some indication that investors were not simply reacting to cosmetic activity.
The context mattered. Startups working on novel technology gained 8 points more. Startups in the most crowded markets gained, on net, nothing (page 22, Table 7). By domain, AI and blockchain startups gained the most and consumer-facing startups the least (pages 23 and 28, Figure 5). The authors frame this as a trade-off between drawing on shared knowledge and protecting what makes a company distinct.
Engagement also preceded products. After it began, startups were about 8 points more likely to have launched on Product Hunt, 1.8 times the baseline; with the age controls added, the difference fell to about 2 points (page 24, Table 8). The funding association was stronger for large first rounds and for first rounds raised from venture investors and from investors with more prior exits (page 26, Table 10).
Coverage is thin. Only 9 percent of the startups in the sample had a GitHub organization account, and 8 percent had any outside activity (page 13, Table 1a). The authors also note that startups can use open source through package managers such as pip or npm without forking anything, which their measure does not see (page 29).
Describe this figure
Two horizontal bar charts on the same scale, 0 to 100 percent. The first splits startups' activity on repositories they do not own by type: forks, copying another project to build on it, were 96 percent; stars 2 percent; pushes of code to someone else's project 1 percent. The second shows coverage across the 160,065 U.S. startups in the sample: 9 percent had a GitHub organization account and 8 percent had any outside activity. The rest, more than nine in ten, left no public record, which the piece reads as unknown, never as zero. The figures come from the authors' manuscript, page 13 and Table 1a; the three activity shares sum to 99 as printed, and open source used through a package manager leaves no event to count.
The authors' reading, in the published abstract, is that one important channel potentially driving the results is access to outside knowledge for technology development, which may help startups innovate and create a minimum viable product. They allow that visibility may also play a part, and judge the knowledge explanation at least as relevant (page 28). They note that one platform limits how far the result generalizes (page 29).
Synthesis
What the study does not tell an investor
It measures who gets funded, not who returns capital. A signal that anticipates a first round tells the firm where other investors are likely to arrive soon, and the paper found the association strongest for venture investors and for those with more prior exits. That makes the signal useful for timing. It does not make it a verdict on quality.
It is observational. The authors match carefully, add layers of controls, and rerun the result against a battery of alternatives, including dropping California and accelerator startups and controlling for new hires (pages 18 to 19). They also say plainly that startups select into open source, which makes a truly causal estimate difficult (pages 29 to 30). I would treat the result as strong evidence of a pattern, not proof that forking causes funding.
It stops in 2020. The Crunchbase data runs to the second quarter of 2020. How startups write and borrow code has changed since, and I return to that below.
Synthesis
What that means for the firm's field
Count interaction with other people's code, not presence. "Has a GitHub organization" is the field most people would build first, and it is the one the paper found weaker. The event worth counting is a startup's organization forking, contributing to, or otherwise working with repositories it does not own.
Leave out stars and README edits. Stars were a sliver of the activity, and in my own landscape work I already treat stars as a measure of attention rather than adoption. README edits are the easiest activity to stage and showed no relationship to funding. A field that rewards either invites gaming and measures the wrong thing.
Read it by segment. Engagement meant most where technology was novel and least where markets were crowded. A team in a crowded market that keeps its code private may be protecting its position, which is a reasonable choice. The field should not penalize it.
Treat a blank as unknown. With more than nine in ten companies in the study's sample showing no outside activity, a blank field is the normal state, and a company that pulls open source in through a package manager leaves no public event at all. It should read "no public record," never zero, and never feed a ranking that pushes those companies down.
Weight the recent change over the lifetime total. The association appeared right after engagement began, and engagement typically came about five months before the round. A company that started working with outside code in the last two quarters is the case worth a look; one with years of steady activity is already known to anyone watching.
Link on the domain and check the link. The researchers matched accounts to companies through the website on the GitHub organization, which is the same key most firms already use for company records. A wrong match is the quiet failure: a record shows lively engagement that belongs to a different company with a similar name. The check is whether the domain on the organization matches the domain on the record, and the field should say which one was used.
Stay at the level of the organization. The study worked with company accounts. Tracking individual developers is a different decision with different obligations, and I would keep it out of scope unless the firm makes that decision deliberately.
Proposal
How I would build it and prove it
The data is public. GH Archive publishes the public GitHub timeline, hourly, back to February 2011, as downloadable files and as a public BigQuery dataset. The GitHub API returns the website on each organization. A small scheduled job can resolve organizations to domains, count outside-repository events per organization per quarter, and write one field to the company record with a link to the underlying events. That is a build a small team can own, and the full cost of owning it should be written down before it starts.
If a data vendor already supplies a GitHub number, ask three questions before trusting it. Which event types feed it? Do stars or documentation edits count? How are accounts linked to companies, and can the firm see the link? A number that cannot answer those is a number the team should not sort by.
Before anyone relies on it, test it against the firm's own history. Take the companies the firm met over the past two or three years. For those with a linked organization, check whether a rise in outside engagement came before their first round, and whether the team would have met them earlier had the field existed. If the lookback would not have changed a single decision, the field is decoration.
Place it in the workflow as a prompt to look, not a score. It appears on the record with its evidence, its date, and its link method. It is reviewed on the same cadence as the rest of the pipeline, and it has an owner who can explain any value it shows.
Proposal
What I would test next
I would run the lookback before building anything. A few hours with the firm's past first meetings and the public archive will show whether engagement moved ahead of the rounds the firm cared about, how many companies have any record at all, and how often the domain link is wrong. Those three numbers decide whether the field is worth a pipeline.
Open question
Does the pattern survive AI coding tools?
The study's data ends before AI coding assistants became part of how many startups build, and the authors already note that package-manager use is invisible to their measure. If teams now draw on outside code through a model rather than a fork, the public event the paper counted may become rarer while the underlying behavior continues. I do not know whether that weakens the signal or only moves it. The firm's lookback, run each year, is the cheapest way I know to find out.