Development Resources/HOWTO/Incubation Phase
Guidelines for Incubation Phase
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:
- 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.
IP Due Diligence. All code contributions, including initial code contributions, must be vetted against the
- 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. APIs. The raison d'etre for Eclipse projects is to provide an extensible set of
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.
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.
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.
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.
- Release Review.
For 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 document, etc. - the practice of all that is invaluable preparation for the full 1.0 Release Review. Interim Releases. Incubation Phase 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
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:
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:
All conforming Incubation phase Eclipse projects are eligible to participate in the Parallel IP process
A conforming project:
- Is in the Incubation phase.
- Correctly displays the incubation logo on their project home page.
- Correctly displays the same incubation logo on their project's primary download page.
- All downloadable zip files for builds (including release builds) and milestones must include the word "incubation" in the filename. For example,
- The jar files in the download zip file are not required to contain the word "incubation" in the filename. (See bug 178944 for the explanation.)
- All "Bundle-Name"s must include the word "incubation". Note that "Bundle-SymbolicName"s should not include "incubation" because the Bundle-SymbolicName is a technical namespace, not a user namespace. For example,
Bundle-Name: Foo Plug-in (Incubation)
- Similarly, the names for features must include the word "incubation". For example,
Eclipse Platform (Incubation)
If you believe your project is conforming (i.e., 1-5 above) but is listed on the main projects page as non-conforming, send email to the EMO and ask us to update the database.This page is moderated by the EMO