How recommendations work

orgs, recommend, repos, issues, and ideas all try to answer one question: where can this person start contributing, given what they know, what they care about, how much open source they have done, and how many hours they have? This page explains how the answer is built, what it never claims, and how well it works.

What you get

git-into-gsoc recommend --tech html,css --interests accessibility --experience new --hours 8 returns:

orgs gives the same fit, evidence, and caveats for a quick list. In an AI assistant, the gsoc_recommend_path and gsoc_search_orgs tools return the same fields.

Your words

You can type skills and interests in your own words. A small vocabulary, kept in matching/concepts.py, maps about 150 skills and subjects to the many ways people and organizations write them:

Short words that are also English words (go, c, r, react, spring) only count in tags and in what you type, never inside a description, unless they appear with their usual capital letter ("written in Go").

What we know about each organization

Three public sources describe each organization:

Source What it tells us How fresh
Its official GSoC listing (tags, categories, tagline, description) What the organization says it works on and with The latest official list, embedded and refreshed weekly
Its ideas page How many ideas, the difficulty and size each states, and the skills and subjects they name Read for every organization once a month and shipped as data/org_signals.json
Its GitHub repositories How many were pushed to in the last year, and their languages and topics Same monthly refresh

A tag the organization chose counts most. A word in its description, ideas page, or repositories counts less, and more when several sources agree. A subject that tags, ideas, and code all mention is central to an organization; a single tag may be a side interest. The ideas evidence always names its year ("listed as a skill in 9 of 12 2026 ideas"), because last year's page says what an organization works on even before the new one appears.

How fit is decided

Relevance decides the order:

  1. Interests. How well the organization's work covers each thing you care about. A match through a neighbouring subject (physics for astronomy) counts for less, and the evidence says so plainly: "Topic Astronomy and space: not named; the nearest is Physics". An umbrella subject such as "science" or "web" never stands in for a specific interest.
  2. Skills. A skill matches only itself or what it is part of: React counts where JavaScript is used, but Phoenix never counts because an organization does backend work, and C is not assembly. Skills are alternatives: someone who knows Python and R can work where either is used, so the best match counts most and covering more of them adds a little. A skill few organizations use (Julia, Kotlin) says more than one most use (Python), so rare skills weigh more, like inverse document frequency in search engines.
  3. Interests and skills count about equally, with a small bonus when both match.
  4. An organization named after something you asked for (The Rust Foundation, LLVM, Open Robotics) is that thing's home and gets a small lift when its other evidence agrees, except for people new to open source, for whom fit matters more than a flagship.
  5. An organization that lists many skills or subjects (a runtime for nine languages, an umbrella for dozens of projects) says less about each one than a focused organization does, so its matches count a little less, the way search engines discount very long documents.

Three things only break ties. Together they can move an organization by a fifth of its score, never past a clearly better match:

With several interests, the list is reordered a little so each interest appears near the top (maximal marginal relevance, Carbonell and Goldstein, 1998).

A fit is good only when the organization names at least one of your interests itself; a match only through a neighbouring subject is partial. It is strong only when two kinds of evidence (a tag and its description, ideas, or code) agree on the interest, and nothing decides against it: not when most of an organization's ideas need a language you did not list (it says "Most of its ideas need Fortran, which you did not list"), when its stated idea sizes cannot fit your hours, when most of its ideas are hard and you are new, or when your interest is so broad that it matches dozens of organizations.

The numeric match_score in JSON output only orders results. Please never present it, or the fit level, as a probability of anything.

When your words are broad

A broad word matches dozens of organizations: "ai" matches more than 90, and "python" alone more than 120. Then orgs and recommend add a tip with narrower words and how many organizations each matches, for example "LLMs and AI agents (29), Computer vision (11), Natural language processing (8)", or for a skill with no interest, the subjects the organizations that use it work on most. The JSON output has the same tips under sharpen.

Experience and hours

Set them once with profile --experience new|some|experienced --hours 10, or pass them to recommend. With profile --github USER and no --experience, the level is read from how many of your pull requests were merged in other people's repositories (none: new; 1 to 9: some; 10 or more: experienced), and the output says where it came from.

The coming year and last year

Google announces each year's organizations around February. Until then, orgs and recommend use the latest official list and say plainly that none of these organizations is confirmed for the coming year (official API, checked 2026-10-21: the 2027 program does not exist yet).

