My Practical Guide to Starting Open Source

Open source is not a coding contest. It is a long game of curiosity, patience, communication, and useful work.

I am Vishvamsinh Vaghela, GSoC 2024 contributor with Postman/AsyncAPI, LFX 2025 mentee with CNCF Jaeger, and SDE Intern at HackerRank.

My open-source journey did not start with a huge feature. It started with reading issues, breaking local setup, asking better questions, and making small pull requests until the codebase stopped feeling like a locked room.

What Open Source Actually Means

Open source means the code, docs, issues, design discussions, and decisions are visible enough for people outside the core team to participate.

That participation can be:

• Fixing a bug
• Improving docs
• Writing tests
• Reproducing an issue
• Reviewing a pull request
• Improving CI, examples, or developer experience
• Answering questions from newer contributors

The big mental shift is this: your contribution does not need to be glamorous to be valuable. A clean docs fix that saves 200 people from setup pain is real impact.

Why I Started

I wanted practical experience that college assignments could not give me:

• Reading unfamiliar code
• Working with Git branches, reviews, and CI
• Communicating with maintainers
• Debugging without a perfect problem statement
• Learning how production projects make tradeoffs

AsyncAPI became my main playground. I started with small issues, then moved into tests, TypeScript migration work, and larger implementation tasks. That path eventually helped me build enough credibility for GSoC.

The pattern was simple: small useful work, repeated consistently.

Step 1: Pick a Project You Can Stay With

Do not start by chasing the biggest logo. Start with a project where you can imagine spending a few months.

Look for:

• A tech stack you know or genuinely want to learn
• Recent commits and merged pull requests
• A CONTRIBUTING.md or contributor guide
• Issues with real maintainer responses
• A community chat, discussion forum, or regular meetings
• Tests you can run locally

Red flags:

• Many old PRs with no response
• No setup instructions
• Maintainers reacting rudely to normal questions
• Issues that are vague but labelled beginner-friendly
• A project that needs deep domain knowledge before you can do anything useful

My rule: if I cannot run the project locally after a serious attempt, I either ask a very specific setup question or move on.

Step 2: Learn the Project Before Asking for Work

Before asking "Can you assign me an issue?", do this:

1. Read the README and contributor guide.
2. Run the project locally.
3. Read 3 recently merged PRs.
4. Read 3 open issues and their discussion.
5. Check how tests and linting are run.

Then introduce yourself with context:

Hi, I am Vishvamsinh. I am new to this project but comfortable with TypeScript and React. I ran the project locally and looked at issues #123 and #456. I would like to try #123 because the expected behavior is clear. Is anyone already working on it?

That message is short, specific, and easy for a maintainer to answer.

Step 3: Choose Your First Issue Carefully

Good first issues are not always labelled good first issue.

Strong beginner tasks usually have:

• Clear reproduction steps
• A small affected area
• Existing tests or examples nearby
• A maintainer comment explaining the desired behavior

Great first contributions:

• Fix broken docs or setup steps
• Add a missing test case
• Improve an error message
• Reproduce and document a bug
• Update examples after an API changed
• Fix a small UI or accessibility issue

Avoid starting with:

• Large refactors
• Performance rewrites
• Security-sensitive changes
• Issues with no agreement on expected behavior
• Anything that touches many unrelated files

Small PRs get reviewed faster. Fast feedback teaches you more.

Step 4: Make the PR Easy to Review

A maintainer should be able to understand your PR in two minutes.

Use this structure:

• Title: say what changed, not how hard it was.
• Description: link the issue and summarize the fix.
• Testing: mention the exact command you ran.
• Screenshots: add them for UI changes.
• Scope: keep unrelated cleanup out.

Example PR description:

Fixes #123
 
This updates the parser error message when the config file is missing. The old message only said "failed"; the new message points to the expected config path.
 
Tested with:
- pnpm test parser
- pnpm lint

That is boring in the best possible way. Reviewers love boring clarity.

Step 5: Handle Review Like a Teammate

Code review is not a personal judgment. It is the project protecting itself.

When you get feedback:

• Reply after you understand the comment.
• Ask clarifying questions if the requested change is unclear.
• Push small follow-up commits.
• Do not argue to "win" the review.
• If you disagree, explain the tradeoff calmly.

Useful reply:

Thanks, that makes sense. I updated the test to cover the empty config case too. Could you check if this matches what you had in mind?

That kind of communication quietly builds trust.

The Skills That Actually Matter

You do not need to be a genius. You need enough basics and a lot of consistency.

Learn:

• Git: branch, commit, rebase basics, resolving conflicts
• GitHub: issues, PRs, reviews, actions
• One language well enough to debug real code
• Testing in your chosen stack
• Reading docs before asking questions
• Writing short technical updates

The underrated skill is follow-through. Many people claim issues. Fewer people return with a working PR, a clear question, or a useful reproduction.

A 30-Day Open Source Plan

Week 1: Explore

• Pick 3 projects.
• Run each locally.
• Join their community channels.
• Read recent issues and PRs.

Week 2: Make Yourself Useful

• Reproduce one bug.
• Improve one doc page.
• Comment with useful findings on an issue.

Week 3: Submit a Small PR

• Pick one scoped task.
• Ask for confirmation if needed.
• Submit the PR with tests or screenshots.

Week 4: Build Momentum

• Respond to review.
• Ship the follow-up.
• Pick a slightly harder issue.
• Write a short note about what you learned.

By the end of 30 days, you may not have a merged PR yet. That is okay. You will have the one thing beginners usually lack: project context.

Resources I Recommend

• Open Source Guides: How to Contribute
• GitHub Blog: Getting started with OSS contributions
• First Contributions
• The Odin Project
• freeCodeCamp

Use these to learn the workflow, but do not stay in tutorial mode forever. Real projects teach faster.

Final Advice

Start smaller than your ego wants.

Pick one project. Run it locally. Read the room. Make one useful change. Communicate clearly. Repeat.

That is how you go from "I want to contribute" to becoming someone a community can rely on.