🛸 Hitchhiker's Guide — Phase 01: Apache Contributor Foundations

Read this if: You want to contribute to an Apache project but you've never shipped a patch that got merged — or you've shipped one and still feel invisible. By the end you should be able to draw the Apache trust hierarchy from memory, explain the six trust dimensions that committers use to evaluate candidates, and place any engineer (including yourself) on the contributor ladder with a clear picture of what it would take to move up.

0. The 30-second mental model

Apache projects are maintained by a trust-weighted graph of engineers, not a company org chart.

Users
└── Contributors    (send patches, file bugs, vote non-bindingly)
      └── Committers    (write access; can merge; trusted with the code)
           └── PMC Members    (binding governance; vote on releases, new committers)
                └── PMC Chair    (reports to ASF Board; administrative, not technical authority)
                     └── ASF Board    (elected by ASF Members; governs all projects)

Three questions drive every major decision in an Apache project:

  1. Can we trust this person with the codebase long-term?
  2. Will this change help or hurt future maintainers?
  3. Does the community support this direction?

By the end of Phase 01 you should be able to place any engineer on this graph and explain what it would actually take to move them up one level.

1. The Apache Hierarchy in Depth

1.1 Users

Users file bugs, ask questions on user@, and sometimes vote (+1/0/-1) on mailing list decisions. Their votes are not binding on release or governance matters. Users build on the project but have no formal standing in its governance.

1.2 Contributors

A contributor has submitted at least one accepted patch, reported and helped diagnose a confirmed bug, or contributed documentation, tests, or design review. "Contributor" is informal — there is no ceremony for it and no roster entry.

What separates contributors from non-contributors in the Apache model is visible, trackable participation. The project's JIRA, GitHub, and mailing list archives are permanent. Maintainers remember — and search — who did what.

1.3 Committers

