Apache Incubator




Incubation Policy

In October 2002 the Board of Directors of the Apache Software Foundation passed a resolution creating the Apache Incubator PMC (referred to as the "Incubator PMC" in this document) charged with "accepting new products into the Foundation, providing guidance and support to help each new product engender their own collaborative community, educating new developers in the philosophy and guidelines for collaborative development as defined by the members of the Foundation, and proposing to the board the promotion of such products to independent PMC status once their community has reached maturity" (reference Board Resolution).

The Incubator was tasked with the following responsibilities (reference Board Resolution):

  • the acceptance and oversight of new products submitted or proposed to become part of the Foundation;
  • providing guidance and ensuring that subprojects under its purview develop products according to the Foundation's philosophy and guidelines for collaborative development; and
  • regularly evaluating products under its purview and making the determination in each case of whether the product should be abandoned, continue to receive guidance and support, or proposed to the board for promotion to full project status as part of an existing or new Foundation PMC; and be it further.
About this Document

This document is the normative reference for the policies and procedures put in place by the Incubator PMC for the Incubation process, which is used by the Incubator PMC to discharge their duties as described above.

It contains the minimum requirements that all new products and projects must meet before they will be fully accepted into the Apache Software Foundation.

The document makes use of the terms MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL. Where capitalised, these terms are to be used as per the definitions found in RFC 2119.


This document contains the minimum requirements and processes that must be met by products and projects wishing to become part of the Apache Software Foundation.

This document does not apply outside the process of Incubation. Policies and processes that need to be met by products under incubation are not mandated (by this document) for other projects and sub-projects within the ASF.

Relationship to Other Documents

This document is the normative set of requirements for Incubation. Where other documents are in conflict, this document should be taken as correct.

Changing this Document

The contents of this document are formally approved by the Incubator PMC. All changes must be authorised by the Incubator PMC.

Objectives of the Process

To provide a clear path for potential projects and sub-projects within the ASF to move from proposal stage through to fully membership in such as way as to ensure :

  • new projects and sub-projects are developing products according to the ASF's philophy and guidelines for collaborative development;
  • the ownership of any code initially submitted by the project is formally and legaly transferred to the ASF; and
  • only those products that meet the Apache's requirements are fully accepted into the ASF.

Overview of the Process

The incubation process covers the establishment of a candidate, acceptance (or rejection) of a candidate leading to the potential establishment of a Podling and associated incubation process, which ultimately leads to the establishment or a new Apache Top-Level-Project (TLP) or sub-project within an existing Apache Project.


Entry to Incubation

Entry to Incubation requires a number of hurdles be passed.


In order to enter the Incubator, a Candidate MUST

  • be nominated for incubation by a member of the Apache Software Foundation ("The Champion"); and
  • be approved by a Sponsor.

Approval by a Sponsor will generally occur only after a vote within the Entity, and will require that the Entity be convinced that the Candidate is appropriate for Incubation. A Sponsor may be one of:

  • the Board of the Apache Software Foundation;
  • a Top Level Project (TLP) within the Apache Software Foundation (where the TLP considers the Candidate to be a suitable sub-project); or
  • the Incubator PMC.

To start this process, a Candidate SHOULD submit a proposal to a Sponsor. The Proposal SHOULD, at minimum, detail the following areas :

Need to provide a short list

Acceptance of Proposal by Sponsor

The decision to accept a project MUST be taken on a vote by the Sponsor, in accordance with that Entity's charter.

Upon a successful result, the Sponsor SHOULD request the Incubator PMC take on the Candidate as a new Podling. The request to the Incubator PMC MUST contain the following information :

  • a reference to the results of the vote (so as to provide an audit trail for the records);
  • a reference to the Candidate's proposal;
  • the Mentors, nominated by the Sponsor, who will guide the Candidate through the Incubation Process. At least one nominated Mentor MUST be a member of the Apache Software Foundation.

The Incubator PMC MAY immediately accept the Candidate, or may (at the discretion of the Incubator PMC) require a successful VOTE by the Incubator PMC.

The nominated Mentors MAY be immediately accepted by the Incubator PMC. However the Incubator PMC MAY also suggest replacement Mentors. The Incubator PMC has the final choice of Mentors.

Creation of Podling

Upon acceptance by the Incubator PMC, the Candidate becomes a Podling under the care of the Incubator PMC.

Upon acceptance by the Incubator PMC, the Podling's Mentor becomes a member of the Incubator PMC (should they not already be one).

