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.

After receiving a steady stream of questions from open source enthusiasts about Google Summer of Code, I decided it would be more useful to write one comprehensive guide than to keep answering the same things individually. This is that guide, covering both open source generally and GSoC specifically.

Allow me to introduce myself first, so you know where the advice is coming from. I am an open source enthusiast who has contributed to numerous projects since 2018. On the strength of those contributions I was honoured with the Google Open Source Peer Bonus (opens in a new tab) award in 2022, which is granted to external individuals who have made remarkable contributions to the world of open source.

I have had the pleasure of taking part in several open source programs:

Before delving into the details of the program, it is worth taking a moment to understand the significance of open source software and why it matters in the first place.

What is open source?

Open source refers to software whose source code is made available to the public. Anyone can view it, modify it, and distribute it. Open source software is typically created and maintained collaboratively by a community of developers rather than by a single company or organization.

The importance of open source lies in its ability to promote innovation, collaboration, and transparency. By allowing anyone to read and change the code, open source encourages a decentralized approach to development in which ideas and contributions are shared freely. That tends to produce better and more reliable software, and it democratizes access to technology in a way closed development cannot.

The benefits of joining the open source movement are abundant and significant, but one stands above the rest: the opportunity to collaborate with a real community. The value is not in the single pull request you land — it comes from ongoing participation and from helping carry a project forward over time. Working alongside mentors, and drawing on the resources and guidance they provide, is one of the strongest motivators there is for getting involved and continuing to contribute.

It is worth being concrete about why that matters, because it is easy to underrate. The code being readable is the least interesting part of open source. What matters is that a working community is attached to it — people who will review your work, argue with your design, and tell you plainly when you are wrong. That feedback loop is difficult to obtain any other way early in a career. You can read every book on the shelf; you cannot simulate someone senior explaining why your pull request will not survive contact with production traffic.

How to get started with open source?

If you are new to open source software development, participating in GSoC can be an excellent way in, even with no prior experience. The first step is to choose a programming language you are interested in learning or already have some familiarity with. Once you have settled on a language, look for a project that aligns with your interests.

There are numerous organizations you can contribute to, and the GSoC archive is an excellent starting point, since it lists organizations that have participated in the program in the past. One effective approach is to browse those organizations and choose one based on the type of end product that excites you rather than the specific technology stack they happen to use. Enthusiasm for the problem will carry you further than familiarity with the language.

Once you have selected an organization, take time to explore it in more detail. Most organizations publish instructions on how to get started, and it is essential to follow those guidelines carefully — they exist because maintainers have answered the same setup questions many times. If you need background on a particular concept, a search will usually turn up what you need.

At this stage, try to fix a simple bug or implement a straightforward feature. These initial steps are often the most challenging part of the entire journey, and it is crucial to remain persistent. Once you have gained some confidence, you can begin contributing to more complex issues and start working across other projects. The key to success in open source development is a willingness to learn, to collaborate, and to persevere when the first attempt does not land.

With that groundwork in place, let us return to the main subject of this guide.

What is GSoC?

Google Summer of Code is a global, online program focused on bringing new contributors into open source software development.

Google created GSoC to encourage and support the growth of open source. The program connects talented and motivated contributors with open source organizations and mentors, giving contributors the opportunity to learn and contribute to real projects while gaining practical software development experience. In doing so, Google aims to foster innovation and collaboration within the open source community and to advance technology for everyone's benefit.

It is worth being precise about that design goal, because misreading it leads people to prepare for the wrong thing. GSoC exists to bring new contributors into open source communities. It is not a hiring pipeline, and it is not a competition to identify the strongest programmer in the applicant pool. The practical consequence is that mentors are not scoring you purely on technical brilliance. They are deciding whether they want to work with you for three months. Can you communicate clearly? Will you ask for help when you are stuck rather than disappearing for a fortnight?

Why should you participate in GSoC?