recommend (and orgs, for its top three) also reads what its top five organizations (three without a GitHub token) posted about the coming year, in their issue trackers and wiki home pages. One whose maintainers say it will not take part moves to the end with the post as its first caveat, and its issues are left out of the starter list. A maintainer post about the coming year becomes a readiness line. A name you search that took part in earlier years but is not on the current list gets an explanation instead of an empty table.

Who can apply

recommend ends with the facts that decide whether and where you can apply, quoted from the GSoC FAQ: you must be 18 or older when you register, and a student or a beginner to open source ("GSoC is not for experienced open source developers"; it says this to anyone who calls themselves experienced). For someone who lists only writing tools, it notes that GSoC projects are coding projects. When no 2026 organization uses one of your skills (Elixir, for example), it says so, because the results then rest on your other skills.

Repositories, issues, and ideas

How well it works

Two benchmarks in evals/ run offline against the embedded data: 34 personas with graded judgments from reviewers who never saw the ranking code, and 238 profiles written from real GSoC 2026 accepted projects, where the accepting organization is the answer. Each has a dev half, used while tuning, and a test half, checked only after tuning. On the test halves, agreement with the graded judgments (nDCG@10, where 1 is perfect) went from 0.643 with the keyword ranker this replaced to 0.810, and the accepting organization reaches the top five for 66% of profiles against 52% before. People unlike any earlier persona are where matching is weakest; evals/README.md has every table, the sealed holdout sets, and how to reproduce the numbers.

What independent reviewers found

Twice, a reviewer who never saw the code read the live recommend output for all 46 personas and graded it as a mentor would. Both times every output was honest: no chance of acceptance, the 2027 list never presented as confirmed, and the eligibility rules stated correctly. About 70% of the top three organizations were graded good or strong (a mean of about 2 out of 3), and the learning path was judged right for about two thirds of people. Their findings led to the stricter evidence, the screened starter issues, the eligibility notes, and the sitting-out flags described above.

Starter issues were then compared in blind pairs: for each of the 46 personas, a reviewer read the live thread of every issue in two lists without knowing which version made which, graded each issue good, ok, or bad for that person, and picked the list they would rather hand over. Against the version before the stricter screen, the current one kept the same number of good issues (8 against 8), cut bad ones from 26 to 8, cut the people handed a bad issue from 19 to 7, and was preferred for 19 people against 6 (21 ties). The price is that 9 more people get an empty list with a note on where to look instead. Two further rules were tested against the reviewers' grades and left out because they would have dropped good issues: skipping an issue that a merged pull request mentions (4 good, 13 ok, and 7 bad issues), and skipping one that several pull requests tried and failed (a single example).

repos was checked the same way: for 20 personas and their top organization, a reviewer read each suggested repository on GitHub. The first review graded 38 of 98 top-five repositories bad. A blind paired review of the old and new versions found good ones up from 29 to 35 and bad ones down from 34 to 27. 16 of 20 people now have a good repository first, against 14 before, and the reviewer preferred the new list for 8 people against 2 (10 ties). A small penalty for repositories in a language the person did not list was tried and left out: it dropped a C library a physicist could use, and brought in a logo repository. Reading recent outside merges for the top five was then compared the same way, by a third reviewer: it was a tie (28 good repositories in both, 36 bad against 38, preferred for 7 people against 8). It stays because it tells you, with the count, whether outsiders get work merged there, and it turns a list of quiet repositories into a pointer to the ideas page. The three reviewers also graded the same lists quite differently (28 to 35 good), so only comparisons made by one reviewer are meaningful.

The learning path was then reviewed the same way. A mentor graded every step of the 46 paths from a live run, and in the first review 8 of 46 paths were ones to hand over as they were. None said where GSoC was in its year, and none reached the application. The path now starts with the calendar. For anyone at 10 hours a week or less, it next works out which project size fits, with room to spare and the mentor's agreement named when it runs past the standard 12 weeks. It asks experienced people to check they are eligible, picks the repository that fits rather than the busiest, suggests a short tutorial for a missing skill, links an ideas page the tool could not read, and ends with past projects and a proposal draft. In a blind paired review of the old and new paths, the new ones were preferred for 44 of 46 people; 35 of 46 were ones to hand over as they were, against none before, and wrong steps fell from 10 to 3.

What the reviewers still found weak is listed next.

Known limits

Research this builds on

Source: docs/recommendations.md on GitHub. Corrections are welcome.