Scaler Open Source Club

What it is

You have been using it all day. Nobody told you that you could change it.

Open source is software written in public, by anyone, for everyone to use. Not a niche category — the things below are four of the most widely used pieces of software on earth, and you can read every line of all of them right now.

Linux
C
The operating system inside every Android phone, and on the servers behind almost every website you loaded today.
Written in public since 1991 and still is. Anyone can read the code that boots your phone, and thousands of people a year change it.
Read the source
Python
C, Python
Probably the first language you came across.
The interpreter that runs your code is called CPython, and its source, its bug tracker and the arguments about its design are all public.
Read the source
VS Code
TypeScript
The editor you almost certainly have open on the other monitor.
Its source is public under the MIT licence — the build Microsoft ships adds a few closed pieces on top, which is a distinction worth knowing rather than glossing over.
Read the source
Git
C
The thing you type commands at without being sure what they do.
Written by Linus Torvalds in 2005 because the Linux kernel needed it, and open from the first commit. You can read that commit.
Read the source

Built in the open

Every change is a public proposal. You can read the code, the discussion about the code, and the reason a change was refused. Nothing happens in a meeting you were not in.

By anyone

There is no application to read the code and no permission needed to suggest a change. A second-year in Bengaluru and a staff engineer in Berlin open pull requests through the same door.

For everyone

The result is free for anybody to use, including the companies that will interview you. That is why your commits in these repositories are worth something to them.

How a change actually gets in

You do not edit the project. You propose a change to it.

The grey line
The project's history — every change anyone has ever made to it, public, in order, with names attached.
The blue line
Your branch. You copy the project, change something on your own copy, and nothing you do here can break anybody else's work.
The filled dot
The merge. A maintainer agreed, and your change is now part of the grey line — permanently, and for everyone who downloads it after.

Who is on the other side

There is a person at the other end of your pull request. Usually an unpaid one.

This is the part that changes how you behave, and almost nobody explains it before somebody's first contribution.

Often not paid for it

The person who reviews your first pull request is frequently doing it in the evening, after the job that does pay them, because they care about the project. This is the single most useful thing to understand before you open an issue.

Nobody had even mapped it

The Linux Foundation, the OpenSSF and Harvard's Laboratory for Innovation Science ran a census just to establish which open-source packages the world's software actually depends on. That question needed a research project to answer, which tells you how little of this is centrally organised — nobody is in charge of making sure it keeps working.

Which is why review feels slow

A pull request sitting for three weeks is almost never about you or your code. It is one person with a backlog and a day job. Knowing that turns the wait from a rejection into a queue.

Census III of Free and Open Source Software ↗

The words

Nobody is going to explain these to you. So here they are.

12 words that get used constantly and explained never. Not knowing them is the most common reason a capable person never opens their first pull request, and every one of us had to work them out by being confused in public.

upstream: The original project, as opposed to your copy of it. “Landed upstream” means the real project took your change — which is the only version that counts.
fork: Your own copy of the project on GitHub. You work here, so nothing you do can break anybody else's work.
good first issue: A label maintainers add to tasks they have deliberately sized for somebody new. Filtering by it is not cheating; it is the intended use.
maintainer: The person who decides what gets merged. Usually a volunteer. Almost always busier than you assume.
triage: Reading new issues and working out what they actually are. Unglamorous, endless, and one of the most welcome things a newcomer can help with.
nit: A small, non-blocking comment. “nit: trailing whitespace” is not a rejection and is not criticism of you.
LGTM: “Looks good to me.” An approval. The first time somebody writes it under your patch is a genuinely good day.
rebase: Replaying your commits on top of the latest upstream code, so the history stays a straight line instead of a knot. Most projects will ask you to do this at least once.
squash: Collapsing your eleven “fix typo” commits into one clean commit before it is merged. Nobody minds that you needed eleven.
licence: The terms the code is released under. MIT and Apache-2.0 let anyone use it including companies; the GPL additionally requires that derived work stays open. This is what makes open source a legal arrangement rather than just published code.
CLA: A Contributor License Agreement. Some foundations ask you to sign one before your first merge. It is routine, it is not a trap, and it takes two minutes.
RFC: A written proposal for a change big enough that people should argue about it before anyone writes code. Reading old ones is the fastest way to learn how a project thinks.

