How to Apply for GSoC: Process, Timeline and Checklist

If you want to know how to apply for GSoC, complete five connected tasks: prove you meet the current formal rules, work from the official calendar, select an accepted organization and feasible project, follow that community's prerequisites, and submit a compliant proposal through the GSoC web application before the UTC deadline. Community contact and contributions strengthen the work, but neither replaces the official submission.

The current process is documented in the official timeline, FAQ, Get Started page, applicant advice and proposal guide. The workflow below was verified on August 12, 2026. Dates and portal fields must be reopened for each new edition.

Do not begin with a proposal template. Begin with the rules. As of August 12, 2026, current contributor eligibility includes being at least 18 at registration; being a student or open-source beginner; being legally eligible to work in the country of residence; complying with current geographic rules; and having no more than one prior GSoC acceptance. Prior mentor or organization-administrator roles also affect contributor eligibility.

Use the detailed GSoC eligibility decision tree, then save a short eligibility record:

Formal eligibility does not mean an organization will select the proposal. It prevents a known rule failure so you can spend the rest of the process on project and community fit. If the roles remain confusing, read what GSoC is before proceeding.

The GSoC timeline shifts each year. The 2026 contributor process provides a concrete example: accepted organizations were published February 19; the contributor application period opened March 16 at 18:00 UTC and closed March 31 at 18:00 UTC; accepted projects were announced April 30. Community bonding and coding followed. These dates describe 2026 only.

As of August 12, 2026, Google had not published the official 2027 timeline. The GSoC 2027 guide keeps estimates separate from announcements. When a new calendar appears, copy the dates into your own UTC-first plan with reminders, but retain the official page as the source of truth.

A safe calendar contains four layers:

• Official UTC timestamp: exactly as Google publishes it.
• Local conversion: converted with the correct date and daylight-saving status.
• Personal target: at least several days earlier for the first complete upload.
• Contingency target: time reserved for PDF errors, broken links, portal issues and final review.

Google's applicant advice says proposal-deadline extensions are not provided, including for exams, misunderstanding the time zone, connection problems or emergencies. The deadline is a hard boundary, not the suggested time to begin uploading.

During the current contributor application window, use the official GSoC site and sign-in flow. Read the current terms and complete required profile information truthfully. Names, residence and prior participation should be consistent with later verification; do not optimize profile fields by misrepresenting them.

Use a private pre-submission record for:

• the account email you actively monitor;
• the display name you intend to use publicly where applicable;
• your accurate residence during the program;
• organization and project choices;
• proposal file names and versions;
• the official submission confirmation.

Do not place identity or residency documents in a public repository. Accepted contributors receive separate instructions for proof of residence, tax information and the payment provider. The application stage is also a good time to protect the account with secure authentication and to recognize that unofficial people asking for payment or documents are not part of the normal application process.

Work from the accepted organization list for the edition to which you are applying. Historical lists help you learn, but a previous participant is not confirmed until Google accepts it for the current year.

Google's applicant advice recommends filtering by interests, technologies and categories, researching roughly three to five organizations, and then narrowing to one or two. The research should go beyond an idea title:

• read the mission, current ideas page and application instructions;
• inspect the repository, recent issues, pull requests and release activity;
• find the contribution guide, code of conduct, license and public channels;
• identify the actual project skills, tests, build requirements and possible mentors;
• note required tasks, proposal templates and AI restrictions;
• ask whether you would still value the community if not selected.

The GSoC organizations list and organization-choice scorecard support discovery, but the official program page and current organization documentation decide application status.

The purpose of contact is to improve mutual understanding, not to ask a mentor to guarantee selection. Find the channel named on the organization or ideas page, observe its norms and introduce your context briefly. Public channels are often preferred because answers can help other applicants and community members can participate.

A useful first message contains:

1. the project or problem you researched;
2. the repository pages, issue or code path you inspected;
3. what you tried or learned;
4. one focused question whose answer changes your next action.

Avoid generic direct messages such as "Please guide me for GSoC," mass-posting the same introduction across communities, or asking for an easy project. Mentors are open-source volunteers and may need time to respond. Continue reading and testing while waiting.

Google's applicant advice says organizations do not choose solely from a polished proposal and strongly encourages direct engagement. Contact is evidence of project research and communication fit; it is not a private pre-approval.

There is no universal requirement for a particular number of merged pull requests. An organization can nevertheless require one or more of the following:

• a contribution, bug reproduction, test or qualification task;
• local setup and a documented build;
• a project discussion with named mentors;
• a proposal template or required questions;
• a specific application channel in addition to the official upload;
• restrictions or disclosure rules for AI-assisted work.

Create a prerequisite ledger rather than relying on memory:

Requirements can change during the research period. Reopen the idea page before final submission. The first-contribution guide covers repository setup, issue selection, implementation and review without treating PR count as a selection formula.

