DEV Community: Ghanshyam Singh

I Didn't Join for GSoC — And That's What Led Me There

Ghanshyam Singh — Sat, 27 Jun 2026 02:18:01 +0000

I joined Alpha One Labs without knowing Django, without a plan, and without even thinking about GSoC. A few months later, I was selected. This is that story.

When I joined Alpha One Labs in November 2025, Google Summer of Code wasn't part of the plan.

In fact, I barely had a plan.

I wasn't thinking about proposals, acceptance rates, or becoming a GSoC contributor. I wasn't calculating which organizations had the best odds. I wasn't reading blogs about how to impress maintainers.

I was simply looking for a place where I could learn, contribute, and gain real experience working on something that mattered.

And at that point, I had never worked with Django before.

Not even once.

That didn't stop me. And looking back, that's exactly what made the difference.

I should mention something here that most people don't know about my journey.

Alpha One Labs wasn't the only organization I was contributing to.

At any given point during those months, I was actively contributing to six different open-source organizations. Different codebases, different tech stacks, different communities. Open source had become genuinely interesting to me — not as a means to an end, but as a way of learning things I couldn't learn anywhere else.

But Alpha One Labs always felt different. Not because of the code. Not because of anything else. It was special because of one person — my maintainer, Daniel.

Every time I made a mistake — and I made plenty — he didn't let it discourage me. He corrected me, explained why, and kept me moving forward. There was never a moment where I felt like my presence in the community was a burden or that I was too far behind to catch up.

That kind of support is rarer than people realize.

It's also what kept me coming back.

Joining Without a Roadmap — November 2025

The first time I opened the Alpha One Labs codebase, I felt completely lost.

The project was a full-scale Django educational platform — views.py alone was thousands of lines. There were models.py, forms.py, forms_additional.py, admin.py, admin_views.py, signals.py, consumers.py, middleware.py, dedicated services for things like calendar sync, video conferencing, secure messaging, peer challenges, quiz logic, notifications, referrals, and a full virtual lab system. Migrations going back two years. Templates everywhere. A test suite. Linting configs. Pre-commit hooks.

It had real structure, real history, real patterns built by people who clearly knew what they were doing.

And I was someone who had never touched Django.

But here's the thing about open source that nobody tells you upfront.

You don't need to understand everything before you start.

You just need enough curiosity to take the first step and enough stubbornness to take the next one after that.

So I started small.

I set up the development environment. I read through the codebase, file by file, trying to connect the dots. I broke things. I fixed them. I experimented. I read the Django documentation over and over again until things slowly started making sense.

Those early days were humbling.

But they were also exactly where the learning happened.

Small Contributions, Big Lessons

My first contributions were nothing spectacular.

A bug fix here. A small improvement there. A documentation update that nobody would write a blog post about.

But those tiny contributions taught me something new every single day.

Every time I opened a pull request, I was forced to understand the code a little more deeply. Every review comment I received pushed me to think more carefully. Every merged change — no matter how small — gave me a slightly better understanding of how the project worked.

I wasn't doing this to impress anyone.

I was doing it because I genuinely wanted to understand.

And then came the first merged pull request.

I still remember opening GitHub and seeing those words: Merged.

It wasn't a complex change. It wasn't a feature that would make it into a release announcement. But it was mine, and it was real, and someone on the other side of the world had reviewed it and decided it was good enough to be part of the project.

That feeling was difficult to explain.

It wasn't just code getting merged. It was proof that I belonged there.

The Conversation That Changed Everything

After a few contributions, something unexpected happened.

Daniel noticed my work.

He wasn't just acknowledging that I had submitted pull requests. He was paying attention to the quality of my thinking, the consistency of my presence, and the fact that I kept showing up even when no one was asking me to.

He encouraged me to keep going. To explore larger problems. To think beyond the small fixes and start looking at the project from a bigger picture.

That conversation changed something in me.

Up until that point, I had been contributing with my head down, focusing on one task at a time. After that conversation, I started seeing the project differently. I started looking for problems that hadn't been solved yet, ideas that could genuinely improve things, work that was a little bigger than anything I had attempted before.

When a maintainer tells you they trust your judgment, it reshapes how you see yourself.

Building Something Real — December 2025

A group of us decided to build an AI project together inside Alpha One Labs.

We called it ScholarAI.