What this is

A club is easy to start. Getting a stranger to merge your code is not.

Most student open-source groups measure attendance. We measure the quality and number of pull requests a maintainer accepted, because that is what somebody outside the room had to agree to.

Everything on this page links to the upstream repository. If a claim here cannot be checked in one click, it should not be here.

Beyond the stipend

The money is the smallest part. What lasts is who ends up knowing your work.

A maintainer who knows your name

You spend a summer being reviewed by someone senior at a real project. They remember who ships. That relationship does not expire when the programme ends — it is the single most valuable thing here, and it is not the money.

A public record an employer can read

Merged pull requests in a project a company already depends on. Not a certificate, not a course completion — code they can open and read, with your name on the commit.

A reference from outside your college

Every student in your batch has the same professors. Almost none of them have someone at a foundation willing to vouch for their work.

The people doing it with you

The others in this club apply to the same programmes, review each other's patches, and share which maintainers actually reply. That network is why the second selection is easier than the first.

Why it matters

Nobody is going to read your college projects. They will read your commits.

This is the part that sounds like a pitch and is not. Every line below is a mechanism you can trace, and the reason it works is boring: open source is the only part of your CV that a stranger has already checked for you.

Your GitHub stops being empty

Right now it holds semester projects nobody asked for. After one merged pull request it holds a change that a maintainer of a real project read, argued about, and accepted. Those are not the same artefact, and anyone technical can tell the difference in about nine seconds.

Engineers at global companies review your code, for free

The person reviewing your patch to a Kubernetes-adjacent project may well do that work at Google or Red Hat. You do not have to get hired there first to have them read your code and tell you why it is wrong — which is, bluntly, better feedback than most of us get in a semester.

It is the most honest signal you can send a recruiter

A certificate says you attended. A CGPA says you did well at exams somebody else set. A merged pull request says a stranger with no reason to be kind to you looked at your work and let it into software other people depend on. That one cannot be bought, padded, or group-projected.

It is also harder to fake than anything else on a resume, which is exactly why it counts.

Some of it pays, in your second year

Google Summer of Code, LFX Mentorship and Outreachy pay stipends to people with no professional experience. Not a competition prize — a stipend, for spending a summer being mentored on a real codebase. Most students never apply because nobody told them it existed.

No fixed podium.

A contest has a set number of winners. This does not.

Choosing a club

Competitive programming has a fixed number of winners. Open source does not.

Three clubs on this campus want the same four years of your evenings. Here are six questions, asked of all three.

Competitive programming, AI/ML and open source compared across six questions
	CP club	AI/ML club	OSC club
How many can win	3 Only one team from a given institution may advance to the World Finals. Three students, per college, per year. Ten Indian teams reached Baku in 2025 — thirty students, for the entire country. They earned every place; the door is simply that narrow by design. ICPC Regional Rules ↗ICPC 2025 standings ↗	A hackathon or a Kaggle competition ranks everyone who entered and pays the top of the list. How many places exist is decided before registration opens.	∞ No rule caps how many people from your college get code merged into Kubernetes. Competitive programming is a sport with a fixed number of podium places. Open source is a backlog with an unbounded number of open issues.
Odds at the top	The World Finals is the ceiling and it is brutal. Nothing on this page pretends otherwise.	The leaderboard is public and open, which means you are ranked against everyone who entered — including people who do this full time.	8.4% GSoC accepted 1,280 people from 15,240 applicants in 2025. This is not the soft option, and we will not pretend it is. Google Open Source Blog ↗
What you keep if you do not get in	A rating graph. It is a real measure of real skill, and it lives on one site, in one profile.	A model in a notebook. Good work — and the competition it was built for closes, and the leaderboard is archived.	Commits with your name on them, in a repository other people run in production. Merged is merged whether or not the stipend came with it.
When you stop being eligible	Five regional years, two World Finals, and you must still be enrolled. The clock is part of the format.	Kaggle has no student rule. Most campus hackathons do — the badge goes with the enrolment.	Your commit history has no eligibility clause, and GSoC dropped its student-only requirement in 2022. GSoC eligibility change ↗
Who signs off on your work	An automated judge, in thirty seconds. The fastest feedback loop of the three and unbeatable for getting quick at DSA. What it cannot tell you is whether another person could read what you wrote.	A metric on a held-out set. Objective and immediate, and indifferent to everything a number cannot see — including whether anybody but you can run the code.	A maintainer who has to read your patch, push back on it, and then live with it for years. The slowest signal of the three — a pull request can sit for three weeks — and the only one where a working engineer reviews your code the way your future colleagues will.
What it pays	Prize money at the top of the bracket. Below it, the return is the skill itself — which is not nothing, but it is not a stipend.	A prize pool, split between the teams that place.	GSoC, LFX Mentorship, C4GT and Summer of Bitcoin pay stipends to contributors who are nowhere near the best in the country. The money is the floor here, not the ceiling.

