How I Got Selected in GSoC 2026

From losing Summer of Bitcoin by one edge case to KDE/Kdenlive contributor to Google Summer of Code 2026. The full story, the grind, the silence, the dashboard moment, and a full no-bullshit guide at the end.

June 23, 2026·29 min read·—·view raw
gsocopen-sourcekdekdenliveguide

okay so my site says this is a 29 min read lmao. basically a full git clone of my whole gsoc journey, no --depth=1 shallow stuff. it's long, i'm not gonna lie. read it in chunks, git stash and come back, whatever works.

I opened the GSoC dashboard not expecting to be in it.

No email had come. I'd refreshed my inbox a few times, told myself it was fine, and then kind of half-convinced myself I hadn't made it. So when I finally opened the dashboard anyway, almost just to close the tab and move on, and saw I was in, I just sat there for a second.

That's the moment. That's the one I keep coming back to.

But that moment only happened because of everything that came before it, and that's what this post is actually about.

If you're here for the guide and not the story, scroll down to the big "A No-BS Guide to Starting Open Source" section at the bottom. It's the thing I promised on X, and honestly it's the most useful part.

Where I StartedCopied!

I'm a second year B.Tech CSE student at IIT Jodhpur. Going into early 2026, I'd worked on side projects, learned Python, done some web dev, used Linux daily (Fedora + Hyprland), and spent a lot of time breaking and fixing random things. What I hadn't done was seriously contribute to open source.

I'd tried. A couple of GitHub issues, one or two PRs that went nowhere. The usual beginner experience of cloning a massive repo, spending three hours just getting the dev environment to work, and then having no idea where to actually look.

I wasn't chasing easy merges. I wanted to understand how real software gets built. To read other people's code, get actual reviews from developers who knew what they were doing, and become okay with not understanding everything immediately. That last part took a while.

The honest picture of where I started: I thought contributing meant "find bug -> fix bug -> PR merged." What it actually looked like was opening a file and getting confused. Opening another file to make sense of the first one and getting more confused. Reading the docs, convincing myself I finally understood, then running the project and watching nothing work. Half a day gone just fixing the environment. Going back to the code. And then, eventually, understanding one single function and feeling like Einstein for about thirty seconds before the next file reset me to zero. Then doing the whole thing again the next day.

Wagtail, Zulip, and Learning How Open Source Actually WorksCopied!

My first real contributions happened in Wagtail CMS and Zulip.

The Wagtail stuff started with bakerydemo, their sample project, because I needed it running locally to test changes. I broke the setup twice, re-cloned from scratch, spent an embarrassing amount of time on fixture exports, and got my first PRs out. Not impressive PRs. A docker-compose -> docker compose change in a Makefile that got merged, and a fixture update on bakerydemo that's still open as I write this. The kind of thing that doesn't look like much but teaches you the whole contribution loop: clone, set up, find issue, change, commit, PR, respond to review, iterate.

Zulip was where I learned how maintainers actually think. My PR there was a CSS alignment fix, group pills in the compose banner were vertically misaligned. The fix seemed obvious at first. vertical-align: baseline, screenshot attached, done. Then the reviewer asked why the underline was overflowing. I hadn't even noticed the underline. I slapped on a CSS workaround, they rejected it and asked for the root cause.

The root cause was whitespace inside a Handlebars template. Whitespace text nodes inside the <a> tag were causing the overflow. Not CSS. The template. I changed it, they asked for a separate commit, asked me to clean my commit history, pointed out a missing period at the end of a commit title. A period.

That PR never got merged. I dropped it during exam season and a maintainer ended up closing it and finishing it themselves. That one stung. But I learned more from that failed PR than from both merged ones in Wagtail. Interactive rebase, commit discipline, git push --force-with-lease, how to reference issues properly. I learned that OSS maintainers often test your process as much as your code.

The biggest takeaway from this whole phase wasn't technical. It's that open source isn't just code. It's people. Maintainers, contributors, reviewers, discussions. The code is just the weird artifact everyone gathers around.

The KDE Detour That Became the Main ThingCopied!

I started contributing to KDE not because I had a plan, but because I found the KDE Developer Tutorial and Article site and thought it was genuinely cool.

I didn't care about Krita or digiKam. I wasn't excited about graphics engines or image editors. I was into websites, tooling, developer experience. The site had real work to do: keyboard navigation, text fragments, lazy loading, search improvements. I made around 10 MRs there, learned how KDE's GitLab workflow operates, got reviewed by Carl Schwan, and started actually feeling comfortable in the codebase. None of this was strategic. I just liked working on it.