The problem was simple to describe and surprisingly hard to solve. Research papers are long. Reading through pages of dense academic content to extract the key ideas takes a lot of time, even for people who do it regularly. Students and researchers were drowning in literature. We wanted to build something that could help.

The idea: an AI-powered research assistant that could take long academic documents and intelligently summarize them, help with paper discovery, and let you actually query the content. Not just keyword extraction. Actual comprehension. Something that understood context.

We explored RAG. We worked with LLMs. We figured out how to process long-form text, chunk it meaningfully, retrieve relevant sections, and generate summaries that actually made sense.

It wasn't perfect.

Looking back, the implementation had gaps. There were architectural decisions we would make differently today. As an open-source contribution, it probably needed more polish before it was truly production-ready.

But that wasn't really the point.

The point was that we had stopped thinking like contributors who fixed bugs and started thinking like people who built products. We had looked at a real problem, designed a solution, and seen it through from idea to working prototype.

That shift in thinking — from fixing what's broken to building what's missing — is one of the most important things open source gave me.

GSoC Wasn't Even on My Mind

Here's the part that surprises most people when I tell this story.

Even as all of this was happening — the contributions, the conversations with Daniel, the AI project — I was not thinking about GSoC.

Not even a little.

I was not optimizing my contributions to look impressive on an application. I was not selecting issues based on what might catch a mentor's eye. I was not secretly building a strategy while pretending to just be learning.

I was just there.

Contributing because I enjoyed it. Learning because I wanted to grow. Helping because it felt good to help.

This is the exact opposite of how most people approach these programs. Most people start with the goal and work backwards. I started without a goal and let the work take me somewhere unexpected.

I have no doubt that this made a difference.

Because genuine contribution looks completely different from strategic contribution.

Becoming a Reviewer — January 2026

At some point, something quietly shifted.

I wasn't only submitting pull requests anymore.

I was reviewing them.

When new contributors opened pull requests, I was one of the people looking at their code, asking questions, offering suggestions, and helping them improve. I reviewed more than 25 pull requests over the course of my time in the organization.

That number matters more than it might seem.

Most contributors never reach this point. They contribute, they learn, and eventually they move on. Very few earn the trust of maintainers to the point where they are actively helping evaluate other people's work.

That trust was not given to me because I asked for it.

It was given because I showed up consistently, because my contributions were thoughtful, and because the community could see that I genuinely cared about the project.

The moment you go from contributor to reviewer, you stop being a visitor and become part of the foundation.

The Season Everything Got Loud — February 2026

When GSoC season officially arrived, the entire organization changed.

New contributors appeared from everywhere. Issues that had been sitting quietly suddenly had multiple people working on them. Pull requests flooded in. Discussions became more frequent, more urgent, more competitive.

Maintainers who had been thoughtfully engaged with every contributor were now stretched thin, juggling dozens of conversations simultaneously.

And I found myself doing something I had not expected.

Helping manage the chaos.

I was answering questions from new contributors. I was helping people find the right issues to start with. I was reviewing their work and giving feedback so maintainers didn't have to field every question alone.

I had become someone the organization relied on — not because of a title, not because of a formal role, but because I had been there long enough and contributed enough that it was natural.

Looking back, this was probably the moment that made my eventual selection feel inevitable rather than surprising.

Exams, Deadlines, and a Proposal I Almost Didn't Write — March 2026

Here is where the story gets honest.

The GSoC proposal deadline was March 31, 2026.

My exams were happening at the same time.

While many other applicants had been carefully crafting and refining their proposals for weeks, I was in the middle of exam season with only a few days left before the deadline. I had been so focused on actual contribution that I had barely thought about the application itself.

There was a moment where I genuinely considered whether there was even enough time.

But I sat down and wrote it anyway.

I went back through everything. My contributions. The AI project. The PRs I had reviewed. The problems I had solved. The direction I thought the project could grow in. I tried to write a proposal that sounded like me — someone who had been in the codebase, not someone who had studied it from the outside.

Daniel reviewed it.

His feedback was direct and specific, the kind of feedback you only get from someone who knows both the project and your work well enough to tell you exactly what needs to change.

I made the edits. I read it again. I submitted it.

And then I waited.

The Email

The results were announced on April 30, 2026.

I opened my inbox that evening.

I had submitted my proposal. I had done everything I could do. Whatever happened next was genuinely out of my hands, and I had made peace with that.

