Incubation Readiness

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:

• Project proposers
• Podling PPMCs and mentors
• IPMC members reviewing new proposals

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:

• “This is not ready yet”
• “Please fix these issues before we vote”
• “This is not a good fit for the Incubator in its current shape”

The patterns come from real proposals and are anonymised into general guidance.

This guide complements, but does not replace:

• 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:

• The software is still a research prototype or teaching framework rather than a stable, reusable codebase.
• The core code is more of an experiment or proof-of-concept than a maintained project.
• The proposal reads more like a roadmap or ambition than a description of an existing, working project.
• There is little evidence that anyone is using the project in production or relying on it outside the originating organisation.

In these cases, mentors and IPMC members often suggest:

• 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:

• “We will fix this during incubation” is being used as the main plan for community, governance, or accessibility gaps.
• A belief that incubation itself will create an international community, rather than shaping one that already exists in some form.

Observed corrections 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:

• The primary codebase, or key dependencies, are under a license incompatible with ASF distribution (for example, strong copyleft or non-approved licenses).
• The project expects to continue distributing parts of the system under a non-Apache, non-compatible license, but wants to brand the whole as an Apache project.
• The proposal treats license choice as a marketing or positioning question, rather than a non-negotiable policy constraint.

Typical Incubator responses in these cases:

• Clarify which components can be part of an Apache codebase and which cannot.
• Require that incompatible parts be separated, relicensed, or clearly excluded before a proposal proceeds.
• In some cases, conclude that the project is not a viable fit for the ASF in its current form.

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:

• Category X implications and distribution constraints are present in dependency choices.
• The likelihood that compliant ASF releases would require substantial changes to dependencies.
• A proposal that has not yet demonstrated a credible path to remove or replace problematic dependencies.

Observed corrections 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:

• All discussion channels and documentation are effectively inaccessible to non-local contributors.
• Very little evidence of intent or ability to build a global, time-zone-spanning community.

The Incubator does not require a project to be global on day one, but it does require:

• A real path to globally accessible communication
• A willingness to move key decisions to ASF-friendly, open channels
• An understanding that ASF projects serve a global public, not only one domestic market

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

Observed concerns and corrections from proposal discussions

Observed concerns included:

• Documentation not available in English.
• Development and community communications are not yet ready for global participation.
• Uncertainty about how contributors outside a region would participate.

Observed corrections 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:

• All commit access and practical control live in a single company or lab repository, often a mono-repo that includes internal products or tooling.
• The proposal does not clearly separate:
  • The project that is to be donated
  • From internal code that will remain private.
• The donating organisation cannot easily give the ASF a clean, independent repository for the project.

This raises questions such as:

• Will external contributors be second-class citizens compared to internal developers?
• Can the project evolve independently of the organisation’s mono-repo strategy?
• Is it even technically feasible to split the project cleanly?

If these questions cannot be answered clearly, the Incubator often asks the project to:

• 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:

• Proposal scope embedded in a larger repository, with donation boundaries unclear.
• Uncertainty about whether the proposed project could be built and run independently.
• Unrelated modules create risk or confusion about what was actually being proposed.
• The need for clear boundaries so outsiders can understand what is “the project” and what is not.

Observed corrections 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:

• Large internal teams have contributed privately, but very few have established external contributors.
• Governance that still looks like a lab, research group, or company structure.
• Planning and decision-making that happens outside public mailing lists or issue trackers.

ASF incubation expects:

• Development to move onto public mailing lists and public repositories
• Decisions to be made transparently
• The project to be able to attract and retain contributors beyond the originating institution

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:

• Little or no substantive discussion on issues.
• Few review comments on pull requests.
• Patterns suggest internal development blocks external contributions and harms community building.

Observed corrections 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:

• People listed as committers who have barely contributed or are no longer active.
• A large internal list of contributors, but only a few people are doing most of the work.
• A gap between the described community and what experienced reviewers see in the public repository.

This often leads to questions such as:

• “Who is actually doing the work right now?”
• “Are these people prepared to participate under ASF norms?”
• “Is this committer list designed to look good, or does it reflect reality?”

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:

• Decision-making is not clearly happening in the open.
• Unclear contribution and review norms.
• Limited evidence of operating within ASF-style expectations.
• Proposal content reads more like a code transfer than a plan for an open, sustainable community.

Observed corrections 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:

• Proposers may assume mentors are there to represent a company, “sponsor” acceptance, or “own” the project.
• Mentors might be recruited for their name recognition rather than for their time and willingness to engage.
• The proposal treats mentors as optional sign-offs rather than as active guides and checks.

Incubation works best when:

• Mentors are chosen for their ability and willingness to help the podling adopt ASF norms.
• Proposers understand that mentors are not a shield against community feedback.
• The project expects to work through tough questions rather than bypass them.

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:

• Mentor capacity and timing were part of the proposal discussion when significant readiness gaps remained.
• The scale of work implied by repo restructuring, licensing cleanup, and governance/internationality readiness.

Observed corrections 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:

• “This is promising, but not ready for incubation yet.”

In practice, that usually means the project should:

• Stabilise licensing and code boundaries.
• Move more development into public infrastructure.
• Attract some non-originating contributors.
• Update the proposal to reflect the more mature reality.

“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.

Corrections that resolved discussion pressure:

• 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.

Corrections that resolved discussion pressure:

• 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.

Corrections that resolved discussion pressure:

• 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.

Corrections that resolved discussion pressure:

• 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.

Corrections that resolved discussion pressure:

• Pause the proposal rather than forcing it through.
• Return with structural, licensing, governance, and accessibility gaps addressed.