Your First Open-Source Contribution

Title

Your First Open-Source Contribution. From reading a project to opening a pull request.

This tutorial explains how open-source projects work and walks through your first contribution, step by step.

What open source is, and why it matters

Open-source code comes with a license that lets anyone use, study, change and share it. You learn from real code and reviewers.

Open source means the code comes with a license that allows anyone to use, study, change and share it, and much of the software you use every day depends on it.

Licenses, the simple version

The license sets the rules. MIT: keep the credit note. GPL: share your recipe too. No license: all rights reserved.

Always read the license first, because it decides what you may do with the code and what you must do when you share it.

How projects are run

Maintainers run the project. Issues track bugs and ideas. CONTRIBUTING explains the rules. Every change gets reviewed.

Maintainers look after the project, issues hold the to-do list, CONTRIBUTING describes how to help, and every change goes through review.

Analogy: the library's easy-tasks board

Look for labels like "good first issue" or "help wanted". Read CONTRIBUTING and the thread, then comment before you start.

Beginner labels help you find a starting point, but always check the discussion and ask the maintainers before you begin.

Analogy: your own copy of a public cookbook

A fork is your own copy of the project on GitHub. You can change it freely without touching the original.

A fork is a separate repository under your account that starts as a copy of the original, called the upstream.

Clone your fork and add upstream

Clone your fork to your laptop. Then add the original project as a second remote, named upstream.

git clone https://github.com/YOUR-NAME/tiny-project.git
cd tiny-project
git remote add upstream https://github.com/ORIGINAL-OWNER/tiny-project.git
git remote -v

origin points to your fork, where you can push, and upstream points to the original project, where you fetch new work.

Branch, commit, push

Make a branch for your change, commit it, and push the branch to your fork.

git switch -c fix-install-typo
# edit README.md, then:
git add README.md
git commit -m "Fix typo in installation steps"
git push -u origin fix-install-typo

Working on a separate branch keeps your fork's main clean and lets you open one focused pull request per change.

Analogy: an edit proposal sent to the editor

On GitHub, open a pull request: a proposal to merge your branch into the original project.

A pull request asks the maintainers to merge your branch, and words like "Fixes #42" link it to the issue so the issue closes when the pull request is merged into the default branch.

Analogy: peer-editing a draft

Maintainers review your change and may ask for edits. Push new commits to the same branch, and the pull request updates.

Reply to every review comment politely, push fixes to the same branch, and be patient, since maintainers are often volunteers.

Keep your fork up to date

Your fork does not update itself. Fetch from upstream and merge, or use the "Sync fork" button on GitHub.

git fetch upstream
git switch main
git merge upstream/main
git push origin main       # update your fork on GitHub too

Syncing brings the original project's new commits into your clone and fork, so your next branch starts from the latest code.

Recap

Read the license and CONTRIBUTING. Ask on the issue. Fork, clone, branch, commit, push, open a pull request, respond kindly.

mkdir -p ~/git-practice/t08-oss && cd ~/git-practice/t08-oss

# The maintainer's project, with a typo on purpose
git init -b main maintainer
cd maintainer
echo "# Tiny Project" > README.md
echo "Instalation: run setup" >> README.md
git add README.md && git commit -m "Add README"
cd ..

git clone --bare maintainer upstream.git     # the public original
git clone --bare upstream.git my-fork.git    # your "fork" (on GitHub, the Fork button does this)
git clone my-fork.git work                   # your laptop copy
cd work
git remote add upstream ../upstream.git
git remote -v

git switch -c fix-typo
echo "# Tiny Project" > README.md
echo "Installation: run setup" >> README.md
git add README.md
git commit -m "Fix typo in README"
git push -u origin fix-typo
git log --oneline --all --graph              # press q if a pager opens

# Keep your fork in sync
git fetch upstream
git switch main
git merge upstream/main
git push origin main

You now know the full contribution flow, and the best next step is to find one small issue and try it.