Committers have been explicitly elected by the PMC. They have write access to the codebase. They can merge patches (their own and others'). They can vote on releases and governance matters — but only PMC members' votes are binding.

"A committer is not someone who can write good code. A committer is someone the current committers trust to make good decisions about the project without supervision." — paraphrased from Apache Contributor Guide

The election process:

1. A PMC member nominates a contributor (private@ PMC mailing list)
2. PMC discusses — can take days to weeks
3. Formal vote is held
   - Requires 3+ binding +1 votes
   - Zero binding -1 vetoes
4. If approved, ASF Infrastructure grants repository access
5. New committer is announced on dev@ mailing list

1.4 PMC Members

PMC = Project Management Committee. PMC members:

  • Cast binding votes on releases (3 binding +1, no vetoes required)
  • Vote on adding new committers and new PMC members
  • Steer the project's roadmap and policies
  • Are the legal stewards (with the ASF) of the project's releases

A committer can be invited to the PMC. Most PMC members are also committers, but the two roles are technically independent.

1.5 PMC Chair

Each Apache project has a PMC Chair who acts as VP for that project and reports quarterly to the ASF Board. The Chair is elected by the PMC — it is an administrative and communications role, not a technical authority role. The Chair has no veto power that regular PMC members lack.

1.6 ASF Members and the Board

The ASF Board is elected by ASF Members (individuals recognized for significant ASF contributions across projects). The Board delegates all project decisions to PMCs and intervenes only when a project fails to follow ASF policies. Day-to-day technical decisions are never made at the Board level.

2. How Trust Is Actually Built

This is the section most engineers miss. Trust in Apache is compound interest: small deposits over a long time outperform large deposits made once.

2.1 The Six Trust Dimensions

DimensionWhat it means in practice
Technical credibilityYou find real bugs. Your fixes are correct and don't introduce regressions. Your reviews identify real problems, not style preferences.
Review qualityYour comments are constructive, specific, and actionable. You understand the codebase well enough to see second-order effects. You review others' patches consistently, not just when it benefits you.
ReliabilityYou follow through. You pick up issues you claimed. You don't abandon in-progress patches after receiving review comments. When you say you will do something, you do it.
CommunicationYou write clearly on mailing lists and JIRA. You respond to questions. You acknowledge disagreement without hostility. You explain why, not just what.
Stewardship mindsetYou think about the project's long-term health, not just your immediate feature or fix. You ask "what happens to the operator running this in production two years from now?"
Community participationYou help new contributors. You answer user questions. You show up consistently — not just when you need something. You participate in design discussions even when it's not your code.

2.2 Why Technically Strong Engineers Never Become Committers

This happens more than most people expect. Five failure modes:

Failure Mode 1 — Low review engagement

The engineer submits good patches but never reviews others' code. Reviewers feel like the engineer is extracting value from the project — consuming the review bandwidth of others without contributing to it. Trust stagnates regardless of patch quality.

Failure Mode 2 — Abandoning patches mid-cycle

Filing a JIRA, producing a draft patch, receiving review comments, then going silent is one of the fastest ways to damage trust. It creates work for maintainers who must re-triage the issue. One abandoned patch is forgiven. Two is a pattern.

Failure Mode 3 — Design without community alignment

Building a large feature privately and then submitting a 5,000-line patch is a reliable path to rejection — not because the code is bad, but because:

  • The PMC had no chance to redirect the design early
  • The review burden is enormous
  • There may be better alternatives nobody got to suggest
  • The author has sunk cost and will resist changes

Apache favors incremental changes discussed openly on dev@ before significant implementation begins.

Failure Mode 4 — Adversarial communication

A single dismissive or hostile exchange on a mailing list can set back a committer candidacy by years. The Apache community is small enough that everyone reads the archives. A reputation for poor communication persists.

Failure Mode 5 — Treating Apache as a vendor

Some contributors engage only when they need a bug fixed or a feature for their employer. This is obvious to maintainers. Community members who contribute durably regardless of immediate self-interest are the ones who get elected.

2.3 What Senior Maintainers Actually Evaluate

When a PMC member considers nominating a contributor, the mental checklist looks like this:

1. Have I (and other committers) seen this person's patches over multiple months?
2. Do they find issues we wouldn't have found ourselves?
3. Do their patches arrive already well-tested and documented?
4. When we pushed back, did they understand why and improve — or argue defensively?
5. Have they reviewed others' patches, and were those reviews genuinely helpful?
6. Do they participate on the dev list or just submit code?
7. Would I be comfortable if they had write access and I was on vacation for two weeks?

Question 7 is the real one. Committer access means merge access without review. PMC members are trusting the nominee with the production quality of a system used by thousands of companies and millions of users.

3. The Stewardship Mindset

Stewardship is the quality that separates committers from contributors, and PMC members from committers. It is also the quality most difficult to fake and most rewarding to genuinely develop.

A steward asks:

"What is the right long-term decision for the project, even if it is harder for me right now?"

3.1 Stewardship Behaviors in Practice

Backward compatibility by default: You do not break APIs unless the benefit is overwhelming and a documented migration path exists. You assume the person upgrading from version N to N+1 has 50 production jobs depending on the behavior you are about to change.

Incremental change: You break large improvements into reviewable patches, each of which leaves the project in a better state than it was before. A reviewer should be able to understand each patch independently.

Operational empathy: You think about the operators who run this system in production, not just the developers using the API. "What happens when this node fails during the migration?" is an operational question that most feature implementors don't ask.

Documentation as a first-class artifact: Design docs, migration guides, release notes, and JIRA descriptions are not afterthoughts — they are part of the contribution. A patch without a test is suspicious. A design doc without a migration section is incomplete.

Saying no as a service: Rejecting a well-intentioned patch that would create long-term maintenance burden is a contribution to the project, not a rejection of the person. The hardest part of stewardship is learning to say "this is not the right approach" kindly and clearly.

3.2 The Five-Year Test

A useful mental exercise: imagine the project in five years, with 20 new committers who weren't there when this change was made.

  • Will they understand why it was done?
  • Will they be able to maintain it?
  • Will it have created problems they'll need to untangle?
  • Did the documentation survive?
  • Did the compatibility guarantee hold?

If the answer to any of these is "probably not," the change needs more work.

4. Apache Mailing Lists — The Permanent Record

Apache projects operate on mailing lists, not Slack or Discord. This is intentional — mailing lists create a permanent, searchable, asynchronous record of every technical and governance decision.

4.1 The Three Primary Lists

ListPurpose
dev@project.apache.orgTechnical discussion, patch reviews, design proposals, release coordination
user@project.apache.orgEnd-user questions and support
private@project.apache.orgPMC-only; committer nominations, sensitive governance

All dev@ and user@ archives are public. Everything you write becomes part of the project's permanent technical history.

4.2 Communication Norms

Be specific: "This may have a performance issue" is not a useful review comment. "In TaskSchedulerImpl.submitTasks(), the taskIdToTaskSetManager map is accessed without synchronization on the CoarseGrainedSchedulerBackend thread; this can cause a ConcurrentModificationException under concurrent task submission" is.

Be patient: Apache contributors span dozens of time zones and most are volunteers or split their time between employer work and community work. A week of silence is not rejection.

Start a thread before writing code: For non-trivial changes, send a [DISCUSS] thread to dev@ before writing a patch. This surfaces design concerns early and builds community alignment before you have sunk cost in an implementation.

Understand consensus vs majority: Apache uses consensus, not majority rule. A single binding -1 (veto) on a release or governance motion blocks it. Vetoes must be accompanied by a technical reason, but the veto-holder is not required to accept a rebuttal. The right response to a veto is to address the technical concern — not to outvote.

4.3 Vote Notation

+1  : I actively support this
+0  : I don't object but won't advocate
 0  : Neutral
-0  : I have concerns but won't block
-1  : I veto this (must include technical justification)

For releases: a binding -1 blocks the release until the technical concern is resolved.
For committer elections: a binding -1 with technical justification blocks the election.
For most code changes: consensus is assumed if no binding -1 appears within a reasonable period (lazy consensus).

4.4 Searching Archives

Every mailing list archive is publicly searchable. Before asking a question on dev@:

  1. Search the archive at lists.apache.org — the question may have been answered
  2. Search JIRA — there may be an open or closed issue
  3. Search the project's documentation

Asking a question that was answered three months ago on the list is a small negative signal. Referencing the prior thread and asking a follow-up is a positive one.

5. Reading a Contributor's Public History

5.1 Where the Evidence Lives

SourceWhat to look for
Apache JIRAIssues filed, patches attached, review comments left, issues assigned and completed vs abandoned
GitHubPull requests authored and reviewed, comments, consistency over time
dev@ archivesDesign proposals, DISCUSS threads, vote participation, response quality
Apache Whimsywhimsy.apache.org/roster/committee/ — official PMC and committer rosters
Apache ReporterProject health stats, commit activity, release history

5.2 What a Strong Contributor Profile Looks Like

Timeline: 18+ months of visible activity
JIRA:
  - 20+ issues filed with good reproduction cases
  - 15+ patches submitted, most accepted
  - Comments on 30+ issues (not just "any update?")
  - No abandoned patches without explanation
GitHub:
  - Consistent PR review activity across multiple components
  - Review comments that identify real problems
dev@ list:
  - Participated in at least 3 DISCUSS threads
  - Responded constructively when challenged
  - Answered 5+ user@ questions
No red flags:
  - No hostile exchanges
  - No pattern of claiming issues then going silent
  - Activity spread over time, not burst-and-disappear

5.3 What a Weak Contributor Profile Looks Like (Despite Technical Skill)

Activity: 3–6 months, driven by a single employer need
JIRA: 5 patches submitted, 3 accepted — but only for one subsystem
GitHub: 0 reviews on others' PRs
dev@ list: 0 DISCUSS thread participation; 0 user@ responses
Pattern: contributor got what they needed and disengaged

This profile is common and almost always results in stalled committer candidacy. The engineer is technically capable but has not demonstrated the durability and breadth the community requires.

6. Interview Questions — Concepts You Must Explain Out Loud

TopicOne-line answer
Difference between a committer and a PMC member?Committer has write access and technical trust; PMC member has binding governance authority over releases, new committers, and project direction.
How does someone become an Apache committer?Nominated by a PMC member, elected by PMC vote (3+ binding +1, no vetoes), then access is granted by ASF Infrastructure.
What is a binding vote?A vote from a PMC member that counts toward the required threshold on releases or governance decisions. Committer votes are advisory unless the committer is also a PMC member.
What is lazy consensus?A proposal is considered accepted if no binding -1 appears within a defined period (typically 72 hours for minor changes).
Why does Apache favor mailing lists over chat?Permanent record, searchable history, asynchronous collaboration, timezone inclusiveness, no vendor lock-in.
How should you propose a major change?Send a [DISCUSS] thread to dev@ before writing code, establish alignment, then implement incrementally.
Why do large patches fail review?Hard to review, introduce many concerns at once, create compatibility risk, and are difficult to revert. The author also has sunk cost and resists changes.
Why do technically strong engineers fail to become committers?Low review engagement, inconsistent participation, poor mailing list behavior, abandoning in-progress work, or transactional relationship with the project.
What is operational empathy in a distributed system context?Thinking about the person running your code in production at 3am, not just the developer calling your API in a test.
What is the five-year test?Imagining the project 5 years later with new maintainers who weren't there when your change was made — will they understand, maintain, and not be harmed by it?

7. References