Then I saw it.

The subject line.

The acceptance email.

I read it once. I read it again. I closed the tab and reopened it to make sure I was reading correctly.

I had been selected for Google Summer of Code 2026.

I sat there for a moment in silence.

There was no dramatic celebration. No immediate post. Just a quiet recognition of what it meant — not just the selection itself, but everything that had led to it.

The months of learning Django from scratch. The pull requests that no one was asking me to open. The reviews I wrote because I wanted to help. The AI project we built because it was interesting. The contributions made in a season when I never once thought about this moment.

All of it had quietly been building toward something.

What I'm Actually Building

My GSoC project is rebuilding the Alpha One Labs website from the ground up.

The old website — the Django monolith I had been contributing to for months — works. It has features, users, a community, and years of work behind it. But the new vision is different.

The new platform is called learn. It is being built as a fully encrypted educational platform. Different tech stack entirely: HTML, CSS, and Python running on Cloudflare Workers. No traditional backend in the same sense. The encryption is not a feature added on top — it is built into the foundation.

It is a fundamentally different way of thinking about what a learning platform can be.

When I submitted my proposal, I was writing about a problem I had been inside for months. I wasn't describing the old codebase from the outside. I had touched views.py and models.py and templates and migrations enough to understand what the old architecture looked like, and what it would take to move to something completely new.

That context is what no amount of last-minute preparation can replace.

I will be writing a detailed blog about the proposal itself, the technical decisions, and the actual work happening inside the coding period. There is a lot more to say about the architecture, the challenges, and what encrypted-by-default actually means in practice.

That story is still being written.

What I Know Now

If you are a student reading this hoping to get into GSoC, I understand what you are looking for.

You want the strategy. The shortcut. The formula.

But I am not sure there is one.

What I can tell you is what I experienced.

Contributing to six open-source organizations while keeping Alpha One Labs at the center. More than 10 pull requests merged. More than 25 pull requests reviewed. ScholarAI built from a real problem. Months of showing up in a community and genuinely caring about what I was building.

A maintainer who never once let me feel discouraged when I got something wrong.

None of that was done because I had a plan.

All of it was done because I was curious, because I enjoyed the work, and because Daniel and the community at Alpha One Labs made me feel like my contributions actually mattered.

GSoC became a result of those contributions.

Not the reason for them.

And I think that distinction — that quiet, almost invisible distinction between contributing because you want something and contributing because you love the work — is the thing that changes everything.

You do not need to start with a destination. You just need to start.

The rest has a way of finding you.

If you want to go deeper — the proposal, the technical decisions behind the learn platform, and what the actual GSoC coding period looks like — I'm writing a separate blog about all of that. The journey inside Alpha One Labs has more to it than a selection email. That story deserves its own space.

From Beginner Contributor to KubeStellar LFX Mentee

Ghanshyam Singh — Sun, 31 May 2026 09:43:47 +0000

If someone had told me a year ago that I would be contributing to a CNCF project, mentoring other contributors, reporting more than 140 bugs, and being selected for an LFX Mentorship, I probably would not have believed them.

Back in June 2025, I was just another student curious about open source.

I had heard people talk about GitHub contributions, CNCF projects, Kubernetes, community calls, and all the exciting opportunities available in the cloud-native ecosystem. But honestly, I did not really know how any of it worked.

I was not an experienced contributor. I was not a Kubernetes expert. I did not have a long list of impressive pull requests.

I was just curious.

That curiosity ended up changing my life.

Discovering CNCF and KubeStellar

Around June 2025, I started exploring projects within the CNCF ecosystem. I wanted to understand how real-world open-source projects worked and how contributors collaborated across the world.

While exploring different projects, I came across KubeStellar.

At first, it was just another interesting project on my screen. But the more I explored it, the more fascinated I became. The idea of simplifying multi-cluster Kubernetes management felt incredibly powerful, and I wanted to learn more.

The problem was that learning and contributing were two completely different things.

I quickly realized that I could not simply read documentation and magically become a contributor. I needed to set up my environment, understand the project architecture, learn Kubernetes concepts, and actually start participating.

Even my laptop had other plans.

Running local Kubernetes environments was not exactly easy on my machine. I spent time upgrading and fixing my setup before I could comfortably run local clusters. After several rounds of troubleshooting, configuring tools, and experimenting with KIND clusters, I finally had an environment where I could start learning by doing.

