Cracking the Google Summer of Code Application: A Pattern-Based Guide ☀️ - Insights from successful applications to Google DeepMind (2025) and Joplin (2024)

How to Have a Successful Application to Google Summer of Code by Ton Hoang Nguyen.md

How to Have a Successful Application to Google Summer of Code ☀️

By Ton Hoang Nguyen (Bill)
Accepted to Google DeepMind (GSoC 2025) and Joplin (GSoC 2024)

Last Updated: Mon 26 May 2025

Hi! I welcome you to the document that explains how to create the most successful application for Google Summer of Code based on my observations and discovered patterns. This will not only apply to Google Summer of Code, but it will also be helpful in other aspects of your professional life.

There's a hidden pattern to successful Google Summer of Code applications - one that I discovered after being accepted to not just one but two GSoC organizations: Google DeepMind and Joplin.

This pattern isn't obvious. Most applicants focus solely on technical skills. But after analyzing others' proposals and identifying what drives acceptances, I've decoded the formula that can dramatically increase your chances of getting selected.

In this guide, I'll show you exactly how to craft a winning GSoC proposal, based on what actually worked for me.

Note

I hope this will help you and make the whole process of applying to Google Summer of Code clearer and easier for you. If you have any improvements or additional resources that could be useful in this document, feel free to let me know.

Lastly, comment on this GitHub Gist and follow me on GitHub if you have successfully gotten into Google Summer of Code using some advices from me. It will make me very happy to see you guys winning :)

Sections

This document will structured and partitioned into these following sections:

1. About My Journey to Google Summer of Code

If you are just interested in how to craft the best application, you can skip this section. However, it contains some information about my application process to both Google Deepmind and Joplin. It may be a useful read for you.

Here, you will learn about my journey from discovering open source through "Cathedral and Bazaar" to achieving two successful GSoC acceptances. I'll share:

• How I got started with open source at MindsDB (YC 20)
• My first GSoC success with Joplin's AI summarization project
• How I leveraged that experience for my Google DeepMind acceptance

2. Pattern Recognition

Through my successful applications and analysis of other accepted proposals, I've identified two distinct patterns that form the foundation of winning GSoC applications. This section explores the technical specification pattern, which is ideal for engineering-focused projects, and the research proposal pattern, which better suits machine learning or scientific computing projects. Understanding these patterns and knowing when to use each approach can significantly strengthen your application.

3. Proposal Structure

Here we'll dive deep into the essential components that make up a successful GSoC proposal. I'll walk you through each section from front matter to conclusion, using real examples from my accepted proposals to illustrate key points. You'll learn how to effectively communicate your ideas, demonstrate technical capability, and show genuine enthusiasm for the project. This section serves as a practical template you can adapt for your own proposal.

4. Final Remarks

The closing section synthesizes the key lessons from my GSoC experiences and advises future applicants.

By following this structured approach, you'll gain a comprehensive understanding of what makes GSoC proposals successful and how to craft your own compelling application. Whether you're applying for the first time or trying again after previous attempts, this guide will help you present your ideas and capabilities in the most effective way possible.

Tip

🚀 QUICK START If you're short on time:

1. Skip to Pattern Recognition to understand proposal types
2. Use Proposal Structure as your template
3. Review Final Remarks for key success factors

Table of contents

