Skip to main content

Your First Open-Source Contribution: A Guide Through Arch Linux and Beyond

February 19, 2026

Contributing to open source feels intimidating at first. The codebases are huge, the maintainers seem unreachable, and you're not sure where to start. This guide breaks it down using Arch Linux as a concrete example, but the principles apply to any project.

Why Contribute?

  • Build real skills — Production codebases teach things tutorials can't
  • Get code reviewed by experts — Free mentorship from experienced developers
  • Build reputation — Contributions are public proof of your abilities
  • Give back — You use open-source software every day
  • Career opportunities — Many companies hire from contributor pools

Before You Start

Pick a Project You Actually Use

Don't contribute to a random trending repo. Contribute to something you use daily — you'll understand the problems better and stay motivated.

Good first projects:

  • Your Linux distro (Arch, Ubuntu, Fedora)
  • Tools you use (VS Code, Neovim, Fish shell)
  • Frameworks you build with (Next.js, Django, Rails)
  • CLI tools (ripgrep, fzf, bat)

Understand the Contribution Types

Code isn't the only way to contribute:

TypeExamples
CodeBug fixes, features, performance
DocumentationTypos, guides, API docs, translations
TestingBug reports, test cases, CI improvements
PackagingAUR packages, Debian packages, Homebrew formulas
TriageReproducing bugs, labeling issues, closing duplicates
DesignUI improvements, icons, screenshots
CommunityAnswering questions, writing tutorials, mentoring

Start with documentation or bug reports. They're lower risk and help you learn the project's workflow before touching code.

Contributing to Arch Linux

Arch Linux is one of the best projects for new contributors because of its clear structure and welcoming community.

The Arch Ecosystem

ProjectWhat It IsHow to Contribute
Arch WikiCommunity documentationEdit articles, fix outdated info
AURUser repository of PKGBUILDsCreate and maintain packages
Arch packagesOfficial packagesReport bugs, submit patches
pacmanPackage managerBug reports, code patches
archinstallGuided installerPython code, profiles
mkinitcpioInitramfs generatorBash/C code, hooks

Start with the Arch Wiki

The Arch Wiki is one of the best resources in all of Linux. Contributing here is the easiest entry point.

Set Up an Account

  1. Create an account at wiki.archlinux.org
  2. Read the Help:Editing guide
  3. Read the Help:Style guide

What to Contribute

- Fix outdated package versions or commands
- Add missing steps to installation guides
- Improve clarity of confusing sections
- Add troubleshooting tips you discovered
- Translate articles to your language
- Mark articles that need updating

Example: Fixing an Outdated Wiki Page

You notice the Nginx article references an old config path:

- Edit `/etc/nginx/nginx.conf` and add the following server block:
+ Edit `/etc/nginx/nginx.conf` (or create a new file in `/etc/nginx/conf.d/`):

Small fixes like this are valuable. Thousands of people read these pages.

Create an AUR Package

The Arch User Repository (AUR) is where community-maintained packages live. Creating a package is a great way to contribute.

PKGBUILD Basics

A PKGBUILD is a shell script that tells makepkg how to build a package:

# Maintainer: Your Name <your@email.com>
pkgname=my-tool
pkgver=1.2.0
pkgrel=1
pkgdesc="A useful CLI tool for developers"
arch=('x86_64')
url="https://github.com/author/my-tool"
license=('MIT')
depends=('glibc')
makedepends=('go')
source=("$pkgname-$pkgver.tar.gz::https://github.com/author/my-tool/archive/v$pkgver.tar.gz")
sha256sums=('SKIP')

build() {
    cd "$pkgname-$pkgver"
    go build -o "$pkgname" -ldflags "-s -w" .
}

package() {
    cd "$pkgname-$pkgver"
    install -Dm755 "$pkgname" "$pkgdir/usr/bin/$pkgname"
    install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}

Test Your PKGBUILD

# Validate the PKGBUILD
namcap PKGBUILD

# Build the package
makepkg -s

# Install and test
makepkg -si