Looking back now, it feels funny.

At the time, getting a cluster running successfully felt like a huge achievement.

My First Steps Into Open Source

One thing people do not talk about enough is how intimidating open source can feel when you are new.

Most people think the hard part is understanding the code.

For me, the hard part was the people.

Not because the community was not welcoming. Actually, it was the opposite. Everyone was incredibly supportive.

But I had never worked with a global team before. I had never joined technical community meetings before. I had never publicly discussed bugs, features, ideas, or architecture decisions before.

Every Tuesday and Thursday at 8:30 PM IST, I joined the KubeStellar community meetings.

And honestly?

I was nervous every single time.

Before every meeting, I would mentally prepare myself to speak. Sometimes it was a question. Sometimes it was an update. Sometimes it was simply sharing what I had been working on.

Even when I felt nervous, I pushed myself to participate.

Those small moments might sound insignificant, but they completely changed my confidence over time.

Each meeting made me a little more comfortable. Each discussion taught me something new. Each interaction helped me grow.

Today, when I look back, I realize that learning how to communicate in a community was just as valuable as learning Kubernetes itself.

Becoming an Unpaid Mentee

My first major opportunity came through KubeStellar's unpaid mentorship program.

This was where everything started becoming real.

During the mentorship, I worked on the A2A project, contributing to CLI improvements, documentation, and website-related work.

More importantly, I started understanding how open source actually functions behind the scenes.

Before that, GitHub felt like a platform where people uploaded code.

Now I was seeing the full picture.

Ideas became issues.
Issues became discussions.
Discussions became pull requests.
Pull requests became features.
And behind all of it were real people collaborating to build something meaningful.

The mentorship ran from August to November, and those months taught me more than I could have learned from any tutorial.

By the time it ended, I was not just contributing.

I had become part of the community.

If you want to explore the project that pulled me deeper into the ecosystem, start here:

Falling in Love With Open Source

Even after the mentorship ended, I did not stop contributing.

In fact, I became even more involved.

I explored other open-source organizations, contributed across projects, learned new technologies, and continued participating in community discussions.

Somewhere during that journey, open source stopped feeling like a way to improve my resume.

It became something much more meaningful.

I genuinely enjoyed helping people. I enjoyed learning in public. I enjoyed collaborating with contributors from different backgrounds and different parts of the world.

For the first time, I felt like I was not just consuming technology.

I was helping build it.

The LFX Application

When the LFX Mentorship applications opened, I decided to apply.

To be honest, I did not have huge expectations.

LFX is highly competitive, and there are many talented contributors applying every term. I submitted my application, prepared for interviews, and hoped for the best.

But deep down, I was not sure whether I would be selected.

Then one day, I received the email.

I had been selected.

I still remember the excitement.

Months of learning, contributing, attending meetings, asking questions, fixing issues, and staying consistent had finally led to this moment.

For me, the selection was not just an achievement. It was proof that growth happens when you keep showing up.

Working on the Future of Multi-Cluster Kubernetes

During LFX Term 1 from March to May, I worked on the KubeStellar Console project.

The vision behind the project was incredibly exciting.

KubeStellar Console aims to simplify multi-cluster Kubernetes operations through an AI-powered experience. Instead of manually managing every aspect of Kubernetes, users can interact with intelligent workflows and automation to manage their environments more efficiently.

My focus was on improving AI Missions and helping build an agent capable of handling operational workflows across Kubernetes environments.

This meant spending a lot of time testing, validating behavior, reproducing issues, understanding edge cases, and improving the overall experience.

A large part of my work involved using KIND clusters to simulate real-world scenarios and verify how different workflows behaved under various conditions.

Every day felt like a new learning opportunity.

What I Worked on Technically

The technical part of the mentorship was where things became intense in the best way.

KubeStellar A2A sits at an interesting intersection: Kubernetes operations, multi-cluster workflows, automation, and AI-assisted interfaces. My work was not limited to writing code in isolation. It involved understanding how user intent could become a reliable operational action inside a Kubernetes environment.

Some of the areas I spent time on:

Testing AI Missions and validating whether generated workflows behaved correctly.
Reproducing bugs using local KIND clusters and different kubeconfig contexts.
Checking cluster discovery, namespace listing, resource lookup, and multi-cluster behavior.
Reviewing CLI behavior and making sure commands were understandable for new users.
Improving documentation so contributors could set up, test, and debug faster.
Validating edge cases around failed clusters, missing context, invalid input, and partial workflow failures.

