Establishing an Apache Project

Currently, Apache consist of 68 individual projects and countless numbers of subprojects, all listed in detail and freely downloadable at www.apache.org, the Apache website. To ensure that the same consistent quality of the original HTTP project is maintained in all new projects, Apache created a formal vetting process with three motivational points to validate all candidate projects (Apache, n.d.):

1. Developing according to the ASF’s philosophy and guidelines for collaborative development.

2. Ensure the legality of the code is for open distribution and transfer to the ASF under the Apache Software License (ASL).

3. Only products that meet the Apache's requirements are fully accepted into the ASF.

a. Vetting Process (Incubation) Overview

The process of bringing a candidate project into the ASF collection of projects begins in the Apache Incubation process (Apache, n.d.). This process starts with the candidate soliciting for a ASF sponsor and a proposal from the candidate to Apache describing the candidate project. If the ASF board accepts the candidate’s proposal, the candidate enters a “podling” phase of development where it is refined and groomed into Apache pedigree. From the podling phase, a candidate may graduate into an Apache Top-Level-Project (TLP) or sub-project within an existing Apache Project. Figure 28 pictorially shows the path of progressing form candidate to ASF project member.

Figure 28. Apache Notional Project Adoption Vetting Flow (From Apache, n.d.)

The ASF bases all of it decisions democratically using a Project

management Committee (PMC) majority vote with each TLP having its own PMC. This democratic process carries though for major decisions such as accepting new projects, to minor decisions such as deciding if a new software versions should be released. The Incubator PMC is charged with the vetting of candidate projects through the ASF guidelines, vision, philosophy, and ultimately (if warranted) graduation into a TLP or subprojects.

Apache provides a mentoring process to assist candidates throughout the incubation process. During each phase of the Incubation process, a candidate has one or more mentors assigned that assist the candidate in the completion of phased tasks as well the ASF transitions. Once accepted into the ASF, a former candidate becomes an eligible

b. Becoming a Candidate Project (Pre-Podling)

The process from Candidate to Podling takes six steps, from finding a sponsor to acceptance into the Podling phase.

(1) Find A Sponsor. A candidate project must network with the existing TLP PMCs, the board of ASF, or the Incubator PMC in hopes that one of them will sponsor the candidate. The primary means of soliciting a sponsor is through mail-lists found on the Apache homepage. A sponsor is any PMC of the ASF, and has the duties of providing the initial review of the candidate before being presented to the Incubation PMC. This initial sponsor will become the candidate’s mentor or will provide mentors once the candidate is voted into the incubation process.

(2) Build A Proposal. Once a candidate has a sponsor, it must then build its proposal to Apache. The proposal defines the project in terms of assumed benefits, known risks (dependencies, open source experience), Licensing, Cryptography, required resources (Subversion, mailing list), and a number of other aspects that define why the candidate is good, and how it is compliant with the Apache way of life and philosophy. There is no formal structure for the proposal, but the general guidelines and an example are available on the incubator proposal webpage (Apache, n.d.).

(3) Sponsor Vetting Proposal. The sponsor reviews and votes on the candidate’s proposal. The sponsor applies its Apache experience to evaluate the candidate’s preparedness for the incubation process and ultimately whether it is a good addition to the ASF.

(4) Sponsor Forwards Candidate Proposal to the Incubation PMC.

If the sponsor approves the candidate’s proposal by majority vote, the sponsor then forwards on behalf of the candidate to the Incubator PMC:

 Results of the sponsors Votes

 Candidates proposal

 Nominated mentors

(5) Incubation PMC Vetting. Once the Incubator PMC has the candidate’s package of information, a 72-hour waiting period starts, after which, without a “hold” statement, automatically approves the candidate for the incubation process and entry into the Podling phase.

Any member of the incubator PMC can place a hold on the candidate. If a hold is placed within the 72-hours, a formal discussion and vote is conducted to make the final decision whether or not to accept the candidate.

(6) Podling Phase Approval. After being reviewed, and approved by the Sponsor and the Incubation PMC, the candidate, now podling, enters the Podling phase of maturing and refinement. Here the candidate is assigned its official mentor who will assist the candidate through the remaining steps of the process for integrating into the ASF.

