How to Make Your First Open-Source Contribution: A Practical Guide 🚀

mariam amin — Mon, 28 Sep 2026 17:16:12 +0000

Making your first open-source contribution can feel intimidating.

You might think:

What if I don't understand the codebase?
How do I choose an issue?
What if my PR gets rejected?
How do I know whether my code follows the project's standards?
What exactly should I write in the Pull Request?

I recently went through this process for the first time while contributing to FOSSASIA's Badge Magic, a Flutter application.

My first PR was merged, and along the way, I learned a practical workflow that I think can help other developers make their first contribution.

1. Start With the Right Repository

For your first contribution, don't randomly choose a huge project just because it has thousands of stars.

Look for a project where:

You understand the technology used.
The repository is actively maintained.
Issues are clearly described.
There are contribution guidelines.
Maintainers are actively reviewing PRs.

For me, Flutter was a natural choice because I already had experience with it.

I found the FOSSASIA Badge Magic project and started exploring the repository.

2. Don't Immediately Pick the Hardest Issue

A common mistake is thinking your first contribution needs to be impressive.

It doesn't.

Your first goal should be to understand the contribution workflow.

A smaller issue can teach you:

What makes a good first issue?

Look for issues that:

Have a clear expected result.
Don't require changing the entire architecture.

3. Read the Repository Before Writing Code

This is probably one of the most important steps.

When you find an issue, don't immediately start editing files.

First, look at:

README.md
CONTRIBUTING.md
Project structure
Existing issues
Existing Pull Requests
Coding conventions
Tests

You want to answer questions such as:

How is this project structured?

Where is this functionality implemented?

How do other developers solve similar problems?

Are there specific formatting or testing requirements?

This saves a lot of time later.

4. Keep the PR Focused

One of the easiest ways to make a PR difficult to review is to mix unrelated changes.

A good PR should have a clear purpose.

Keeping the scope focused made the change easier to understand and review.

5. Test Before Opening the PR

Run the project's available checks.

6. Write a Clear Pull Request

A maintainer should be able to understand your PR without reading every changed file.

A useful PR description should answer:

7. Be Ready for Code Review

This was one of the most useful parts of the process for me.

Don't take review comments personally.

The purpose of review is to improve the code and make sure the contribution fits the project.

Sometimes you'll agree with the feedback.

Sometimes you'll need to explain your reasoning.

Both are part of contributing to open source.

8. What Happens After the PR Is Merged?

Once your PR is merged, don't stop there.

Look at the next issue.

Your first contribution is basically an introduction to the project's workflow.

The second contribution is where you start becoming more comfortable.

My First Open-Source PR 🚀

Following these steps, I made my first contribution to FOSSASIA's Badge Magic, an open-source Flutter application.

After going through the implementation, testing, and code review process, the PR was successfully merged into the main branch. 🎉

You can check out the full Pull Request here:

PR #1958 — Standardize Border Radius Using AppRadius

DEV Community: mariam amin