Incubation Activities

The following sections detail the minimum activities that must be undertaken by the various parties during an Incuabation process.

Setting Up a New Podling

Once the Podling and Mentor have been accepted by the Incubator PMC, the following activities SHOULD take place :

  • creation of lists;
  • creation of cvs;
  • Incubator PMC mandating a helper Mentor
Ongoing Activities

The progress of a Podling SHALL be tracked in a "project status" file which SHALL be stored in the incubator/site-author/projects/ repository and so become available at http://incubator.apache.org/projects/

The "project status" document SHALL include the following minimum content :

  • status of setup tasks;
  • all exit criteria (see section Exiting the Incubator below);
  • status of Podling against exit criteria.

The Mentor MUST ensure that the "project status" document is up to date at all times. See instructions.

Review of Activity

Each Podling in Incubation SHALL undergo a regular review of progress by the Incubator PMC. Such reviews SHALL occur at least quaterly. The Incubator PMC MAY, at their discretion, choose to review individual Podlings with greater frequency. The Incubator PMC SHALL inform Podlings of review dates at least 4 weeks in advance.

At least one week prior to each review, the Mentor MUST produce a report for the Incubator PMC detailing overall progress with a focus on the preceding review period. It is RECOMMENDED that the report be based on the "project status" document for the Podling.

After each review, the Incubator PMC SHALL produce an Assessment of the project. The Assessment SHALL contain one of three recommendations :

  • that the Podling be Terminated;
  • that the Podling continue in Incubation; or
  • that the Podling be escalated out of the Incubator.

Termination and Escalation are discussed in more detail in section "Exitting the Incubator".

Disputing an Assessment

If the Podling or Mentor disagree with an assessment, they MAY request the Incubator PMC review the report. Such a request MUST include a details of what the Podling and/or Mentor is disputing, and their reasons for doing so.

Upon receipt of an Assessment Dispute, the Incubator PMC SHALL review the request and provide feedback to the Podling and Mentor. Such feedback MAY include a change to the original Assessment.

Should the Podling and/or Mentor still disagree with the contents of the report, they may appeal to the Board of the Apache Software Foundation. Such an appeal MUST include

  • the original assessment;
  • the request for review to the Incubator PMC;
  • the response from the Incubator PMC; and
  • the reason the Podling and/or Mentor still dispute the report.

The Board of the Apache Software Foundation MAY, after reviewing the appeal, choose to

  • ammend the incubation Assessment;
  • validate the assessment of the Incubator PMC; or
  • take any other action it deems appropriate to the circumstance.

The decision of the Board of the Apache Software Foundation is final.


A recommendation by the Incubator PMC for continuation of incubation SHALL include development recommendations. The Incubator PMC SHALL ensure that the recommended actions are tangible and quantifiable.

The Mentor SHALL review the contents of the continuation recommendation and ensure that the development recommendations are carried out over the following review period.

Podling Constraints

While in Incubation, Podlings are constrained in the actions they can undertake.


Podlings are, by definition, not yet fully accepted as part of the Apache Software Foundation. Podling web sites MUST include a clear disclaimer on their website and in all documentation stating that they are in incubation.

Podlings SHOULD use the following text for all disclaimers :

<project name> is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the <name of sponsor>. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.

Podlings wishing to use a different disclaimer message MUST have the disclaimer approved by the Incubator PMC prior to use.

Podlings websites SHOULD contain the Apache Incubator Project logo as sign of affiliation.


As podlings are not yet fully accepted as part of the Apache Software Foundation, any software releases (including code held in publically available SVN) made by Podlings will not be endorsed by the ASF.

However, as software releases are an important part of any software project, they are permitted in certain circumstances, as follows.

Podlings in Incubation SHALL NOT perform any releases of software without the explicit approval of the Incubator PMC. Such approval SHALL be given only after the Incubator PMC has followed the process detailed in (Reference to Charter), and SHALL NOT occur until all source has been legally transferred to the ASF.

Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL formally request the Incubator PMC approve such a release. The request SHALL have the endorsement of the Mentor.

Should the Incubator PMC, in accordance with (Reference to Charter) vote to approve the request, the Podling MAY perform the release under the following constraints :

  • the release archive MUST contain the word "incubating" in the filename; and
  • the release archive MUST contain an Incubation disclaimer (as described in the previous section), clearly visible in the main documentation or README file.
Use of Apache Resources

