Skip to content

Appendix C-Contributing to the Container Ecosystem

The container ecosystem is in a few major repos, all on GitHub, all with active maintainer communities.

C.1 The Project Map

Project Language Scope Difficulty Notes
opencontainers/runc Go Reference OCI runtime Hard Slower review; correctness-first
opencontainers/runtime-spec Markdown Spec Medium Doc PRs welcome; behavior changes need TOB consensus
opencontainers/image-spec Markdown Spec Medium Same as above
containers/podman Go Daemonless container manager Medium Active, friendly
containers/buildah Go Image build library/CLI Medium Active, friendly
containers/skopeo Go Image transport tool Easy–Medium Smaller surface, good first patches
containerd/containerd Go Container daemon Hard Large; subsystem-specific reviewers
cri-o/cri-o Go Kubernetes CRI runtime Medium Friendly to newcomers
containers/crun C Fast OCI runtime Hard Single maintainer historically; high bar
containers/youki Rust Rust OCI runtime Medium Smaller, more approachable than runc
sigstore/cosign Go Image signing Medium Active, growing
anchore/syft & anchore/grype Go SBOM + vuln scan Medium Friendly
aquasecurity/trivy Go Vuln + config scan Medium High velocity
google/go-containerregistry Go OCI registry library Easy–Medium Underused gem; good starter

C.2 First-Issue On-Ramps

Easy

  • skopeo: documentation fixes, new transport options, bug reports with reproductions.
  • go-containerregistry: examples, error-message improvements, new registry-mirror tests.

Medium

  • podman: bug fixes for edge cases (look at the kind/bug + good-first-issue labels).
  • buildah: feature parity gaps with docker build BuildKit features.
  • cri-o: small CRI-protocol corrections.
  • syft: new package format detectors (e.g., a niche language ecosystem).
  • cosign: documentation, integration examples, smaller bug fixes.

Hard

  • runc: anything in libcontainer/ is high stakes-security-critical.
  • containerd: snapshotters, the CRI plugin, runtime shims.
  • youki: larger features as the project still has gaps vs runc.
  • crun: C, low-level, single-maintainer ergonomics.

C.3 The Workflow (typical GitHub project)

  1. File or claim an issue. Read the contributing guide first; some projects require pre-discussion.
  2. Fork, branch, code.
  3. Sign-off your commits. All container projects require DCO (git commit -s).
  4. Run the test suite locally. make test or per-project equivalent.
  5. Open a PR. Reference the issue. Describe the change and the testing.
  6. Address review. Most projects use squash-merge; rebase your branch on main as needed.
  7. Merge. Maintainer approves; CI green; merged.

Cycle time varies: skopeo / cosign / syft are fast (days). runc / containerd are slow (weeks).

C.4 The OCI Process (spec changes)

Spec changes are governed by the OCI Technical Oversight Board. The process: 1. Open an issue describing the proposed change. 2. Build consensus on the issue thread (this is the slowest step). 3. Open a PR with the spec change. 4. The TOB reviews; super-maintainers approve. 5. Merge; release the spec on the next cadence.

This is not a fast path. Reserve it for genuine spec-shaped problems; everything else fits in a tool repo.

C.5 Calibration

A reasonable goal for a curriculum graduate:

  • By end of week 23: a PR open against skopeo, syft, cosign, or another approachable repo (a doc fix or small bug fix is sufficient).
  • By end of capstone: that PR merged.
  • 6 months post-curriculum: a substantive contribution-a new transport in skopeo, a new package detector in syft, a new feature in podman.

The container ecosystem is genuinely welcoming to newcomers. The path from "user" to "contributor" is shorter than in most kernel-adjacent projects.

Comments