The Eclipse Development Process has a notion of phases. Two of those phases are Incubation and Mature.
While in both of these phases, an Eclipse open source project operates in basically the same manner: only committers can push content, committers are brought on board by election, committers accept contributions, and projects in the incubation phase can issue major, minor, and service releases. In fact, we strongly encourage all new project teams to engage in at least one release while in the incubation phase as part of learning our process. Traditionally, a project in the incubation phase numbers their releases < 1.0 (e.g. “0.7”), but there is no requirement to do so.
Incubation is a phase, or state, for a project. That a project is in the incubation phase (we oftentimes refer to a project in this phase as “incubating”) is a flag for adopters and the community at large that the project team is still learning the various processes that Eclipse project teams follow, or that the content produced is either unstable or volatile (e.g. APIs are likely to change while a project is in incubation). Note my use of the word “or” in the previous sentence: a project with a stable code base that has just moved to the Eclipse Foundation (with committers who are new to our process) starts in incubation.
To highlight that a project is in the incubation phase, it must implement incubation branding. Primarily, this takes the form of displaying the incubation logo in prominent locations, including the project’s major web properties and including the word “incubation” or warning that products shipped as part of a release “may include incubating components”.
For those readers who are already familiar with our incubating branding, you’ll hopefully be delighted to learn that we’ve selected a logo to replace the venerable old “incubation egg” and will be rolling it out soon (while these sorts of things tend to be a team effort, we give credit to @stephaniejswart for bringing this new logo to life).
The IP process provides some additional flexibility for projects in incubation; the implication being that there may be some modest increase in intellectual property-related risk (especially when combined with a new development team who don’t yet live and breath the Eclipse IP Policy).
To leave incubation, a project team must engage in a graduation review (graduation reviews are typically combined with a progress or release review). During that review, the project team must demonstrate that:
- The project team understands and implements the EDP and and related processes, and understands their obligations under the Eclipse IP Policy;
- The APIs are stable; and
- The content produced is of “Eclipse Quality”
In practice, this takes the form of a few extra sentences in the documentation associated with the review (after, of course, actually learning the ropes and stabilizing the content quality).