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:
| Type | Examples |
|---|---|
| Code | Bug fixes, features, performance |
| Documentation | Typos, guides, API docs, translations |
| Testing | Bug reports, test cases, CI improvements |
| Packaging | AUR packages, Debian packages, Homebrew formulas |
| Triage | Reproducing bugs, labeling issues, closing duplicates |
| Design | UI improvements, icons, screenshots |
| Community | Answering 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
| Project | What It Is | How to Contribute |
|---|---|---|
| Arch Wiki | Community documentation | Edit articles, fix outdated info |
| AUR | User repository of PKGBUILDs | Create and maintain packages |
| Arch packages | Official packages | Report bugs, submit patches |
| pacman | Package manager | Bug reports, code patches |
| archinstall | Guided installer | Python code, profiles |
| mkinitcpio | Initramfs generator | Bash/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
- Create an account at wiki.archlinux.org
- Read the Help:Editing guide
- 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 updatingExample: 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.zstSubmit 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 pushAdopt 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 pushReport Bugs to Arch
Arch uses a Gitlab instance for bug tracking:
- Go to gitlab.archlinux.org
- Find the relevant project
- Check if the bug is already reported
- 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-pagerGeneral 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 itStep 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-readmeBranch naming conventions vary. Common patterns:
fix/issue-123-description
feat/add-dark-mode
docs/update-api-referenceStep 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 clippyStep 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-readmeThen 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 conventionStep 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-readmeCommon 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 change2. 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 issues5. 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 trueGitHub 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 --approveUseful 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" bugTrack Your Contributions
# See your recent contributions
gh api graphql -f query='
{
viewer {
contributionsCollection {
totalCommitContributions
totalPullRequestContributions
totalIssueContributions
}
}
}'Find Projects That Need Help
- good-first-issues.github.io
- up-for-grabs.net
- firsttimersonly.com
- GitHub "Explore" tab → Topics you're interested in
Quick Reference
| Stage | Action |
|---|---|
| Find | Look for "good first issue" labels or documentation gaps |
| Read | CONTRIBUTING.md, recent PRs, issue history |
| Ask | Comment on the issue before starting non-trivial work |
| Branch | Create a focused feature branch from latest main |
| Code | Small changes, follow existing style, add tests |
| Commit | Imperative mood, explain why, reference issue |
| PR | Clear title, description, checklist |
| Review | Respond promptly, don't take feedback personally |
| Iterate | Make requested changes, keep branch updated |
Summary
Contributing to open source is a skill you build over time:
- Start with what you use — Arch Wiki, your favorite framework, a CLI tool
- Start small — Docs, typos, bug reports, then code
- Read everything first — CONTRIBUTING.md, recent PRs, coding style
- Make focused changes — One PR, one purpose
- Communicate — Ask before big changes, respond to reviews quickly
- 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.