My GSoC Journey: From First Contribution to Selection

I’m Sahil Sarawagi, a student from UIT RGPV Bhopal, and in 2025, I was selected as a Google Summer of Code (GSoC) contributor with GitLab!
In this blog I will share how I went from being curious about open source to contributing to Gitlab — and eventually getting selected for GSoC.

Google Summer of Code (GSoC) is a global, remote program sponsored by Google that gives students the opportunity to contribute to open source projects while being mentored by experienced developers from well-established organizations.

GitLab is an open-core company that provides a DevSecOps platform built on open source — a place where you can manage your entire software development lifecycle, from planning and version control to CI/CD and monitoring. It’s also a huge open-source project with a very active contributor community.

I’ve always wanted to learn directly from experienced people — not just through tutorials, but by seeing how real developers approach and solve real problems. That’s what drew me to GSoC.

It wasn’t just about writing code or adding features — it was about having a mentor who could guide me through their thought process, share feedback through code reviews, and help me grow as an engineer. That was my biggest motivation to apply — to learn how to think like a developer.

Thankfully, I’ve been paired with an amazing mentor, Ayush Billore, who is not only highly experienced but also incredibly patient and supportive. He’s helped me understand how important it is to deeply analyze an issue, explained complex concepts when I was stuck, and always took the time to understand my approach and gave me better view.

How I Got to Know About GitLab (and Got Started with Open Source)

This part of my GSoC journey is kind of interesting.

I was scrolling through YouTube one day, feeling a bit lost. I knew I wanted to get into backend development, but I had no clue which language to choose — Java? Node.js? Something else?

That’s when I stumbled upon a video titled “Get Software Engineering Interviews in 2023” by Scott Stern, and the thumbnail looked really cool, so I clicked it immediately.

Scott is a developer from Silicon Valley and used to work at GitLab. The way he explained things just clicked with me — clear, honest, and super insightful. I binge-watched more of his videos, and I realized he was genuinely passionate about helping people break into tech.

I don’t know what exactly came over me, but I decided to email him with some of the questions that were bugging me at the time.

