How I Got Selected for GSoC with OpenWISP
Hi, I’m Deepanshu Sahu. In this post, I share my journey to getting selected for Google Summer of Code (GSoC) with OpenWISP and the practical lessons I learned along the way.
1. My Background
Before I started contributing to open source, my technical experience was limited. I had completed a 3-month internship working with Python and Django, and I had built a few small projects while following the Namaste React course by Akshay Saini.
That was it.
I didn’t have deep system knowledge, I hadn’t understood any large codebases yet, and I had never collaborated on real production software. Most of what I knew came from tutorials and personal projects. I could build things that worked, but I didn’t yet understand how real-world software was designed, reviewed, and maintained at scale.
2. How I Shortlisted Organizations and Chose OpenWISP
I started by filtering GSoC organizations based on Python and Django, since that was the stack I was already comfortable with. From that filtered list, I joined the community channels of multiple organizations to understand how active and competitive they were.
Very quickly, it became clear that large organizations like the Django Software Foundation, Python Software Foundation, PostgreSQL, Chromium, Google DeepMind, OWASP, and Zulip were extremely competitive. They had a large number of active contributors, many of whom already had months of open-source experience. Breaking into these ecosystems within a short time frame would have been difficult for me.
While exploring different organizations, I noticed an important pattern: project ideas that don’t get a contributor in one year are often repeated the next year. This is a strong signal. It tells you where competition is lower and which projects are realistic targets. By checking past idea lists, you can estimate crowd size, competition, and plan your contributions around a specific project.
An interesting fact is that many open-source organizations struggle to find enough capable contributors. A lot of projects remain unimplemented, not because they lack value, but because there aren’t enough contributors with the time and consistency to carry them through. There is no lack of projects coming in GSoC; there is a lack of good, consistent contributors.
When I looked at OpenWISP, I saw that out of five proposed ideas in the previous year 2024, only one had been successfully completed. I already had a clear preference for a specific project, which made it easier to align my contributions with that idea. On top of that, the development documentation was clean and well-written. I was able to set up the project in about five minutes, and the codebase felt approachable and easy to understand for someone at my level.
Note: I strongly recommend using a Linux Debian-based distribution for open-source work. If you’re on Windows, a dual-boot setup with Ubuntu helps a lot (Mac users don’t need to worry). Most open-source projects are Linux-first, and their setup guides and documentation are usually written with Linux environments in mind.
3. Now the real contributions started
After finalizing OpenWISP, my first step was to look for good first issues. I quickly realized that most of them were either already picked up or actively being worked on. Instead of waiting, I chose a different approach.
I picked a good-first-issue where a pull request was already opened but had no activity for 3–4 weeks. The advantage was that the review comments were already there, which made it easier to understand what was expected and how to implement the fix correctly. I followed the same approach for two or three similar issues, such as small changes like updating text to uppercase, adding a simple browser test, or modifying image labels. These were simple, but they helped me understand the workflow, testing setup, and review standards.
After that, I wanted to move beyond small fixes and start making serious contributions. I began looking for issues labeled as features and picked one in my target project repository. The task involved updating a library dependency to its latest version. This wasn’t a simple bump; the update introduced breaking changes that affected multiple parts of the project. To handle this, I went through the release notes in detail, understood what had changed, and updated the code accordingly. I used ChatGPT to clarify some of the changes while implementing the fix. After submitting the pull request, I was asked to add browser tests to cover the new behavior, which I did. Once the PR was merged, a mentor directly messaged me saying they liked my work on this PR 🎉. That recognition mattered a lot.
With that confidence boost, I started contributing more consistently. I also helped maintainers with ongoing maintenance work, especially dependency updates. Around the same time, Python 3.13 and Django 5.2 were released, and the maintainers wanted all repositories updated, refactored where necessary, and kept backward compatibility intact. Picking up these tasks turned out to be a great way to build trust and increase visibility. I also became more involved in the day-to-day development activity of the project, participating in discussions, helping clarify issues, reviewing context for others, and assisting new contributors when possible. This made me feel more like a part of the community. Over time, I realized this matters just as much as code: maintainers look for contributors who help move the project forward as a whole, not just those who open pull requests.
Get Deepanshu Sahu’s stories in your inbox
Join Medium for free to get updates from this writer.
From there, I kept picking issues one after another and contributing as much as possible before writing the proposal. By the time I started working on my GSoC proposal, I already had 3 issues reported and 14 pull requests merged, which was more than any other contributor at that time. I didn’t do this to optimize my chances; I did it because I genuinely started enjoying the work. Every issue came with a new technical challenge, and each contribution pushed me to learn something new.
4. Writing the Proposal and Getting Selected
Contributions matter more than the proposal. However, when you’re competing with someone who has a similar level of contributions, the proposal can make a decisive difference.
In my case, OpenWISP already had a well-defined proposal template and clear questions in its documentation, which helped a lot. I focused on answering those questions honestly and explaining every part of the project in detail. I included screenshots showing where new code would be added, built a small prototype to demonstrate how a critical feature would work, and clearly described the technical flow. If you’re interested, you can find my full proposal linked in the Experience section of my LinkedIn profile.
Where UI changes were involved, I added Figma designs covering different screen sizes. I also defined a clear week-by-week timeline, with specific outcomes and deliverables expected at the end of each week. After completing the draft, I shared it with the mentors, incorporated their feedback through multiple review rounds, and finally submitted the proposal to the official GSoC portal. A few weeks later, I got selected 🥳.
5. Advice for new contributors
After joining an organization’s community channel, don’t ask mentors to find an issue for you. Find one yourself and start working on it. Some organizations do assign issues when asked, but showing initiative by identifying a problem and attempting a fix on your own makes a much stronger impression.
You should already know the basics of the technology stack on which the project is built. Asking questions like “What is the Django admin password?” in a developer channel only signals that you haven’t done basic groundwork. That kind of question hurts more than it helps.
While working on a fix, don’t rely entirely on AI to do the work for you. Before opening a pull request, you should be able to confidently answer these questions yourself:
- Does this change actually fix the issue? Have I tested it properly?
(I was personally called out once for not testing after addressing review comments just to get a PR merged faster.) - Do I understand every change I made, what each line does, and why it’s needed?
- Is there a better or more idiomatic way to implement this fix that matches the existing code structure and patterns?
- Have I avoided unrelated or unnecessary changes?
- Are tests written correctly, and do they fail without the fix and pass with it?
How many PRs do you need to get selected? There’s no single right answer. I got selected with 14 PRs, while some fellow contributors were selected with two or three substantial contributions, or even one major contribution paired with a smaller one. What matters most is visibility and impact, not the raw number of pull requests. Solving a serious, high-impact issue puts you in a much stronger position than submitting four or five trivial “good first issues.” A good strategy is to use one or two small issues to learn the contribution workflow and review process, then focus on delivering at least one meaningful, high-impact contribution. That’s what mentors remember and what actually influences selection.
Please don’t submit AI-generated pull requests hoping they’ll get merged without you understanding the code. Mentors are already flooded with low-effort, AI-generated PRs. These are instant red flags and are often ignored or closed without review.
Finally, be respectful of reviews. Address comments carefully and as promptly as possible. Maintainers are investing their time to review your work, and they usually want to get things merged efficiently. Treat their feedback seriously, as professionalism matters more than you think.
6. Selection Reality
If you ask me how hard it is to get selected, I’d say it’s moderate to easy, apart from a few highly competitive organizations. Every year, there are more projects than selected contributors. If you choose the right organization, contribute consistently, and genuinely engage with the community, getting selected is not out of reach.
GSoC isn’t about being the smartest person in the room. It’s about showing up regularly, doing the work, and earning trust over time. If you’re willing to put in focused effort in the right direction, this is achievable for almost anyone.