The work forced me to think less like someone trying to make a demo pass and more like someone responsible for a real user journey.

Local testing loop:
1. Create or reset KIND clusters
2. Configure kubeconfig contexts
3. Run the A2A workflow or CLI command
4. Reproduce the issue with clear steps
5. Capture logs, screenshots, and expected behavior
6. Report or validate the fix

That loop became a habit.

It also taught me that good engineering is not only about building features. It is also about making failures understandable.

A bug report is not just "this is broken." A good bug report is a map that helps someone else reach the same problem and fix it with confidence.

Sleepless Nights, Bugs, and Ownership

One lesson that LFX taught me was ownership.

When you are working on a real project with real users, bugs are not just bugs.

They are problems that affect someone's experience.

There were multiple nights when I stayed awake much longer than planned.

Debugging. Testing. Investigating issues. Verifying fixes. Trying to understand why something worked yesterday but not today.

Sometimes the solution appeared in minutes. Sometimes it took hours. Sometimes it took days.

But that is part of engineering.

And that is where some of the biggest learning happened.

142 Bug Reports Later

By the end of the mentorship, I had submitted 142 bug reports.

That number still surprises me.

Each bug report represented investigation, testing, reproduction, documentation, and communication.

It was not just about finding issues.

It was about helping improve the project and making it better for future users and contributors.

Through that process, I learned how important quality assurance, testing, and attention to detail are in large-scale open-source projects.

Lessons From A2A and Multi-Cluster Testing

The A2A project helped me understand why multi-cluster Kubernetes tooling is difficult.

In a single-cluster setup, you already have many moving parts: workloads, namespaces, services, RBAC, kubeconfig, logs, events, controllers, and user permissions.

In a multi-cluster setup, that complexity multiplies.

Now the system has to answer harder questions:

Which cluster should this action target?
What happens if one cluster is reachable and another is not?
How do we expose useful errors without overwhelming the user?
Can an AI-assisted workflow explain what it is about to do?
Can the same workflow be tested safely before applying changes?

These questions made me appreciate the value of dry runs, clear command output, reproducible test cases, and careful documentation.

They also made me respect the people building infrastructure tools even more. The best tools feel simple because someone has already absorbed a lot of complexity for the user.

From Being Mentored to Mentoring Others

Perhaps the most rewarding part of the entire journey was realizing how much I had grown.

A year earlier, I was nervous about speaking in community meetings.

During my mentorship, I had the opportunity to help mentor four unpaid mentees.

I answered questions, shared knowledge, helped contributors navigate the project, and supported them whenever possible.

That experience meant a lot to me because it reminded me of where I started.

The same community that helped me learn had given me the opportunity to help others learn too.

And honestly, that is one of the most beautiful things about open source.

Knowledge gets shared. People help each other. Everyone grows together.

Thank You to My Mentors

This journey would not have been the same without the people who reviewed my work, answered questions, gave direction, and trusted me with responsibility.

A huge thank you to Andy Anderson and Rishi Mondal for their mentorship, patience, technical guidance, and constant support throughout the journey.

They helped me understand not only the project, but also how to think like an open-source contributor: communicate clearly, document decisions, respect maintainers' time, and keep improving the work until it becomes genuinely useful.

I am also grateful to the KubeStellar community, the Linux Foundation LFX Mentorship program, CNCF, and every contributor who made the community feel welcoming.

The best mentorship does not just help you finish a task. It changes how you approach the next hard problem.

Final Thoughts

When people ask me what I gained from open source, my answer is simple.

Yes, I learned Kubernetes. Yes, I learned testing, debugging, collaboration, and cloud-native technologies.

But more importantly, I learned confidence.

I learned how to communicate. I learned how to work with people across the world. I learned how to ask questions. I learned how to contribute even when I was not completely sure of myself.

My journey from a beginner contributor to a KubeStellar LFX mentee was not perfect.

There were challenges, mistakes, sleepless nights, and moments of self-doubt.

But there was also growth, community, learning, and opportunity.

And if there is one thing I have learned from this journey, it is this:

You do not need to be an expert before you start. Sometimes all you need is curiosity, consistency, and the courage to show up.