Then February 9th happened and I realized organizations would be announced around February 18th and I was, by my own estimation, very, very late.

The spiral was fast:

"People have been contributing for years."
"I only have one month."
"I already missed my chance."

I went through years of KDE GSoC projects looking for recurring repos I could contribute to. Kept landing on Krita and digiKam. Spent a few days trying to convince myself I could get excited about image processing algorithms. Couldn't.

Then I had the actual important realization: I wasn't strategic enough to force myself into a prestigious project. The reason I had 10 MRs on the developer tutorial site while struggling to make a single PR anywhere else was simple. I found it interesting. Enjoyment turned out to be a load-bearing part of the whole thing.

So I looked at what the developer tutorial site was most related to, and landed on Kdenlive. And that's when it actually clicked, because I use Kdenlive. It's the video editor I open basically every day for editing my own stuff. Seeing it sitting right there in the KDE project ideas list genuinely made me happy. This wasn't some random prestigious repo I was forcing myself into. It was a tool I already knew from the user side, that I already had opinions about, and the idea of contributing to the thing I use every day felt exciting instead of like a chore.

Then I found the "Improve Effect Widgets" idea. Read it and immediately started thinking about how the existing CurveParamWidget worked and why switching channels wiped your curve data. When you read an issue and your brain just starts solving it without you forcing it, that's the signal. That's the one to follow.

Going From the KDE Docs Site to KdenliveCopied!

Kdenlive is a video editor, and I'd been using it as a user for a while. But using something and understanding its codebase are completely different things, and I had no idea how any of it worked under the hood. The thing that gave me a way in was that the codebase is Qt/C++, which I'd already been reading through my KDE docs work. And the problem itself was interesting: three clear UI gaps that needed real engineering solutions, not patches. It helped a lot that I actually knew these effects from the user side, so I understood why they were annoying in the first place.

The Curves effect had no per-channel memory. Switching from Red to Green wiped whatever you'd drawn. The Gradient effect was hardcoded at two color stops. The Time Remapping panel had linear-only transitions with no easing. These weren't vague "improve UX" suggestions. They were specific, bounded, solvable problems.

I built my environment. Installed dependencies. Got Kdenlive building locally. Then started actually finding and fixing issues, partly to contribute, partly to understand the codebase deeply enough to write a real proposal.

The first MR was missing HD-ready (1366×768) project profiles. Mundane, but it needed me to understand how Kdenlive's profile system worked, how MLT handled them, how the UI read them. (MLT is the multimedia framework Kdenlive is built on top of, it's the engine that actually does the video stuff underneath.) MR !824.

Then MIME types in the desktop file. Kdenlive wasn't showing up as an option when opening video files from file managers because its .desktop file only registered application/x-kdenlive. Fixed. MR !826.

Then duplicate profiles in the New Project dialog. This one needed me to actually read ProfileRepository::refresh(), find a two-compounding-bug situation (MLT ships duplicate profile files AND refresh was being called twice), and rewrite the deduplication logic. MR !827.

Then configurable clip type colors, a settings UI change that meant touching the timeline controller. This one got reviewed and merged by Jean-Baptiste Mardelle, the lead Kdenlive maintainer, the guy who's basically been running the project for years. Everyone just calls him JB. That was the first time he merged my code, and it mattered a lot more to me than the MR itself did. MR !831.

Then the tab order bug in the Render dialog. Bug #487883, tagged junior-jobs, assigned to JB himself. The fix was entirely in a .ui file but needed me to understand how Qt Designer's tab order mode worked and manually map 30+ widgets. MR !835. After this one, a community contributor named luzpaz left a comment I still think about: "Thanks so much for fixing a ticket I tried to fix but wasn't successful doing so."

The Proposal, the Mentor, and the Gap in CommunicationCopied!

I submitted the proposal on March 31st. The night before the deadline, pushing edits until it felt right.

