Google Summer of Code (GSoC) Guide for Indian Students: How to Get Selected

Most Indian students who fail to get into Google Summer of Code make the same mistake. They treat it like an exam: wait for the organization list in February, pick the org with the most famous name, write a proposal in March, and hope. The students who get selected treat it like a job. They pick an organization months earlier, quietly make themselves useful, and by the time applications open, their mentor already knows their GitHub handle.

This guide is the job-style approach, broken into concrete steps: how to pick organizations that suit your skills, how to land your first pull request in an unfamiliar codebase, what a proposal that gets accepted looks like section by section, and how to turn the summer into resume value for placements. Rules and dates change a little every year, so verify specifics on the official GSoC site before you plan around them.

What Google Summer of Code Actually Is

Google Summer of Code is a program where Google funds new contributors to work on open source projects under the guidance of mentors from participating organizations. Google does not write the project ideas, does not pick the contributors, and does not mentor you. The organizations do all three. Google's role is to accept organizations, run the application platform, set the rules and pay stipends.

This distinction matters for strategy. Your audience is not a Google recruiter screening thousands of resumes. It is two or three maintainers of a specific project, deciding which of the 10 to 60 applicants they are willing to spend their summer evenings mentoring. Maintainers are volunteers or employees with day jobs. They want someone who will finish the project, communicate without hand-holding and maybe stay on as a contributor afterwards.

Organizations range widely: language and runtime projects, scientific computing libraries, browsers and graphics stacks, operating system components, developer tooling, machine learning libraries, documentation-heavy community projects, and umbrella organizations that host many smaller projects. Some regulars over the years include large foundations and umbrella orgs (Python Software Foundation, Apache, Linux Foundation projects), scientific stacks, and projects like OpenCV, Git, Chromium-adjacent tools and many more. The list changes every year, so treat any specific organization as "check if it is participating."

What GSoC is not

• Not an internship at Google. You are not a Google employee and you will not be interviewed by Google engineers. It is often confused with the Google STEP internship, which is a different program covered in our Google STEP internship guide.
• Not a competition. There is no leaderboard. An organization with 5 slots picks the 5 people it trusts most.
• Not limited to students anymore. Since 2022, GSoC has been open to people aged 18+ who are students or beginners in open source.

Eligibility, Project Sizes and the Stipend

The core eligibility rules in recent years have been stable: you must be at least 18 at registration, be either a student or an open source beginner, be eligible to work in your country, and not be resident in a country under US embargo. There is also a cap on how many times one person can be a GSoC contributor, which has been two in recent cycles. Read the current year's rules page rather than relying on a blog post, including this one.

Project sizes

Projects come in three sizes, measured in expected hours of work. The size determines both the effort you are committing to and your stipend.

Timelines can be extended (up to about 22 weeks in recent rules) when the mentor and contributor agree, which helps if your college semester overlaps with the standard coding period.

How much is the GSoC stipend in India?

Stipends are set per country using purchasing power parity, so an Indian contributor receives less in dollar terms than a US contributor for the same project size. In recent years the India figures have been in the range of roughly $750 for small, $1,500 for medium and $3,000 for large projects, paid in instalments after evaluations. Treat those numbers as approximate and check the official stipend table for your year. Payment typically goes through a payment provider to your bank, and the amount is taxable income in India, so keep the records for your ITR.

The GSoC Timeline, and the Timeline That Actually Matters

The official timeline is published each year. The shape has been consistent: Google announces the program in the autumn, organizations apply in January, the accepted organization list comes out in late February, contributor applications open mid-to-late March for about two weeks, results come out in early May, then a community bonding period, then coding from roughly June through August (or later for extended projects).

Now look at the timeline selected contributors actually follow. Their real work happens before the official one starts.

Indian semester calendars clash with this. Many colleges have end-semester exams in late April or May, which overlaps with the review period and community bonding, and odd-semester classes restart in late July. Put your exam dates in the proposal. Mentors are fine with planned unavailability; they are not fine with surprises.

How to Choose a GSoC Organization (Especially as a Beginner)

Organization choice is the single biggest lever on your chances. Most students pick based on brand ("I want to contribute to a famous ML library") and end up as one of hundreds of applicants in an org with a handful of slots. Choose based on fit and competition instead.

The four filters

