I first wrote about Google Summer of Code in 2023 as a plain guide. Then people started replying — questions, corrections, things I had got wrong, gaps worth filling. So I rewrote it. More feedback came in. This is the current version.

That is roughly how it should work. A post about a program that changes every year has no business staying still. If you read this and think I have missed something, tell me, and it will end up in the next one.

For context: I have been in open source since 2018. Google Season of Docs in 2020 and 2021, LFX Mentorship, GSoC 2022 as a contributor with Keptn, and mentoring Jenkins projects since 2023. Both sides of the table, in other words, which is mostly what changed my mind about how selection works.

What the program is for

There is a persistent belief that GSoC is a competition and the best programmer wins.

It is not, and the misreading is expensive.

GSoC exists to bring new contributors into open source communities. That is the stated goal and it is also, in my experience, how mentors actually behave. Google is not running a hiring pipeline. The measure of a successful project is not the code — it is whether the contributor is still around in November.

Which changes what you should be optimizing for. The question in a mentor's head is not is this the strongest candidate. It is can I work with this person for three months. Will they say when they are stuck? Will they disappear in week six?

Every contributor I have seen do well treated it as a chance to learn rather than a contest to win, and the difference is visible from the first email.

What changed for 2026

Timeline. Organizations apply January 19 to February 3 and are announced February 19. Contributor applications run March 16 to March 31. Results land April 30. Coding starts May 25.

Focus areas. Google is pushing AI/ML, security, and cloud projects this year, so there are more slots in those areas than usual.

AI-written proposals. This is the big one. A number of organizations — Joomla, Plone, and the Processing Foundation among them — now reject proposals that look machine-generated. Others permit AI as a writing aid but want the ideas to be yours. Check the policy of every org you apply to, because they are not uniform.

I will put this more bluntly than the official guidance does: mentors can tell. The register is wrong in a way that is hard to describe and easy to notice — uniformly confident, no specifics, no evidence anyone read the codebase.

Country restrictions. You cannot participate while residing in Russia, Belarus, the Donetsk or Luhansk regions, or any country under US embargo. Contributors elsewhere in Ukraine are eligible. Check the rules if your situation is unclear.

Eligibility is unchanged. Eighteen or over, new to open source, and accepted to GSoC at most once before. You have not needed to be a student since 2022 — career switchers and self-taught developers are eligible and always have been under the current rules.

How the whole thing runs

Three parties: Google funds and administers, organizations mentor, contributors do the work. Organizations apply first; the accepted ones publish project ideas; contributors then apply to those ideas.

From your side it goes: find organizations, find specific ideas, join the community and start contributing, write a proposal, submit it, wait. If accepted, there is a community bonding period to learn the codebase and agree milestones with your mentor, then twelve or more weeks of coding with a midterm and a final evaluation.

You may submit up to three proposals. Only one can be accepted.

Look at ideas, not organization names

This is where most people go wrong, and it costs them the whole application cycle.

Someone sees Kubernetes or Apache or Mozilla on the list and decides they are not good enough. Or they see a name they recognize and apply without reading what the work is.

Both are the same mistake: treating the organization name as information about the project.

A cloud-native org may be advertising a documentation site rebuild. A machine learning org may need a dashboard built. A database project may want tutorials written. None of those require what the organization's reputation suggests they require.

I have watched people talk themselves out of applying to an org because they assumed infrastructure knowledge was needed, when the actual idea was "build a React component for the contributor portal."

Read the idea. Read the required skills. Ask the mentor about scope. The name at the top of the page is nearly noise.

The uncomfortable part

Plenty of capable developers get rejected every year, and usually not for lack of ability.

The pattern I see repeatedly: someone discovers GSoC in late February, panic-applies to five organizations with a generic proposal, gets rejected, and posts asking what went wrong.

Meanwhile someone with less experience but better timing started contributing in December, was on first-name terms with two mentors before applications opened, and wrote a proposal that named a real problem in the project.

The second person wins, and it is not close. Selection rewards showing up consistently far more than it rewards raw skill.

Choosing an organization

Big names look good and are brutally competitive. Some suggestions that work better:

Check participation history. An org that has run GSoC for five or more years has a working mentoring process. The archive (opens in a new tab) shows you who.

Lurk in their chat for a week before committing. Are mentors answering questions? Is there any traffic at all? A dead channel in February will still be dead in July, and you will be on your own.

Match your actual stack. Applying to a C++ project as a Python developer means spending half the summer learning the language instead of building the thing.

Check the scope is sane. Some posted ideas are far too ambitious for twelve weeks; some are trivial. You want something you can finish but would not finish in a fortnight.

Ask whether you would contribute here without GSoC. If the answer is no, apply elsewhere. That one shows.

Contribution is not only code

A widespread misconception, and it narrows what people think they are allowed to do.

Patches count. So does everything else:

  • Joining design discussions — sharing a view on a proposed feature, asking why something works as it does. This shows you are engaged with where the project is going.
  • Reviewing pull requests — you do not need to be an expert. "I tested this locally and it works" is useful. So is "this part confused me, could it use a comment?"
  • Documentation — outdated READMEs, missing examples, absent tutorials. Chronically neglected nearly everywhere and genuinely appreciated.
  • Answering questions from people newer than you. If you solved it last week, say so.
  • Detailed bug reports — expected behaviour, actual behaviour, reproduction steps, environment. A good one saves a maintainer hours.
  • Proposing ideas, including ones that turn out to be wrong. The discussion is the contribution.

Pick whatever fits how you actually work. Some people read code first; others need the big picture before anything makes sense. Both are fine. What does not work is grinding through issues purely to inflate a contribution count — it is obvious, and it teaches you nothing.

Writing a proposal that gets read

Talk to the mentor before writing anything. Ask about scope, ask what they think is hard. A proposal from someone who never made contact starts at a disadvantage.

Be specific. "I will improve the documentation" is not a plan. "I will restructure the API reference into three sections, add fifteen worked examples, and write a v2 migration guide" is.

Timeline by week, not by month. With buffer. A schedule with no slack says you have not shipped anything on a deadline before.

Name the risks. What could go wrong and what you would do about it. This reads as experience.

Link your contributions — PRs, issues, discussions. Do not make a reviewer search for them.

Format it for a tired reader. Headers, bullets, short paragraphs. Yours is not the only proposal they are reading tonight.

Write it yourself. See above.

If you are reading this in January

Late, but not too late.

Now to February 19: research organizations in last year's archive. Start contributing to two or three. Join their channels and introduce yourself.

February 19 to March 16: the official ideas are out. Talk to mentors about the ones that fit. Draft the proposal and get feedback on it.

March 16 to March 31: submit early. Fold in whatever the mentor says. Keep contributing.

April 30: results. If accepted, start bonding properly. If not, keep contributing anyway — see below.

Mistakes I see every year

Starting too late. The people who get in usually began four to six months before applications opened.

Applying to all three slots. You can submit three. That does not mean you should. One good proposal beats three rushed ones.

Not talking to mentors. Your proposal should not be the first they hear of you.

Recycling old proposals. Mentors have read the old ones.

Ignoring org-specific templates. Some have required sections or word limits. Following them is free.

Going quiet after acceptance. Community bonding is part of the program, not a break before it.

Counting only code. Discussions, reviews, and docs are contributions.

Judging by name instead of idea. Covered above, and still the most common one.

If you do not get in

It happens to more applicants than not, simply because there are more applicants than slots.

Everything you did to prepare still stands. You learned a codebase, contributed to something real, and got to know maintainers who now recognize your name. That does not evaporate on April 30.

Many people who get in were rejected the year before. And some organizations hire contributors directly, GSoC or not — I have seen contributions turn into freelance work and full-time offers without the program involved at all.

Reference

GSoC is not magic and it does not require genius. It rewards showing up, contributing steadily, and being someone a stranger would willingly work with for three months.

The program exists for people who are not yet part of open source. That is the whole point of it. If you are reading this wondering whether you are good enough, the bar is lower than you think and the work is more ordinary than you expect.

Pick an org. Read the ideas, not the name. Open one small pull request this week.