Participating in GSoC provides several concrete benefits.

It allows you to gain practical experience in software development and to work on real-world open source projects rather than tutorial exercises. You receive guidance and mentorship from experienced developers in the field, which is difficult to arrange on your own. The program also offers a stipend for your work, which can be a valuable source of income as well as recognition for your contribution to the community.

Beyond the immediate work, GSoC is an opportunity to network with other developers, gain exposure to technologies you would not otherwise touch, and in many cases open the door to future employment. Maintainers talk to each other, and a contributor who was reliable for three months is remembered.

What prerequisites are required to participate in GSoC?

Getting started with GSoC can be daunting, especially if you are new to the program. However, you do not need a long list of skills to participate — what you need is enthusiasm and the dedication to see a project through. Every project is unique and requires different skills, and more often than not those are things you learn as you start working rather than beforehand.

When starting out, it is crucial to find projects that genuinely align with your interests. Bear in mind that organizations vary considerably: some are set up to teach and are very supportive of candidates building the necessary skills, while others have stricter expectations and will assume you already know their stack. That difference matters more than the technology on the page.

In addition to finding the right project, it helps to have some basic knowledge of version control systems and enough programming ability to read an unfamiliar codebase without panicking. This will let you understand the technical aspects of your project much faster.

Finally, and most importantly, check the eligibility criteria before you invest time in a project, because no amount of preparation survives being ineligible. The Google Summer of Code Program Rules (opens in a new tab) are the authority on this.

How to get started with GSoC?

There is no single definitive answer to this question, but there are several concrete steps where you can assert yourself.

  1. Research participating organizations. Take time to research the organizations that participate in GSoC and identify those that align with your interests and skills. You can browse the list of participating organizations on the GSoC website, and the archive (opens in a new tab) shows who has taken part in previous years.
  2. Identify potential projects. Once you have found organizations that interest you, look for the project ideas listed on their websites or GSoC pages. Consider which projects align with your skills and which ones you would actually enjoy working on for three months. Look at the ideas themselves rather than the organization's reputation — a famous infrastructure organization may well be advertising a documentation site rebuild, which is web development, not distributed systems. The name on the page tells you very little about the work.
  3. Reach out to mentors. After identifying potential projects, contact the mentors to introduce yourself and express your interest. Use their preferred communication channels, whether that is a mailing list, chat, or email. Ask about scope, and ask what they think the hard part will be.
  4. Start contributing. Before submitting a proposal, start contributing to the project. Look for open issues labelled "good first issue" or "beginner-friendly" and submit pull requests with fixes or small features. This helps you get familiar with the codebase and establishes a relationship with the mentors and the wider community. This is the step people skip, and it is the one that matters most — by the time your proposal is read, the mentor should already recognise your name.
  5. Write a strong proposal. Once you have contributed and established a relationship with the mentors, write your proposal. It should clearly articulate your understanding of the project, your proposed solution, and your timeline for completing the work.
  6. Submit your proposal. Submit through the GSoC website during the application period. Follow the guidelines and include all the required information — and submit before the deadline rather than on it.
  7. Wait for acceptance. After submitting, wait for the organization to review your proposal. If accepted, you will receive further instructions on how to proceed. Keep contributing while you wait.
  8. Participate. Once you are accepted, start collaborating with your mentor and contributing to the project in earnest. Keep track of deadlines and maintain regular communication. If you have questions or concerns, do not hesitate to raise them with your mentor or the organization's administrators. And if you are not accepted, do not be discouraged — you can try again next year, and in the meantime you can continue contributing and sharpening your skills.

How to write a good proposal for GSoC?

