Commons Incubator Proposal

ABSTRACT

The Commons Incubator would act as a "perpetual podling" or "mini-Incubator" overseeing the influx of components to be adopted into Apache Commons.

BACKGROUND

Apache Commons, a conglomerate of smallish Java libraries, lacks a good procedure for importing preexisting codebases.

RATIONALE

The typical ASF top-level project (TLP) absorbs code donations by means of a software grant. Clearly delineated subprojects (usually partially or completely dependent on the TLP) often enter instead through the Incubator. Commons, as a project that has no code other than that of its subprojects, is essentially a microcosm of the ASF itself. Commons has long offered a sandbox area for the development of new ideas, similar to the approach now taken in Apache Labs. With regard to the creation of new subprojects from preexisting codebases, however, the PMC is in agreement that procedures similar to those in practice in the ASF Incubator are more appropriate than the software grant approach, given that the Incubator has already formalized much the same process as would need to be taken to guarantee the acceptability of donated code. Unfortunately the processes of the Incubator proper are not a perfect fit.

With regard to community exit requirements, a typical podling requires a heterogenous community of three or more developers. Commons considers itself an open community in that all Commons committers have karma to all components, thus any component to graduate into Commons proper inherits an existing, diverse community. This greatly mitigates any component's risk of orphanhood. The PMC envisions Commons' incubator space as functioning in a manner similar to that in which its development sandbox currently operates: all ASF committers are welcome to participate in the Commons sandbox, and would be welcome to contribute to incubating components, subject to a natural consensus-building process. Active contributors to graduating components would be accepted into the project as full Commons committers with shared karma.

Another aspect in which existing Incubator practices are suboptimal for Commons' requirements is that, a Commons component being a relatively small entity, it is difficult to justify expending the same effort to set one up as would typically be required for a normal-sized podling. Commons expects this situation would be compounded by the large number of components currently slated for incubation. It would be seen as advantageous to keep incubating Commons components under a single Subversion tree, and as subcomponents of a single JIRA project. Finally, the existing Commons communications lists could be utilized. Component setup would thus be minimal.

Having established that setting up a Commons Incubator separate from the Apache Incubator would be counterproductive and quite a duplication of effort, Commons would like to see established on its behalf a "special case" podling or miniature Incubator whose exit criteria parallel those Commons uses to gauge the propriety of a sandbox component's promotion to "proper" status, namely:

INITIAL GOALS

CURRENT STATUS

Meritocracy:

Community:

Core Developers:

Alignment:

KNOWN RISKS

Orphaned Products:

Inexperience with Open Source:

Homogenous Developers:

Reliance on Salaried Developers:

No Ties to Other Apache Products:

A Fascination with the Apache Brand:

DOCUMENTATION

INITIAL SOURCE

EXTERNAL DEPENDENCIES

REQUIRED RESOURCES

Mailing Lists:

Subversion Directory:

Issue Tracking:

INITIAL COMMITTERS

AFFILIATIONS

SPONSORS

Champion: Henri Yandell (or I will champion if you're going to be too busy -MJB)

Nominated Mentors: Henri Yandell, Matt Benson(, volunteers?)

Sponsoring Entity: Commons PMC

April 10, 2008

CommonsIncubatorProposal (last edited 2009-09-20 23:48:37 by localhost)