I first wrote about Google Summer of Code in 2023 as a simple guide, nothing fancy. Then something interesting happened. People started reaching out with questions, feedback, things I had got wrong, and areas I should expand on. So I rewrote it. More feedback came in. More changes followed. And now here we are, writing it once again. It is a good illustration of how even a single post keeps evolving over time.

That is the thing about sharing knowledge — it is never really finished. Every version gets a little better because the people who read it help make it better. This post exists because of all those messages, comments, and corrections over the years. So if you read this and think I have missed something important, tell me. It may well end up in the next version.

NOTE

This guide might not cover everything, and I am sure I have missed something. But if it helps even one person take their first step into open source, that is enough for me.

Quick background if you do not know me. I have been in the open source space since 2018. I did Google Season of Docs twice, in 2020 and 2021, then LFX Mentorship, then GSoC 2022 as a contributor with Keptn, and I have been mentoring Jenkins projects since 2023. I also received the Google Open Source Peer Bonus award in 2022, which was unexpected but pretty cool. Both sides of the table, in other words, which is mostly what changed my mind about how selection works.

Anyway, let us get into it.

What the program is actually for

I see a lot of confusion about this. People treat GSoC like it is an exam or a competition where the best coder wins.

It is not, and the misreading is expensive.

GSoC exists for one reason: to bring new contributors into open source communities. That is it. Google is not running a hiring pipeline and they are not looking for rockstar developers. The whole point is to help beginners become part of the open source ecosystem and, ideally, to stick around long after the program ends. The measure of a successful project is not the code — it is whether the contributor is still there in November.

This changes everything about how you should approach it.

You are not trying to prove you are the smartest person in the room. You are trying to show that you can learn, collaborate, and become a valuable community member. Mentors are not grading you on technical brilliance. 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 communicate well? Will they ask questions when they are stuck instead of disappearing in week six?

The psychology here matters more than people expect. If you go in thinking "I need to impress everyone with my skills," you will come across as someone who mainly wants the stipend and the line on their CV. If you go in thinking "I want to learn and contribute to something meaningful," that authenticity shows — and it shows from the very first email.

Every successful GSoC contributor I know approached it as a learning opportunity first, not a competition to win.

What changed for 2026

A few things are different this year.

Timeline shifts

Organization applications open January 19 and close February 3, with accepted organizations announced February 19. Contributor applications run March 16 to March 31. Results land April 30. Coding kicks off May 25.

Focus areas

Google is pushing AI/ML, security, and cloud projects hard this year. If you have skills in any of those areas, you will find more opportunities than usual.

The AI policy situation

This is the big one. Many organizations now explicitly ban AI-generated proposals. Joomla, Plone, and the Processing Foundation, among others, will reject your application outright if it reads like ChatGPT wrote it. Others permit AI as a writing aid but want the ideas to be yours. Check each organization's policy before you apply, 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, and no evidence that anyone actually read the codebase.

Country restrictions

This is important and people miss it. You cannot participate while residing in Russia, Belarus, or the Donetsk and Luhansk regions. You also cannot participate from any country currently under United States embargo. Contributors elsewhere in Ukraine are eligible. Check the official rules if your situation is at all unclear.

Eligibility stays the same

You need to be 18 or older, new to open source, and you can only have been accepted to GSoC once before. You no longer need to be a student — that changed back in 2022. Self-taught developers, career switchers, and anyone new to open source can apply.

The full picture

Let me break down the entire process so you know exactly what you are getting into.

Step 1 — Understand the ecosystem. GSoC connects three groups: Google, who runs and funds the program; mentoring organizations, which are the open source projects themselves; and contributors, which is you. Organizations apply to Google first. If accepted, they post project ideas. Contributors then apply to work on those ideas.

Step 2 — Find organizations and ideas. Once organizations are announced, on February 19 for 2026, browse the list on the GSoC site. Each organization has a page with its project ideas, its technology stack, and its communication channels.

Step 3 — Start contributing and talking. Before applications open, join the organization's community. Introduce yourself. Ask questions. Make contributions. Build relationships with potential mentors. This step is doing most of the work.

Step 4 — Write and submit your proposal. During the application window, March 16 to 31, submit through the GSoC website. You can submit up to three proposals to different projects, but only one can be accepted.

Step 5 — Wait for results. Google and the mentors review proposals. Accepted contributors are announced on April 30.