# Validate the built package
namcap my-tool-1.2.0-1-x86_64.pkg.tar.zst

Submit to AUR

# Clone the AUR repo (empty for new packages)
git clone ssh://aur@aur.archlinux.org/my-tool.git
cd my-tool

# Add your PKGBUILD
cp ../PKGBUILD .

# Generate .SRCINFO
makepkg --printsrcinfo > .SRCINFO

# Commit and push
git add PKGBUILD .SRCINFO
git commit -m "Initial upload: my-tool 1.2.0"
git push

Adopt an Orphaned AUR Package

Many AUR packages are orphaned (unmaintained). Adopting one is a great way to help:

# Search for orphaned packages you use
# On aur.archlinux.org, filter by "Orphans"

# Click "Submit Request" > "Orphan" on the package page
# Or if already orphaned, click "Adopt"

Then keep it updated:

# Update pkgver
pkgver=1.3.0

# Update checksums
updpkgsums

# Rebuild .SRCINFO
makepkg --printsrcinfo > .SRCINFO

# Commit
git add PKGBUILD .SRCINFO
git commit -m "Update to 1.3.0"
git push

Report Bugs to Arch

Arch uses a Gitlab instance for bug tracking:

  1. Go to gitlab.archlinux.org
  2. Find the relevant project
  3. Check if the bug is already reported
  4. File a new issue with:
    • Package name and version
    • Steps to reproduce
    • Expected vs actual behavior
    • Relevant log output
    • System info (uname -a, pacman -Q package-name)
# Gather system info for a bug report
echo "=== System ===" && uname -a
echo "=== Package ===" && pacman -Q nginx
echo "=== Logs ===" && journalctl -u nginx --since "1 hour ago" --no-pager

General Open-Source Contribution Workflow

These steps apply to any project on GitHub, GitLab, or elsewhere.

Step 1: Find an Issue

Look for labels:
- "good first issue"
- "help wanted"
- "beginner friendly"
- "documentation"
- "easy"

Don't start with "good first issue" on mega-popular projects (React, Kubernetes) — those get claimed in minutes. Find mid-sized projects with active maintainers.

Step 2: Read Before You Code

Before writing a single line:

1. Read CONTRIBUTING.md (or CONTRIBUTING.rst)
2. Read the CODE_OF_CONDUCT.md
3. Read recent merged PRs to understand the style
4. Read the issue comments for context
5. Check if someone is already working on it

Step 3: Set Up the Development Environment

# Fork the repo on GitHub/GitLab
# Clone your fork
git clone https://github.com/YOUR-USERNAME/project.git
cd project

# Add upstream remote
git remote add upstream https://github.com/ORIGINAL-OWNER/project.git

# Create a feature branch
git checkout -b fix/issue-123-typo-in-readme

Branch naming conventions vary. Common patterns:

fix/issue-123-description
feat/add-dark-mode
docs/update-api-reference

Step 4: Make Your Changes

# Make small, focused changes
# One PR = one logical change

# Run existing tests
npm test          # Node.js
pytest            # Python
cargo test        # Rust
make check        # C/C++

# Run linters if configured
npm run lint
flake8 .
cargo clippy

Step 5: Write a Good Commit Message

git commit -m "$(cat <<'EOF'
Fix typo in authentication middleware docs

The example showed `req.user` but the middleware actually sets
`req.currentUser`. Updated the example to match the actual API.

Fixes #123
EOF
)"

Commit message rules:

  • First line: imperative mood, under 72 characters
  • Blank line after first line
  • Body explains why, not what
  • Reference the issue number

Step 6: Submit a Pull Request

# Push to your fork
git push origin fix/issue-123-typo-in-readme

Then create a PR with:

## Summary
Fix incorrect variable name in auth middleware documentation.

## Changes
- Updated `req.user` to `req.currentUser` in the middleware example
- Added a note about the `currentUser` type definition

## Related
Fixes #123

## Checklist
- [x] Read CONTRIBUTING.md
- [x] Tests pass locally
- [x] Linter passes
- [x] Commit message follows convention

