How to Get Selected for Google Summer of Code: A Step-by-Step Guide

A practical guide on how to get selected in GSoC: choosing organisations, making first contributions, writing a strong GSoC proposal, and what to do next.

By InternHack Team · 2026-09-15 · 10 min read · Open Source

This guide is for Indian CS students who want to take part in Google Summer of Code (GSoC) but do not know where to begin. It walks through the full process in order: understanding the programme, picking an organisation, making your first contributions, working with mentors, writing the proposal, and planning for the case where you are not selected. There are no shortcuts here, only the steps that consistently separate selected applicants from the rest.

What GSoC is and how it works

Google Summer of Code is a global programme in which new contributors work on open source projects under the guidance of mentors. Open source organisations apply to take part, Google accepts a set of them, and then students and other beginners apply to those organisations with a project proposal. Selected contributors spend a defined period coding on their project, with mentors reviewing their work and evaluations along the way.

Two facts shape everything else:

• You apply to an organisation, not to Google in general. Each organisation publishes its own ideas list, expectations and contact channels. Selection is decided largely by the organisation's mentors.
• Eligibility and format change from year to year. Rules about who can apply, project sizes and durations, and the payment structure are set by Google and published on the official site. Read the current rules on the GSoC website instead of relying on older blog posts, including this one.

A general timeline

Exact dates change every year, so always check the official timeline. The general shape is:

The most important point in this table: the best preparation starts months before the application period. People who begin in March are competing against people who have been contributing since November.

Step 1: Build the prerequisites

You do not need to be an expert. You need to be able to work in a real codebase.

• Git and GitHub. Fork, clone, branch, commit, rebase, resolve conflicts, and open a pull request. If any of these terms are unfamiliar, practise them on a personal repository first.
• One or two languages well. Pick technologies that match the organisations you are considering. Python, JavaScript/TypeScript, Java, C++, Go and Rust all have active organisations.
• Reading code. Open source work is mostly reading, debugging and understanding existing code. Try reading the source of a library you use and tracing one function from start to end.
• Written communication. Mentors are often volunteers across time zones. Clear issue reports and polite, specific questions matter a lot.

If you are new to how open source interviews and discussions work, the open source interview guide covers common questions, and the open source section on InternHack helps you find projects to start with.

Step 2: Choose organisations carefully

Choosing well is half the battle. A popular organisation that receives hundreds of applications may accept only a few contributors, while a smaller one with active mentors may give you a much better chance and a better experience.

Use these filters:

1. Technology fit. Choose stacks you can already work in, or could become productive in within a few weeks.
2. Activity. Open the repository. Are pull requests being reviewed within days? Are there recent commits? A quiet repository means slow feedback.
3. Beginner friendliness. Look for labels such as "good first issue", a contributing guide, and a welcoming chat or mailing list.
4. Past participation. The GSoC archive shows which organisations took part earlier and what projects were completed. Read a few past proposals and final reports to understand the expected scope.
5. Ideas list quality. Good ideas lists describe expected outcomes, required skills and mentor names.

Shortlist three to five organisations and then focus on one or two. Spreading yourself across ten projects usually results in shallow contributions everywhere.

Note that you can submit more than one proposal in the application period, subject to the current rules, but each proposal needs the same depth of work. Quality of one strong proposal beats three rushed ones.

Step 3: Make your first contributions

Mentors want evidence that you can complete work and respond to feedback. Merged pull requests are the clearest evidence.

How to start

• Join the organisation's communication channel (chat, forum or mailing list) and read for a few days before speaking.
• Follow the setup guide, build the project locally and run its tests. If the setup fails, that is your first opportunity to report or fix documentation.
• Pick a small issue: a typo fix, a bug with clear reproduction steps, a missing test, or a documentation improvement. Comment on the issue to say you would like to work on it, unless the guide says otherwise.
• Submit a focused pull request that follows the project's style and contribution rules.
• Respond to review comments quickly and politely.

What counts as a good contribution

Quantity is not the point. A few well-reviewed pull requests that fix real problems beat twenty trivial whitespace changes. Try to progress from a tiny fix to something that touches the area of your proposed project, so that the mentor can see you understand it.

Also, avoid asking "can I work on this?" on every issue without doing anything, and avoid submitting AI-generated changes you do not understand. Mentors can tell, and being unable to explain your own patch is a quick way to lose trust.

Step 4: Communicate with mentors properly

Mentors decide whether they want to work with you for a whole summer. The way you communicate is part of your application.

• Ask in public channels rather than private messages unless the organisation says otherwise. Answers help others and show you are part of the community.
• Do your homework before asking. A good question includes what you tried, what you expected, the exact error, and links to the code. "It doesn't work, please help" gets ignored.
• Do not ping repeatedly. Wait a reasonable time, a couple of days, before following up.
• Share your proposal draft early. Ask for feedback on scope and approach, then actually incorporate it.
• Be honest about your availability. If you have exams or college commitments during the coding period, say so and plan around them.

Step 5: Write a proposal that gets selected

The proposal is a project plan, not a personal essay. It should convince a mentor that you understand the problem, have a realistic approach, and can deliver on time. Many organisations publish their own proposal template; follow it if they do. If not, use this structure.