The Podling is not yet an Apache project, and it should thus always refer to the Incubator Project Resource usage Guidelines, that are as follows.

  • every project site sources stay in the project SVN
  • every project has this URL space where to publish the site:
  • every project has an incubation status file under
  • every project has eventual extra incubation docs under:
  • The website is live in directory on www.apache.org:

To create the website, the directory /www/incubator.apache.org/projectname is checked out of SVN. We don't care how it gets into SVN, or which SVN module it lives in, but it had better be there. See instructions for project website.

People using Maven, ForrestBot, or any other tool still have to address the SVN publishing requirement that the infrastructure team has laid out. If that is done, then we just run "svn update" in that directory to load the site from SVN.

The Mentors MUST add the information to the project incubation status file, to describe the SVN module and the directory which holds the published site.

>Exiting the Incubator

This section describes the requirements and process for exitting the Incubator.

Minimum Exit Requirements

Prior to escalation to the ASF, a Podling needs to show that :

  • it is a worthy and healthy project;
  • it truly fits within the ASF framework;and
  • it "gets" the Apache Way.

This is achieved by imposing a set of Exit Criteria that, when met, will demonstrate these objectives.

Therefore, to successfully exit the Incubator and be escalated fully into the ASF, a Podling SHALL meet the minimum exit requirements detailed below. The Incubator PMC MAY set additional requirements at their discretion. Such additional requirements MAY be proposed by the Mentor or the Sponsor, however only the Incubator PMC is authorised to formally place such requirements on a Podling.