Organization choice and project choice are different decisions. A project needs a useful outcome, appropriate mentor support, a manageable technical boundary and a schedule matching its small, medium or large scope. Do not choose a title only because it uses a fashionable technology.

Run a small feasibility spike:

• locate the existing subsystem and related issues or prior work;
• reproduce the current behavior or build the relevant component;
• identify external dependencies, data, hardware and permissions;
• sketch required deliverables, tests and documentation;
• separate core outcomes from stretch work;
• list technical unknowns and a fallback for each major risk.

The dedicated project-choice guide provides a scorecard and scope register. If an organization permits original ideas, discuss yours early enough to find community value and a willing mentor. The official proposal guide warns that unmentored, incoherent or oversized original projects are particularly risky.

Follow the organization's exact template first. The Contributor Guide says organization formats and length limits matter and that applicants need a PDF version to upload. A strong proposal normally explains:

• the problem and why it matters to the community;
• related code, issues and prior work;
• the technical approach and relevant alternatives;
• required deliverables, optional deliverables and explicit non-goals;
• milestones connected to tests and documentation;
• dependencies, risks, mitigations and fallback scope;
• your relevant experience with links to evidence;
• known outside commitments and absences;
• the intended communication and reporting rhythm.

Use the GSoC proposal guide to review each section. Do not copy a historical accepted proposal: its project, organization rules, schedule and applicant evidence belong to another decision. Do not use AI-generated text unless the organization permits it, and never submit work you cannot explain and defend.

Submit a meaningful draft early. The official guide says drafts can be edited before the deadline and early submission gives reviewers time to ask questions or request detail. Labeling an early version as a draft can clarify that feedback is welcome, but you remain responsible for replacing it with the final version on time.

The official FAQ says all proposals must be submitted through the GSoC site, not sent only to organizations. Use this final submission procedure:

1. Export the proposal in the required PDF format and open the exported file yourself.
2. Check page order, tables, diagrams, text selection, URLs and organization-specific length rules.
3. Upload it through the correct official application entry for the correct organization and project.
4. Complete all required web fields accurately.
5. Reopen or preview the submitted record and verify that the intended file is attached.
6. Save a local final copy, timestamp and confirmation without exposing private data.
7. Finish before your personal target, not at the official final minute.

The current rules permit up to three proposals and only one acceptance. Google's published applicant advice recommends one or two strong applications and reports that more than 94% of accepted people in a referenced prior cohort submitted two or fewer. That statistic supports focus, not a guaranteed outcome.

Before the deadline, monitor the official system and the organization's published channels for legitimate questions. Respond with concise evidence and update the proposal if permitted and useful. Do not repeatedly demand a selection prediction or private status.

After the deadline, organizations review proposals using their own criteria, identify projects they can mentor and rank their choices within the GSoC process. Mentor availability, project usefulness, feasibility, communication, prerequisites and applicant evidence may all matter. Google then completes program-level administration, including allocation and resolving duplicate selections.

Keep contributing only where the work is genuinely useful and the community welcomes it. Do not flood a repository with last-minute patches designed to create a count. Also maintain a non-GSoC plan for your time; selection results should not be the only reason you learn or participate.

Use the official timeline for the results date and the official site for status. Be cautious of unsolicited messages claiming they can secure acceptance or asking for money.

If accepted, describe the result accurately: you were accepted to a GSoC project with the named mentoring organization. You are not yet a completed GSoC contributor and are not a Google employee. Begin community bonding, finalize the schedule and milestones, and follow the official payment and contributor instructions.

If not accepted, do not infer that every part of the proposal was poor. Mentor capacity, project priority and limited slots can affect decisions. Ask for feedback politely if the organization offers it, continue useful work at a sustainable level and decide whether to rescope, pursue another opportunity or prepare for a later cycle.

This map turns the process into verifiable outputs rather than vague activity:

• I rechecked the current FAQ, rules, timeline and contributor terms.
• My age, student/beginner status, residence, work eligibility and prior roles are accurate.
• I converted the official deadline from UTC and set an earlier personal deadline.
• My organization is accepted for the current cycle.
• I read its current ideas, contribution, proposal and AI-policy pages.
• I inspected the repository and discussed a specific, useful project through the preferred channel.
• I completed every documented prerequisite and kept evidence links.
• The project has measurable core scope, tests, documentation, risks and fallback work.
• The proposal follows the organization's format and accurately discloses outside commitments.
• I opened the exported PDF and checked all links and pages.
• I uploaded it to the official GSoC web application and verified the correct final file.
• I saved confirmation and finished with enough time to recover from a technical problem.

Learning how to apply for GSoC is mainly learning how to manage evidence and boundaries: official versus organization-specific rules, current versus historical dates, preparation versus submission, and ambition versus feasible scope. Follow those boundaries and the application will at least represent your real work accurately, even though no checklist can guarantee selection.