# GitHub contributor lists are an early startup hiring pool > Pedigree and incoming applications gave me weak signals, so I started sourcing early startup hires from open-source contributors and people I already knew. - Source: https://jays.fyi/blog/github-contributor-lists-are-an-early-startup-hiring-pool - Author: Jay Derinbogaz - Published: 2026-08-10 - Language: en - Tags: startups, hiring, open-source - Reading time: 7 min --- TextCortex began with my attempts to fine-tune GPT-2 for useful creative writing. That work became the product's technical starting point. In 2021, I met Dominik Lambersy at Entrepreneur First in Berlin. We turned the work into TextCortex AI and bootstrapped the company until our first institutional round. The [announcement from June 2022](https://textcortex.com/post/democratizing-written-communication-textcortex-raises-1-2-million-pre-seed-to-advance-proprietary-nlg-capabilities-and-launch-chrome-extension) records $1.2 million led by btov Partners, now b2venture, with Speedinvest and Entrepreneur First participating. Before the round, recruiting took hours from the product, customers and whatever had broken that morning. Funding changed the bank account faster than the job. I treated famous employers as a proxy for startup range. I expected academic depth to transfer into product chaos. Then I worked through ATS applications while urgent work arrived from every other direction. My sample is one company, without a controlled experiment or conversion table. The filter I trust is simple: **look for people who chose a useful problem, worked on it in public and kept going without a manager assigning it.** Contributors provide that evidence before the first interview. Former colleagues can provide it too. ## A famous logo measures success inside somebody else's machine A Google or Amazon badge says the person cleared a hard hiring process and learned to operate at scale. It says little about what happens when the machinery around them disappears. An early engineer can touch the frontend before lunch, trace an infrastructure failure in the afternoon, repair a migration and answer a customer. With no platform team or written process, somebody has to notice the gap and own it. Some former big-tech employees are exceptional startup hires. The logo cannot identify them. I made the same category error with PhDs. A doctorate proves somebody can finish difficult research in a narrow area. Could this person turn an incomplete complaint into a product decision and ship the repair? Could they abandon a beautiful approach when the cheap one would keep the company alive? My experience with PhD hiring is small and bad, so the claim stays narrow. I no longer award startup readiness for the credential. Maintaining a library, shipping side projects or working across a product stack supplies better evidence. ## Your ATS flattens the most useful signal ATS applications place the founder inside a queue where candidates have learned to look alike. Keywords and compressed outcomes replace the repository, review discussion and messy decisions that reveal ownership. A bootstrapped startup cannot inspect every patch of sky. You choose where to look. An ATS starts with people who selected your company. Contributor research starts with work that selected its author. ## Open-source work leaves the receipts A contribution is much richer than a green square on a profile. The commit shows what the person changed. The pull request shows how they explained it. The review shows how they reacted when somebody disagreed. The issue history shows whether they helped after the exciting part was merged. Nobody assigned an external contributor your company's exact problem. They found a project, learned enough to change it and accepted that a maintainer might reject the work in public. A thoughtful rejected pull request can reveal as much about judgment and response to feedback as a merged one. ## The dependency graph already contains a candidate map Start with the software your company uses. Building with an open-source component library? Inspect its contributors. Working with PyTorch? Look at the people improving the parts adjacent to your product. A famous repository creates the same pedigree trap as a famous employer when you chase the name and ignore the work.
GitHub sidebar for shadcn/ui showing Used by 24K and 607 contributors.
GitHub displayed 607 contributors and “Used by 24K” for shadcn/ui on 10 August 2026. A component-library contributor list is a practical place to begin a frontend search.
That screenshot contains a hiring pool an ATS cannot manufacture. Read the contributions. Find changes resembling the problems your company has. Check whether the work is recent and whether the profile invites contact. Then write to the few people whose work you can describe honestly. The first message should prove that you did the reading: > I read your contribution to [project], especially the decision you made in > [specific pull request]. We are dealing with a related problem at [company]. > The role covers [actual scope], and the cash and equity ranges are [ranges]. > If that sounds interesting, I would like to show you the problem and hear how > you would approach it. It explains why this person, exposes the scope and puts compensation in the open. A shoestring budget is a company constraint. It gives you no permission to waste a candidate's time or disguise weak cash with heroic language. ## A research prompt is only useful when it returns the work Give either model a narrow brief and demand links. Replace every bracketed field. **Claude:** ```text Research contributors for [ROLE] at [COMPANY, URL]. We build [PRODUCT] with [STACK] and need help with [3 CONCRETE PROBLEMS]. Search [REPOSITORY URL], its dependencies and adjacent projects. Return at most six people. For each, link a profile and two relevant commits, pull requests, reviews or issues. Explain the technical match, judgment shown, recency and uncertainty. Prefer substance over commit counts. Use only public professional information. Never infer protected traits, guess contact details or invent evidence. ``` **ChatGPT:** ```text Research a [ROLE] for [COMPANY, URL] working on [PROJECT AND PROBLEMS]. Search [REPOSITORY URL], its dependencies and related projects. Return at most six contributors in a table: profile, contribution links, problem ownership, response to review, recency, fit and caveats. Every judgment must cite public work I can open. Exclude prolific but weak matches. Do not scrape personal data or draft bulk outreach. Give me one specific question about each person's work. ``` ## Bulk outreach destroys the signal you came for Scraping every contributor and turning the graph into another funnel is the obvious shortcut. Do not do it. GitHub's [Acceptable Use Policy](https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies) explicitly bars using information obtained from the service for spam, including unsolicited email, and calls out recruiters, headhunters and job boards. It is also bad hiring. Specificity creates the advantage. Automation deletes it and leaves the same flat queue, except now you have interrupted people who never applied. Use the graph for discovery, follow the contact route a contributor published, make declining easy and stop after a clear lack of interest. The smaller list is the feature. ## Friends come with a long reference check People you know supply evidence no interview loop can recreate. You have seen whether they finish boring work, handle conflict and warn you early. Friendship still does not establish role clarity, appetite for risk or agreement about cash and equity. Put those in writing. Explain the ugly parts with the same care you use for the mission. Show them the actual problem rather than making the company sound safer than it is. Use the same standard in interviews. Ask candidates to walk through work they chose, then give them a real problem with confidential details removed. Watch what they ask and how they handle an incomplete specification. High agency includes asking for help before a problem gets expensive. ## Cheap sourcing cannot rescue a careless filter Public contribution has its own bias. It favours people with time, permission and confidence to work where strangers can judge them. Excellent engineers with caregiving duties, restrictive employment contracts or closed-source careers may leave no public trail. Use public work as a high-signal source. Its absence proves nothing. Decide what the job demands and write down the evidence that predicts those behaviours. After the hire has done real work, compare the prediction with what happened. If contributor candidates need as much direction as ATS candidates, your theory failed. Change the filter. I cannot show you a table proving that contributors beat former Googlers, PhDs or applicants. I can show the filter that survived my mistakes. A brand told me where somebody succeeded. A degree told me what they studied. An application told me how they described themselves. Public work showed me what they chose, what they shipped and what happened when another person pushed back. On a shoestring budget, certainty is unavailable. Evidence is cheaper than a bad hire, and it is already sitting in the dependency graph.