the board resolution used to create the official project upon graduation,


compliant container.



description of the proposal. Should be reasonably declarative. More discursive material should be included in the rationale (or other later sections).


declarative framework for building,



adopted definition).

Example (Heraldry):

provide some background, the Higgins Project is being actively




Explains why this project needs to exist and why should it be adopted by Apache. This is the right place for discursive material.

Example (Beehive):

easy-to-use programming model

forced to write tedious plumbing code; and tools

Initial Goals


complex proposal (involving multiple existing code bases, for example) may cause concerns about its practicality. A good way to address these concerns is to create a plan that demonstrates the proposal is feasible and has been carefully thought through.

Example (Heraldry):



Current Status


topics) describes the candidate's current status and development practices. This should be an honest assessment balancing these against Apache's principles and development ideals.

proposals, this is a chance to demonstrate understanding of the issues that will need to addressed before graduation. For others, this is a chance to highlight the close match with Apache that already exists. Proposals without an initial code base should just simply state that.


natural that active committers are elected to the project management committee (PMC).

demonstrate that this process is understood by the proposers.

Example (OFBiz):

and users from around the

and then privileges over a larger

Example (Beehive):

lessons that the XMLBeans

work that needs to be done, and


in communities.


Example (Beehive):

build a new community at Apache.

Example (WebWork2):

Example (WADI):

clustering and caching component in the

Apache is composed of individuals.

It is useful to provide a brief introduction to the developers on the initial committers list. This is best done here (and not in that section). This section may be used to discuss the diversity of the core development team.

Example (ServiceMix)

already very experienced open source developers. There is at


Example (WADI)

ActiveMQ, and ServiceMix.

Describe why Apache is a good match for the proposal. An opportunity to highlight links with Apache projects and development philosophy.

Example (Beehive):

services component, based on JSR-181, will

we will need to work with, such as the Portals

Known Risks

An exercise in self-knowledge. Risks don't mean that a project is unacceptable. If they are recognized and noted then they can be addressed during incubation.

A public commitment to future development.

Recruiting a diverse development community and strong user base takes time. Apache needs to be confident that the proposers are committed.

Example (Yoko):

the usual warning signs of orphaned or abandoned code.

Example (Ivy): Due to its small number of committers, there is a risk of being orphaned. The main knowledge of the codebase is still mainly owned by Xavier Hanin. Even if Xavier has no plan to leave Ivy development, this is a problem we are aware of and know that need to be worked on so that the project become less dependent on an individual.

Example (Tika): There are a number of projects at various stages of maturity that implement a subset of the proposed features in Tika. For many potential users the existing tools are already enough, which reduces the demand for a more generic toolkit. This can also be seen in the slow progress of this proposal over the past year.

However, once the project gets started we can quickly reach the feature level of existing tools based on seed code from sources mentioned below. After that we believe to be able to quickly grow the developer and user communities based on the benefits of a generic toolkit over custom alternatives.

If the proposal is based on an existing open source project with a history of open development, then highlight this here.

If the list of initial committers contains developers with strong open source backgrounds then highlight this here.

Inexperience with open source is one reason why closed projects choose to apply for incubation. Apache has developed over the years a store of experience in this area. Successfully opening up a closed project means an investment of energy by all involved. It requires a willingness to learn and to give back to the community. If the proposal is based around a closed project and comes with very little understand of the open source space, then acknowledge this and demonstrate a willingness to learn.

Example (Cayenne):


Example (Beehive):

Example (Ivy):

since then - the svn repository is

open source development model is currently limited.

Example (River):

there is limited experience developing code with an

Healthy projects need a mix of developers. Open development requires a commitment to encouraging a diverse mixture. This includes the art of working as part of a geographically scattered group in a distributed environment.

Starting with a homogenous community does not prevent a project from entering incubation. But for those projects, a commitment to creating a diverse mix of developers is useful. Those projects who already have a mix should take this chance to highlight that they do.

Example (Beehive):


distributed environment.

Example (River)

project are from

developers and add them as committers as we progress. There are

work, Dan has been involved with

Jini-based development, including commercial work at Virgil

Example (Ivy):

two core developers, at least they are not homogenous! Xavier and

A project dominated by salaried developers who are interested in the code only whilst they are employed to do so risks its long term health.

Apache is about people, not corporations. We hope that developers continue to be involved with Apache no matter who their current employer happens to be.

This is a right place to indicate the initial balance between salaried developers and volunteers. It's also good to talk about the level of commitment of the developers.

Example (OpenJPA):

from the Java community for

the project.

Example (River):

(currently from Sun, but it's expected that other company's salaried developers

meantime, Sun will support the project in the

Example (Wicket):

consulting work, though two -

multiple projects, and will do so for a considerable while as

Relationships with Other Apache Products:

Apache projects should be open to collaboration with other open source projects both within Apache and without. Candidates should be willing to reach outside their own little bubbles.

This is a an opportunity to talk about existing links. It is also the right place to talk about potential future links and plans.

Apache allows different projects to have competing or overlapping goals. However, this should mean friendly competition between codebases and cordial cooperation between communities.

It is not always obvious whether a candidate is a direct competitor to an existing project, an indirect competitor (same problem space, different ecological niche) or are just peers with some overlap. In the case of indirect competition, it is important that the abstract describes accurately the niche. Direct competitors should expect to be asked to summarize architectural differences and similarities to existing projects.

Example (OpenJPA):

commons logging.

Example (River)

etc)that will be explored.