JB had been sick and reviewed it later. On April 13th he sent feedback on Matrix (that's the chat platform KDE uses, like a Discord/Slack thing): use avfilter.curves instead of multiple frei0r.curves effects for the curve editor, look into speed_map instead of time_map for the speed ramp. Specific, technical feedback. The kind you only get when someone actually read the proposal.

I didn't reply.

Not for two weeks. Exams, yes, but still. This was my mentor, the person whose approval mattered most for selection, and I left his feedback just sitting there. He eventually emailed me asking if I even had Matrix access.

That was a real "you messed up" moment. I'd dropped the ball at the worst possible time. I replied immediately, acknowledged the feedback, updated what I could.

The lesson there was simple: maintainer communication is part of the contribution. You can write great code and miss your window because you went silent.

The Things That Actually Happened Along the WayCopied!

My laptop died for two weeks. Not metaphorically. The hardware stopped working. I was mid-contribution, mid-bonding-period, with a build environment that didn't exist on any other machine. I came back, set everything up again, kept going.

Summer of Bitcoin happened before GSoC results, and that one hurt in a way I still think about. I didn't just get a rejection email. I'd actually made it into the Challenge Round, which is a four-week hands-on Bitcoin bootcamp where you learn Bitcoin by solving hard challenges, and you only advance each week if you clear the bar. So I was in it. Solving real problems, week after week.

Then came a challenge where you had to pass all the public and hidden test cases. I passed 34 out of 35 hidden test cases. One failed. A small edge case I'd missed. One test case out of thirty-five, and it knocked me out.

I cannot describe how sad that felt. So close, on something I'd genuinely poured myself into, and it was over because of a single edge case. In that moment it felt like everything was just done. Like all of it had been for nothing. If you've ever lost something by the smallest possible margin, you know exactly the feeling I'm talking about.

I bring this up because it matters for the rest of the story. A loss like that messes with your head right before another result comes in. It makes the next thing feel like it's either going to confirm that you're not good enough, or contradict it, and you have no idea which until the result actually lands. I was carrying that one edge case around with me when the GSoC results came.

I also made around 10 documentation MRs on the KDE developer tutorial site before ever touching Kdenlive. Carl Schwan reviewed all of them. When the Marknote GSoC project I'd originally considered got taken by contributors who had two months head start on me, Carl offered to put in a word for me with another mentor. He remembered the work.

There's a version of this story where I'd been smarter and more strategic from the start. Picked Kdenlive earlier, gotten more Kdenlive MRs in before March. That version probably had more margin. But the version that actually happened needed the docs contributions to earn Carl's trust, and Carl's trust to get referred toward Kdenlive with some credibility. The longer path ended up being the necessary one.

By the time results came out, the contribution count across all repos was real: 7 merged Kdenlive MRs, around 10 KDE documentation MRs, and an upstream MLT framework PR (#1222) for a subtitle metadata regression I'd traced all the way into MLT itself. That last one only happened because I was reading deeply enough to notice the bug wasn't in Kdenlive at all.

That MLT PR is worth being honest about, because it didn't go the way I wanted. I'd put the fix in the wrong function. MLT maintainer Dan Dennedy closed it with a comment that, paraphrasing, said this doesn't compile and it looks like you (or your AI) meant to change a different function, so he'd apply the change there himself and close this. That stung a bit, the "or your AI" part especially. But here's the thing: he was right, he took my actual fix, put it in the correct place (find_default_streams()), and the bug got fixed upstream. The subtitle stream metadata that was missing now shows up correctly. So the contribution landed, just not with my name on a green "merged" badge. That happens. The fix mattering more than the credit is a mindset that'll save you a lot of ego damage in open source.

The "Identify Gaps" FeatureCopied!

One of the most interesting contributions from the pre-selection period was implementing "Add Markers at Gaps", a feature to detect silent gaps across timeline tracks and create ranged markers at them. Bug #352409, filed in 2015.

The original bug reporter, Bernd Jordan, had left a detailed spec on what the feature should do. Eugen Mohr reviewed the MR across multiple rounds, asking edge case questions, pushing on the implementation until it was right. The algorithm ended up being a union-of-intervals approach across all video tracks. Not obvious, not trivial, but the right solution once you understood what "gap" actually meant across multiple overlapping clips.

Bernd's comment after it was done: "a great new function." From someone who'd been waiting 11 years for that fix, that was the comment I saved.

April 30thCopied!

No email came.

I'd been checking since the morning. By the afternoon I'd stopped expecting anything. I'd told myself the work had been good regardless of the outcome, which was true but felt thin.

I opened the dashboard anyway. Figured I'd close the tab and actually stop checking.

I was in.

GSoC 2026, KDE Community, "Improving Effect Widgets for Kdenlive." 350-hour large project, 12 weeks, mentored by Jean-Baptiste Mardelle.

The email came in later that night and made it feel real in a way the dashboard somehow hadn't.

The X post I wrote that night was the most honest thing I could think of: "opened the gsoc dashboard fully expecting a rejection. saw I was in." That was the whole story in six words.

What the Coding Period Has Actually Been LikeCopied!

The project is three widgets: a tabbed per-channel RGB curve editor (R/G/B/All tabs with colored curves and GIMP-style ghost overlays), a multi-stop gradient editor, and a Bézier speed ramp UI.

Four weeks in: the Curves widget is done. 48 unit tests, all passing. Per-channel tab switching with preserved curve data, colored axes, ghost overlays showing the other channels, editable point coordinates, a reset button. The code is in MR !887 and actively under review.

Along the way: fixed a 13-year-old UI bug that showed up while I was digging through the codebase. Also built MLT 7.38.0 from source when it was blocking the build, which is the kind of thing you don't put on a resume but takes half a day and teaches you more than you'd expect.

JB's review process is thorough. Specific comments on implementation choices, suggestions on architecture, expectations about test coverage. The kind of mentorship where you actually become a better developer, not just someone who shipped a feature.

What I'd Tell Someone Starting NowCopied!

Don't optimize for prestige first. Optimize for interest. The reason I had 10 MRs on a KDE documentation site while struggling to make one PR in the "impressive" projects was that I actually cared about it. That genuine interest compounded. It produced contributions without willpower, which produced trust with maintainers, which produced the path to everything else.

Start earlier than you think you need to. I felt late in February with two months left. That's not late. But late is real. The people who'd been contributing to Marknote for two months before I touched it had an advantage I couldn't close in two weeks.

Go deep in one place rather than shallow in five. Ten MRs in one repo means you understand how it works, who the maintainers are, what they care about, where the real problems live. That depth is what produces a proposal with actual technical specificity instead of a vague "I will improve X."

Maintainer communication is not optional. Reply to feedback. Reply promptly. If your mentor leaves technical notes on Matrix and you go silent for two weeks, you've created a problem that has nothing to do with your code quality.

And finally: the selection isn't one thing. It's an accumulation. Every MR that got merged, every review I responded to thoughtfully, every time I traced a bug back to its actual cause instead of patching the symptom, all of it was happening in parallel. There was no single moment that decided it. There were hundreds of small ones.

The dashboard moment felt like a surprise. Looking back, it wasn't.

A No-BS Guide to Starting Open SourceCopied!

Okay, so this is the part I actually promised.

After I posted my GSoC story on X, it kind of blew up. And then I tweeted that I'd write a full guide on how a complete beginner gets into this, and that tweet blew up even harder. So hard that X temporarily slapped a label on my account and killed my external reach for a bit, lol. So if you saw that post and then couldn't find me, that's why. Anyway, I promised the guide, then it got delayed because I was heads-down on a project and on GSoC itself (the actual coding period doesn't pause just because you promised the internet a blog post), plus the whole temporarily-reach-limited-account thing. But here it finally is.

People keep asking me the same questions. In DMs, in replies, in random LinkedIn messages at midnight.

"How do you find orgs?"
"How do you read 1000 lines of production code?"
"How do you even start?"

So here's everything, in one place, written the way I wish someone had written it for me.

First: GSoC Is Not JEECopied!

This is the most important thing I can tell you, and most guides skip it entirely.

JEE is a competition. There's a rank. You're measured against every other person who sat in that hall. The person next to you doing better is directly bad for you.

GSoC is not that.

There's no national rank. No cutoff percentile. The guy contributing to Kubernetes is not competing with you for a Kdenlive slot. Two people applying for the same project slot are competing, yeah, but the pool is small, and the selection is based on your proposal quality and your pre-existing contributions to that specific project, not a test score.

More importantly: the people who get selected aren't necessarily smarter than you. They found a project they actually liked, contributed consistently, wrote a good proposal, and communicated well with their mentor. That's the whole formula.

I know someone who was contributing harder than me in my org. Pushing PRs constantly, working 24/7. I'd genuinely mentally prepared to lose to him. He didn't get in. His proposal was weak. I'd spent weeks on mine. Turns out that mattered more than raw commit count.

GSoC selects for the person the maintainer wants to work with for 12 weeks. Be that person.

The Actual Starting Point Nobody MentionsCopied!

Most people get stuck before writing a single line of code. They open a massive repo, see thousands of files, and freeze.

Here's what actually helps:

Don't start with the codebase. Start with the product.

Use the software you want to contribute to. Actually use it. Break it. Notice what's annoying. Notice what's missing. Notice what makes you think "this seems wrong."

That feeling, "this seems wrong," is worth more than any good first issue label. Because when you go find the issue tracker and search for what you noticed, you'll find a bug report filed in 2018, never fixed, with three people saying "me too." That's your entry point.

I found Kdenlive through this. I was already using it for a project, noticed some profile settings behaving oddly, opened the issue tracker, and started reading. By the time I wrote my first MR it wasn't because I was hunting for something to fix. It was because I'd actually seen the problem.

Finding GSoC OrgsCopied!

The tactical answer: go to gsocorganizations.dev and filter by tech stack + recurring organizations. Organizations that have been giving projects for 3-4 years in a row are safer bets than first-timers. They know how to run the program, their mentors are experienced, and their idea lists are usually real work, not experiments.

But the better answer is: find something you already use.

I spent time on the organizations site trying to strategically pick the highest-probability org. Gave up. Then remembered I used Kdenlive and went to check if KDE had a GSoC project. They did. That took 10 minutes and led to a selection.

The projects you'll contribute best to are the ones where you already understand why they exist. You don't need to be an expert user. You just need enough context that when you read the issue tracker, things make sense.

One more thing on orgs: ignore the self-raise-self-solve thing. Some projects work that way. Kdenlive had a 12-year-old bug sitting in its tracker that nobody had touched. I solved it. You don't need to manufacture your own issues when real ones exist.

Git: The Actual PrerequisiteCopied!

Before anything else, if you don't know git, stop and learn it first. And I don't mean "I've heard of git." I mean actually learn it. Cloning a repo, making branches, committing, pushing, rebasing, resolving merge conflicts, and writing commit messages that aren't "fixed stuff."

The bare minimum you need before touching any open source codebase:

  • git clone, git checkout -b, git add, git commit, git push
  • git fetch, git rebase (not just merge, actually learn rebase)
  • git log, git diff, git stash
  • git rebase -i for cleaning up your commit history
  • git push --force-with-lease for after a rebase

I'm not exaggerating about the commit discipline part. A Zulip maintainer literally pointed out a missing period at the end of one of my commit messages. Maintainers care about this stuff way more than you'd expect coming from college projects where nobody reads your commits. Learn it properly once and you never have to think about it again.

What actually worked for me: the Pro Git book (it's free, online) for the concepts, and then just practicing on a throwaway repo until the commands stop feeling scary. You don't need to memorize everything. You need to not panic when a rebase conflict shows up.

How to Read a Codebase You Don't UnderstandCopied!

This is the question I get asked the most. And the honest answer is: you don't read all of it.

You search for the specific thing you're trying to fix.

Here's the process I use:

Step 1: Find the thing in the UI, the error, or the behavior.
You're fixing a bug. Something specific is wrong. Name it precisely. Not "audio is broken" but "when playback stops, the playhead jumps back and produces audio scrub."

Step 2: Search for keywords related to that behavior.
Use grep -r "keyword" src/ or whatever search your editor has. Not the whole codebase, just the thing you're looking for. "playback", "stop", "seek", "scrub." You're looking for the code that touches what you're touching.

Step 3: Read only those files.
Often it's 200-300 lines. Not 100,000. The codebase is large but the problem lives in a small corner of it.

Step 4: Follow the dependencies.
The function you found calls another function. Read that one. It references a class. Read that one. You're building a map of one small neighborhood, not memorizing the entire city.

Step 5: Look at closed PRs on the same issue.
Someone else tried to fix it before. Why was their PR closed? What was wrong with their approach? What did the maintainer ask for? This gives you more context than any documentation.

I solved the duplicate profiles bug in Kdenlive by reading ProfileRepository::refresh(), a single function, maybe 80 lines, and noticing it was being called twice and that MLT shipped profile files with identical specs. That's it. I didn't understand the whole codebase. I understood that function.

Setting Up a Dev EnvironmentCopied!

This is where most beginners quietly quit, and nobody talks about it. You'll spend your first few hours, sometimes literally days, just getting the project to run locally. That is normal. Everyone goes through it. It is not a sign you're not cut out for this.

The general pattern for most projects looks like this.

First, fork the repo on GitHub/GitLab, then clone your fork (not the original):

git clone https://github.com/YOUR_USERNAME/project-name
cd project-name

Now read the CONTRIBUTING.md and README before doing anything else. They tell you the exact setup steps for that specific project, and they're almost always more accurate than whatever generic tutorial you'd find online.

Then install dependencies. This varies a lot by project: Python projects are usually something like pip install -e ".[dev]", Node projects are npm install (or bun install), and C++ projects use whatever build system they've set up, usually cmake and ninja or similar. The contributing guide will tell you which.

And finally, run the project once to confirm it actually works before you touch a single line of code. You need a known-good baseline, otherwise you won't know whether you broke something or it was already broken.

A few things that'll save you:

  • If setup fails, copy the exact error message and search the issue tracker for it. Someone else almost certainly hit the same wall.
  • Join the project's Discord/Matrix/Slack and ask in the dev channel. Maintainers expect setup questions from new people, that's normal, you're not bothering them.
  • Don't skip getting it running. You literally cannot test your own fix without a working local build, and submitting an untested "fix" is the fastest way to look like you didn't try.

For what it's worth, I built MLT from source at one point because it was blocking my Kdenlive build. Half a day gone. But after that, environment setup stopped scaring me, and that's worth more than the half day cost.

What "Understanding" Actually Feels LikeCopied!

It's not a moment where everything clicks and you suddenly get it.

It's more like reading a file and getting confused, opening another one and getting more confused, reading the docs and thinking you understand, running the project and watching nothing work, fixing the environment, going back to the code, and finally understanding one function and feeling like a genius for a minute. Then you move to the next function and you're confused again. And you just keep doing that.

The learning happens in those tiny increments. Every bug teaches you something the codebase does. Every review comment teaches you something the maintainer cares about. Every failed PR teaches you something about how open source actually works.

I had a PR in Zulip, a CSS alignment fix. Seemed simple. The reviewer asked why the underline was overflowing. I hadn't noticed an underline. I slapped on a CSS workaround. They rejected it and asked for the root cause.

The root cause was whitespace inside a Handlebars template. Text nodes inside the <a> tag causing the overflow. Not CSS at all. And I only found that by actually going back, testing, reading the rendered HTML, and staring at it until it made sense.

That is how the learning actually happens. Point by point, mistake by mistake. You don't arrive understanding everything. You arrive understanding slightly more than before.

Finding and Claiming Issues (The Etiquette Nobody Tells You)Copied!

Finding the issue is the easy part. The etiquette around claiming it is what trips people up, and getting it wrong makes maintainers quietly write you off.

But first, the single most important thing: this varies a lot by org, so read the CONTRIBUTING.md and any related docs before you do anything. Don't skip them. Some projects make claiming mandatory. You comment, a maintainer assigns the issue to you, and only then do you open a PR. Other projects don't have any of that ceremony. Kdenlive, for example, has no claiming system at all. You just find an issue, open an MR, and wait for feedback. That's it. So whatever I say below is the general pattern, but the project's own docs always win over my advice.

Here's the general pattern when an org does use claiming:

  • Go to the project's issue tracker and filter by the good first issue or junior jobs label.
  • Read the whole issue before commenting. Including every existing comment. People skip this and then ask a question that was already answered three comments up.
  • Check whether someone is already assigned, or commented "I'm working on this" recently. If so, leave it. Find another one.
  • If it looks free, comment something like "I'd like to work on this, can I be assigned?" and then wait for a response before you start. Don't open a PR out of nowhere on an issue nobody gave you. (Again, only where the project works this way. In a project like Kdenlive you'd just open the MR.)
  • Don't claim five issues at once. In Zulip I watched maintainers actively turn away contributors who hoarded issues and never finished them. One at a time. Finish it, then take the next.
  • If you claim something and realize it's over your head, just say so and unassign yourself. That's completely fine. Ghosting it is what annoys people.
  • No good first issue label on the project? Look for old open bugs that haven't been touched in months. Those are usually genuinely available, and fixing a stale one nobody else wanted looks great. (My Kdenlive entry points were exactly these.)

For the ML/Data Science PeopleCopied!

You're in a different spot but not a harder one.

The projects most accessible to you: ML libraries (scikit-learn, PyTorch, JAX ecosystem), data tooling (Pandas, Polars, DVC), scientific computing (NumPy, SciPy). Pick something you've actually imported in a project.

Your entry points are usually:

  • Documentation improvements. ML projects always have gaps between what the code does and what the docs say. Read the source, find the gap, fix it. This is a real contribution.
  • Test coverage. Find a function with no tests or weak tests. Write them. You'll need to read the function to write accurate tests. That's the whole learning loop.
  • Reproducing open issues. Someone filed a bug. Can you reproduce it? If yes, add a minimal reproduction case to the issue. If no, say that. Either way you've contributed something useful and shown you're active.

The gap between "I know Python and ML" and "I can contribute to scikit-learn" is smaller than it looks. The codebase is large but the individual functions are readable. Start with the functions you've already used.

The ProposalCopied!

Once you've contributed to a project and have some history there, the proposal is where you either win or lose.

A proposal that gets selected:

Is specific. Not "I will improve the curve editor." But "the current CurveParamWidget uses a single CurveModes enum without storing per-channel data, so switching from Red to Green wipes whatever the user drew. I'll add a std::map<CurveModes, QString> m_channelData to preserve state per channel, update the serialization format to avfilter.curves with r='...' g='...' syntax, and add a QTabWidget for R/G/B/All tabs."

That level of specificity tells the mentor you've actually read the code. You can't fake it.

Is realistic. Mentors know how long things take. If your timeline says "implement all three widgets in week 1," they know you haven't thought it through. Break it down into weeks. Include time for review cycles and feedback. Include a buffer.

Sounds like you. Mentors are going to spend 12 weeks working with you. They want to know who you are. Not corporate language. Not AI-sounding paragraphs. Write how you actually talk.

Where you submit it, and what goes in itCopied!

The proposal goes on the official GSoC portal at summerofcode.withgoogle.com, during the contributor application window (usually mid-March to early April, but always check the official timeline for your year).

The sections a strong proposal actually needs:

  • About you. Who you are, your relevant skills, and links to your contributions to this specific project. Keep it short. Nobody wants your life story here.
  • The problem. What's broken or missing right now. Be specific, quote the issue number, describe what currently happens versus what should happen.
  • Your solution. How you'll fix it, in technical detail. Name the files, the classes, the functions you'll touch. This is the section that separates people who've actually read the code from people who haven't. You cannot fake this one.
  • Timeline. Week by week. 12 weeks for a standard project, more for a large one. Be realistic: include review cycles, mentor feedback, and a buffer week. Don't promise three major features in week 1.
  • Why you. Brief, not arrogant. What makes you the right person for this work.

Length: 1500 to 2500 words is typical. Don't pad it. And don't generate it with AI, mentors can tell instantly and it reads flat and hollow. The whole point is for them to hear you.

If you want to see what "specific" actually looks like instead of just being told to be specific, here's my actual Kdenlive proposal. Heads up that the technical details in it are Kdenlive-specific, so treat it as an example of the level of detail, not a template to copy. The real class names and serialization formats are the point, not the content.

And communicate with your mentor before the deadline. Ask technical questions. Show you've been thinking about the implementation. JB gave me specific feedback about using avfilter.curves instead of frei0r.curves, and that kind of early exchange tells a mentor you're engaged, not just submitting a form.

(I dropped the ball here and went silent for two weeks during exams. JB had to email me asking if I had Matrix access. Don't do that.)

The GSoC Timeline (When Things Actually Happen)Copied!

A lot of the panic around GSoC comes from not knowing the calendar. Here's roughly how each year runs. Exact dates shift, so always check the official timeline for your year, but the shape is the same:

  • ~January: GSoC gets announced for the year.
  • ~February: Participating organizations are announced. This is when you find out which orgs actually have projects this year.
  • ~March: Contributor application window opens. You can start submitting proposals.
  • ~Early April: Application window closes. No more submissions, no exceptions.
  • ~Late April / Early May: Results announced. Accept or reject.
  • May: Community bonding period. Meet your mentor, set up communication, get deeper into the codebase. This is not free time, treat it as part of the work.
  • Late May: Coding officially begins.
  • ~July: Midterm evaluation.
  • ~August: Final evaluation and submission.

Here's what that means in practice. If orgs are announced in February and applications close in early April, you've got maybe 6 to 8 weeks to find a project, make real contributions, and write a proper proposal. That is not a lot of time if you're starting from zero. This is exactly why I tell people to start contributing in November or December, before you even know whether the org will participate that year. The contribution history is what makes the 6-8 week window survivable.

Staying Active in the CommunityCopied!

The biggest mistake people make is treating open source as a transaction. File issue, submit PR, done.

The projects where I made the most progress were the ones where I was actually hanging around. Reading the Matrix channel. Seeing what maintainers were frustrated about. Understanding what was blocked, what was actively being worked on, what would be a good fit.

Some things that help:

  • Join the communication channel (Discord, Matrix, Slack, whatever the project uses) and read it for a week before saying anything.
  • When you do say something, ask questions that show you've tried first. "I found X in file Y, it seems related, but I'm not sure because of Z, does that seem right?" is better than "how do I fix this bug."
  • Don't announce that you're contributing for GSoC. Just contribute. Maintainers can tell when someone's there for the stipend versus actually interested.
  • Reply to review comments promptly. A maintainer spent time on your PR. They shouldn't have to chase you for a response.

The people who get selected are usually the ones maintainers enjoy working with. That's a combination of code quality, communication, and showing up consistently.

One Thing Worth Being Aware OfCopied!

I want to mention this gently, because it matters and most guides skip it.

There's a real wariness in open source right now toward low-effort, spammy contributions, and some of it has unfairly rubbed off on beginners in general. It's nothing about who's a better developer. It's just that a few very loud spam waves left a mark, and it helps to know the context so you don't accidentally look like part of the problem.

The most well-known example is the Express.js incident. A big coding YouTube channel put out a Git and GitHub tutorial that, instead of using a practice repo, walked beginners through opening a pull request on the actual Express.js repo, basically adding your name to the README. The video got over a million views, and what followed was a flood of meaningless spam PRs. According to Socket's writeup, contributors called it "an attack on open source" that filled the repo with "pages and pages of UTTER GARBAGE," and maintainers were even getting emailed and harassed over it.

And it shows up in the tooling. In the Express maintainers' own thread about fighting the spam, they noted most of these PRs came from accounts with a repo named "localrepo" and used that as a signal to detect them, and ended up automating away PRs titled "Update Readme.md." When spam gets loud enough, maintainers start pattern-matching it, and you don't want to match the pattern.

It's not just Express or Hacktoberfest either. If you read r/developersIndia or r/Btechtards, people are pretty vocal about the "JEEfication of GSoC," treating an open source experience like a rat race to be "cracked" for a stipend and a resume tag. Mentors talk about being buried in AI-generated slop MRs, contributors going silent the moment GSoC ends, and review replies that are clearly just pasted from an AI. None of that is a knock on the many people doing genuinely great work. It's just the noise you want to make sure you're not adding to.

Here's the thing I keep coming back to, and Theo Browne said it well in his "Don't Contribute to Open Source" video: open source contributions "aren't valuable because they exist. They're valuable because they show that you've run into real problems with software" and fixed them. Open source is not a vending machine for resume points. It's people doing unglamorous, mostly unpaid work to keep software alive, and the spam wave treats their time as free.

So the move is simple. Just don't add to the noise. Specifically:

  • Don't spam "please assign this to me" on every open issue. Claim one, finish it, then take the next.
  • Don't open PRs that just add your name to a README or change one line of whitespace for a green square. That's not a contribution, and maintainers can smell it instantly.
  • Don't follow a YouTube tutorial that tells you to make your "first PR" on a real production repo like Express or React. Practice on your own fork or a sandbox repo.
  • Don't paste AI output into review replies and code you can't explain. Mentors can tell, and being unable to defend your own PR is worse than not opening it.
  • Don't disappear the day GSoC ends. If you only ever contribute during application season, everyone can see it.

And here's the genuinely good news: the bar to stand out is low precisely because of all this noise. The moment you show up with a real fix, a comment that proves you read the code, and basic git discipline, you instantly read as someone completely different from the spam. I felt this directly. The contrast between me and the flood of low-effort PRs probably helped me more than I realized at the time. Be the person who makes a tired maintainer update their assumptions in the good direction. That's a real edge, and it costs nothing but honesty and effort.

On Starting LateCopied!

February 9th, I realized org announcements were expected February 18th and panicked.

"I'm very very late."
"People have probably been contributing for years."
"Maybe I already missed my chance."

I had 10 KDE documentation MRs, 2 Wagtail PRs, and a pending Zulip PR. That felt like nothing.

But here's what that actually was: familiarity with GitLab's contribution workflow, experience getting reviewed, a track record in the KDE org that Carl Schwan remembered when I needed a referral. The "late" period had taught me more than I realized.

You are probably not as late as you think you are. But earlier is always better. Not because of contribution count, but because you need time to actually understand the codebase well enough to write a specific proposal. That understanding doesn't come from reading. It comes from contributing, getting reviewed, and going back in with the reviewer's feedback in mind.

Start now, with something you find interesting, and stay with it.

The One ThingCopied!

If there's a single thing that made the difference for me, not the MR count, not the proposal quality, not the mentor interaction, it's that I ended up contributing to something I found genuinely interesting.

I didn't pick Kdenlive because it was prestigious or because it maximized my selection probability. I picked it because when I read the issue about per-channel curve memory, I immediately wanted to know how CurveParamWidget was currently implemented and why it didn't store the data. That curiosity is what kept me reading for hours. That's what made the contributions feel like learning instead of labor.

GSoC is 12 weeks. The project after that is the whole rest of your career. Find the thing that makes you want to understand how it works.

Everything else follows from that.

Currently in Week 5 of the coding period. The Curves widget is under review, the Gradient widget skeleton starts this week. If you have questions, drop them below or reach out at @xevrion. Happy to help.

Comments