This guide was generated from real discussion threads on the Apache Incubator mailing list, including proposals where committer selection, contribution legitimacy, and community health concerns played a central role.

Who This Guide Is For

  • Project proposers
  • Podling PPMCs
  • Mentors
  • IPMC members reviewing proposals

It explains how the ASF evaluates the legitimacy of a project’s committer group and what patterns signal that a project is not yet ready for incubation.

How To Use This Guide

  • Proposers can use it as a reality check before sending a proposal.
  • Mentors and IPMC members can use it as shared language when giving feedback about committer lists and community structure.

Why This Matters

Committers are not a marketing asset or a status label.

At the ASF, committing rights reflect:

  • Demonstrated contribution
  • Trust earned over time
  • Participation in public, community-led development

A project’s proposed committer list is one of the strongest indicators of:

  • Governance maturity
  • Community reality
  • Project sustainability
  • Ability to operate under ASF norms

The Incubator regularly encounters proposals where the committer list does not reflect the actual community. This guide distils the common patterns behind that, and the expectations that sit behind ASF review questions.

1. What ASF Looks For in a Healthy Committer Group

Before looking at failure modes, it helps to be clear about what a good proposal shows.

Reviewers are reassured when:

  • The committer list closely matches the people who are doing the work in the public repository and issue tracker.
  • More than one person is regularly contributing, reviewing, and making decisions.
  • Committers understand ASF-style development (public lists, voting, shared review).
  • There is at least some diversity of role, employer, or background, or a clear intention to welcome that.
  • Public history shows active review and collaboration, not just one person pushing code.

The rest of this guide describes common ways proposals diverge from this picture.

2. Inflated or Aspirational Committer Lists

Some proposals include a long list of “committers” who:

  • Have never contributed to the repository
  • Have only a single small commit
  • Were added because it “looks good”
  • Do not know they are being proposed
  • Are not active and have no intention of participating

This pattern often triggers questions such as:

  • Who is actually doing the work?
  • Why are these people listed?
  • Do they understand the responsibilities of a committer?

In ASF terms, committer lists should describe who is already acting like a committer, not who might do so in the future.

3. Single-Contributor Dominance

Several reviewed proposals showed situations where:

  • One developer had 80 per cent or more of all commits
  • Most others had extremely small contributions
  • Code review and discussion were not shared
  • Decision-making flowed from one person or one internal role

This raises concerns such as:

  • If the primary contributor leaves, the project collapses.
  • Other “committers” have not demonstrated readiness for shared governance.
  • ASF-style review culture does not exist yet.

A project does not need a perfect balance at proposal time, but it should show:

  • More than one person is capable of reviewing and committing
  • Evidence that work is shared
  • Some redundancy in knowledge and decision-making

Incubation can help grow a community, but it cannot replace core bus-factor problems.

4. Committer Lists That Do Not Match Public Contribution History

In some proposals, reviewers noticed:

  • Names listed as committers, but no visible contributions
  • Contributions are happening mainly in private or internal repositories
  • Claims of a large contributor group are not reflected in public history

ASF review is always based on public evidence:

  • Public commits
  • Public issues
  • Public lists
  • Public decision making

If the committer list and the observable public history do not line up, reviewers will question whether the proposal accurately reflects the real community.

5. Internal or Student Contributor Pools Without Long-Term Commitment

Some projects, especially those from academic or research settings, include:

  • Large pools of students or interns contributing in short cycles
  • Contributors who have since left the institution
  • High churn and little continuity
  • Unclear ownership of long-term maintenance

ASF projects require:

  • Committers who intend to stay involved beyond a course, internship, or grant cycle
  • Contributors who understand responsibilities beyond code, including release and community work
  • Governance that survives employment or academic turnover

If most contributors are temporary, the committer list needs to be stabilised around people who will be present for the long term.

6. Company-Controlled Committer Groups

Another pattern is a broad committer list where:

  • Most or all committers are employees of one company
  • External participation is low or absent
  • Decision-making is effectively corporate

Reviewers ask:

  • Can this project operate independently of the company if needed?
  • Are non-employees genuinely welcome and empowered?
  • Is the project’s future tied too closely to one organisation’s priorities?

ASF does not require perfect diversity, but it does require:

  • Genuine openness to outside participation
  • Merit-based committership
  • A path for independence over time

7. Missing or Weak Review Culture

A weak review culture appears when:

  • Commits go directly to main without review
  • Discussions are minimal or always one-way
  • One person reviews or approves all changes

A healthy proposal shows:

  • Multiple reviewers
  • Visible public discussion about substantial changes
  • Shared ownership of technical decisions

Review culture matters because it shows how the community will scale when more contributors arrive.

8. Committers Who Do Not Yet Understand ASF Responsibilities

Some proposals include committers who:

  • Have never worked in ASF-style open development
  • Do not understand list-based collaboration
  • Expect internal managers or product owners to direct the project
  • Treat ASF committership as a title rather than a responsibility

ASF committers are expected to:

  • Work on public lists
  • Participate in votes
  • Review and mentor contributors
  • Demonstrate independence from employers when acting in project roles

Before proposing, it helps to confirm that each future committer is willing and able to operate in this way.

9. The Difference Between Contributors and Committers

A frequent misunderstanding is:

  • “These 40 people contributed internally before, so we list them all as committers.”

ASF distinguishes:

Contributors - Anyone who submits code, docs, or ideas.

Committers - Contributors who have earned long-term trust and demonstrated sustained participation, and who are willing to take on ongoing responsibilities.

At proposal time:

  • It is acceptable to have more contributors than committers.
  • It is better to start with a smaller, accurate committer list than a large, inflated one.
  • Additional contributors can be added as committers later under normal ASF processes.

10. When the Proposed Community Does Not Match ASF Expectations

Reviewers often conclude a project is not ready when:

  • The project has a single key developer
  • The committer list is aspirational rather than evidence-based
  • Governance is controlled by one company
  • Public history does not match the claims made in the proposal
  • Review culture is absent or one-sided
  • Long-term commitment from named committers is unclear

In these cases, the most constructive outcome is usually:

  • “Grow the community further and return when it is closer to ASF norms.”

Waiting in this way avoids setting the project and the Incubator up for avoidable problems later.

11. Key Takeaways for Proposers, Mentors, and the IPMC

  • Committer lists should be based on public evidence of contribution and participation.
  • Single-contributor dominance is a major risk that incubation cannot fix on its own.
  • Visible review culture is an essential sign of project health.
  • Community legitimacy matters as much as the quality of the code base.
  • Corporate dominance needs to be balanced by openness and merit-based trust.
  • Committers should understand ASF norms and responsibilities before being proposed.
  • A strong, honest committer story is one of the best predictors of successful incubation.
  • No labels