Concerns have been raised in the past that some projects appear to have been proposed just to generate positive publicity for the proposers. This is the right place to convince everyone that is not the case.

This is also the right place to build bridges with the community after past misdemeanors (for example, if any of those associated with the proposal have - in the past - sort to associate themselves with the Apache brand in factually incorrect ways) and promise good conduct for the future.

Example (CeltiXfire):

Rationale section. However, we will be sensitive to


Example (Wicket):

continue on that path with no problems at all.

enthusiastic users of Apache from the earliest hour

Example (OpenJPA):

something that will benefit from wide

such as the Geronimo project.


References to further reading material.

Examples (Heraldry):



Initial Source

Describes the origin of the proposed code base. If the initial code arrives from more than one source, this is the right place to outline the different histories.

If there is no initial source, note that here.

Example (Heraldry):


traction in the Open

languages and there is a large overlap between the two

Source and Intellectual Property Submission Plan

Complex proposals (typically involving multiple code bases) may find it useful to draw up an initial plan for the submission of the code here. Demonstrate that the proposal is practical.

Example (Heraldry):

specification and content on openid.net from Brad

Six Apart, Ltd. and Johannes Ernst of NetMesh, Inc.

VeriSign, Inc.

External Dependencies:

dependencies for the initial source is important. Only some external dependencies are allowed by Apache policy. These restrictions are (to some extent) initially relaxed for projects under incubation.

dependencies all have Apache compatible licenses. These include


If the proposal involves cryptographic code either directly or indirectly, Apache needs to know so that the relevant paperwork can be obtained.

Required Resources:

private@{podling}.incubator.apache.org (for confidential PPMC discussions) and dev@{podling}.incubator.apache.org lists. Note that projects historically misnamed the private list pmc. To avoid confusion over appropriate usage it was resolved that all such lists be renamed.

focus needs to be on recruiting new developers. Early adopters are potential developers. As momentum is gained, the community may decide to create commit and user lists as they become necessary.

Existing open source projects moving to Apache will probably want to adopt the same mailing list set up here as they have already. However, there is no necessity that all mailing lists be created during bootstrapping. New mailing lists can be added by a VOTE on the Podling list.

recommended that this naming convention is adopted.

moderated subscriptions)

dash-separated (-) directory names. The directory should be within the incubator directory space (http://svn.apache.org/repos/asf/incubator).


prefixed with incubator and later renamed assuming the project is promoted to a TLP.


issue tracking system.

proposal. Note that the infrastructure team usually requires a compelling argument before new services are allowed on core hardware. Most proposals should not require this section.

resources not covered above (such as continuous integration) should be added after bootstrapping. The infrastructure documentation explains the process.

Initial Committers

List of committers (stating name and an email address) used to bootstrap the community. Mark each which has submitted a contributor license agreement (CLA). Existing committers should use their apache.org email address (since they require only appropriate karma). Others should use the email address that is (or will be) on the CLA. That makes it easy to match CLAs with proposed committers to the project.

It is a good idea to submit CLAs at the same time as the proposal. Nothing is lost by having a CLA on file at Apache but processing may take some time.

Note this and this. Consider creating a separate section where interested developers can express an interest (and possibly leave a brief introduction) or ask them to post to the general list.

Example (OpenJPA):

(awhite at bea dot com)

apache dot org) *


Little bit of a controversial subject. Committers at Apache are individuals and work here on their own behalf. They are judged on their merits not their affiliations. However, in the spirit of full disclosure, it is useful for any current affiliations which may effect the perceived independence of the initial committers to be listed openly at the start.

For example, those in salaried positions whose job is to work on the project should list their affiliation. Having this list helps to judge how much diversity exists in the initial list and so how much work there is to do.

This is best done in a separate section away from the committers list.

Only the affiliations of committers on the initial bootstrap list are relevant. These committers have not been added by the usual meritocratic process. It is strongly recommended that the once a project is bootstrapped, developers are judged by their contributions and not by their background. This list should not be maintained after the bootstrap has been completed.

process. It is common - but not necessary - for the Champion to also be proposed as a Mentor.

formulate the proposal and work with you to resolve comments and questions put forth by the IPMC while reviewing the proposal.

Lists eligible (and willing) individuals nominated as Mentors [definition] for the candidate.

Three Mentors gives a quorum and allows a Podling more autonomy from the Incubator PMC, so the current consensus is that three Mentors is a good number. Any experienced Apache community member can provide informal mentorship anyway, what's important is to make sure the podling has enough regularly available mentors to progress smoothly. There is no restriction on the number of mentors, formal or informal, a Podling may have.

Apache taking responsibility for this proposal. The sponsoring entity can be:

whether to sponsor (by a vote). Unless there are strong links to an existing Apache project, it is recommended that the proposal asks that the Incubator for sponsorship.

destination within the Apache organizational structure will be decided upon graduation.

MessagingComponentsProposal (last edited 2017-06-26 10:10:40 by johndament)