Warmup Guide — Apache Contributor Foundations

Zero-to-expert primer for Phase 01. Explains, from nothing, what the Apache Software Foundation is, how its trust model actually works, and how careers inside it are built — so the two labs (contributor landscape, trust audit) have full context.

Table of Contents

Chapter 1: What the ASF Is

From zero: the Apache Software Foundation is a US 501(c)(3) charity (founded 1999, descended from the Apache HTTP Server group) that provides legal, infrastructural, and governance shelter for ~300 open-source projects — Hadoop, Spark, Kafka, Hive, Flink, Iceberg among them. It owns the trademarks, holds the licenses, runs the infrastructure, and — crucially — defines the governance template every project follows.

Why a foundation at all: corporate-owned open source can be relicensed, abandoned, or weaponized by its owner. ASF projects can't be: the license (Apache 2.0) is fixed, the governance is by individuals on their own merit (not their employers), and the Board audits each project's independence. For companies betting infrastructure on these projects, that neutrality is the product. This is also why committer status is personal and portable — it survives changing employers, which is precisely what makes it a career asset.

The hierarchy above a project: Board → elected by ASF Members (individuals) → each project's PMC reports quarterly to the Board. Below that, everything is per-project.

Chapter 2: The Apache Way — Five Operating Principles

These phrases carry precise operational meaning; the labs ask you to observe them in the wild:

  1. Community over code: a project with healthy reviewers and a mediocre codebase outlives the reverse. Decisions optimize for the decade, not the sprint.
  2. Merit, earned and remembered: status is granted retroactively for sustained contribution. You cannot apply to be a committer; you are noticed into it.
  3. Open communications — "if it didn't happen on the list, it didn't happen": decisions made in private (a company Slack, a hallway) are not decisions. This rule protects contributors who aren't in the room — including you.
  4. Consensus before votes: voting is the fallback when discussion fails, not the default. Lazy consensus ("I'll do this in 72h absent objections") keeps velocity.
  5. Independence: hats matter — a committer employed by Cloudera speaks as an individual; PMC composition spanning employers is a health metric the Board watches (and your Lab 01 measures).

Chapter 3: The Role Ladder

RoleGranted byWhat it actually means
User—Uses the software; bug reports already count as contribution
Contributor—Patches, docs, reviews, list answers — no formal status
CommitterPMC voteWrite access; judgment trusted on day-to-day changes
PMC memberPMC voteBinding votes on releases/people; accountable to the Board
PMC ChairBoard appointAdministrative officer, not a boss — files the reports
ASF MemberMembers voteFoundation-level citizenship, cross-project

The numbers that calibrate expectations (your Lab 01 will measure real ones): typical contributor→committer journeys in major data projects run 9–24 months and 20–60 merged patches plus visible review/list activity. Spark has had ~2,000 contributors and ~75 committers — a ~4% conversion. The ladder is real but steep, and each project's culture sets a different grade.

Chapter 4: The Trust Model — What Is Actually Being Evaluated

The non-obvious core of this phase: a committer vote is a risk assessment, not a reward. Write access means your judgment executes without prior review. The PMC is asking: if this person merges something at 2am, do we sleep? Concretely, they weight:

  • Calibration: do you know what you don't know? (Asking good questions scores positively; overconfident patches in unfamiliar subsystems score very negatively.)
  • Follow-through: do your merged patches stay healthy? Do you respond when your change breaks CI a week later? Abandoned messes are remembered for years.
  • Review behavior: reviewing others' patches is the single most legible trust signal — it is literally practicing the committer job in public.
  • Conflict behavior: how you took your first harsh review; how you handled being wrong. One graceless thread can outweigh twenty good patches.
  • Sustained presence: monthly-for-a-year beats daily-for-six-weeks-then-gone. The fear behind the criterion: committers who vanish leave unmaintainable code with write access.

The strategic consequence: optimizing for merged-PR count is optimizing the wrong variable. The Lab 02 trust audit has you score yourself against these axes and design the gap-closing plan.