India now has the largest open-source contributor base in the world. American developers still contribute more per head. That gap is the entire reason this club exists. GitHub Octoverse 2025 ↗

Where we are

Small, new, and counting honestly.

Everything here is derived from the other four pages rather than typed in by hand, so it cannot say more than the evidence does. Click through and check any of it.

25
members we can name: 46
pull requests merged: 15
Google Summer of Code: 1
active projects: 15
selected into programmes: 1
organisations reached

In their words

Their words, not ours. Including the parts where it was confusing.

“Though I started GSoC prep later than usual, I did not make quick, surface-level PRs. I decided to go deep — truly understanding codebases, maintainer needs, and underlying architecture. That single mindset shift is what got me into GSoC. Open source isn't a race to start first; it's a marathon of building real engineering depth.”
Kartik Deshpande
Batch ’27 · GSoC 2026
“For me, open source is about building real engineering depth, not generating surface-level code. That's why I enforce a strict zero-AI rule across my contributions. When you rely on AI tools to write your PRs, you skip the most critical part of the process — reading documentation, debugging edge cases, and truly understanding the architecture. Open source exists to make us better engineers, not better prompt operators.”
Ojas Maheshwari
Batch ’28 · GSoC 2026
“My open-source journey was anything but a straight line. Between navigating intense FOMO, handling rejected PRs, and feeling lost in massive codebases, there were countless moments I felt stuck. But instead of walking away, I kept reading docs, fixing broken builds, and submitting code — even when progress felt invisible. Making it to GSoC wasn't luck; it was the result of showing up every day and staying relentless through every single setback.”
Shubham Kapoor
Batch ’28 · GSoC 2026
“Though I started GSoC prep later than usual, I did not make quick, surface-level PRs. I decided to go deep — truly understanding codebases, maintainer needs, and underlying architecture. That single mindset shift is what got me into GSoC. Open source isn't a race to start first; it's a marathon of building real engineering depth.”
Kartik Deshpande
Batch ’27 · GSoC 2026
“For me, open source is about building real engineering depth, not generating surface-level code. That's why I enforce a strict zero-AI rule across my contributions. When you rely on AI tools to write your PRs, you skip the most critical part of the process — reading documentation, debugging edge cases, and truly understanding the architecture. Open source exists to make us better engineers, not better prompt operators.”
Ojas Maheshwari
Batch ’28 · GSoC 2026
“My open-source journey was anything but a straight line. Between navigating intense FOMO, handling rejected PRs, and feeling lost in massive codebases, there were countless moments I felt stuck. But instead of walking away, I kept reading docs, fixing broken builds, and submitting code — even when progress felt invisible. Making it to GSoC wasn't luck; it was the result of showing up every day and staying relentless through every single setback.”
Shubham Kapoor
Batch ’28 · GSoC 2026

Laptop open.

People arguing about a codebase, not sitting through slides.

Why students join

College gives you a syllabus. This gives you a review thread.

Four things that actually run every week, and every one of them is open to anyone — there is no selection at the door.

Members of the current cohort · photographs to follow

Regular commit sessions

Open laptops, one issue each, somebody senior in the room.

Hackathons & bounties

Short cycles where the output is a merged patch, not a slide deck.

Student networking

The people who got in last cycle are the people reviewing you now.

1-on-1 mentorship

A mentor who has landed work upstream reads your patch first.

*accessible to serious students only

The students winning are building open source.

Join the club →

15 selectedthis cohort