Skip to content

13 - Picking a Project

What this session is

About 30 minutes + browsing. What "containerized OSS" projects accept first contributions, with specific candidates.

What kinds of projects fit container skills

The OSS work you can do with container skills (without needing deep programming):

  • Improve Dockerfiles - slimming, multi-stage builds, non-root user, pinning, multi-arch.
  • Improve compose.yaml - health checks, env-file examples, missing services.
  • Fix bugs in container-related code - entrypoint scripts, init scripts, install scripts.
  • Improve documentation - most container docs lack examples or have inconsistencies.
  • Add GitHub Actions - build-and-push workflows that don't yet exist.
  • Translate container/deployment docs.

These are everywhere. Almost every OSS project today ships container images.

10-minute evaluation

Same criteria as the other beginner paths:

Signal Target
Stars 100-50000
Last commit Within a month
Open PRs Some, not 200+
Recent PR merge time Under 14 days
good first issue count At least 5
Has a CONTRIBUTING.md yes
docker build works on fresh clone yes

Candidates

Tier 1 - small, gentle

  • nginxinc/docker-nginx - official nginx Docker image (the Dockerfile for nginx:latest). PRs improving the Dockerfile here ship to millions.
  • docker-library/ - Docker's official image collection. Each language/database has a sub-repo. Excellent labels.
  • linuxserver/docker-baseimage-alpine - base images used by many linuxserver.io images. Small, active.
  • cookiecutter-docker-science - small templates for containerized science workflows.

Tier 2 - medium, well-organized

  • Plausible/community-edition - analytics platform with a compose-based deployment.
  • getsentry/onpremise - Sentry's on-premise containerized stack.
  • nextcloud/docker - Nextcloud's container images. Active.
  • testcontainers/testcontainers-* - Testcontainers (various languages). Containerization for tests.
  • bitnami/charts - Bitnami's Helm charts (technically Kubernetes; container topology nonetheless).

Tier 3 - larger, more visible

  • docker/docs - Docker's docs site. Improving examples or fixing typos is a great first PR.
  • docker-library/official-images - the meta-repo that governs all official images.
  • docker/buildx - Buildx itself.

Tier 4 - don't start here

  • The Docker engine itself. Large, Go, complex.
  • moby/moby - Docker's runtime. Same.

A specific recommendation: docker-library/

docker-library/* repos are excellent first targets. Each Dockerfile is small, public, and gets heavy use. Issues range from "fix typo in the README" to "add example for X". Maintainers are responsive.

Pick one whose underlying project you use: docker-library/postgres, docker-library/python, docker-library/redis, etc.

Finding issues

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

Read 5-10. Pick one with: - Clear description. - Contained fix (one file, ideally). - Unclaimed. - Not open for a year.

Comment to claim. Wait for maintainer confirmation.

What counts

For container work: - Updating a Dockerfile to a newer base. - Adding a non-root user. - Adding a .dockerignore. - Adding multi-stage. - Adding multi-arch builds via buildx. - Fixing a typo in a Docker Hub README. - Adding an example to documentation. - Fixing a broken compose example.

All real, all count.

Exercise

  1. Browse three Tier 1 / Tier 2 projects.
  2. 10-minute evaluation on each.
  3. Pick the most responsive.
  4. Read CONTRIBUTING.md.
  5. Clone:
    git clone https://github.com/<owner>/<repo>
    cd <repo>
    docker build . -t test:1.0
    
    If the build fails on a fresh clone, that's already a flag - either you missed setup, or the project's docs are out of date (might be a good first issue right there).
  6. Browse good first issue tickets. Pick two candidates.

What you might wonder

"What if I don't see Docker-specific labels?" Some projects use generic labels. Filter by docker keyword in the issue search bar, or Dockerfile, or containerization.

"What if no one's published a Dockerfile for a tool I love?" That IS a contribution. Open an issue: "Would a Dockerfile + GHCR build be welcome?" If yes, submit one.

Done

  • Recognize container-OSS contribution shapes.
  • Run the 10-minute eval.
  • Have specific candidate projects.

Next: Anatomy of a containerized OSS project →

Comments