Chapter 5: Where Apache Work Happens — Lists, JIRA, GitHub

The tooling map (projects vary; Spark/Hadoop/Hive conventions):

  • dev@ mailing list: design discussions, votes, release threads. Slow, archived, authoritative. Reading six months of archives is the fastest culture download available — Lab 01 requires a slice of this.
  • user@: support. Answering questions here is an underrated trust builder (it proves knowledge and patience).
  • JIRA (or GitHub Issues): the work ledger. Issue quality — reproduction, version, stack trace, minimal case — is your first writing sample.
  • GitHub PRs: code review happens here now for most projects, but decisions still belong to the list (principle 3).
  • Slack/Discord where they exist: ephemeral, convenience-only; nothing binding.

Etiquette constants: search before filing; one topic per thread; patches small; silence ≠ rejection (ping politely after a week); never DM-pressure a reviewer.

Chapter 6: Reading a Project's Social Topology

Lab 01's skill — given a project, map who actually moves it:

  • git shortlog -sn --since="1 year ago" — the live contributor distribution (expect a power law; note where the elbow is).
  • Match top authors against the project's committer/PMC roster (every project publishes one) — the gap between "high committer" and "high author" reveals who reviews vs who writes.
  • Read 10 recently merged PRs and 10 stalled ones: who reviewed, how long to first response, what stalled the stalled ones (no reviewer? scope? contributor vanished?).
  • Employer mapping (public affiliations): single-employer dominance is a risk flag — and an opportunity flag for an outsider with sustained presence.
  • Identify the 2–3 people whose review unblocks the subsystem you care about. Your eventual first patches should land in their area of attention, scoped to be easy to say yes to.

Lab Walkthrough Guidance

Order: Lab 01 (landscape) → Lab 02 (trust audit) — measure the territory, then yourself against it.

  • Lab 01: pick ONE project you plausibly intend to contribute to (the analysis pays off later phases). Fill the contributor-profile template with measured numbers (shortlog, roster, PR latencies), not impressions. Deliverable test: could someone else plan their first patch from your map alone?
  • Lab 02: score yourself on Chapter 4's five axes with evidence (links, dates), not self-ratings. The output is a 6-month plan whose units are observable acts ("review one open PR per week in module X"), not virtues ("get better at Java").

Success Criteria

You are ready for Phase 02 when you can, from memory:

  1. Explain committer vs PMC vs Chair, and who grants each.
  2. State the five Apache Way principles with one operational consequence each.
  3. Describe the trust model as a risk assessment and name its five evaluation axes.
  4. Name where decisions are binding (the list) and why that rule protects you.
  5. Produce, for your chosen project: the contributor power-law shape, the 2–3 key reviewers in your target subsystem, and the median first-response latency.

Interview Q&A

Q: Why do companies pay Staff salaries for committer status? Because it is non-purchasable influence over infrastructure the company depends on: patches land faster, the roadmap hears their needs, releases get unblocked, and the trademark of trust transfers to the company's hiring and credibility. A committer on staff is a seat at a table money can't otherwise buy — which is also why the status being personal (it leaves with you) makes it a career asset.

Q: How would you earn committership in a project where you know nobody? Months 0–2: build, run tests, fix the onboarding doc gaps I hit (cheap, genuinely valued); triage and reproduce others' bug reports. Months 2–6: small correct patches in one subsystem until the same reviewers see my name repeatedly; answer user@ questions in that area. Months 6+: review others' PRs in that subsystem, take on a stuck-but-wanted issue, stay present. The plan optimizes reviewer recognition and trust, not patch count.

Q: What's the biggest mistake new contributors make? Submitting a large, multi-concern first patch into a subsystem they haven't read, then going silent when review stalls. It maximizes reviewer cost exactly when trust is zero. The inverse strategy — small, test-covered, in an active reviewer's area, with fast responses — is mechanically easy and rare enough to be noticed.

References