How I Got Selected For GSoC 2026: Four Months, 80+merged PR, 800+ PR Reviews, and One Hell

How I Cracked GSoC 2026 with Sugar Labs: My Complete Journey from January to Selection

From writing my first PR on January 4 to reviewing hundreds of pull requests, building a complete project demo, and eventually getting selected for Google Summer of Code 2026.

I wasn't even planning to do GSoC this year.

Seriously.

I had already participated in GSoC before, and this time I was mostly focused on exploring AI, building projects, and improving my engineering skills.

Then one of my friends suggested something.

Since I was already going deep into AI, why not explore GSoC organizations working on interesting AI projects?

That sounded reasonable.

But I didn't want to pick an organization just because it was participating in GSoC. I wanted to find a project I would genuinely enjoy building.

That's when I came across Sugar Labs.

They were proposing a project around AI-powered activity generation, where users could describe what they wanted and generate educational activities using AI.

I remember thinking, damn, this is actually something I'd love to build.

There was just one problem.

Sugar Labs was an established GSoC organization with a long history, an active community, and plenty of competition.

I knew getting selected wouldn't be easy.

But I also knew that if I approached the process carefully, I could give myself a pretty good chance.

And that's where everything started.

January 4: The First Contribution

I originally wanted to start contributing around December 15.

But college exams happened.

By the end of December, I was getting stressed because I hadn't made any progress. I kept thinking about how other contributors might already be working while I was stuck preparing for exams.

My exams finally ended around January 3.

On January 4, I started contributing to Sugar Labs.

One advantage I had was that I wasn't completely new to open source.

I had already spent considerable time contributing to different projects, so I understood Git, GitHub, pull requests, code reviews, and how open-source communities generally work.

I also did something that I think helped me quite a lot.

Before going deep into contributions, I researched the organization itself.

I looked into previous GSoC contributors, explored their communication channels, figured out when community meetings happened, and tried to understand what maintainers actually valued.

I wasn't just trying to figure out how to get PRs merged.

I wanted to understand how the organization worked.

My first PR was relatively small. I treated it as a way to familiarize myself with the codebase, understand the development workflow, and see how maintainers reviewed contributions.

Nothing particularly impressive yet.

But things started getting interesting after that.

The First Important Decision: Listening Before Contributing

I started attending Sugar Labs community meetings.

And I mean actually listening.

Not just joining a meeting to make my name visible.

I paid attention to the problems maintainers discussed, the features they wanted to prioritize, and the areas where the project needed help.

During one meeting, I remember a mentor mentioning that performance was an important concern in Music Blocks.

Certain parts of the application weren't performing as well as they should.

That immediately caught my attention.

Here's what I was thinking.

A lot of new contributors naturally gravitate toward relatively straightforward issues. They're easier to understand, easier to finish, and often easier to turn into a merged PR.

Performance problems are different.

They require investigation, profiling, understanding existing architecture, and sometimes spending hours figuring out why something behaves the way it does.

And there's no guarantee you'll find a solution quickly.

I realized this could be an opportunity.

Instead of just working on whatever issue was available, I started working on problems that the maintainers actually cared about.

My second PR focused on performance.

Over the following weeks, I continued working on performance improvements and other issues.

Eventually, during one of our meetings, a mentor specifically acknowledged and thanked me for the improvements I had been making to Music Blocks.

It was a small moment, but it meant quite a lot.

Not because someone had praised me.

But because I could see that my contributions were starting to make a difference.

The Day Music Blocks Production Broke

One of the most memorable moments happened when the production version of Music Blocks broke.

Someone had submitted a PR, it had been reviewed, and everything initially looked fine.

But a subsequent change introduced a problem that affected production.

I remember being in college when I noticed the discussions happening in the Sugar Labs Matrix channel.

For context, Sugar Labs uses Matrix for community communication. It's somewhat similar to Discord, but built around an open communication protocol.

People were discussing the issue, and the application wasn't behaving correctly.

I thought, what if I could figure out what's actually breaking?

When I got time, I sat down and started investigating.

I checked the browser's network requests, looked at what was failing, and tried to trace the problem back to its source.

Eventually, I found an issue involving a browser API call.

I fixed it and submitted a PR.

I remember being genuinely excited.

Something had broken in production, and I had managed to identify and fix the issue in roughly an hour of focused investigation.

That experience taught me something important.

You don't necessarily stand out by writing the most code. Sometimes you stand out by solving the problem that matters at the right moment.

It also helped me build trust with the maintainers.

And that trust became important later.

February 19: Why I Started Contributing to Joplin Too

While Sugar Labs was my primary focus, I didn't want to depend entirely on one organization.

GSoC is competitive, and selection involves factors beyond your control.

An organization might receive fewer slots than expected. Project priorities can change. Other applicants might also have excellent proposals.

