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.

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.

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:

• IP 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).
  • 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.
• APIs. 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.
• Frameworks. 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.
  • 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.
• Regular 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.
  • 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.
• Interim Releases. Incubation Phase projects may make releases. All major and minor releases must go through a Release Review.
  • Interim releases by an Incubation Phase project conventionally have a pre-1.0 version number, but there is no specific requirement to do so. Consider the community and whether or not a 1.0 version number will create confusion if the project is still in incubation.
• Graduation. Incubation Phase projects will eventually graduate, signifying that the project code base has stabilized and that the project team is familiar with the Eclipse Development Process.
  • Graduation Reviews are generally combined with a release review.
  • For projects with larger initial code bases, we encourage the project to have at least one interim release before attempting a graduation 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 document, etc. Release Review.

Communities

See "2.5 Three Communities" in the Eclipse Development Process.

Essential to the Purposes of the Eclipse Foundation is the development of the three inter-related communities around each Project, and the Incubation Phase is the best time to start forming those communities:

• Contributors and Committers - a thriving, diverse and active community of developers is the key component of any Eclipse Project. Ideally, this community should be an open, transparent, inclusive, and diverse community of Committers and (non-Committer) Contributors. Attracting new Contributors and Committers to an open source project is time consuming and requires active recruiting, not just passive "openness". The Project Leadership must make reasonable efforts to encourage and nurture promising new Contributors.
  • Projects must have the diversity goals to ensure diversity of thought and avoiding relying on any one company or organization.
  • Diversity is a means to an end, not an end in itself, thus diversity goals will differ by project based on the other accomplishments of the project(s).
  • There is evidence that having a single company with a focused, well socialized team, is a good way to start up a challenging new project. We do not want to discourage this start-up method, but we do want to ensure that for a project to move into the Mature Phase, it has an expanded committer community.
• Users - an active and engaged user community is proof-positive that the Project's exemplary tools are useful and needed. Furthermore, a large user community is one of the key factors in creating a viable ecosystem around an Eclipse project, thus encouraging additional open source and commercial organizations to participate. Like all good things, a user community takes time and effort to bring to fruition, but once established is typically self-sustaining.
• Adopters - an active and engaged adopter/plug-in developer community is only way to prove that an Eclipse project is providing extensible frameworks and extensible tools accessible via documented APIs. Reuse of the frameworks within the companies that are contributing to the project is necessary, but not sufficient to demonstrate an adopter community. Again, creating, encouraging, and nurturing an adopter community outside of the Project's developers takes time, energy, and creativity by the Project Leadership, but is essential to the Project's long-term open source success.

Projects are expected to make substantial progress on establishing these communities during their Incubation Phase. The Eclipse community standards will make it difficult to graduate from Incubation without all three of these communities.

Operations and Logistics

Other than the "learning the Eclipse Way" aspects, the day-to-day operations of an Incubation phase Eclipse Project are mostly identical to those of a Mature phase Project. Please see the these pages:

• Words of wisdom and bits of advice; and
• How-tos, checklists, and guidelines

The exception to "identical" is that Incubation Phase projects are required to display the incubation graphic in a conforming way.

Graduating from Incubation

For details, see:

• Criteria for Graduating; and
• Graduation Reviews

Incubation Branding

Please see Conforming Incubation Branding.

This page is moderated by the EMO