Step 7: Respond to Reviews

Maintainers will review your PR. Common feedback:

- "Can you add a test for this?"
- "This doesn't match our coding style, please use X instead"
- "Good change, but can you split this into two PRs?"
- "We decided not to go this direction, closing"

How to handle feedback:

  • Don't take it personally — it's about the code, not you
  • Respond promptly and make requested changes
  • If you disagree, explain your reasoning politely
  • If the PR gets rejected, ask what would be accepted

Step 8: Keep Your Fork Updated

# Fetch upstream changes
git fetch upstream

# Rebase your branch
git checkout main
git merge upstream/main
git push origin main

# Rebase your feature branch
git checkout fix/issue-123-typo-in-readme
git rebase main
git push --force-with-lease origin fix/issue-123-typo-in-readme

Common Mistakes to Avoid

1. Giant PRs

Bad:  1 PR with 47 files changed, 3 features, and a refactor
Good: 3 separate PRs, each focused on one change

2. Not Reading CONTRIBUTING.md

Every project has different rules. Some want signed commits. Some want specific commit formats. Some require CLA signing. Read the docs.

3. Starting Without Asking

For non-trivial changes, comment on the issue first:

"Hi, I'd like to work on this. My approach would be to
add a new middleware that checks X before Y. Does that
align with what you had in mind?"

This prevents wasted work.

4. Ignoring CI Failures

If CI fails on your PR, fix it before requesting review. Check the logs:

# Common CI failures:
- Linting errors
- Type errors
- Failing tests
- Build errors
- Formatting issues

5. Disappearing After Submitting

Maintainers are volunteers. If they review your PR and ask for changes, respond within a few days. Abandoned PRs get closed.

Tools for Open-Source Contributors

Git Configuration

# Sign your commits
git config --global user.signingkey YOUR_GPG_KEY
git config --global commit.gpgsign true

# Better diff algorithm
git config --global diff.algorithm histogram

# Rebase by default on pull
git config --global pull.rebase true

GitHub CLI

# Install gh
# AlmaLinux
sudo dnf install -y gh

# Ubuntu
sudo apt install -y gh

# Fork and clone in one command
gh repo fork OWNER/REPO --clone

# Create PR from terminal
gh pr create --title "Fix auth docs" --body "Fixes #123"

# Check CI status
gh pr checks

# Review PRs
gh pr review 456 --approve

Useful Browser Extensions

  • Refined GitHub — Cleaner GitHub interface
  • OctoLinker — Click imports to navigate code
  • GitHub Isometric Contributions — Better contribution graph

Building a Contribution Habit

Start Small

Week 1: Fix a typo in documentation
Week 2: Improve an error message
Week 3: Add a missing test
Week 4: Fix a "good first issue" bug

Track Your Contributions

# See your recent contributions
gh api graphql -f query='
{
  viewer {
    contributionsCollection {
      totalCommitContributions
      totalPullRequestContributions
      totalIssueContributions
    }
  }
}'

Find Projects That Need Help

Quick Reference

StageAction
FindLook for "good first issue" labels or documentation gaps
ReadCONTRIBUTING.md, recent PRs, issue history
AskComment on the issue before starting non-trivial work
BranchCreate a focused feature branch from latest main
CodeSmall changes, follow existing style, add tests
CommitImperative mood, explain why, reference issue
PRClear title, description, checklist
ReviewRespond promptly, don't take feedback personally
IterateMake requested changes, keep branch updated

Summary

Contributing to open source is a skill you build over time:

  1. Start with what you use — Arch Wiki, your favorite framework, a CLI tool
  2. Start small — Docs, typos, bug reports, then code
  3. Read everything first — CONTRIBUTING.md, recent PRs, coding style
  4. Make focused changes — One PR, one purpose
  5. Communicate — Ask before big changes, respond to reviews quickly
  6. Be patient — Maintainers are volunteers with their own schedules

Your first merged PR is the hardest. After that, you'll wonder why you didn't start sooner.

Recommended Posts