Skip to content

13 - Picking a Project

What this session is

About 30 minutes plus browsing. What "Linux-adjacent open source" looks like for someone with terminal skills but not a programming language background - and how to evaluate one.

What kinds of project welcome you

You've learned command-line Linux but not a programming language. The OSS projects that fit your skills are:

  • Dotfiles repos. Configuration files for shells, editors, terminal tools. People share their setups.
  • Shell scripts and CLI utilities. Small bash/python/shell-based tools.
  • Documentation for any project. Docs are read more than code; improvements are always welcome.
  • Distro / package configuration. Helping with Debian package metadata, Arch AUR packages, NixOS configs.
  • Ansible roles, Docker images, Kubernetes manifests. Config-as-code.
  • Translations. Many projects need help translating their UI or docs.

Many of these are perfect first-contribution territory because they don't require deep programming.

What "manageable" means

  1. Small. Under 5k lines of any code/config.
  2. Active. Recent commits, responsive maintainers.
  3. Friendly tone. Welcoming README, code-of-conduct, polite issue interactions.
  4. You actually use or care about the project. Motivation matters.

10-minute evaluation

Same checks as the other beginner paths: - Stars: 100-10000. - Last commit: within a month. - Open issues: many, with labels. - PR merge time: under 14 days. - CONTRIBUTING.md exists.

Candidates

Tier 1 - dotfiles, shell tools, small CLI utilities

  • mathiasbynens/dotfiles - a famous, well-organized dotfiles repo. Issues range from "improve a script" to "add a new alias I find useful."
  • thoughtbot/dotfiles - opinionated dev setup. Active.
  • Your own dotfiles. Start one. Publish to GitHub. Contributors will come.
  • junegunn/fzf - fuzzy finder, written in Go. The user community contributes scripts and docs heavily.
  • tldr-pages/tldr - community-curated command examples (like a friendlier man). Adding/improving entries is a perfect first contribution. Highly recommended for a first PR.
  • tj/git-extras - extra git commands. Mostly shell scripts.

Tier 2 - sysadmin tools, infra config

  • ansible-collections/... - modular Ansible content. Each role is small.
  • prometheus-community/... - exporters, dashboards, alerts. Configuration repos.
  • Various distro package repos - Debian, Arch AUR, Nixpkgs. Mostly metadata work.
  • asdf-vm/asdf - version manager. Plugins are individual repos, often small.

Tier 3 - docs and translation

  • Most popular open-source projects - Linux distributions, Kubernetes, Docker, etc. - have separate docs/ repos or i18n/ directories where docs-only contributions are very welcome.
  • kubernetes/website - Kubernetes documentation. Active translation effort; English clarifications welcome.
  • docker/docs - Docker docs.
  • mozilla-l10n/... - Mozilla's localization repos.

Tier 4 - the big stuff, don't start here

  • The Linux kernel itself (C, complex, slow review).
  • Major web browsers.
  • Anything with a big-company CLA process.

tldr-pages: a near-perfect first contribution

tldr-pages deserves special mention. It's: - A community-curated set of example-driven man pages. - Written in Markdown. - Small, well-organized. - Welcoming to first-time contributors. - Has dozens of "good first issue" tickets at any time (typos, missing examples, missing commands).

If you finish this path and want one specific recommendation for a first PR: tldr-pages. Fix a typo. Add a missing example. Translate an entry. Submit. Five-minute PR; real-world workflow.

How to find issues

Project's Issues tab → Labels. Look for: - good first issue - help wanted - documentation - easy

Read 5-10. Pick one where: - Description is clear. - Fix is contained. - Nobody has claimed it. - It hasn't been sitting open for a year.

Comment: "I'd like to work on this; can you confirm it's still wanted?" Wait for the maintainer.

What counts as a contribution

For Linux-adjacent OSS:

  • Fix a typo in a README.
  • Improve the docs for a command-line flag.
  • Add a missing example to a tldr-pages entry.
  • Add a missing alias to a dotfiles repo.
  • Improve a shell script's error message.
  • Translate a doc page.
  • Add a missing test for a script.
  • Improve an Ansible role's variable defaults.

All real. All count.

Exercise

  1. Browse three projects from Tier 1.
  2. Run the 10-minute eval on each.
  3. Pick the most responsive.
  4. Read its CONTRIBUTING.md.
  5. Clone: 
    git clone https://github.com/<owner>/<repo>
cd <repo>
    Browse the file structure. Run any tests/checks they document.
  6. Browse the good first issue list. Pick two candidates - don't claim yet.

If you can't decide: pick tldr-pages. It's a guaranteed positive experience.

What you might wonder

"I don't really know any programming language. Am I going to be useful?" Yes. Plenty of OSS work isn't programming - docs, configs, scripts, infrastructure, translations. The contribution workflow (git, PRs, code review) is the same regardless of what you're contributing. After this path you have those skills.

"What if I want to get into 'real' Linux work?" Move to the "Linux Kernel" path next (which assumes a C-and-Unix background). Or pick up a programming language first - the "Go from scratch" or "Python from scratch" paths are good companions.

"Should I publish my own dotfiles?" Yes. Even a tiny dotfiles repo on your GitHub is useful - it's your config, version-controlled, syncable. Plus it teaches you git in a low-stakes way.

Done

  • Understand the kinds of Linux-adjacent OSS that fit terminal skills.
  • Run the 10-minute eval.
  • Have specific candidate projects in mind.
  • Have a tentative issue.

Next: Anatomy of a small project →

Comments