In Part 1 you learned how to prepare for Google Summer of Code and how to choose the right organization to work with. In Part 2 -- how you contribute to a project and communicate with its community. In this part we turn to another critical step in the process: writing a strong proposal. Your proposal is where you present your idea, explain your technical approach, and demonstrate that you understand both the project and the work required to complete it. This part will guide you through structuring a clear proposal, defining realistic milestones, and communicating your plan in a way that helps mentors evaluate your readiness to successfully complete the project.
Proposal strategy: how to use your 3 slots wisely#
A contributor can submit up to three proposals during a single Google Summer of Code cycle (only one project proposal may be accepted per GSoC contributor). These proposals can target a single organization or multiple organizations.
How you use these slots matters. Each proposal should be well researched and thoughtfully prepared. Submitting several rushed proposals is rarely effective. One or two strong proposals that clearly align with a project and its mentors typically perform better than three superficial ones. It is also important to remember that a contributor can only be accepted into Google Summer of Code a maximum of two times across their entire participation history.
Preparing before writing the proposal#
Strong proposals are rarely written from scratch without prior involvement in the project. Spending time understanding the organization and its code base significantly improves the quality of your proposal and the feasibility of your technical plan. Before starting the proposal itself, carefully review the organization's idea list and narrow your focus to one or two projects that match your interests and skills.
Organizations often prefer applicants who have already interacted with the project or mentors before submitting a proposal. Even short conversations can clarify expectations and help refine your technical approach. With this foundation, you can now begin structuring your proposal to clearly introduce yourself, describe the project, and outline your plan for successful completion.
Introduction and background#
Most proposals begin with a short introduction explaining who you are and what background you bring to the project. This section should briefly describe your academic (or professional) background, relevant technical skills, and any previous projects or open source contributions. The goal is to give mentors enough context to understand your experience and why you are a good candidate for the proposed work. If you have previously worked on projects related to the proposal, mentioning them can help demonstrate that you already have experience with similar challenges.
Motivation and expectations#
A strong proposal explains why you are interested in the project and what you hope to gain from the experience. Focus on your motivation for working on the specific project rather than simply participating in the program. Explaining what interests you about the problem, the technology involved, or the goals of the organization helps mentors understand why you chose this particular project. It can also be useful to briefly describe what you expect to learn during the program and how the experience fits into your broader technical interests or long-term goals.
Project description#
The core of the proposal should clearly describe the project itself and demonstrate that you understand the problem it aims to solve. Start by indicating the project size, then provide a short overview of the idea and explain the problem the project addresses. Instead of repeating the idea description verbatim, restate the problem in your own words and describe the general approach you plan to take. Explain how your proposed work fits into the existing project ecosystem to help mentors understand how your contribution will integrate with ongoing development.
Project size and duration#
Google Summer of Code projects are categorized by size, based on the estimated number of hours required to complete the work. Small (90-hour) projects can run for 8 (or 12 with mentor approval) weeks but cannot use the extended timeline. Medium (175-hour) and large (350-hour) projects normally span 12 weeks, and in some cases may request an extended timeline of up to 22 weeks. Align your proposed scope, timeline, and deliverables with the selected project size so that mentors can realistically assess workload and milestones.
Related work#
Include an overview of related work in your proposal. This can cover work that has already been done within the project or organization, as well as similar projects, experiments, or technologies in the same stack. Highlight lessons learned from these related efforts and explain how they inform your design decisions, technical approach, or timeline. Providing this context demonstrates that your proposal is grounded in existing work and that you understand how your contribution fits within the broader project or technical landscape.
Benefits to the community#
If your proposal is an original idea not listed by the organization, it is especially important to clearly explain how the work will benefit the project and its broader community. Describe the practical impact, such as how it improves the ecosystem, solves a real problem, or enables new capabilities for users or contributors. This helps mentors understand why the work is worth prioritizing and how it fits into the overall direction of the organization.
Technical approach and architecture#
A strong proposal benefits from a good description of the technical approach, including the architecture, key modules, APIs, libraries, or frameworks, and important design decisions. Explain why you selected certain technologies over alternatives and how your approach integrates with the existing project. Highlighting these details demonstrates that you have considered practical implementation challenges and are prepared to execute your plan thoughtfully.
Project deliverables#
Clearly describe what will be delivered by the end of the program. Deliverables should be concrete and may include implementing specific features, adding new modules or components, improving existing functionality, expanding documentation, increasing test coverage, or integrating the project with other tools or services. Define a clear minimum viable outcome and present additional improvements as optional stretch goals if time allows. Clearly describing expected outcomes helps mentors understand what success will look like when the project is completed.
Risks and mitigation#
Identify potential risks and describe how you will address them. Possible challenges include technical limitations, dependencies, or tight timelines. Explaining how you plan to mitigate these risks (by implementing fallback solutions, breaking work into smaller milestones, or testing incrementally) signals that you are proactive and prepared for obstacles.
Testing and validation plan#
Include a testing or validation plan to demonstrate that you care about quality and maintainability. Describe how you will verify your work through unit tests, integration tests, automated pipelines, or user testing. Clear validation strategies show that you can measure success objectively and ensure your project meets the intended requirements.
Project timeline and milestones#
Include a detailed plan for how the work will be implemented during the program. Break the project into weekly or bi-weekly milestones and connect each milestone to specific deliverables. Include buffer time for review cycles, debugging, or unexpected challenges. A realistic timeline demonstrates that you have thought through the development process and understand how to manage the project over the duration of the program.
Collaboration and availability#
Successful projects depend heavily on communication between contributors and mentors. Describe where communication will take place and how you plan to provide regular updates. Many contributors share weekly progress summaries including completed work, current tasks, and blockers. Clearly state your timezone, expected hours per week, and any known commitments such as exams, travel, or part-time work. This allows mentors to plan milestones realistically and ensures smooth collaboration throughout the program.
Applications to other projects or organizations#
Some organizations appreciate knowing whether applicants have submitted proposals to other projects or organizations. While not always required, sharing this information can be considered good practice. Briefly mention whether you applied elsewhere and, if relevant, which proposal represents your primary preference. Being transparent helps mentors understand your plans and make informed decisions during the selection process.
Responsible use of AI tools#
Contributors may choose to use AI-assisted tools to help draft proposals or clarify ideas. While these tools can be useful for organizing thoughts, mentors expect proposals to reflect your own understanding and original work. Using AI to generate content that looks identical to another applicant's submission, especially in the technical approach or implementation plan, can create serious concerns and may lead to rejection. Always review and adapt AI-generated text to reflect your own knowledge and hands-on experience. Use AI responsibly: it should support your thinking, not replace it.
A well-prepared proposal that clearly introduces yourself, explains your motivation, outlines the project and its related work, describes community benefits, details the technical approach. It defines concrete deliverables and stretch goals, addresses risks and testing, presents a structured timeline, and sets expectations for collaboration and availability demonstrates that you are ready to contribute effectively throughout the program. Thoughtful preparation and clarity often make the biggest difference in helping mentors evaluate and select successful proposals.
References#
- Extending Your Project Length
- GSoC AI Guidance
- GSoC Program Rules
- LinkedIn original Part 3
- Project Size vs Project Length
A big thank you to the OWASP Foundation and the Python Software Foundation for participating and giving us the opportunity to tackle real-world problems through this incredible program organized by Google. I had the privilege to mentor multiple projects for OWASP and PSF guiding 10+ students alongside great mentors like Kateryna Golovanova, Panpakorn Siripanich, Sam Stepanyan, Serhii Murza, and Tamara Lazerka.
Disclaimer: The following insights and suggestions are based on my mentoring experience within OWASP and PSF umbrella projects (OWASP 2024, OWASP 2025, PSF 2025). They do not guarantee acceptance into GSoC but can significantly improve your chances if applied properly.
Originally published on LinkedIn on 16 Mar 2026 as Google Summer of Code: Your Complete Guide to Success, Part 3.
