Google Summer of Code logo

NOTE

This is the 2023 version. I have since rewritten it with three more years of mentoring behind me — see Google Summer of Code 2026 for the current guide, including the 2026 timeline, the new AI policy, and what I have learned about how selection actually works. This post is kept as it was written.

Enough people asked me about Google Summer of Code that writing it down once seemed better than answering the same questions individually.

For context: I have contributed to open source since 2018, and was given a Google Open Source Peer Bonus (opens in a new tab) in 2022. The programs I have been through are:

What open source actually gets you

The code being readable is the least interesting part. What matters is that a working community is attached to it — people who will review your work, argue with your design, and tell you when you are wrong.

That feedback loop is difficult to get any other way early in a career. You can read all the books you like; you cannot simulate someone senior explaining why your pull request will not work at scale.

What GSoC is for

Google Summer of Code exists to bring new contributors into open source communities. That is the whole design goal.

It is not a hiring pipeline and it is not a competition for the strongest programmer. Reading it as either one will lead you to prepare for the wrong thing.

The practical consequence: mentors are not scoring you on technical brilliance. They are deciding whether they want to work with you for three months. Can you communicate? Will you ask when you are stuck instead of vanishing for two weeks?

What you actually need

Less than you think. There is no skill checklist. Projects differ enormously, and most of what you need you will learn while doing the work rather than before it.

Two things genuinely help beforehand: basic familiarity with version control, and enough programming to read an unfamiliar codebase without panicking.

The one thing you must check is eligibility, because no amount of preparation survives being ineligible. The program rules (opens in a new tab) are the authority.

Choosing where to apply

Organizations vary a lot in how much they will help a beginner. Some are set up to teach; others assume you already know their stack. That difference matters more than the technology.

Pick on the basis of what the project does, not the technology listed on the page. You will be more use to a project you find interesting, and it shows.

Then go and look at the actual project ideas rather than the organization's reputation. A famous infrastructure org may well be advertising a documentation site rebuild — which is web development, not distributed systems. The name on the page tells you almost nothing about the work.

The sequence that works

  1. Research organizations. The archive (opens in a new tab) shows who has participated before.
  2. Find specific ideas that match what you can actually do.
  3. Talk to mentors. Ask about scope. Ask what they think the hard part is.
  4. Contribute before you apply. Small fixes, documentation, reviews. This is the step people skip, and it is the one that matters most.
  5. Write the proposal.
  6. Submit before the deadline, not on it.
  7. Keep contributing while you wait.

Step 4 is doing most of the work. By the time your proposal is read, the mentor should already know your name.

Writing a proposal worth reading

Mentors read a lot of these, and most blur together. What separates the ones that do not:

Be specific about the deliverable. "I will improve the documentation" says nothing. "I will restructure the API reference into three sections, add fifteen worked examples, and write a migration guide for v2" is a plan someone can evaluate.

Break the timeline down by week, not by month, and leave slack in it. A schedule with no buffer tells the reader you have not done this before.

Say what could go wrong. Naming a risk and how you would handle it reads as maturity. Pretending nothing will go wrong reads as inexperience.

Link your contributions. Make it trivial for a reviewer to see what you have already done.

Keep it readable. Headers, short paragraphs, code where code helps. A wall of text is exhausting to review, and yours is not the only one they are reading that evening.

Explain your reasoning. Why this approach and not the obvious alternative? That question separates people who have thought about the problem from people who have only read the issue title.

If it does not work out

More people apply than there are slots, so plenty of good candidates are turned down. But nothing you did to prepare is wasted: you learned a codebase, made real contributions, and got to know maintainers. None of that is contingent on being selected.

A fair number of the people I know who got in had been rejected the year before.

Reference

The proposals and reports from my own programs are in GSoD-2020 (opens in a new tab), GSoD-2021 (opens in a new tab), LFX-2021 (opens in a new tab), and GSoC-2022 (opens in a new tab) if a worked example is useful.

These are my own views and not the whole story — there are many ways into open source and this is only the one I took. But if you are waiting to feel ready before you start, that feeling does not arrive. Pick a project and open something small.