So when the updated organization list came out, I started exploring another organization.

That's how I found Joplin.

I began contributing there around February 19.

I was among the earliest contributors during that period, and instead of immediately opening random issues, I started by reaching out to the maintainers.

I wanted to understand their expectations.

I also asked whether they had an AI usage policy for contributors.

The response was interesting.

The maintainer thought it was a good idea and decided to establish guidance around AI-assisted contributions.

The idea was simple: if contributors were using AI, they should be transparent about how they used it and which parts of their work involved AI assistance.

I liked that approach.

Over the following weeks, I actively contributed to Joplin while continuing my work at Sugar Labs.

I opened approximately 18 issues and had around 13 PRs merged.

Balancing both organizations wasn't easy.

I was attending meetings, investigating issues, submitting fixes, reviewing feedback, and keeping up with college.

Some days were genuinely exhausting.

But it meant I wasn't depending on a single opportunity.

If you're preparing for GSoC, this is one thing I'd recommend considering:

Choose two organizations you genuinely want to contribute to, rather than putting everything into one option.

Of course, only do this if you have enough time to make meaningful contributions to both.

March: Building a Proposal That Actually Stood Out

By March, I had spent nearly two months actively contributing.

I understood the community, had interacted with maintainers, and was familiar with the technical direction of the project.

Now came the proposal.

And I knew I didn't want to rush it.

One thing I'd noticed about GSoC applications was that many contributors started writing proposals quite close to the deadline.

I decided to do the opposite.

I started preparing my proposal roughly a month in advance.

My thinking was simple.

If I gave myself enough time, I'd have more opportunities to identify missing details, improve my ideas, build something meaningful, and get feedback.

Especially for an AI-related project, writing an impressive-looking proposal had become relatively easy.

Anyone could ask an AI model to produce a long, polished technical document.

I needed to show something beyond polished writing.

I wanted my proposal to demonstrate that I genuinely understood the project and could execute it.

So I spent time on the details.

I structured the document carefully, explained the architecture, added screenshots, used diagrams and arrows wherever they made an explanation clearer, and broke the implementation into manageable phases.

I also built a working demo.

I didn't want the proposal to be just a description of what I might build.

I wanted the maintainers to see what I was already capable of building.

I even included a separate Notion timeline to make it easier to track the planned work.

There was another small detail I deliberately included.

During our community meetings, my mentor had repeatedly emphasized learning by actually doing things.

That idea stayed with me.

So I reflected it in my proposal.

It connected the technical plan with something the community genuinely valued, and it showed that I had been paying attention to our discussions.

Proposal: https://docs.google.com/document/d/1EcbYSfOsAO-7Sar9_KpFHqr_ZADbZsMjp9077ucNlD0/edit?usp=sharing

I kept revising the proposal until I felt that the structure, technical details, screenshots, and presentation were as strong as I could make them.

Later, my mentor told me it was one of the best proposals he had seen.

That meant a lot.

Because I knew how much work had gone into it.

The Final Eight Hours Before Submission

Now comes one of the most stressful parts of the entire journey.

It was the final day of the proposal submission period.

I had already prepared my proposal, built the demo, documented the architecture, and polished everything.

I reached out to my mentor for some last-minute feedback.

That night, he suggested adding version control to the project.

And I remember thinking:

Oh fuck. I have to build this now?

It was an important suggestion.

Version control would allow users to track changes and manage different revisions of generated activities.

But adding it to the existing demo at the last minute wasn't exactly part of my plan.

Still, I decided to try.

I used AI assistance to accelerate parts of the implementation, worked through the changes, updated the demo, and recorded another video showing the new functionality.

The entire process took roughly eight hours.

I was stressed, exhausted, and constantly thinking about the deadline.

But I managed to include the improvements before submitting.

Looking back, this was probably one of the clearest examples of how seriously I was taking the application.

Not because working at the last minute is something to celebrate.

But because I was willing to respond to meaningful feedback, even when implementing it was difficult.

And finally, the proposal was submitted.

April 4: The Decision That Changed Everything

By this point, Sugar Labs had received an enormous amount of contribution activity.

I remember seeing approximately 700 open pull requests.

And naturally, contributors were continuing to submit more.

I started thinking about something.

I could keep raising PRs, trying to remain one of the most active contributors, and competing on contribution numbers until selection.

But for how long?

It was becoming exhausting.

And I wasn't sure that submitting more PRs was necessarily the most valuable thing I could do for the organization.

So during a meeting around April 4, I suggested something different to my mentor, Walter Bender.

What if I helped review and organize the pending pull requests?

I could go through the contributions, identify useful changes, document my findings, and make it easier for him to decide what should be merged.

He liked the idea.

So I created a document to track the PRs I had reviewed and recommended.

Initially, there were around 10 entries.