Step 6 — Community bonding. If you are accepted, you spend a few weeks getting familiar with the codebase, setting milestones with your mentor, and preparing to write code.

Step 7 — Coding period. You spend twelve or more weeks — anywhere from eight to twenty-two, depending on project size — working on your project with mentor guidance. There is a midterm evaluation and a final evaluation.

Step 8 — Completion. Submit your work, get evaluated, receive your stipend, and ideally carry on contributing to the project afterwards.

Focus on ideas, not organization names

This is where so many people go wrong, and it costs them the entire application cycle.

Someone sees Kubernetes or Apache or Mozilla on the organization list and immediately thinks "that is too advanced for me" or "I would need to know everything about container orchestration." Others see a name they recognize and apply without reading what the work involves.

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

Stop and look at the actual project ideas. A Kubernetes organization might have an idea about improving their documentation website — that is web development, not cluster management. A machine learning organization might need help building a dashboard, which is frontend work. A database project might want someone to write tutorials, which is technical writing.

The organization name tells you almost nothing about what you will actually work on.

I have seen people panic because they assumed applying to a cloud-native organization meant they needed deep infrastructure knowledge. Then they looked at the ideas and found things like "build a React component for the contributor portal" or "create automated testing for our Python SDK."

Always look at the specific project idea first. Read the description. Check which skills are actually needed. Talk to the mentor about the scope.

Some of the best GSoC experiences come from contributors who picked an idea matching their skills inside an organization they had never heard of, rather than chasing a famous name attached to an idea that did not fit.

The uncomfortable truth about selection

Here is something most guides will not tell you. A lot of genuinely good developers get rejected every year — not because they cannot code, but because they picked the wrong organization or wrote a mediocre proposal.

I have seen this pattern over and over.

Someone discovers GSoC in late February. They panic-apply to five or six random organizations. They copy-paste a generic proposal. They get rejected. They post online asking what went wrong.

Meanwhile, someone with less coding experience but a better strategy gets accepted, because they started contributing in December, built relationships with mentors before applications opened, and wrote a proposal showing they understood the project's actual problems.

The second person wins, and it is not close. Selection is not about being the smartest person in the room. It is about showing up consistently and proving you can collaborate.

How to pick an organization, the smart way

Forget chasing big names. Mozilla and Apache look great on a CV, but they are also brutally competitive and receive hundreds of applications. Here is what I would do instead.

Look at participation history. Organizations that have been in GSoC for five or more years usually have their process figured out. They know how to mentor beginners. The archive (opens in a new tab) shows you who they are.

Check their communication channels. Join their Slack, Discord, or Matrix before you commit, and lurk for a week. Are mentors active? Do they respond to questions? Some organizations have channels that are effectively dead, and a dead channel in February will still be dead in July — you will be on your own.

Match your technology stack. If you are a Python developer, do not apply to a C++ project just because it sounds interesting. You will spend half your summer learning the language instead of building the feature.

Look at project idea scope. Some organizations post ideas that are far too ambitious for twelve weeks. Others post work that is trivial. You want something challenging but achievable — something you can finish, but would not finish in a fortnight.

Ask yourself whether you would contribute here even without GSoC. If the answer is no, pick a different organization. Mentors can tell when someone is only there for the stipend.

What contribution actually means

Here is something people get wrong, and it needlessly narrows what they think they are allowed to do. Contributions are not just code patches.

Fixing bugs and adding features counts, certainly. But so does everything else.

Participating in discussions. Joining a GitHub discussion about an architecture decision. Sharing your perspective on a proposed feature. Asking thoughtful questions about why something works the way it does. This shows you are engaged with the project's direction rather than looking for quick wins.

Reviewing other people's work. Reading through open pull requests and leaving constructive comments. You do not need to be an expert. Even "I tested this locally and it works" or "this part confused me, maybe add a comment?" is valuable.

Improving documentation. Updating outdated READMEs. Adding examples to API docs. Writing tutorials for beginners. Documentation is chronically neglected in most projects, and maintainers genuinely appreciate the help.

Answering questions. Helping newer contributors in chat channels. If someone asks about something you figured out last week, share what you learned. This is how communities grow.

Filing detailed bug reports. Found something broken? Do not just say "it does not work." Explain what you expected, what happened, the steps to reproduce it, and your environment. A good bug report saves maintainers hours.