1. About My Journey to Google Summer of Code
   1. First Contributions at MindsDB (YC 20
   2. When I heard about Google Summer of Code
   3. Application period 2024 - Joplin
   4. WWOOOOOHOOOOO
   5. Application period 2025 - Google Deepmind
   6. WWOOOOOHOOOOO VOL.2
2. Pattern Recognition
   1. Technical Specification and Design Document
   2. Research Proposal
3. Proposal structure
   1. Front Matter
   2. Motivation
   3. Introduction or Summary
   4. Background or Context
   5. Goals and Objectives
   6. Methods or Solutions
   7. Implementation
   8. Timeline and Milestones
   9. Extra Goals and Objectives
   10. Conclusion
4. Conclusion and Final Remarks
5. References

1. About My Journey to Google Summer of Code 👨

I knew about open-source before by reading the Cathedral and the Bazaar¹. The book's author, Eric S. Raymond, analyzed and showed the difference between closed-sourced and open-sourced development. For example, he explained that open-source projects iterate and develop faster because more developers make pull requests (PRs). However, the code quality could be worse compared to closed-source developers, and you have to manage and talk to many people, which can create chaos, hence the name Bazaar. He credited Linus Torvald, the creator of Linux, as the inventor of the open source development process.

Reading the book felt like reading an ancient script, and I enjoyed every minute of it :D It also helped me understand why some YC companies are open-sourcing their products and how it benefits them.

i. First Contributions at MindsDB (YC 20)

After reading the book, I quickly became interested in open-source and decided to contribute to projects aligned with my interests, mainly AI-focused products. I then stumbled upon MindsDB (YC 20). I was impressed how the codebase was written and figured out that these guys were pretty smart. Then I saw that they were organizing Hacktoberfest and asked myself: why not participate, let's do it. That was in Fall 2023.

ii. When I heard about Google Summer of Code

Some time after, I remembered that back in college, my friend Eniko Kollar (a brilliant mind) talked about Google Summer of Code and encouraged me to apply for it. However, back then, I was part of the AI student team and did not pay much attention to it.

iii. Application period 2024 - Joplin

During the application period in early 2024, I searched for AI projects that I would love to work on. I eventually found Joplin, the note-taking application that emphasizes user privacy. One of the project ideas was to use AI to summarize notes and notebooks (groups of notes). I really liked this idea and thought that it will be super fun to work on it, so I decided to go for it.

The first think I did was to research about text summarization techniques and how would I be able to run AI/ML models on the client-side using Javascript/Typescript. I learned about that there are two types of summarization and that is: extractive and abstractive ².

Then I explored Joplin's codebase and documentation. I eventually made coupled of PRs and there were my first interactions with Joplin's maintainers and mainly with Laurent Cozic, who is the creator of Joplin!

I then asked the community couple of question about the my GSoC proposal to Joplin and it was super useful ³. I think that if I did not ask the community, my proposal may have been rejected.

iv. WWOOOOOHOOOOO

In the late afternoon, in London's packed underground at Westminster station, I received an email from Google Summer of Code. My heart was pumping, and I nervously opened the email. I found out that I got in, I was very happy and wanted scream out of my lungs!

v. Application period 2025 - Google DeepMind

When I found out that Google DeepMind was participating in Google Summer of Code this year, I could not ignore it. I thought I had a 0.0000001% chance of getting in, and there were some doubts about whether to create a proposal. In the end, despite the odds, I still went for it.

I went through Google DeepMind's list of project ideas. Most of them were super interesting! However, in the end, I only chose one idea: enhancing coding extensions, which was the greatest fit for me.

I love to research AI/ML techniques and methods and implement them, then brainstorm how users would benefit from the AI features. It was easy for me to show this passion for producing AI features for users because of my open-sourced work in Joplin. I showcased and emphasized those in my proposal as an argument why I am an excellent fit for the project idea.

This was not a traditional Google Summer of Code application, where you can directly interact with mentors and communities. Plus, with the spike in the number of applicants, making pull requests that would be merged was near impossible.

That meant I had to take a different approach: I had to dive deeply into a topic and focus on creating the best proposal. Therefore, I read as much literature (research papers, articles, documentation, etc.) as possible on LLMs, long context-tackling, and context caching approaches.

vi. WWOOOOOHOOOOO VOL.2

When I received an email from Paige Bayley from Google DeepMind, I was ULTRA SUPER MEGA SHOCKED AND EXCITED. So there goes another WWOOOOOHOOOOO!

2. Pattern Recognition 🔍

I believe that everything in this world is a pattern and has hidden knowledge in it. Salespeople know how to sell products based on their observed patterns, firefighters know how to climb on the steel rod based on their observed patterns, doctors can identify certain sicknesses based on their observed patterns, and so on.

From my observation, the pattern of proposing an idea and convincing GSoC organizations to invest their time in you and believe in your solution is similar to the existing proposal structure/document used in companies or academia.

Before starting brainstorming and creating a solution, it is essential to consider the project's main pain points and how solving them will affect the project, users, etc. This part will strengthen and explain your motivation for the project. It also shows that you are aware of what is happening around the topic, which is great to show.

Lastly, it is very important to explain why you are a good fit for the projects and provide evidence for it.

Technical specification and Design Document

There is a clear and straightforward definition of the technical specification ⁴:

A technical specification document outlines how you’re going to address a technical problem by designing and building a solution for it. It’s sometimes also referred to as a technical design document, a software design document, or an engineering design document. It’s often written by the engineer who will build the solution or be the point person during implementation, but for larger projects, it can be written by technical leads, project leads, or senior engineers. These documents show the engineer’s team and other stakeholders what the design, work involved, impact, and timeline of a feature, project, program, or service will be.

When applying to GSoC, I discovered that the most successful proposals essentially function as technical specs. They need to ⁴⁵:

• Break down the problem clearly
• Explain your solution approach step-by-step
• Include implementation details and timelines
• Address potential challenges

I found that when I structured my proposals like professional technical specs, organizations could easily evaluate my thinking process and implementation plan. This was crucial for both my Joplin and Google DeepMind acceptances.

Research Proposal

Some GSoC organizations, especially those focused on machine learning, scientific computing, or academic research, expect a more research-oriented proposal rather than a pure engineering spec.

Key Differences from Technical Specs:

• Stronger emphasis on methodology and theoretical framework
• More extensive literature review/background
• Clear research questions or hypotheses
• Detailed experimental design
• Discussion of potential research impacts

Essential Components⁶:

1. Research Context

   • Current state of the field
   • Gap analysis
   • Research questions

2. Methodology

   • Theoretical framework
   • Experimental design
   • Data collection/analysis
   • Evaluation metrics

3. Expected Contributions

   • Theoretical advances
   • Practical applications
   • Impact on the field

4. Research Timeline

   • Literature review phase
   • Implementation phase
   • Evaluation phase
   • Documentation phase

3. Proposal Structure and Guide 📜

Now that we have learned and understand technical specification/design document, we can dive into the GSoC proposal structure and details that worked for me twice.

i. Front Matter

This section should include:

• Project title
• Your contact info
• Links to prior PRs
• Timezone
• Communication handle

This is where you explain why you're the best fit for the project. In my DeepMind proposal, I highlighted my previous GSoC experience with Joplin and how the AI implementation skills I gained were directly applicable to the new project. For Joplin, I emphasized my experience with MindsDB and my participation in Hacktoberfest.

Don't just list technologies you know—show specific examples of how you've used them in contexts relevant to the project.

ii. Motivation

This is where you explain why the proposal was made and how your solution will benefit the organization. For my Joplin proposal, I explained how note summarization would help users quickly extract key information from lengthy notes, saving them time and mental energy.

Your motivation section should:

• Identify the core problem
• Explain why it matters to users
• Connect to the organization's broader goals
• Make a compelling case for implementation

The strongest proposals demonstrate you understand not just what to build, but why it matters.

iii. Introduction or Summary

Keep this concise but comprehensive - it should be scannable in under a minute. For my DeepMind proposal, I outlined two potential approaches to enhancing Gemini support in coding extensions, with a clear comparison table highlighting the pros and cons of each.

Your introduction should:

• Summarize the problem and solution
• Preview your technical approach
• Highlight key benefits
• Set expectations for the rest of the proposal

Remember that many reviewers will make their initial judgment based on this section alone, so make it count!

iv. Background or Context

Here's where you demonstrate you've done your homework. For my Joplin proposal, I explored existing text summarization techniques (extractive vs. abstractive) and explained how they could be implemented client-side using Transformers.js.

Strong background sections include:

• Analysis of the current state
• Technical environment understanding
• Previous approaches or attempts
• Relevant technical constraints
• User needs and pain points

Don't just copy from documentation, synthesize information to show deep understanding.

v. Goal and Objectives

Be specific about what you'll deliver. For my Joplin proposal, I broke down objectives into implementing both extractive and abstractive summarization, with clear deliverables for each.

Effective goals are:

• Specific and measurable
• Realistic within the GSoC timeframe
• Prioritized by importance
• Connected to user benefits

Include both "must-have" core deliverables and "nice-to-have" stretch goals.

vi. Methods or Solutions

This is the technical meat of your proposal. In my Joplin application, I detailed specific algorithms (TextRank, frequency-based) and models (Flan-T5-small) I would use, complete with benchmarking results.

Your methods section should include:

• Technical approach with justification
• Libraries, frameworks, and tools
• Architecture diagrams or mockups
• Algorithms or methodologies
• Potential challenges and solutions

The more specific and detailed, the better—it shows you've really thought through implementation.

vii. Implementation

Break down how you'll actually build your solution. For DeepMind, I outlined specific features like UI enhancements, long context support, and caching mechanisms, with technical details for each.

Strong implementation sections include:

• Step-by-step build approach
• Integration points with existing code
• API changes or additions
• Data models or structures
• Testing strategy

Show you understand not just what to build, but how to build it within the existing codebase.

viii. Timeline and Milestones

Create a realistic week-by-week plan. For both my successful proposals, I included:

• Community bonding activities
• Weekly deliverables with specific dates
• Buffer weeks for unexpected challenges
• Testing and documentation phases
• Evaluation preparation

Be honest about what you can accomplish—organizations value realistic planning over ambitious but unachievable timelines.

ix. Extra Goals and Further Considerations

Show you're thinking beyond the minimum requirements. In my Joplin proposal, I included extra goals for notebook-level summarization and discussed future AI features that could build on my work.

Good extra considerations include:

• Performance optimization
• Security considerations
• Accessibility improvements
• Future extensions of your work
• Maintainability concerns

This section demonstrates your thoroughness and long-term thinking.

x. Conclusion

Wrap up concisely, reiterating why your project matters and why you're the right person for it. Express genuine enthusiasm and commitment to the organization's goals.

4. Final Remarks

Based on my successful experiences with both Joplin and Google DeepMind, I've found that winning GSoC proposals share these qualities:

• They show, not just tell - Include code samples, diagrams, and specific examples
• They demonstrate community engagement - Reference discussions, issues, and PRs
• They balance ambition with realism - Propose meaningful but achievable goals
• They speak to organizational needs - Connect your project to the org's broader mission
• They anticipate challenges - Address potential roadblocks proactively

Remember that GSoC is about more than just coding. It's about becoming part of an open-source community and creating something of lasting value. Your proposal should reflect this broader purpose.

Lastly, don't get discouraged if you don't get accepted on your first try. Use the feedback to improve and try again next year. Both of my acceptances came after thorough preparation and genuine engagement with the communities I wanted to join.

Good luck with your GSoC journey and I wish you well in your life! ☀️

References

Footnotes

1. The Cathedral and the Bazaar: https://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ ↩

2. Summarize Your Notes with Joplin AI: https://gist.github.com/HahaBill/564ac86ef926fc25ce9ac91192f3fc02 ↩

3. Asking community about the Summarization Project Idea: https://discourse.joplinapp.org/t/summarize-your-notes-with-joplin-ai/36983/7 ↩

4. Technical Specification: https://stackoverflow.blog/2020/04/06/a-practical-guide-to-writing-technical-specs/ ↩ ↩²

5. Design Document: https://www.freecodecamp.org/news/how-to-write-a-good-software-design-document-66fcf019569c/ ↩

6. Research Proposal: https://www.ed.ac.uk/studying/postgraduate/applying/your-application/research-proposals ↩