What this blog is actually about
Adaptability. Collaboration. Real-World Readiness.
This isn't a flex post. It's a behind-the-scenes look at how I learned to operate in a real distributed team โ with codebases I didn't write, maintainers I'd never met, and workflows I had to figure out on the go. GSSoC'25 wasn't just about open source. It was about proving โ to myself and to the world โ that I can read unfamiliar code, communicate asynchronously, adapt fast, and ship work that gets merged.
Let me paint you a picture. It's a Tuesday evening, and I'm staring at GitHub like it's written in a language I was never taught. Pull requests, forks, upstream, base branch โ it all looked like jargon from a world I wasn't supposed to be part of yet.
And then GirlScript Summer of Code 2025 happened. And everything changed.
Act I: The Part Nobody Talks About ๐
Here's what the typical "open source success story" conveniently skips: the part where you have absolutely no idea what you're doing. I didn't know how to find projects. I didn't know how to get an issue assigned. And I definitely didn't know what a "base branch" was.
As someone who had only ever coded on their own laptop, in their own projects, the concept of working on someone else's codebase felt completely alien. What if I break something? What if they reject my PR? What if my code is embarrassingly bad? The fear was real โ but so was the curiosity.
"The first step into open source doesn't feel like a step. It feels like a leap off a cliff โ and hoping the community is the net that catches you."
How I Cracked the Code (Literally) ๐
I started where most people start: Discord and Telegram. The GSSoC community had active groups, project channels, and contributors sharing wins and struggles in real time. I lurked first โ reading, observing, learning the rhythm of how things worked before jumping in.
Then came the detective work. I'd find projects listed under GSSoC on GitHub, track down their maintainers on LinkedIn, then email them first โ genuinely introducing myself, expressing interest in the project, and asking what kind of contributors they were looking for. Part networking, part research, part courage.
Once in, I'd explore the GitHub issues โ filtering by good first issue or help wanted
โ and find one that matched my skill level. Not too easy. Not impossible. Just right.
Then I'd DM the maintainer on LinkedIn with exactly how I planned to solve it. Not just "can I do this?" but
"here's my approach." That made all the difference.
The Formula That Worked Every Time
Email intro โ Find Issue โ LinkedIn DM (with solution plan) โ Get Assigned โ Fork + Code โ Open PR โ Follow-up DM โ Review + Revisions โ Merge โ
The first time that green "Merged" label appeared on my PR โ I finally understood what all the fuss was about. Your code, living in someone else's project, used by real people. That feeling is genuinely incomparable. It's addictive in the best way.
Act II: The PRs That Shaped Me ๐ง
GSSoC wasn't about the number of commits or the size of the changes. It was about understanding how real-world project collaboration works โ reading unfamiliar code, communicating across time zones, adapting to existing patterns, and being a reliable member of a distributed team. Here's the journey, project by project.
A fully responsive car rental website offering a smooth, modern booking experience across all devices.
My very first open-source issue. On VehiGo's login and signup pages, the logo wasn't rendering โ just the alt
text. And clicking it triggered a 404 error instead of navigating home. A small but genuinely
impactful UX bug affecting every new user on auth pages.
<!-- BEFORE: broken path, no navigation href --> <a> <img src="logo.png" alt="VehiGo"> </a> <!-- AFTER: corrected relative path + home navigation --> <a href="../../index.html"> <img src="../../assets/images/logo.png" alt="VehiGo Logo" class="logo-img" > </a>
A clean, targeted fix with visible impact. Huge shoutout to Akash Shelke โ my mentor for this contribution โ who made the very first step into open source feel smooth and encouraged. ๐
A platform for college students to raise complaints โ anonymously or with identity โ with AI-powered routing to the right department.
A great project without a great README is a locked door for contributors. CrisisBoard's docs needed to be welcoming for the influx of GSSoC contributors. I rewrote the README from scratch: badges with official logos, a step-by-step setup guide, GSSoC-ready contribution guidelines with branching and commit conventions, and a cleaner section structure.
# CrisisBoard ๐จ    ## ๐ Quick Setup ```bash git clone https://github.com/YOUR_USERNAME/crisisboard.git cd crisisboard && npm install cp .env.example .env npm run dev ``` ## ๐ค Contributing (GSSoC'25 Guidelines) # Branch naming git checkout -b feat/issue-58-dashboard-btn # Commit format git commit -m "feat: add dashboard button to feedback page (#58)"
Navigation is the heartbeat of good UX. The Feedback page had no way to jump back to the Dashboard โ forcing
users to manually navigate. I added an inline SVG icon button styled with TailwindCSS to match the existing
UI, linked directly to dashboard.html. Zero disruption to any existing functionality.
<!-- New: Dashboard button with TailwindCSS + inline SVG --> <a href="dashboard.html" class="flex items-center gap-2 px-4 py-2 rounded-lg bg-purple-600 hover:bg-purple-700 text-white font-medium text-sm transition-all duration-200" > <svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="none" stroke="currentColor" stroke-width="2"> <rect x="3" y="3" width="7" height="7"/> <rect x="14" y="3" width="7" height="7"/> <rect x="3" y="14" width="7" height="7"/> <rect x="14" y="14" width="7" height="7"/> </svg> Go to Dashboard </a>
This one was about stability, not features. app.js had an unclosed event listener (a silent
memory leak waiting to happen) and an orphaned catch block with no matching try. I
reviewed the entire file end-to-end, fixed both issues, and made sure no loose ends remained. Two merges in
one day โ that day was a very good day.
// BEFORE: no cleanup = memory leak on every page visit const handleClick = () => { fetchData(); }; document.addEventListener('click', handleClick); // โ ๏ธ Missing removeEventListener โ listener never cleaned up // Also: orphaned catch with no try block } catch(err) { console.error(err); // โ ๏ธ What is this catching? } // AFTER: proper lifecycle + try-catch structure const handleClick = () => { try { fetchData(); } catch (err) { console.error('Click handler error:', err); } }; document.addEventListener('click', handleClick); window.addEventListener('beforeunload', () => { document.removeEventListener('click', handleClick); });
Big thanks to Abhisar Choubey โ the CrisisBoard maintainer and mentor who trusted me with three contributions and provided clear, encouraging feedback every time. ๐
A comprehensive travel platform โ book flights, trains, buses, rent vehicles, reserve hotels, and explore curated travel guides.
This was a proper feature. The existing navbar was static and fell apart on mobile. I rebuilt it to be sticky with a backdrop blur effect, designed the mobile layout (logo left + pink hamburger menu right for clean UX), implemented the full desktop nav with pink accent styling, and fixed Hero section spacing and text visibility issues โ all matching TravelGrid's existing brand aesthetic.
const Navbar = () => { const [menuOpen, setMenuOpen] = useState(false); return ( <nav className={` fixed top-0 w-full z-50 transition-all duration-300 backdrop-blur-md bg-white/10 border-b border-white/10 `}> {/* Mobile: Logo + Pink Hamburger only */} <div className="flex md:hidden items-center justify-between px-4 py-3"> <Logo /> <button onClick={() => setMenuOpen(!menuOpen)} className="text-pink-500 hover:text-pink-400" > <HamburgerIcon /> </button> </div> {/* Desktop: Full nav with pink accents */} <div className="hidden md:flex items-center justify-between px-8 py-4"> <Logo /> <NavLinks accentColor="pink" /> </div> </nav> ); };
This PR taught me something important: reading a codebase is its own distinct skill. Understanding the component structure, the design system, the naming conventions โ before writing a single line. Thanks to Adarsh Chaubey and the TravelGrid team for the trust. ๐
A global open-source community platform built for creators to connect, collaborate, and grow.
This is the contribution I'm proudest of. Creators-Space had never had an About Us page. I designed and built it entirely from scratch โ mission and vision sections, a technologies used grid, a "Stay Connected" section for contributors, full dark/light mode toggle support, complete mobile responsiveness. I even spotted and logged a GitHub button redirect bug for future fixes.
For a global open-source community, an About page is the handshake โ it tells newcomers who you are, what you believe, and why they should join. Now, Creators-Space finally has that handshake. ๐ค
const AboutUs = () => ( <div className="about-page dark:bg-gray-900 bg-white transition-colors duration-300"> {/* Mission & Vision */} <section className="mission-section py-16 px-6"> <h2 className="text-3xl font-bold text-center mb-8"> Our Mission </h2> <MissionVisionGrid /> </section> {/* Tech Stack Used */} <TechStackSection technologies={techStack} /> {/* Stay Connected โ for contributors */} <section className="connect-section"> <h2>Stay Connected</h2> <SocialLinks /> </section> </div> ); // Dark/Light mode toggle support via className conditionals // Fully responsive โ tested across mobile, tablet, desktop
Huge thanks to Anurag Vishwakarma and Anshi Agrawal for their patient guidance through the review process. Every review comment was a free lesson. ๐
What GSSoC Actually Taught Me ๐
If you're sitting on the sidelines wondering if open source is "for people like you" โ it absolutely is. You don't need to build a framework. You don't need to fix a critical CVE. You just need to start. Find one issue. Make one PR. And watch how quickly the community welcomes you in. ๐
Explore the Projects
All four open-source projects I contributed to during GSSoC'25 โ each one a different lesson.