Proposing ideas. Have a thought about how something could be better? Open a discussion. You might be wrong, and that is fine — the conversation itself is a contribution.

The point is that contribution means participating in the community in whatever way feels natural to you. Some people love diving into code immediately. Others prefer to understand the big picture first through discussions. Both are valid.

The real learning happens when you engage authentically, not when you are grinding through issues purely to pad your profile. That is obvious to everyone watching, and it teaches you nothing.

Writing a proposal that does not get ignored

Mentors read dozens of proposals and most of them blur together. Here is how to stand out.

Talk to mentors first. Before you write anything, reach out. Ask questions about the project idea. Clarify the scope. Get their input on your approach. Ask what they think the hard part will be. Proposals from people who never spoke to the organization get deprioritized.

Be specific about what you will build. "I will improve the documentation" is weak. "I will restructure the API reference into three sections, add fifteen code examples, and create a migration guide for v2 users" is strong, and it is something a reviewer can actually evaluate.

Break down your timeline week by week. Not month by month — week by week. Include buffer time for unexpected problems. A schedule with no slack tells the reader you have not shipped anything to a deadline before.

Address potential problems. What could go wrong, and how will you handle it? Naming a risk reads as maturity. Pretending nothing will go wrong reads as inexperience.

Include your contributions. Link your pull requests, issues, discussions, and community interactions. Make it trivial for a reviewer to see your track record rather than making them search for it.

Keep it readable. Use headers, bullet points, and short paragraphs. A wall of text is exhausting to review, and yours is not the only proposal they are reading that evening.

Do not use AI to write it. Seriously. Mentors can tell. The phrasing is too polished, too generic, too even. It is a fast track to rejection.

A timeline for sensible preparation

If you are reading this in January 2026, you are a little late but not too late.

Now through February 19, when organizations are announced. Research organizations from last year's archive. Start contributing to two or three you might apply to. Join their communication channels and introduce yourself.

February 19 to March 16, the discussion period. Review the official project ideas now that they are published. Talk to mentors about the ones that interest you. Draft your proposal and get feedback on it.

March 16 to March 31, the application window. Submit early rather than on the last day. Incorporate whatever feedback your mentor gave you. Keep contributing while the window is open.

April 30, results. If you are accepted, celebrate and start community bonding properly. If you are rejected, keep contributing anyway and try again next year.

Common mistakes I have seen

Starting too late. The people who get accepted usually start four to six months before applications open.

Applying to too many organizations. You can submit up to three proposals. That does not mean you should. One excellent proposal beats three mediocre ones.

Not talking to mentors. Your proposal should not be a surprise to them. By the time you submit, they should already know who you are.

Copy-pasting from past proposals. Mentors have seen the old proposals. They will notice.

Ignoring organization-specific guidelines. Some organizations have templates, word limits, or required sections. Following them is free.

Disappearing after getting accepted. Community bonding matters. It is part of the program, not a break before it starts.

Only contributing code. Discussions, reviews, documentation, and community help all count. Do not ignore them.

Judging organizations by name instead of ideas. That intimidating organization might have beginner-friendly projects; that approachable one might have impossible ideas. Look at the actual work.

What if you do not get selected?

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

The good news is that everything you did to prepare is still valuable. You learned a new codebase. You contributed to open source. You built relationships with maintainers who now recognize your name. None of that evaporates on April 30.

Many successful GSoC contributors were rejected the first time. They kept contributing, improved their proposals, and got in the following year.

It is also worth knowing that some organizations hire contributors directly, with no GSoC involved at all. Your contributions might lead to freelance work, an internship, or a full-time offer. I have seen it happen more than once.

Conclusion

GSoC is not magic. It is not about being a genius programmer. It is about showing up, contributing consistently, and demonstrating that you can work with a team.

Remember that the program exists to bring new people into open source. That is you. You do not need to already be an expert. You need to be willing to learn, to communicate openly, and to become part of a community.

The stipend is nice. The experience is better. The connections you make can genuinely change the direction of your career.

If you are reading this and thinking "I do not know if I am good enough," you probably are. The bar is not as high as you think and the work is more ordinary than you expect. What matters is putting in the work.

Start now. Pick an organization. Look at the ideas, not just the name. Make your first contribution this week and see where it goes.

References