c. The Podling Phase

The Podling phase is where the candidate project refines its software to meet the ASF quality requirements and “way of life”: licensing, code release,

distribution, and maintenance. Once a candidate project is in the Podling phase, the ASF is saying there is potential in the project, and hope to approve its acceptance into the ASF family of products once mature. The duration of the podling phases is not defined, since that is dependent on the speed of the podling project to transition itself into the Apache way of life.

(1) Podling Reviews. The incubator PMC performs regular reviews, quarterly or less, of the podling project’s progress to determine if it needs to be terminated, continued, or graduation to a TLP. The self-assessment portion of the podling project’s candidate proposal is the foundation of the first review. Ultimately, each review is a measure of the podling project’s development according to the ASF philosophy and guidelines for collaborative development.

(2) Podling Project Pages and Mailing Lists. The incubator PMC, as well as all of Apache, uses project pages and archived mailing lists to track the status of all projects. To accommodate this, each podling project, through mentor assistance, will have to establish the following:

 The reporting schedule (milestone plans)

 The project status page (progress of the project) o Status of setup task

o Exit criteria (graduation)

o Status of exit criteria completion

 The mailing lists (collaborative networking)

 The repository space (code storage)

(3) Podling Check Points. The fundamental aspect of the podling phase is to weed out software that cannot meet the ASF philosophy and way-of-life standards. This is based on a number of common issues:

 Source Code licensing issues that will not enable open source.

 The code is overly dependent on external code that jeopardize the longevity of the podling.

 Not enough collaboration received or desired from the public.

 Fails to meet the ASF “look and feel” of how open source is supposed to work.

(4) Podling Termination and Termination Dispute. A podling can be terminated during any of the quarterly reviews if it fails to maintain schedule or meet the ASF way of life. However, if the podling or its mentor disagrees with the Incubator PMC findings for termination, they can dispute the claim. In receipt of a dispute, the Incubator PMC will review the podling project’s status. If the Incubator PMC finds the podling project worthy of continuation, it resumes its progress, but with added refinement tasks to insure improved progress.

d. The Podling Code Release Constraints

Part of the podling phase is the solicitation of support and interest in the podling project from the public; Apache brands great tools that have public value. To accomplish this, a podling will need to make numerous preliminary version releases to those interested in the project.

The ASF permits releases from their site, the podling repository at Apache, in the effort to further the podling codebase. They do however restrict any Apache brand from being associated to podling code, which is done to ensure the ASF name is not tarnished through immature podling code.

A podling must seek approval from the Incubator PMC for permission to release a code version, and do so only after all of the source-code is transferred to an ASF licensing (ASL). A podling must releases under the ASL, but cannot release under the name of Apache.

The process of approval of a release is conducted by majority vote, as is all other aspects of the ASF. First, a podling must have a majority vote from its mailing list to start a code release. Second, the podling sends a request to the Incubator PMC for code-release permission. Third, the Incubator PMC conducts a majority approval vote to determine code release approval.

With the Incubator PMC approval, the podling may then release their code, but with certain constraints:

 The word “incubating” must be in the filename.

 The release must contain the term “In Incubation” clearly visible in the main documentation or README file.

 Releases must be distributed through incubator approved channels:

o http://www.apache.org/dist/incubator/podling

e. Graduation into the ASF

The end goal of the podling phase is graduation into the ASF as either a TLP or subproject. This determination will be made during the periodic Incubator PMC reviews based on the podling’s ability to show:

 It is a worthy and healthy project

 It truly fits within the ASF framework

 It “gets” the Apache Way

These subjective criteria are achieved with the podling meeting the legal, community, alignment, synergy, and ASF infrastructure requirements as well as any additional requirements established by the Incubator PMC (Apache, n.d.). Does the code work, do people want the code, and is the codebase in-line with Apache’s way of life?

The overall goal of Apache is to maintain the legacy of the namesake.

Only codebases that are well tested, proven, desired, and mature may gain adoption into the Apache family. The candidate must transition its way of doing things into that of the way of Apache. However, through this burden of effort, a candidate reaps the benefits of Apache naming, process and sustainable success.