1. Tech stack you can already read. You do not need to be an expert, but you must be able to read the code on day one. A Python developer should not start with a C++ graphics engine in December. Filter the org list by language and topic tags.
2. Participation history. Orgs that have participated for several consecutive years have mature mentoring processes, clear ideas lists and realistic expectations. Previous years' archives on the GSoC site show which projects they ran.
3. Responsiveness. Open five recent pull requests from newcomers. How long until the first review comment? If PRs sit unreviewed for months, your contributions will not be seen in time.
4. Competition relative to slots. A huge, well-known project may receive hundreds of proposals for a few slots. A mid-sized scientific or tooling org with friendly maintainers might receive a few dozen. Look at chat activity in February and March from past years: dozens of "Hi, I am new, how do I start?" messages per day is a signal of heavy competition.

Picking one org versus many

Spread too thin and you are a stranger everywhere. Concentrate and you risk the org not being selected that year. The sensible middle path is one primary organization where you go deep and one backup where you have at least a merged PR or two. If your primary org is not on the February list, you shift effort to the backup with a month of runway still left.

Org types and what they expect

Your First Contributions: From Zero to Merged PRs

The contribution phase is where selection is actually decided. A proposal from someone with five merged, non-trivial PRs and a history of helpful comments almost always beats a beautifully written proposal from someone the mentors have never seen.

Week 1: get the project building

Fork the repository, follow the contributing guide, and get the test suite passing locally. This alone filters out a surprising number of applicants. Document every snag you hit. If the setup guide is wrong or outdated for a particular OS, that is your first contribution: a documentation fix that the maintainers will appreciate because every new contributor hits it.

# one-time setup
git clone https://github.com/<you>/<project>.git
cd <project>
git remote add upstream https://github.com/<org>/<project>.git

# for every contribution
git fetch upstream
git checkout -b fix-1234-null-check upstream/main
# ... make changes, run the test suite, run the linter ...
git commit -m "Fix crash when config file is empty (#1234)"
git push origin fix-1234-null-check
# open the PR, link the issue, describe what you changed and how you tested it

# when the maintainer asks for changes after main has moved on
git fetch upstream
git rebase upstream/main
git push --force-with-lease origin fix-1234-null-check

Learn rebasing and squashing properly before you start. A newcomer PR with 14 commits named "fix", "fix again" and "final fix" plus a merge commit from main signals inexperience. Our git commands guide covers rebase, squash and conflict resolution in depth.

Weeks 2 to 4: the "good first issue" trap

Every org labels some issues "good first issue". In GSoC season, these get claimed within minutes, sometimes by several people at once. Do one if you can, but do not spend your energy fighting over them. Better sources of first work:

• Reproduce open bug reports. Comment "I can reproduce this on version X with these steps" or "I cannot reproduce on main; it may have been fixed by commit Y." This is genuinely useful triage that maintainers notice.
• Improve test coverage for a module related to the GSoC idea you are eyeing. It forces you to read the code you will later change.
• Fix warnings and deprecations that the CI log shows. Tedious, low-competition, merged quickly.
• Documentation that is actually wrong. Not rewording; fixing examples that no longer run.

Weeks 4 to 10: real contributions near your idea

Once you have a couple of small PRs merged, move to bugs and small features in the area of your target project idea. If the idea is "add async support to the HTTP client module", your contributions should be in that module. Then your proposal can say "I have already fixed issues #812 and #845 in this module, and while doing so I found that the connection pool is the main obstacle." That sentence is worth more than any paragraph about your passion for open source.

How to communicate in project channels

How many PRs do you need?

There is no official number. A reasonable target is 3 to 8 merged contributions, where at least two are real code changes rather than typo fixes, and ideally one touches the area of your proposed project. Quality and relevance beat count. Ten README edits do not show that you can build the project.

Writing a GSoC Proposal That Gets Accepted

A GSoC proposal is a technical design document plus a credible delivery plan. Mentors read it to answer three questions: does this person understand the problem, is the plan realistic, and will they actually finish? Most orgs publish a proposal template or a list of required sections. Follow it exactly. If there is no template, use this structure.

The technical approach section, done right

This is where weak proposals reveal themselves. A weak proposal says "I will implement caching to improve performance." A strong one shows the reader you have already read the code:

Currently Resolver.resolve() in core/resolver.py re-parses the dependency manifest on every call (about 40 ms per call on the benchmark repo in benchmarks/large_repo). I propose an LRU cache keyed by (manifest path, mtime) inside ManifestLoader, invalidated on file change. I considered caching at the Resolver level instead, but that breaks the plugin API because plugins mutate the resolved graph (see issue #902). Proposed interface: ...

Include small code sketches, a diagram if the design has moving parts, and the test strategy. Mentors love proposals that mention how success will be measured: a benchmark, a test suite passing, a feature demo.

A realistic week-by-week timeline

Here is a pattern for a medium-sized project. Note that each block ends with something mergeable, not just "research".

Always include buffer. Code review in open source is slow, and your mentor may be on holiday for a week in July. A timeline with zero slack tells the mentor you have never shipped anything through review.

Get feedback before you submit

Share the draft with mentors at least 7 to 10 days before the deadline, in the format your org prefers (often a Google Doc with comment access, sometimes a draft on the org's forum). Act on every comment. Then submit the final PDF on the GSoC platform early. The portal deadline is strict and people do miss it every year because of IST to UTC confusion; the deadline is published in UTC.

Proposal red flags mentors mention most

• Copying the idea description back as the problem statement.
• A timeline where week 1 to 4 is "understand the codebase".
• No links to any contribution in the org.
• Scope far bigger than the idea, promising five features in a medium project.
• Generic text that could apply to any organization, often a sign of a template or AI draft.
• Not mentioning exam dates, then disappearing in May.

During the Coding Period: How to Pass Evaluations

Getting selected is half the job. Mentors evaluate you at the midterm and the final. Failing an evaluation ends your participation. The contributors who pass comfortably share a few habits.

• Weekly written updates in a public place (mailing list, forum thread, or a blog). What you did, what is blocked, what is next. This doubles as your final report.
• Small, frequent PRs instead of one 4,000-line PR at the end. Large PRs sit in review for weeks and often never merge.
• Raise blockers within a day. If you are stuck for more than a day, ask. Mentors prefer a question to silent slippage.
• Re-plan openly. If the design changes in week 4, update the timeline and tell the mentor. Evaluations are judged against agreed expectations, not the original proposal frozen in March.
• Write the final report as a portfolio piece. A blog post or gist that links every PR, explains what was built and what is left. This is the link you will put on your resume.

GSoC, Your Resume and Placement Interviews

GSoC has strong signalling value in India. It is verifiable (your name appears on the GSoC project page, and your PRs are public), it is competitive, and it shows skills that coursework does not: reading large codebases, writing tests, working through code review, and communicating asynchronously across time zones. Recruiters and interviewers at product companies recognize it.

What it does for you, honestly

How to write GSoC on your resume

Put it under Experience, not under Achievements. Use the format you would for an internship:

Google Summer of Code Contributor, <Organization> (May to Aug 2026, remote)
Built manifest caching for the dependency resolver, cutting median resolve time on large repositories from ~40 ms to ~6 ms per call in the project benchmarks; 9 PRs merged (~2,100 lines), including a plugin-safe invalidation layer and regression suite. Link to final report.

Use numbers you actually measured, and only those. Interviewers will ask how you measured them. For more on phrasing, see our guide on explaining projects in interviews.

What interviewers ask about GSoC

• "Walk me through the architecture of the module you worked on." Draw it. Know the boundaries.
• "What was the hardest bug and how did you find it?" Have one specific story with the debugging steps.
• "Your mentor disagreed with your design. What happened?" Show you can take feedback and still argue with evidence.
• "What would you do differently?" Be honest about scope or design mistakes.
• "How did you test it?" Unit tests, integration tests, CI, benchmarks.

Many students also ask whether to do GSoC or a corporate internship in the summer after third year. If you have a PPO-track internship offer from a company you would join, the internship usually wins because it can convert directly into a job (see our PPO guide). GSoC is the better choice in second year, or if your internship options are at companies you would not join full time.

Mistakes That Sink GSoC Applications

1. Starting in March. By then, the serious applicants have been contributing for three months. You can still apply, but you are competing on proposal quality alone, which is the weakest signal.
2. Choosing by brand. The most famous orgs have the highest applicant-to-slot ratios. A mid-sized org where you become a known contributor gives better odds.
3. Treating mentors as tutors. Mentors are not there to teach you git or Python. Learn basics independently and bring specific questions.
4. Disappearing after submitting. Orgs notice applicants whose activity stops on the deadline day. Keep contributing in April.
5. Over-scoping. Proposing more than the idea asks for looks ambitious to you and unrealistic to mentors.
6. Ignoring the org's application requirements. Some orgs require a specific qualification task or a patch before you can apply. Missing it is an automatic rejection.
7. Giving up after one rejection. Many contributors are selected on their second attempt, in the same org, because they kept contributing through the year and were the obvious choice next time.

The pattern behind every successful GSoC application is the same: be useful to a project before asking it for anything. Pick an organization whose code you can read, fix real problems in the area you care about, talk to mentors in public about specific technical questions, and turn that context into a proposal only you could have written. Start in November, not March.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.