Recommended structure

1. Title and summary. One paragraph describing what you will build and why it matters to the project.
2. About you. Name, university, time zone, contact information, and links to your GitHub and relevant work. Keep it short.
3. Problem and motivation. What is missing or broken today? Show that you have studied the codebase by referencing real files, modules or issues.
4. Proposed solution. Explain the design. Include architecture notes, key APIs or data structures, and alternatives you considered. Diagrams help if they are clear.
5. Deliverables. A concrete list of what will exist at the end: features, tests, documentation.
6. Timeline. Break the work into weekly or biweekly milestones with tests and documentation included. Add buffer time for review and unexpected problems, and mark the midterm and final evaluation points.
7. Availability and commitments. Hours per week, exams, holidays, other jobs or internships.
8. Past contributions. Link to your merged and open pull requests to that organisation, with a sentence on each.
9. Post-GSoC plans. How you intend to keep maintaining or improving what you built.

Tips that matter

• Be specific. "Improve performance" is vague. "Reduce the startup time of module X by lazy-loading Y, measured by benchmark Z" is a plan.
• Reference the codebase. Mentors can immediately tell whether you have read the code.
• Scope realistically. Overpromising is a common mistake. It is better to propose a smaller project you can finish and test than a huge one you cannot.
• Get it reviewed. Share a draft with the mentor well before the deadline and revise it.
• Proofread. Clear writing shows how you will communicate during the programme.
• Submit early. Do not wait for the last hour; portals can be slow.

Common reasons proposals get rejected

• No prior interaction. The mentor has never seen you in the community before the proposal arrives.
• Copy-pasted or generic content. Proposals that could apply to any project are easy to spot.
• Unrealistic timeline. A vague or overly ambitious schedule signals a lack of understanding.
• Weak or no code contributions. Talking about skills without evidence rarely persuades.
• Ignoring the organisation's template or instructions.
• Not responding to feedback. If the mentor suggests changes and you do not act, they will assume the same later.
• Insufficient availability. Many students overlap GSoC with a full course load or an internship without saying so.
• Too many applicants for too few slots. Sometimes a good proposal is simply not selected because the organisation only has a limited number of slots. This is not always a reflection on your ability.

If you are not selected

Rejection is common, and most successful contributors have faced it at least once. What matters is how you use the time afterwards.

1. Ask for feedback. Some mentors will share what could have been improved.
2. Keep contributing. Your merged work has value regardless of the result, and many organisations invite continuing contributors to become maintainers or mentors.
3. Apply to other programmes. There are several alternatives with similar goals:

• Outreachy offers paid remote internships in open source for people underrepresented in tech; check eligibility on their website.
• LFX Mentorship from the Linux Foundation places mentees on projects in cloud native, security and other communities.
• GirlScript Summer of Code (GSSoC) is an India-based open source programme that is friendly for beginners.
• MLH Fellowship offers structured, project-based fellowships, including open source tracks.

1. Use the work in interviews and applications. Open source contributions are excellent resume material. See how to describe them in the ATS-friendly resume guide, and check grants and programmes for other funding and mentorship opportunities.
2. Try again next year. With a longer track record, your second attempt is usually much stronger.

Also keep applying for regular internships alongside open source. They are not mutually exclusive, and a solid contributor profile helps in both.

A simple month-by-month plan

If you are starting from zero and the application period is about five months away:

• Month 1: Learn Git and GitHub well. Pick a language. Read about GSoC and browse past projects.
• Month 2: Choose 3-5 organisations, set up their projects locally, and make your first small contribution.
• Month 3: Take on medium issues in one or two organisations. Start following the community daily.
• Month 4: Once the organisation list is announced, finalise your choice, discuss ideas with mentors, and start drafting.
• Month 5: Refine the proposal with feedback, submit early, and keep contributing while you wait.

If you want a structured way to learn the tools first, look at the roadmaps on InternHack for a suitable learning path.

FAQ

When should I start preparing for GSoC?

Start at least four to six months before the application period. Organisations are usually announced around February and proposals are accepted around March to April, but exact dates change every year, so check the official timeline. Early contributions matter because mentors trust people they have already worked with.

Can a first-year or second-year student get selected?

Eligibility rules are set by Google each year, so read the current requirements on the official website. Within those rules, year of study is less important than your contributions and the quality of your proposal. Starting early in college gives you time to build a record over several attempts.

How many pull requests do I need before applying?

There is no fixed number. A few meaningful, merged contributions in the organisation you apply to are more convincing than many trivial ones. Aim for work that shows you understand the codebase and can respond to review feedback.

Should I apply to many organisations or just one?

Focus on one or two so that you can contribute deeply. You may be allowed to submit multiple proposals under the current rules, but each needs real research and mentor interaction. Ten shallow applications rarely beat one strong one.

Do I need to be an expert programmer to be selected?

No. You need to be competent in the project's language, able to read and modify existing code, and reliable at communicating. Many selected contributors started as beginners and learned the codebase through small issues.

What should I do if the mentor does not reply?

Wait a couple of days, then follow up politely in the public channel with any new progress. If there is still no response, look at whether the organisation is active, and consider shifting your effort to another organisation with faster feedback.