Then 20.

Then 40.

And it kept growing.

I was checking whether the changes made sense, whether they were useful, whether they had problems, and which contributions deserved closer attention.

Walter was still responsible for the final review and merge decisions.

But I was helping reduce the burden.

Something interesting started happening.

Other contributors began tagging me in their PRs and asking me to review their work.

My role in the community was changing.

I wasn't just another contributor submitting code.

I was helping the maintainers manage contributions from everyone else.

From 700 Open PRs to Around 60

Over approximately two weeks, the number of open PRs dropped from around 700 to roughly 60.

During that period, I went through an estimated 800–1,000 pull requests as part of the review and triage effort.

It was intense.

There were days when I spent 16–20 hours working.

I was constantly checking PRs, reading code, updating the review document, answering contributors, and helping move the review process forward.

I wouldn't recommend that kind of schedule as a sustainable way to work.

It took a real toll on me.

But at the time, I knew the application period was approaching its final stage, and I wanted to make the most meaningful contribution I could.

And this entire experience changed the way I thought about open source.

I realized that contributing isn't just about writing code. It's also about helping a project and its community function better.

Code review, triage, maintainability, communication, and helping other contributors are all valuable engineering work.

In fact, some of those activities can have a much broader impact than another small code change.

April 19: I'd Done Everything I Could

Around April 19, I understood that the organization was approaching the point where its selection recommendations would be finalized.

By then, I had:

• Contributed consistently since January.

• Worked on performance improvements and production issues.

• Built relationships with maintainers through actual work.

• Created a detailed technical proposal and working demo.

• Incorporated last-minute mentor feedback.

• Helped review and organize hundreds of pull requests.

• Contributed to Joplin alongside Sugar Labs.

I knew I had given this application everything I reasonably could.

People in the community had also become very encouraging.

Some seemed convinced I would get selected.

But I knew nothing was guaranteed until the official announcement.

And that uncertainty was difficult.

April 21–30: The Waiting Was Worse Than I Expected

Once the main application and review work was over, I reduced the time I was spending on GSoC contributions.

My college exams were approaching, and I needed to get back to studying.

But mentally, I was still thinking about GSoC.

What if I don't get selected?

What if the organization receives fewer slots?

What if something unexpected happens?

I knew my proposal was strong.

I knew my contributions were meaningful.

I knew the maintainers appreciated my work.

But I also knew that selection wasn't entirely in my hands.

And that's probably what made the waiting so stressful.

The previous weeks had already taken a toll on my mental health. I was exhausted from balancing two organizations, college, technical work, and the pressure I'd put on myself.

At some point, I had to accept that I'd done my part.

The rest was no longer something I could control.

April 30: The Selection Email

Then April 30 arrived.

There had already been some discussion around the selection data, and I was beginning to feel that things might work out.

But I still wanted to see the official confirmation.

And finally, I received the email.

I had been selected for Google Summer of Code 2026 with Sugar Labs.

After almost four months of contributions, countless hours of debugging, hundreds of code reviews, a proposal I'd spent weeks preparing, and a lot of uncertainty, it had finally happened.

I had also made significant progress with Joplin and received a positive selection outcome there, but Sugar Labs was my first priority.

So that's what I chose.

I was going to build the AI-powered activity generation project that had caught my attention back in January.

The very project that made me decide to try GSoC again.

That felt pretty special.

What This Journey Taught Me

Looking back, I think the biggest difference wasn't the number of PRs I submitted.

It was the way I approached contributing.

When I started, I wasn't simply trying to maximize my GitHub activity.

I spent time understanding the organization, its people, its problems, and what meaningful contributions actually looked like.

When performance mattered, I worked on performance.

When production broke, I investigated the issue.

When the proposal needed improvement, I built a demo and kept iterating.

When maintainers were overwhelmed by pull requests, I helped review them.

And when I received feedback, I tried to act on it.

None of those individual things guaranteed selection.

But together, they helped me become someone the maintainers could trust.

If there's one thing I want people preparing for GSoC to understand, it's this:

Don't contribute just to get selected. Become someone the organization genuinely benefits from having around.

Also, don't confuse the amount of time you spend working with the value you create.

I pushed myself extremely hard during this period, and there were definitely things I could have managed better.

You don't need to sacrifice your mental health or work 20 hours a day to be a valuable open-source contributor.

Consistency, technical depth, communication, and choosing the right problems matter far more than simply being online all day.

For me, this journey started on January 4 with a small contribution.

It eventually turned into performance engineering, production debugging, proposal design, working with maintainers, and helping manage a large volume of community contributions.

And on April 30, it ended with a selection email.

Or maybe that's not quite right.

Because getting selected was only the beginning of actually building the project.

And that's the part I was most excited about.

From January 4 to April 30. One hell of a journey.

See you in the next one.