Development Resources/HOWTO/Incubation Phase

Guidelines for Incubation Phase

See "6.2.3 Incubation Phase" in the Eclipse Development Process.

After the project has been created, the purpose of the incubation phase is to establish a fully-functioning open-source project. In this context, incubation is about developing the process, the community, and the technology. Incubation is a phase rather than a place: new projects may be incubated under any existing Top-Level Project.

(1) What Is Incubation?

The purpose of the incubation phase is to establish a fully-functioning open-source project. Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience - the incubation phase is not about changing those successful practices, but rather it is about developing the additional practices that create an open, transparent, welcoming, and predictable open-source project.

While it may seem easy to transfer from closed source development to open source development (isn't it just opening up the source code repository?), the history at Eclipse has shown that it takes practice to learn the community-defined Eclipse-centric open source process and to build viable user, plug-in developer, and committer communities.

Of course, in addition to learning "the Eclipse Way", the new project team must continue to do all the typical software project management tasks: identifying critical use cases, producing a high level design, setting up a release engineering system, writing automated unit testing, etc.

(2) Initial Code and Development

New project teams are usually eager to get started writing code and building tools. This is an admirable trait, but there are a few things to remember:

• RIP Due Diligence. All code contributions, including initial code contributions, must be vetted against the Eclipse IP Policy as discussed in the complete Due Diligence Guidelines (you might also examine the IP process flowchart poster). Fortunately, incubation phase projects can use the Parallel IP process to speed check-in approval for their initial code contribution.

  The Eclipse Foundation takes the IP Due Diligence process very seriously and thus one of the worst mistakes a new project can do is to disregard the IP Policy and, for example, check-in unapproved code. The Parallel IP process for incubating projects is a powerful tool, but "you never get a second chance to make a first impression," so why not take that extra couple minutes to understand the Parallel IP process and the Eclipse IP Policy? There are a few pre-requisites to complete before committing code to the source code repository, all described on the Parallel IP Guidelines page.

• RAPIs. The raison d'etre for Eclipse projects is to provide an extensible set of platform quality APIs for the Eclipse community to build upon. High-quality APIs take a lot of hard work to create. Thus it is essential that all new Eclipse projects start their API design, specification, and review process as they start committing code to their source repository.
• RFrameworks. Eclipse is a place for extensible frameworks and exemplary tools - the key point being the order of those clauses (frameworks before tools). Many new Eclipse project teams focus too heavily on building end-user tools rather than on the frameworks. Doing so will delay the project's graduation from incubation because the Eclipse ecosystem (adopters and users) are driven by the frameworks more than the tools. Both are necessary, but as the end-user tools appear easier to most developers, new projects tend to over-focus on tools and under-focus on frameworks. <p>The frameworks are primary and the exemplary tools should be examples of how to use the extensible frameworks. Good examples. Great examples. But just one possible use of the frameworks - Eclipse is about enabling the ecosystem rather than just about giving away free tools.
• GRegular Milestones. Successful Eclipse projects use an agile development process with regular milestones leading to major releases. The major projects have settled on a six week milestone schedule, with each milestone comprising a complete software development lifecycle: design, code, test, integrate, distribute. Eclipse projects that have tried the waterfall style single "code complete", single "feature complete", and final bug fix pass have been less successful. We recommend that new projects establish and maintain a predictable, reliable milestone schedule from the beginning.<p>Perhaps the biggest reason that milestone-style development results in a more successful Eclipse project is the benefit milestones provide to building a community: the regular delivery of complete new functionality is a powerful driver to the formation of the user, adopter, and developer communities.
• RInterim Releases. Incubation Phrase projects may make 0.N releases (e.g., 0.2, 0.5, 0.7, ...) but may not release an N.0 or greater releases (e.g., not 1.0, 1.2, 2.0, ...). A project ready to make a 1.0 release is a project ready to graduate from Incubation. All major releases (i.e., 0.N and M.N) releases, must go through a Release Review.<p>GFor projects with larger initial code bases, we encourage the project to have at least one interim release before attempting a 1.0 release. The process of finishing the code, tests, and documentation to a release standard, plus the process of gathering all the IP documentation, preparing the release docuware, etc. - the practice of all that is invaluable preparation for the full 1.0 Release Review.

This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)