Writing a good proposal is essential to increasing your chances of being selected. A good proposal clearly communicates your understanding of the project, your qualifications for it, and your plan for completing the work. Mentors read a great many of these, and most of them blur together. Here is what separates the ones that do not:

  1. Conduct thorough research. Before drafting, study the project properly. Understand its objectives, features, and functions. Familiarize yourself with the codebase and documentation so that you understand its structure and workflow.
  2. Express your comprehension. Articulate your understanding of the project in your own words. State your interest, explain how you can contribute, and emphasize the skills or experience that make you a good fit.
  3. Outline your strategy. Detail your plan for completing the work, broken into smaller tasks with estimated timeframes. Provide a realistic timeline with milestones and deliverables, and account for potential obstacles. Break it down by week rather than by month, and leave slack in it — a schedule with no buffer signals to the reader that you have not done this before.
  4. Demonstrate your skills. Showcase your qualifications with relevant code samples or previous projects that prove you can contribute effectively.
  5. Maintain professionalism. Use a professional tone, correct grammar, and clean formatting so the proposal is easy to read. Headers, short paragraphs, and code where code helps. A wall of text is exhausting to review, and yours is not the only one being read that evening.
  6. Participate in the community. Engage with the community and contribute to the project before you write the proposal. This demonstrates genuine interest and commitment far more convincingly than any paragraph claiming it.
  7. Seek guidance. Do not hesitate to ask questions about the project or the application process. Asking well shows that you are proactive rather than that you are uninformed.
  8. Provide concrete details. Be specific. "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 actually evaluate.
  9. Inject creativity. Make the proposal engaging through clear language and well-chosen examples so that it stands out from the pile.
  10. End with a strong conclusion. Summarize your qualifications and leave the mentors convinced of your commitment to the project's success.
  11. Incorporate code snippets. Use snippets to demonstrate your programming ability and your understanding of the existing codebase.
  12. Justify your ideas. Explain the reasoning behind the features or changes you propose. 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.
  13. Display your research. Present the independent research you have done on new features or changes, showing that you have considered existing solutions and alternatives.
  14. Divide large tasks. Break extensive work into smaller, manageable pieces. This makes the proposal easier to assess and demonstrates attention to detail.
  15. Embrace feedback. Be receptive to mentor suggestions and incorporate their input. Willingness to revise is itself a signal about what you will be like to work with.

One further point worth adding: name the risks. Saying what could go wrong, and how you would handle it, reads as maturity. Pretending that nothing will go wrong reads as inexperience.

These tips are not hard rules, but they will improve your chances of being selected and of contributing meaningfully once you are.

If it does not work out

Far more people apply than there are slots, so a great many good candidates are turned down each year. That is worth saying plainly, because being rejected is the common case rather than a verdict on your ability.

Nothing you did to prepare is wasted. You learned a codebase, made real contributions, and got to know maintainers who now recognise your name. None of that was contingent on being selected, and all of it carries forward. A fair number of the people I know who eventually got in had been rejected the year before.

Resources for GSoC

I have contributed to several open source programs, and the following repositories may be useful as references. They contain project proposals, project reports, and the work itself:

A worked example of an accepted proposal is often more useful than any amount of advice about proposals, so these are there to be read and borrowed from. Beyond them, plenty of other references and resources are easy to find online.

Conclusion

Please note that the above are my personal thoughts and perspectives on open source and GSoC, and they are not the whole story. There are numerous routes into open source and this is simply the one I took. I have done my best to explain the program and how to begin with it, and I hope you found it useful.

It is worth remembering that whether you pass or fail in your participation, you will always come away with something valuable. Open source projects are excellent learning environments, and GSoC in particular develops a wide range of skills — coding, yes, but also communication, planning, and collaboration. Regardless of the outcome, it is worth staying positive about what you learned and achieved. With an open mind, a willingness to learn, and some persistence, you can keep growing as a developer and as a contributor.

I will write more articles about open source programs, including my own experiences participating in them. Those will go into the technical detail of the projects — the problems, the challenges, and how I worked through them.

If you are waiting to feel ready before you start, that feeling does not arrive. Pick a project and open something small.

Good luck on your journey toward becoming a successful open source contributor.

References