Page History

This guide was generated from real discussion threads on the Apache Incubator mailing list, including proposals where podlings were judged too early, structurally unready, or not yet aligned with ASF norms.

Who This Guide Is For

This guide is intended for:

...

It is designed to help people recognise when a project is not yet ready for incubation and what to correct before trying again.

How To Use This Guide

• Proposers can use it as a pre-flight checklist to see if a proposal is realistically ready.
• Mentors and IPMC members can use it as shared language when explaining why something feels “too early”.

Unifying Principle

The Incubator exists to help communities grow into independent Apache projects, not to fix every structural, legal, or governance problem for them. Some projects need more work before they are ready to enter.

...

Purpose

This guide explains common patterns that led the Incubator community to say:

...

• The ASF Incubator Policy
• The ASF Trademark and Licensing policies

...

1. Signs a Proposal Is Structurally Too Early

Some projects are not yet in a shape where incubation will help them. Common red flags include:

...

• Stabilising the codebase first
• Proving the project in real use cases
• Building an initial community outside the Incubator
• Then returning with a proposal grounded in an existing open project, not just an idea

Observed concerns and corrections from proposal discussions

Observed concerns included:

...

• Run the project as an open source community for a period before entering incubation.
• Demonstrate that the project can attract and retain participation beyond the originating organisation.
• Re-propose once there is visible evidence of open development and community formation.

...

2. License and Policy Misalignment at Proposal Time

Some proposals arrive with serious license or policy misalignments, for example:

...

If a proposal cannot realistically move to ASF-compatible licensing for its core, it is usually better for everyone if it does not enter incubation.

Observed concerns and corrections from proposal discussions (Category X style issues)

Observed concerns included:

...

• Treat removal or replacement of problematic licensing dependencies as real engineering work requiring code changes.
• Provide a clear plan and path to remove or replace the problematic dependencies.
• Return with an updated proposal and/or evidence of progress toward removing the issue.

...

3. Region-Locked Communities and Non-Global Readiness

Some proposals are deeply tied to a single region, language, or domestic ecosystem. Warning signs include:

...

When a proposal cannot credibly commit to that, it is often deemed not ready.

Observed concerns and corrections from proposal discussions

Observed concerns included:

...

• Introduce and maintain an English version of documentation.
• Make English the primary development language.
• Explain how global participation will be supported in practice (communication, contribution, and decision-making).

...

4. Mono-Repo, Mono-Owner, and Single-Organisation Control

Another common readiness failure is structural control by a single organisation:

...

• First, separate the project cleanly in its own repository
• Clarify what is actually being donated
• Demonstrate that external contributors can reasonably participate
• Then return with a proposal describing that independent, ASF-suitable codebase

Observed concerns and corrections from proposal discussions (scope and boundaries)

Observed concerns included:

...

• Split the repository and give the proposed project its own separate repository.
• Ensure the proposed project can be built and run independently.
• Make the donated scope explicit and keep unrelated modules out of it.
• Ensure the resulting structure clearly communicates what is in scope and who controls it.

...

5. Private Development vs Public Collaboration

Many proposals show a long history of private development followed by a sudden decision to donate. Warning patterns include:

...

When a project is still in the mindset of “we control everything” then incubation may be premature. The project should first practise working in public.

Observed concerns and corrections from proposal discussions (public collaboration signals)

Observed concerns included:

...

• Switch active development to the public repository and do the work in the open.
• Demonstrate active review and discussion on issues and PRs.
• Show that contributors outside the originating organisation can participate.

...

6. Governance and Committer Legitimacy Questions at Proposal Time

Some proposals raise questions about whether the listed committers and PPMC members really reflect the active community:

...

When these questions cannot be answered clearly, reviewers may conclude that the project is not yet ready, because the community story is not honest or stable enough.

Observed concerns and corrections from proposal discussions (Apache Way readiness)

Observed concerns included:

...

• Demonstrate public development practices before re-proposing.
• Establish contribution and decision-making processes aligned with ASF norms.
• Show how the community will make decisions and accept contributions in the open.

...

7. Mentor Role Misunderstandings

A frequent readiness failure is misunderstanding what mentors are for:

...

If the mentor story feels decorative or misaligned, that is often a sign the project has not internalised how the Incubator actually works.

Observed concerns and corrections from proposal discussions (mentor capacity and timing)

Observed concerns included:

...

• Pause the proposal rather than forcing it through.
• Return with key gaps addressed before restarting the discussion.
• Reduce reliance on mentors to “carry” readiness work that the project can reasonably do before incubation.

...

8. When the Right Answer Is “Not Yet”

Sometimes the Incubator’s most responsible action is to say:

...

“Not yet” is not a rejection of the idea or of the people. It is a recognition that timing matters for both the project and the Incubator.

...

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

• Incubation is not a way to fix incompatible licensing or structural dependency on private code.
• A project that is still essentially a lab, course framework, or internal product is often not ready.
• Region-locked communities must show a path to globally accessible communication.
• Mono-repos and single-organisation control need to be untangled before donation.
• Commmitter and PPMC lists must reflect the reality of who is doing the work.
• Mentors are governance guides, not corporate representatives or rubber stamps.
• “Not yet” is sometimes the healthiest possible outcome for everyone.

...

Quick Readiness Checklist

For proposers:

• Can you describe a stable, reusable project, not just a plan or prototype?
• Is the core codebase under ASF-compatible licensing, with clear boundaries?
• Could someone outside your organisation reasonably participate today, using public lists and repos?
• Does your committer list match the people actually doing the work?
• Do your mentors understand their role, and are they prepared to engage?

If these answers are mostly “no”, it may be better to fix those gaps first before entering incubation.

...

Appendix: Observed Correction Patterns From Proposal Discussions

This appendix summarises repeatable correction patterns that emerged in proposal discussions. It intentionally separates what was seen as a readiness concern from what changes proposed restartable.

A. Clarify Scope and Separate What Is Being Donated

Observed pattern:

• Proposal scope is hard to verify when mixed into a larger repository or when boundaries are unclear.

...

• Split the repository and give the proposed project its own separate repository.
• Ensure the proposed project can be built and run independently.
• Make the donated scope explicit and keep unrelated modules out of it.
• Make it easy for reviewers to understand the scope of the donation without inference.

B. Treat Dependency Licensing as Engineering Work, Not a Footnote

Observed pattern:

• Category X or upstream licensing constraints create real release risk.

...

• Treat Category X removal as real engineering work requiring code changes.
• Provide a credible plan to remove or replace problematic dependencies.
• Return with updated materials and/or evidence of concrete progress.

C. Make Global Participation Feasible in Practice

Observed pattern:

• Internationality concerns come up when project participation is not realistically accessible to a global audience.

...

• Introduce and maintain an English version of documentation.
• Make English the primary development language.
• Describe how global participation will work in day-to-day practice.

D. Demonstrate Open Governance Before Re-proposing

Observed pattern:

• Governance readiness is questioned when decision-making and contributions are not clearly open.

...

• Demonstrate public development practices before re-proposing.
• Establish contribution and decision-making processes aligned with ASF norms.
• Show real examples of open decision-making and review.

E. Use “Pause and Return” When the Gaps Are Large

Observed pattern:

• Timing and mentor capacity are explicitly discussed when the project is early-stage in open-source readiness.

...