The minimum requirements that a Podling SHALL meet prior to being successfully escalated to the ASF are :

  • Legal
    • All code ASL'ed
    • No non ASL or ASL compatbile dependencies in the code base
    • License grant complate
    • CLAs on file.
    • Check of project name for trademark issues
  • Meritocracy / Community
    • Demonstrate an active and diverse development community
    • The project is not highly dependent on any single contributor (there's at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)
    • The above implies that new committers are admitted according to ASF practices
    • ASF style voting has been adopted and is standard practice
    • Demonstrate ability to tolerate and resolve conflict within the community.
    • Release plans are developed and excuted in public by the community.
      • (requriment on minimum number of such releases?)
      • Note: incubator projects are not permitted to issue an official Release. Test snapshots (however good the quality) and Release plans are OK.
    • Engagement by the incubated community with the other ASF communities, particularly infrastructure@ (this reflects my personal bias that projects should pay an nfrastructure "tax").
    • Incubator PMC has voted for graduation
    • Destination PMC, or ASF Board for a TLP, has voted for final acceptance
  • Alignment / Synergy
    • Use of other ASF subprojects
    • Develop synergistic relationship with other ASF subprojects
  • Infrastructure
    • SVN module has been created
    • Mailing list(s) have been created
    • Mailing lists are being archived
    • Issue tracker has been created
    • Project website has been created
    • Project ready to comply with ASF mirroring guidlines
    • Project is integrated with GUMP if appropriate
    • Releases are PGP signed by a member of the community
    • Developers tied into ASF PGP web of trust

Termination of a Podling

If you receive a recommendation for termination then you have a problem. Chances are that there are either legal or structural problems with your project that in the opinion of the Incubator PMC are not resolvable within a reasonable time frame. A termination decision is basically time to close down the project. However, you do have the right to appeal a termination decision with the Board of Directors and/or your Sponsor. You should be aware that several Members of the Board are also Members of the Incubator PMC and as such, an appeal is unlikely to be successful.

Migration as a Top Level Project

In cases where a Podling has successfully completed Incubation, and is exitting the Incubator to become a Top Level Project, the Incubator PMC SHALL provide a recommendation to the board that the Podling is ready to escalate. The recommendation SHALL include a draft resolution for the board to vote on.

Migration as a sub-project

In cases where a Podling has successfully completed Incubation, and is exitting the Incubator to become a sub-project within an already existing Top Level Project, the Incubator PMC SHALL provide a recommendation to the TLP that the Podling is ready to escalate.

Post-Graduation Check List

The list below summarizes steps a project needs to perform after graduation to move out of the Incubator. PPMC refers to the old PPMC for the graduating project, PMC refers to the new PMC under which the graduating project falls (this might be the former PPMC for a new TLP), and Project refers to the committers on the graduating project.

  • Move svn repository from incubator to new location
    • PMC sends email to infrastructure@ and opens a JIRA issue requesting that infrastructure move the svn repository.
    • PMC updates the svn-authorization files to provide committers access to the newly-named repositories.
    • Project verifies all committers have commit access.
    • Project removes incubator disclaimer notices.
  • Move web site
    • PMC emails root@ and opens a JIRA issue requesting UNIX karma for committers to access new location on people.apache.org.
    • Project verifies all committers know how to and have karma to update the new web site.
    • Project checks out/deploys the files in the new location.
    • PPMC redirects old incubator URL to the new one by editing https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/.htaccess .
    • Project verifies the redirect works, then deletes old stuff at /www/incubator.apache.org/${PROJECT} .
    • PPMC updates http://incubator.apache.org/projects/projectname.html with graduation status and link to new website location.
  • Cleanup incubator
    • PPMC updates http://incubator.apache.org/projects/index.html project from "Currently Incubating" to "Successfully Incubated" table.
  • Update JIRA/Bugzilla
    • PMC emails infrastructure@ requesting that information for the project be updated.
  • Move mail lists:
    • PMC sends email to infrastructure@ and opens a JIRA issue requesting that the mailing lists and archives be moved.
  • If the graduating project wants to send out a press release, it must be cleared with the PRC.

Additional steps for a TLP include:

  • A new TLP needs board approval. The PPMC creates a proposal including a proposed PMC chair and sends that to the board.
  • The ASF Chairman sends out an official notice that the board has approved a new TLP.
  • PMC may then notify infrastructure@ about the new TLP so they can add DNS entries (and anything else).
  • The mentor or other member updates www.apache.org to add a link to the new TLP web site.
  • The mentor or other member adds the new PMC to the board reporting schedule (update the committee.txt file).
  • The new TLP must send monthly board reports for three months after approval.

Resources include:

Roles in the Incubation Process

This section describes the roles involved in the Incubation process.

Incubator Project Management Committee (PMC)

(From the resolution that created the Incubator Project - see http://incubator.apache.org/resolution.html)

The Incubator PMC is responsible for :

  • acceptance and oversight of candidate projects submitted or proposed to become part of the Foundation;
  • providing guidance and ensuring that sub-projects under it's purview develop products according to the Foundation's philosophy and guidelines for collaborative development;
  • providing a repository for the storage of incubation history and information;
  • assisting a Podling's Mentor in discharging her/his duties;
  • regularly evaluating projects under its purview for the purposes of recommending to the Sponsor whether the project should:
    • successfully exit incubation;
    • continue to receive guidance and support within the Incubator; or
    • be terminated.
Chair of the Incubator PMC

The person appointed by the Board of Directors to have primary responsibility for oversight of the Incubator Project, its policies, and policy implementation.


A project that is proposed for incubation.


A Member of the Apache Software Foundation who supports a Candidate's application for Incubation and who supports and assists the Podling through the Incubation process.


The Sponsor is the entity within the ASF that makes the determination that a candidate would make a worthy addition to the ASF, and agrees to take on the candidate in question (or in the case of the Incubator PMC, assist it in finding a home) should it complete the incubation process.

A Sponsor will be one of:

  • The Board of the Apache Software Foundation. In this case, it is expected that the candidate would become a TLP on successful completion of Incubation.
  • A Top Level Project within the ASF. In this case, the project in question has agreed that the candidate is a good fit for their project, and will take on the candidate as a sub-project upon successful completion of Incubation.
  • The Incubator PMC. In this case, the Incubator PMC agrees that the project in question will make a good addition to the ASF, but there is no clear "owner" of the candidate should it successfully complete incubation. An incubation exit requirement for such candidates will be the identification (and successfuly lobbying) of an "owner" entity - either the board (and the candidate will be a TLP) or another project.

A Mentor is a role undertaken by a permanent member of the Apache Software Foundation and is chosen by the Sponsor to actively lead in the discharge of their duties (listed above). Upon acceptance by the Incubator PMC, the Mentor automatically becomes a member of the Incubator PMC. A Mentor has specific responsibilities towards the Incubator PMC, the Sponsor and towards the members of the assigned Podling.


The candidate shall declare an initial set of committers. On acceptance of a candidate project, the assigned Mentor shall be given access to the Podling's cvs repository for the duration of the incubation process. This is to allow the Mentor to perform their incubation duties, and is for administrative purposes only. To be given full committer privileges, such as the right to add new code to the repository, the Mentor must earn them as would any other potential new committer. In some cases, the Mentor may be part of the initial set of declared committers, but this is not a requirement of the Incubation process.

Copyright © 2003-2005, The Apache Software Foundation