To my surprise, he replied really quickly, answered all my questions kindly, and even gave me advice on how to get started. (Shoutout to Scott — you're awesome 🙌)

I’m sharing a screenshot of his email here, in case it helps someone else:

Picking Ruby on Rails

One of the things Scott told me was this:

“Frameworks are going to come in and out of style. I want you to focus on being a backend expert regardless of the framework.”

That stuck with me. After a bit of exploration, I chose Ruby on Rails, and honestly, it turned out to be one of the best decisions I’ve made.

I picked it up quickly and built some cool backend projects with it. RoR felt clean, beginner-friendly, and powerful — I wasn’t getting stuck on complex language rules. Instead, I could focus on actually building stuff, I could focus more on backend stuff.

First Steps into GitLab Contributions

After gaining some confidence with Rails and backend development, I thought it was time to try something bigger — contributing to GitLab itself.

At first, it was overwhelming. GitLab is huge. But after spending time browsing through issues, I found one that felt doable — it was fairly simple and only required running a few commands. The best part? The issue had an amazing implementation guide. Big thanks to Michael Becker for writing that guide and helping me through it 🙏

That issue became my first merged MR — and the feeling was unreal!

❓Common Questions I Had (And You Might Too)

💭 “How do I find an issue that’s suitable for me?”

Start by figuring out your interests. Do you enjoy working with the frontend? Backend? APIs? Once you know that, look for GitLab issues with these labels:

Seeking community contribution
Weight: 1
frontend, backend, etc.

These are beginner-friendly. Use the GitLab issue filter and search something like: this
label:~"backend" label:~"weight::1" label:~"Seeking community contribution"

Once you find an issue:

Read the description carefully.
Try to reproduce the bug or behavior locally.
If you understand the issue well enough to explain it, you're already halfway there!

Many issues also come with an implementation guide or linked MRs. That’s super helpful for getting started.

Once you’re confident, comment on the issue and ask to be assigned — and you’re good to go!

💭 “How do I even work in such a huge codebase?”

I totally get it — GitLab is massive.

But here’s the secret: you don’t need to understand everything.

If you’re working on a button toggle, you don’t need to know how GitLab handles authorization. You’ll be working in a small part of the codebase relevant to your issue.

Plus, most issues include:

Related MRs
File paths
Implementation guides

If you’re stuck, ask for help — either in the issue, on the MR, or in the GitLab Discord. The community is genuinely helpful.

💭 “What if I fail to get my MR merged?”

It’s okay to be scared — I was too.

Start by picking a simple issue that you can solve. If you hit a blocker, don’t stay silent — ask questions in your MR. The reviewers are kind and supportive they want to help you succeed.

Even if your MR doesn’t get merged right away, you'll learn a ton — and that’s still a win.

I’ll be writing another blog soon where I share the exact steps and tips I used to find easy GitLab issues — things that helped me solve 4–5 issues and build the confidence to take on more complex and hard issues.

Gitlab Hackathon

GitLab organizes online Hackathons every 3–4 months. These are open to everyone — beginners and experienced contributors alike. You can contribute to GitLab during the Hackathon period, and each merged merge request earns you points. These points can be used to plant trees or redeem GitLab swag like t-shirts, stickers, and more.

I highly recommend checking out the official GitLab Hackathon page for upcoming dates and details.

July 2024 Hackathon

After making my first contribution, I decided to participate in the July 2024 Hackathon. I worked on five issues, all of which got merged — and I ended up securing 11th place on the leaderboard!

It was such a fun and rewarding experience — not just the ranking, but the whole process of exploring issues, asking questions, and pushing fixes.
📌 You can check out the leaderboard and my MRs here: July Hackathon 2024.

January 2025 Hackathon

In January 2025, I took part again and submitted three MRs. Out of those, two got merged within the Hackathon time window. Although it was a smaller participation compared to the last one, it still helped me stay active and continue contributing.

📌 Leaderboard: January Hackathon 2025

💡 Pro Tip: If you’re thinking about applying to GSoC with GitLab, I strongly recommend participating in a Hackathon first — or at least getting a few MRs merged. It gives you practical experience with the codebase, the review process, and helps your GSoC application stand out.

Applying to GSoC

Since I was already an active contributor at GitLab, it was an easy decision for me to choose GitLab as my GSoC organization.

But you might be wondering — how did I find my project idea?

Well, that’s actually pretty simple. GSoC publishes a list of ideas from all participating organizations every year. You can check out GitLab’s 2025 proposed ideas here: View Idea List.

I would say its good idea to keep an eye on gsoc timeline if you want to participate in it.

🗂️ My Filtering Process

GitLab had multiple proposed ideas. I didn’t just pick one randomly — I created a doc and:

Filtered out ideas based on the tech stack I was familiar with.
Further filtered by ideas I clearly understood.
I was left with 3–4 solid options.

Eventually, I chose one that wasn’t very easy to understand. My reasoning was — if an idea looks complex, maybe fewer people will attempt it, and my chances of selection could be higher.

You’re allowed to submit proposals for up to 3 ideas — but I submitted only one: Selected Idea Name

📄 Preparing the Proposal

I began preparing my proposal by:

Reading the main issue and all related issues/MRs.
Studying previous similar MRs to understand how GitLab solved related problems.
Using last year’s selected proposals as references.

Then, I structured the proposal based on my understanding, outlining milestones, deliverables, and technical details. I submitted it on the GSoC portal and hoped for the best.

❓ What About Feedback?

GitLab, being such a large organization, doesn’t usually offer direct feedback on proposals — and you don’t get to interact with your potential mentors during the application phase. This is understandable, as they receive hundreds of proposals.

See this

Change of Plans (Post-Selection)

After I was selected, something unexpected happened — the idea I proposed got deprioritized.

But here's where I got super lucky — my mentor reached out and offered me a new issue to work on instead. This new direction was around building a custom RuboCop Cop for GitLab’s codebase — something I had never done before, but I was excited to learn.

I’m truly thankful to my mentor for giving me a new issue to work on when my original project idea was deprioritized. I genuinely appreciate the opportunity and guidance.

If there’s one piece of advice I could give — it’s this:
Don’t contribute just to get selected for GSoC.
Even if you don’t make it in, your contributions will always mean something. You’ll still walk away with real skills, real experience, and something you can proudly show to the world.

There’s an amazing feeling in knowing that you wrote code that’s being used by thousands of people. That feeling? It never gets old.

And honestly, GitLab is such a great place to contribute.
They value every contribution — no matter how small. The amount of knowledge you gain, the kind of thoughtful communication that happens here, the support from the community — you’ll fall in love with it all. I know I did.

After Getting Selected...

Well, let’s just say this was my exact reaction:

Did I get selected?

Let’s Connect!

If you found this blog helpful or have any questions about GSoC, GitLab, Ruby on Rails, or open source in general — feel free to reach out. I’d love to chat or help however I can!

Gitlab: https://gitlab.com/sahilsarawagi
LinkedIn: https://www.linkedin.com/in/sahilsarawagi/
Twitter / X: https://x.com/SahilSarawagi