Development Process 2006 New Incubation

Project Lifecycle

Strike through means striked from original, underlined means new.

Projects go through sixseven distinct phases. The transitions from phase to phase are open and transparent public reviews.

Pre-proposal - An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.

• The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.

Proposal - The proposers, in conjunction with the destination PMC and the community, collaborate in public to enhance, refine, and clarify the proposal. Mentors for the project must be identified during this phase.

• The Proposal phase ends with a Creation Review Proposal Review or a Termination Review.

Proposal review - The reviews are not described in the original project lifecycle, it is added here anyway for providing info about the purpose of this review. The proposal review checks whether the proposal is in compliance with the Eclipse Bylaws and if the required number of Mentors have been found.

Proposal Validation - After the proposal has been accepted for validation, the purpose of the proposal validation phase is to establish a basic (documented) architecture and to validate this architecture with a working implementation. The proposal team should make all planed code contributions available during proposal validation. It should be able to instantly use the code contributions. The contributions need to be worked to eclipse quality requirements (tests, api, documentation) during Proposal Validation. The proposers need to create an easily consumable build of the implementation. As there are legal requirements for ip compliance at Eclipse.org, I propose that we use an infrastructure (e.g. from a partner) where the code can live, where we do not have the ip compliance requirement. Eclipse.org would provide newsgroup, mailing list and web space during proposal validation, but the sources and builds would be provided from a different site. IMPORTANT: Mentors would be available to the proposers in the proposal validation phase, but we would not speak of an Eclipse project at this phase.

• The Proposal Validation phase ends with a successful Creation Review or a Termination Review.

Incubation - 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.

• The Incubation phase ends with a successful Graduation Review or a Termination Review.
• The Incubation phase may continue with a Continuation Review.
• Top-Level Projects cannot be incubated and can only be created from existing Mature-phase Projects.

Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.

Jochen, what is the reasoning behind this proposal? Are you trying to have the projects commit to an architecture early in their lifecycle? Are you trying to separate the existence of IP cleared code from the existence of a functioning community? If the proposal has Eclipse-based infrastructure for everything expect the code, aren't there IP issues around that as well (e.g., what if a project discusses a GPLed contribution to their external repository but does so on the Eclipse newsgroup; the newsgroup explicits defines all postings as EPLed, so ...)? And wouldn't this proposal have the side-effect of making it more convenient to propose a project with no initial code (because then you wouldn't have to discuss the architecture in advance)?
I believe you have a goal in mind for this proposal, but I'm not clear what that goal is. Thanks.--Bjorn Freeman-Benson

Bjorn, Yesterday I ran out of time before being able to put down my reasoning, but here it comes - and thanks for your questions. There are three main reasons for this proposal:

• set quality standards that need to be met before we create an eclipse project
• enable proposals to showcase their ideas without having to wait a couple of month for approval of code contributions or use of third party code (and I guess this a reality for most of the new projects) - by being able to distribute binaries and having easily consumable sources. We (the RAP project) have a very real pain with this - we can not provide any builds and it is quite difficult to build a community just by providing information and incomplete sources in CVS.
• distribute the risk of accepting code contributions between the proposers and eclipse.org. Currently eclipse.org is spending time and money on ip compliance for code contributions and third party code before it is clear that
  • the project is able to produce something useful at all (beside an idea)
  • the code has sufficient quality
  • the code will be actively developed to eclipse quality and testing standards

(Bjorn) Are you trying to have the projects commit to an architecture early in their lifecycle? I would like to achieve that projects care about architecture early in their lifecycle and that they document the initial architecture with more then a few boxes (at least a documentation of the main purpose of each plugin and its relation to other plugins, as well as how it shall be extensible. Often enough this kind of documentation happens late in the cycle(or not at all). But it is important for projects that want to build a platform that adopters can comprehend the structures - this is different than with projects that "only" create end user tools.

(Bjorn) Are you trying to separate the existence of IP cleared code from the existence of a functioning community? Sort of. I argue that it is pretty difficult to build a community if you can not provide something easily consumable. But I would not go so far that the community building should be part of the proposal validation phase, I think this remains in the incubation phase. But the community would have something to get started with at the BEGIN of incubation: a full set of sources and binaries (and an architecture overview).

(Bjorn) If the proposal has Eclipse-based infrastructure for everything expect the code, aren't there IP issues around that as well (e.g., what if a project discusses a GPLed contribution to their external repository but does so on the Eclipse newsgroup; the newsgroup explicits defines all postings as EPLed, so ...)? Not sure about this, let's ask the lawyers if others like the idea at all. Maybe this has to be tuned.

(Bjorn) And wouldn't this proposal have the side-effect of making it more convenient to propose a project with no initial code (because then you wouldn't have to discuss the architecture in advance)? I don't think so, as there would still be the need "to establish a basic (documented) architecture and to validate this architecture with a working implementation". And this is not meant to cause only pain to the projects, but instead enable them to show that they can provide something useful and it is worth spending time with them.

-- Jochen Krause

My reading between-the-lines summary of your statements is that you have two reasons: (1) shorten the time from announcement to code visibility in order to make it easier for new projects to recruit community by showing working code, and (2) increase the quality of the APIs, etc of released projects. Unfortunately, the two goals seem at odds with each other, i.e., "reduce oversight (to reduce timeline)" and "increase oversight (to increase quality)". :-)

I'm not convinced that a validation phase would help for the same reason that the Architecture Council has been ineffective: there doesn't seem to be enough time in everyone's busy schedules to properly spend enough time reviewing projects that (as you point out) might never become real. I'm not saying I'm against it, I'm just not convinced yet.

However, I'm definitely positive on the first item. I wrote about my personal proposal for a solution in my blog; it's similar to yours in that it gets the real stuff (the code) out in front of the community earlier and then has the legal review catch up.

-- Bjorn Freeman-Benson

Your reading is quite right, and great that we agree on (1). Regarding (2): I don't expect the great wisdom (and time) of the community to fix the problem, but instead to draw the attention of the projects to this topic right from the beginning. And if we would have a step between the creation of the project and the end of incubation where we ask the projects to provide info about architecture and API, this may help. Another potential problem that this is trying to address is around code contributions - I would love to see a mechanism to a) demonstrate the usefulness of the code b) disallow dumping the code right into "production" without any quality gates, because this is usually very hard to fix later. Quality would be much easier to assess in such a scenario (where a project must demonstrate it), and it would consume less time and may more easily fit in everyone's busy schedules. -- Jochen Krause