Eclipse Foundation Development Process
Version 1.11. Effective September 1, 2023
- 1. Purpose
- 2. Principles
- 3. Requirements
- 4. Project Structure and Organization
- 5. [Reserved]
- 6. Development Process
- 6.1 Reserved
- 6.2 Project Lifecycle
- 6.3 Reviews
- 6.4 Releases
- 6.5 Grievance Handling
- 7. Precedence
- 8. Revisions
This document describes the development process for the Eclipse Foundation. In particular, it describes how the Membership at Large, the Board of Directors, other constituents of the Ecosystem, and the Eclipse Management Organization (EMO) lead, influence, and collaborate with Eclipse Projects to achieve the Purposes defined in the Bylaws.
This document has the following sections:
Principles outlines the basic principles upon which the development process is based.
Requirements describes the requirements that the Eclipse community has for its development process.
Structure and Organization specifies the structure and organization of the Projects and Project community at Eclipse.
Development Process outlines the lifecycle and processes required of all Eclipse Projects.
This document defines terms used elsewhere in Eclipse governance documents. In the event of any conflict between the terms set forth in this document and the terms of the documents listed below, the terms of those documents shall take precedence.
All Committers and Project Leads engaged in Project activity are required to implement the policies and processes described by the Eclipse Foundations Governance Documents, including:
Adopters are the individuals and organizations that adopt Eclipse technology for inclusion in their own products and services.
- Architecture Council
The Eclipse Architecture Council (AC) is a council of experienced Eclipse committers responsible for identifying and tackling any issues that hinder continued technological success and innovation, widespread adoption, and future growth of Eclipse technology. The Eclipse Architecture Council is formally defined in section VII of the Bylaws of the Eclipse Foundation.
- Board of Directors
The business and technical affairs of the Eclipse Foundation are managed by or under the direction of the Eclipse Board of Directors.
- Check Point Review
Check Point Review is a category of Review that includes: Creation Review, Progress Review, Release Review, and Graduation Review.
A committer is a software developer who has the necessary rights to make decisions regarding a Project.
A Contributor is anybody who makes contributions to a Project.
- Creation Review
A Creation Review is a type of Review that marks a Project’s transition from the Proposal Phase to the Incubation Phase.
A Committer or Contributor.
An Ecosystem is a system in which companies, organizations, and individuals all work together for mutual benefit.
- Eclipse Management Organization
The Eclipse Management Organization (EMO) consists of the Eclipse Foundation staff, and the Eclipse Architecture Council.
The term EMO(ED) generally refers to the Executive Director of the Eclipse Foundation. When discussing matters pertaining to the Eclipse Foundation Development Process, EMO(ED) refers to the subset of the EMO consisting of the Executive Director and whomever he or she may delegate specific approval authority to.
- Graduation Review
A Graduation Review is a type of Review that marks a Project’s transition from the Incubation Phase to the Mature Phase.
- Incubation Branding
Incubation Branding is the branding that must be applied to all Projects in the Incubation Phase.
- Incubation Phase
The Incubation Phase is a Phase during which the Project Team develops the process, the community, and the technology for a new Project.
- Integration Build
An Integration Build is a build of the Project content that is generated periodically and made available to the Developer community for testing purposes.
- Major Release
A Major Release is a type of Release that includes either significant new functionality and/or breaking changes.
- Mature Phase
The Mature Phase is a Phase during which a Project operates with an open and transparent process, has an actively involved and growing community, and produces Eclipse-quality technology.
- Membership at Large
The Membership at Large (or Membership) refers to all members of all types, as defined by the Bylaws of the Eclipse Foundation.
A Milestone is a build of the Project content intended for limited distribution to demonstrate progress and solicit feedback.
- Minor Release
A Minor Release is a type of Release that includes new features over a Major Release.
- Nightly Build
A Nightly Build is a build of the Project content that is generated nightly and made available to the Developer community for testing purposes.
- Permanent Incubator
A Permanent Incubator is a Project that is intended to perpetually remain in the Incubation Phase.
A Phase is a stage in the Project lifecycle. See Pre-proposal Phase, Proposal Phase, Incubation Phase, and Mature Phase.
- Pre-proposal Phase
The Pre-proposal Phase is a Phase during which a new Project Proposal is created.
- Progress Review
A Progress Review a type of Review that is used by a Project Team to summarize the accomplishments of the Project, verify that the Eclipse Development Process and IP Policy have been followed, and to highlight any remaining quality and/or architectural issues.
A Project is the main operational unit for open source software development at the Eclipse Foundation.
- Project Lead
A Project Lead, the first level in the Project Leadership Chain, is responsible for the overall well-being of a specific Project and serves as the primary liaison between that Project and the EMO.
- Project Leadership Chain
The Project Leadership Chain is composed of a Project’s Project Lead(s), the leadership of the parent Project (if any), the PMC Leads and PMC Members for the Top-Level Project, the EMO, and the EMO(ED).
- Project Management Committee
A Project Management Committee (PMC) is the primary leadership of a Top-Level Project with responsibility to ensure that the Projects within its purview are active and viable.
- Project Proposal
A Project Proposal (or just Proposal) is a document that is presented to the PMC, Membership at Large, and EMO to describe a potential new Project.
- Project Team
A Project Team is the collective of Committers with responsibilities and privileges on a specific Project.
- Proposal Phase
The Proposal Phase is a Phase during which a Project Proposal is presented to the community and Membership at Large to solicit feedback.
A Release is a collection of Project artifacts intended for distribution beyond the Project Developers.
- Release Candidate
A Release Candidate is a feature-complete Milestone.
- Release Review
A Release Review is a type of Progress Review that is aligned directly with a specific Release.
- Restructuring Review
A Restructuring review is a type of Review that is used to notify the community of significant changes to one or more Projects.
A Review is formally designated period of time during which the Project Management Committee, the Membership at Large, and the EMO are given an opportunity to survey the current state of a Project, provide feedback, and validate that the Project is in good standing.
The Scope is the defined range of activities to be undertaken by a Project. The Project Team must operate within the bounds defined by the Project’s Scope.
- Service Release
A Service Release, or Bug-fix Release is a type of Release that includes no significant changes or additions over the base Release.
A synonym for Project.
- Termination Review
A Termination Review is a type of Review that provides a final opportunity for a Project Team, the Project Leadership Chain, and the Eclipse Membership to consider the proposed archival of a Project.
- Top-Level Project
A Top-Level Project is an organizational unit that defines an overall mission and scope for a collection of Projects.
- Top-Level Project Charter
A Top-Level Project Charter describes the mission, purpose, scope, and operational rules for a Top-Level Project.
The following describes the guiding principles used in developing this development process.
Open - Eclipse is open to all; Eclipse provides the same opportunity to all. Everyone participates with the same rules; there are no rules to exclude any potential Contributors which include, of course, direct competitors in the marketplace.
Transparent - Project discussions, minutes, deliberations, Project plans, plans for new features, and other artifacts are open, public, and easily accessible.
Meritocratic - Eclipse is a meritocracy. The more you contribute the more responsibility you will earn. Leadership roles in Eclipse are also merit-based and earned by peer acclaim.
Eclipse as a brand is the sum of its parts (all of the Projects), and Projects should strive for the highest possible quality in extensible frameworks, exemplary applications, transparent processes, and Project openness.
The Eclipse Foundation has the responsibility to …cultivate…an Ecosystem of complementary products, capabilities, and services…. It is therefore a key principle that the Eclipse Foundation Development Process ensures that the Projects are managed for the benefit of both the open source community and the Ecosystem members. To this end, all Eclipse Projects are required to:
communicate their Project plans and plans for new features (major and minor) in a timely, open and transparent manner;
create high-quality frameworks capable of supporting the building of commercial grade products on top of them; and
ship extensible, exemplary applications which help enable a broad community of users.
Essential to the Purposes of the Eclipse Foundation is the development of three inter-related communities around each Project:
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.
An active and engaged user community is proof-positive that the Project’s exemplary applications 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.
An active and engaged Adopter community is the only way to prove that an Eclipse Project is providing extensible frameworks and applications 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.
The Eclipse community considers the absence of any one or more of these communities as proof that the Project is not sufficiently open, transparent, and inviting, and/or that it has emphasized applications at the expense of extensible frameworks or vice versa.
It is an explicit goal of the development process to be as clear and concise as possible so as to help the Project Teams navigate the complexities, avoid the pitfalls, and become successful as quickly as possible.
This document imposes requirements and constraints on the operation of the Projects, and it does so on behalf of the larger Eclipse community. It is an explicit goal of the development process to provide as much freedom and autonomy to the Projects as possible while ensuring the collective qualities benefit the entire Eclipse community.
Similarly, this document should not place undue constraints on the EMO or the Board of Directors that prevent them from governing the process as necessary. We cannot foresee all circumstances and as such should be cautious of being overly prescriptive and/or requiring certain fixed metrics.
The frameworks, applications, Projects, processes, community, and even the definition of quality continues to, and will continue to, evolve. Creating rules or processes that force a static snapshot of any of these is detrimental to the health, growth, and Ecosystem impact of Eclipse.
Part of the strength of this document is in what it does not say, and thus opens for community definition through convention, guidelines, and public consultation. A document with too much structure becomes too rigid and prevents the kind of innovation and change we desire for Eclipse. In areas where this document is vague, we expect the Projects and members to engage the community-at-large to clarify the current norms and expectations.
Projects are required to engage in practices that ensure the continued viability of the Project, independent from the continued availability of external resources and services, or continued participation on any single individual, organization, or group.
In practical terms, Projects are required to use resources and services approved by the Eclipse Foundation. This includes (but is not limited to) all source code management, distribution channels for artifacts, issue tracking, documentation, and public communication channels.
This document is entirely composed of requirements. In addition to the requirements specified in this development process, the EMO is instructed to clarify, expand, and extend this process by creating a set of development guidelines to advance the creation, evolution, promotion, and support of the open source Projects; and to cultivate both a community and an Ecosystem of complementary products and services.
The EMO has the responsibility and authority to mitigate issues that arise when Committers fail to perform the required behaviors or engage in practices that risk harm to Eclipse Projects, the community, and/or Ecosystem. This includes, but is not limited to, issues that arise due to a failure to implement the Eclipse Foundation Vulnerability Reporting Policy, the Eclipse Foundation Intellectual Property Policy, the Eclipse Foundation Community Code of Conduct, or other governance policies of the Eclipse Foundation.
The EMO’s authority includes, but is not limited to, the ability grant specific individuals equivalent to Committer privileges, suspend access to Project resources, add or remove Committers and Project Leads, and—in extreme cases—terminate the Project.
The EMO is not permitted to override or ignore the requirements listed in this document without the express written endorsement of the Board of Directors.
The motivation for the EMO to take action along with description of the steps taken as part of the mitigation must be publicly disclosed within one week of action being taken. The Grievance Handling section of this document describes the means by which a Member may respond in the event that they believe that the EMO has overstepped its authority.
A Project is the main operational unit at Eclipse. Specifically, all open source software development at Eclipse occurs within the context of a Project. Projects have leaders, Developers, code, builds, downloads, websites, and more. Projects are more than just the sum of their many parts, they are the means by which open source work is organized when presented to the communities of Developers, Adopters, and users. Projects provide structure that helps Developers expose their hard work to a broad audience of consumers.
Eclipse Projects are organized hierarchically. A special type of Project, Top-Level Projects, sit at the top of the hierarchy. Each Top-Level Project contains one or more Projects. Each Project may itself contain zero or more Projects. A Project that has one or more Projects is said to be the parent of those Projects. A Project that has a parent is oftentimes referred to as a Subproject. The term Project refers to either a Top-Level Project or a Subproject.
The descendants of a Project are the Project itself and transitive closure of its child Projects. The top parent of a Project is the Top-Level Project at the top of the hierarchy.
Projects are the unit entity for:
code and Releases;
intellectual property (IP) records; and
Each Project has exactly one set of Committers. Each Project’s set of Committers is distinct from that of any other Project, including Subprojects or parent Projects. All Project Committers have equal rights and responsibilities within the Project. Partitioning of responsibility within a Project is managed using social convention. A Project may, for example, divide itself into logical partitions of functionality; it is social convention that prevents Committers from one logical partition from doing inappropriate work in another. If finer-grained management of Committer responsibilities is required, a Project should consider partitioning (via a Restructuring Review) into two or more Subprojects.
The Committers of a Project have the exclusive right to elect new Committers to their Project; no other group, including a parent Project, can force a Project to accept a new Committer.
There is no roll-up of Committers: the set of Committers on a Project is exactly that set of people who have been explicitly elected into that role for the Project (i.e. being a Committer on a Subproject does not give you any automatic rights on the "parent" Project or any child Project).
In practical terms, each Project has a single UNIX group of its Committers that provides write-access to the Project’s resources. Pictorially below, we see that a Project, in addition to the various resources and Committers it has, can also have zero or more Subprojects. Each of these Subprojects has its own distinct set of Committers and resources.
Each Project owns and maintains a collection of resources.
Resources may include source code, a Project website, space on the downloads server, access to build resources, and other services provided by the Eclipse Foundation infrastructure. The exact infrastructure provided by the Eclipse Foundation varies over time and is defined outside this process document.
A Project is not strictly required to make use of all the resources made available; a Project might, for example, opt to not maintain a source code repository. Such a Project might operate as an organizational unit, or container, for several Subprojects. Similarly, a Project might opt to provide a consolidated website, build and/or download site for its Subprojects (the Subprojects would then not require those resources for themselves).
Namespaces are assigned to a Project by the EMO. All Project source code must be organized in the assigned namespaces and Projects can only Release code under their own namespace (that is, they cannot infringe on another Eclipse Project’s namespace).
Projects are the level of communication with the larger Eclipse community and Ecosystem. Projects may either have their own communications (website, mailing lists, forums/newsgroups, etc) or they may be part of a parent Project’s communications (website, mailing list, forums/newsgroups, etc). In either case, the Project is required to maintain an open and public communication channel with the Eclipse community including, but not limited to, Project plans, schedules, and design discussions.
All Projects must make the communication channels easy to find. Projects are further required to make the separate communication channels of their child Projects (if any) easy to find.
Any Project in the Incubation Phase must correctly identify its website and Releases. A Project with at least one descendant Project in Incubation Phase must correctly annotate its own website so as to notify the Eclipse community that incubating Projects exist in its hierarchy. Any Release containing code from an Incubation Phase Project must be correctly labeled, i.e., the Incubation Phase is viral and expands to cover all Releases in which it is included.
Each Top-Level Project has a Charter which describes the purpose, Scope, and operational rules for the Top-Level Project. The charter should refer to, and describe any refinements to, the provisions of this development process. The Board of Directors approves the charter of each Top-Level Project.
Subprojects do not have separate charters; Subprojects operate under the charter of their parent Top-Level Project.
All Projects have a defined Scope and all initiatives within that Project are required to reside within that Scope. Initiatives and code that is found to be outside the Scope of a Project may result in the termination of the Project. The Scope of Top-Level Projects is part of the charter, as approved by the Board of Directors of the Eclipse Foundation.
The Scope of a Subproject is defined by the initial Project Proposal as Reviewed and approved by the Project Management Committee (PMC) (as further defined below) of the Project’s top parent and by the EMO. A Project’s Scope must be a subset of its parent’s Scope.
There are two different types of Project Leadership at Eclipse: The Project Management Committee (PMC) and Project Leads. Both forms of leadership are required to:
ensure that their Project is operating effectively by guiding the overall direction and by removing obstacles, solving problems, and resolving conflicts;
operate using open source rules of engagement: meritocracy, transparency, and open participation; and
ensure that the Project and its Subprojects (if any) conform to the Eclipse Foundation IP policy and procedures.
The leadership chain for a Project is composed of the Project’s Project Lead(s), the leadership of the parent Project (if any), the PMC leads and PMC members for the Top-Level Project, the EMO, and the EMO(ED).
In exceptional situations—such as Projects with zero active Committers, disruptive Committers, or no effective Project Leads—the Project Leadership Chain has the authority to make changes (add, remove) to the set of Committers and/or Project Leads of that Project, and otherwise act on behalf of the Project Lead.
Top-Level Projects are managed by a Project Management Committee (PMC). A PMC has one or more PMC leads and zero or more PMC Members. Together the PMC provides oversight and overall leadership for the Projects that fall under their Top-Level Project. The PMC as a whole, and the PMC leads in particular, are ultimately responsible for ensuring that the Eclipse Foundation Development Process is understood and followed by their Projects. The PMC is additionally responsible for maintaining the Top-Level Project’s charter.
PMC leads are approved by the Board of Directors; PMC members are elected by the existing PMC leads and members, and approved by the EMO(ED).
In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by the unanimous vote of the remaining PMC members, subject to approval by the EMO. Removal of a PMC Lead requires approval of the Board of Directors.
Eclipse Projects are managed by one or more Project Leads. Project Leads are responsible for ensuring that their Project’s Committers are following the Eclipse Foundation Development Process, and that the Project is engaging in the right sorts of activities to develop vibrant communities of users, Adopters, and Contributors. The initial Project Leads are appointed and approved in the Creation Review. Subsequently, additional Project Leads must be elected by the Project’s Committers, approved by the Project’s PMC, and appointed by the EMO(ED).
To hold a Project Lead role on a Project, an individual must also hold a Committer role on that Project.
In the unlikely event that a Project Lead becomes disruptive to the process or ceases to contribute for an extended period, the individual may be removed by the unanimous vote of the remaining Project Leads (if there are at least two other Project Leads), or unanimous vote of the Project’s PMC.
Each Project has a development team, led by the Project Leaders. The development team is composed of Committers and Contributors. Contributors are individuals who contribute code, fixes, tests, documentation, or other work that is part of the Project. Committers have write access to the Project’s resources (source code repository, bug tracking system, website, build server, downloads, etc.) and are expected to influence the Project’s development.
Contributors who have the trust of the Project’s Committers can, through election, be promoted Committer for that Project. The breadth of a Committer’s influence corresponds to the breadth of their contribution. A development team’s Contributors and Committers may (and should) come from a diverse set of organizations. A Committer gains voting rights allowing them to affect the future of the Project. Becoming a Committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse member company or any company employing existing Committers.
The election process begins with an existing Committer on the same Project nominating the Contributor. The Project’s Committers will vote for a period of no less than one week. If there are at least three (3) positive votes and no negative votes within the voting period, the Contributor is recommended to the Project’s PMC for commit privileges. If there are three (3) or fewer Committers on the Project, a unanimous positive vote of all Committers is substituted. If the PMC approves, and the Contributor signs the appropriate Committer legal agreements established by the EMO (wherein, at the very least, the Developer agrees to abide by the Eclipse Intellectual Property Policy), the Contributor becomes a Committer and is given write access to the source code for that Project.
At times, Committers may become inactive for a variety of reasons. The decision making process of the Project relies on active Committers who respond to discussions and vote in a constructive and timely manner. The Project Leads are responsible for ensuring the smooth operation of the Project. A Committer who is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status revoked by the unanimous consent of the Project Leads. Unless otherwise specified, "an extended period" is defined as "no activity for more than six months".
Active participation in the user communication channels and the appropriate Developer mailing lists is a responsibility of all Committers, and is critical to the success of the Project. Committers are required to monitor and contribute to the user communication channels.
Committers are required to monitor the mailing lists associated with the Project. This is a condition of being granted commit rights to the Project. It is mandatory because Committers must participate in votes (which in some cases require a certain minimum number of votes) and must respond to the mailing list in a timely fashion in order to facilitate the smooth operation of the Project. When a Committer is granted commit rights they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a Developer mailing list unless their associated commit privileges are also revoked.
Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects. There are three voting responses:
-1 (no, or veto), and
Committers are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from Contributors. Committers are responsible for updating problem reports when they have done work related to the problem.
Committer, PMC lead or member, Project Lead, and council representative(s) are roles; an individual may take on more than one of these roles simultaneously.
A Project may designate a Subproject as a "Permanent Incubator". A Permanent Incubator is a Project that is intended to perpetually remain in the Incubation Phase. Permanent Incubators are an excellent place to innovate, test new ideas, grow functionality that may one day be moved into another Project, and develop new Committers.
Permanent Incubator Projects never have Releases. Permanent Incubators may have builds, and downloads. They conform to the standard Incubation Branding requirements and are subject to the IP due diligence rules outlined for incubating Projects. Permanent Incubators do not graduate.
The Scope of a Permanent Incubator Project must fall within the Scope of its parent Project. The Committer group of the Permanent Incubator Project must overlap with that of the parent Project (at least one Committer from the parent Project must be a Committer for the incubator). The parent Project’s Committers are responsible for ensuring that the incubator Project conforms to the rules set forth by the Eclipse Foundation Development Process.
A Permanent Incubator Project must be designated as such by including the word "Incubator" in its name (e.g. "Eclipse Dash Incubator"). To do otherwise is considered exceptional and requires approval from the PMC and EMO(ED).
Only Top-Level Projects and Projects in the Mature Phase may create a Permanent Incubator. Permanent Incubator Projects are created upon request; a Creation Review is not required.
Projects are required to make a Project plan available to their community at the beginning of the development cycle for each major and Minor Release. The plan may be as simple as a short description and a list of issues, or more detailed and complex. Subprojects may opt to include their plans with those of their parent Project.
Project Plans must be delivered to the community through communication channels approved by the EMO. The exact nature of the Project plan varies depending on numerous variables, including the size and expectations of the communities, and requirements specified by the PMC.
Projects must work within their Scope. Projects that desire to expand beyond their current Scope must seek an enlargement of their Scope using a public Review as described below. Further, Projects must fit within the Scope defined by their containing Projects and the Scope defined in the charter of their Top-Level Project.
Projects must provide advanced notification of upcoming features via their Project plan.
Projects go through distinct Phases. The transitions from Phase to Phase are open and transparent public Reviews.
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 at Large by the EMO.
The proposers, in conjunction with the destination PMC and the community, collaborate in public to enhance, refine, and clarify the proposal.
The Proposal Phase ends with a Creation Review, or withdrawal. The proposal may be withdrawn by the proposers at any point before the start of a Creation Review. The EMO will withdraw a proposal that has been inactive for more than six months.
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 Project.
A Project in the Incubation Phase can (and should) make Releases;
Top-Level Projects skip incubation and are immediately put into the Mature Phase;
The Incubation Phase ends with a Graduation Review or a Termination Review.
Designated Permanent Incubator Projects remain perpetually in the Incubation Phase; they do not create Releases, so no Reviews are required.
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.
The Project Team has demonstrated that they are an open-source Project with an open and transparent process, an actively involved and growing community, and Eclipse-quality technology. The Project is now a mature member of the Eclipse community.
Projects that become inactive, either through dwindling resources or by reaching their natural conclusion, are archived. Projects are moved to archived status through a Termination Review.
If there is sufficient community interest in reactivating an archived Project, the Project can start again with a Creation Review. As there must be good reasons to have terminated a Project, the Creation Review provides a sufficiently high bar to prove that those reasons are no longer valid.
The Eclipse Foundation Development Process is predicated on open and transparent behavior. All major changes to Eclipse Projects must be announced and Reviewed by the Membership at Large. Major changes include the Project Phase transitions as well as the introduction or exclusion of significant new technology or capability. It is a clear requirement of this document that members who are monitoring the appropriate media channels not be surprised by the post-facto actions of the Projects.
Projects are responsible for initiating the appropriate Reviews. If it is determined to be necessary, the Project Leadership Chain (e.g. the PMC or EMO) may initiate a Review on the Project’s behalf.
All Reviews have the same general process:
The Project Team will complete all required due diligence under the Eclipse IP Policy prior to initiating the Review.
A Project representative (Project Lead or Committer) assembles Review documentation.
A Project representative presents the Review documentation to the Project’s PMC along with a request to proceed with the Review and for approval of the corresponding documentation.
Upon receiving approval from the PMC, a Project representative makes a request to the EMO to schedule the Review.
The EMO announces the Review schedule and makes the documentation available to the Membership at Large.
The EMO approves or fails the Review based on the feedback, the Scope of the Project, and the Purposes of the Eclipse Foundation as defined in the bylaws.
The Review documentation requirements, and criteria for the successful completion of each type of Review will be documented by the EMO. PMCs may establish additional success criteria.
The Review period is open for no less than one week and usually no more than two weeks. The Review ends with the announcement of the results in the defined Review communication channel.
If any member believes that the EMO has acted incorrectly in approving or failing a Review may appeal to the Board of Directors to Review the EMO’s decision.
The purpose of the Creation Review is to assess the community and Membership at Large response to the proposal, to verify that appropriate resources are available for the Project to achieve its plan, and to serve as a Committer election for the Project’s initial Committers. The Eclipse Foundation strives not to be a repository of "code dumps" and thus Projects must be sufficiently staffed for forward progress.
The Creation Review documents must include short nomination bios of the proposed initial Committers. These bios should discuss their relationship to, and history with, the incoming code and/or their involvement with the area/technologies covered by the proposal. The goal is to help keep any legacy Contributors connected to new Project and explain that connection to the current and future Eclipse Membership at Large, as well as justify the initial Committers' participation in a meritocracy.
The purpose of the Graduation Review is to mark a Project’s change from the Incubation Phase to the Mature Phase.
The Graduation Review confirms that the Project is/has:
A working and demonstrable code base of sufficiently high quality.
Active and sufficiently diverse communities appropriate to the size of the graduating code base: Adopters, Developers, and users.
Operating fully in the open following the principles and Purposes of Eclipse.
A credit to Eclipse and is functioning well within the larger Eclipse community.
A Graduation Review is generally combined with a progress or Release Review.
The purposes of a Progress Review are: to summarize the accomplishments of the Project, to verify that the IP Policy is being followed, to highlight any remaining quality and/or architectural issues, and to verify that the Project is continuing to operate according to the principles and Purposes of Eclipse.
The purpose of a Termination Review is to provide a final opportunity for the Committers and/or Eclipse Membership at Large to discuss the proposed archiving of a Project. The desired outcome is to find sufficient evidence of renewed interest and resources in keeping the Project active.
The purpose of a Restructuring Review is to notify the community of significant changes to one or more Projects. Examples of "significant changes" include:
Movement of significant chunks of functionality from one Project to another.
Modification of the Project structure, e.g. combining multiple Projects into a single Project, or decomposing a single Project into multiple Projects.
Change of Project Scope.
Reviews can be combined at the discretion of the PMC and EMO. Multiple Projects may participate in a single Review. Similarly, multiple Review types can be engaged in simultaneously. A parent Project may, for example, engage in an aggregated Progress Review involving itself and some or all of its child Projects; a consolidated Restructuring Review may move the code for several Projects; or a Progress Review may be combined with a Graduation Review. When multiple Reviews are combined, the Review documentation must explicitly state all of the Projects and types of Reviews involved, and include the required information about each.
It should be noted that the purpose of combining Reviews is to better serve the community, rather than to reduce effort on the part of the Project (though it is fortunate when it does both). Combining a progress and Graduation Review, or aggregating a Progress Review of a Project and several of its child Projects generally makes sense. Combining Progress Reviews for multiple unrelated Projects most likely does not.
Any Project, with exception of Permanent Incubators, may make a Release. A Release may include the code from any subset of the Project’s descendants.
(Most of this section is paraphrased from the excellent Apache Software Foundation Releases FAQ. The Eclipse community has many of the same beliefs about Releases as does the Apache community and their words were already excellent. The Apache Software Foundation Releases FAQ is distributed under the Apache License, Version 2.0.)
Releases are, by definition, anything that is distributed outside of the Committers of a Project. If consumers are being directed to download a build, then that build has been released (modulo the exceptions below). All Projects and Committers must obey the Eclipse Foundation requirements on approving any Release.
The Eclipse IP Policy must be followed at all times. Prior to issuing any Release, the Project Lead must assert that the IP Policy has been followed and all approvals have been received.
The Project Team must provide (either directly or indirectly) a link between the distribution form of Release artifacts and the corresponding source code.
A Project can make official Releases for one calendar year following a successful Progress Review or Release Review. The Project Leadership Chain may—at its discretion—require that the Project engage in additional Reviews (e.g. a progress or Release Review) prior to issuing a Release.
Exception 1: Nightly and Integration Builds During the process of developing software and preparing a Release, various nightly and Integration Builds are made available to the Developer community for testing purposes. Do not include any links on the Project website, blogs, wikis, etc. that might encourage non-early-adopters to download and use Nightly Builds, Release Candidates, or any other similar package (links aimed at early-adopters and the Project’s Developers are both permitted and encouraged). The only people who are supposed to know about such packages are the people following the Developer mailing list and thus are aware of the limitations of such builds.
Exception 2: Milestone and Release Candidate Builds Projects are encouraged to use an agile development process including regular Milestones (for example, six week Milestones). Milestones and Release Candidates are "almost Releases" intended for adoption and testing by early-adopters. Projects are allowed to have links on the Project website, blogs, wikis, etc. to encourage these outside-the-Committer-circle early-adopters to download and test the Milestones and Release Candidates, but such communications must include caveats explaining that these are not official Releases. Milestones and Release Candidate builds must be labeled as such (e.g.
x.yRCn, alpha, beta, or similar).
Exception 3: Service Releases with no new features Service Releases with no significant changes or additions over the base Release are allowed to be released without an additional Review.
Under no circumstances are builds and Milestones to be used as a substitute for doing proper official Releases. Proper Release management and Reviews is a key aspect of Eclipse quality.
Releases and corresponding artifacts for Projects in the Incubation Phase must be labeled to indicate the incubation status of the Project. See Incubation Branding for more information.
When a member has a concern about a Project, the member will raise that concern with the Project’s leadership. If the member is not satisfied with the result, the member can raise the concern with the parent Project’s leadership. The member can continue appeals up the Project Leadership Chain and, if still not satisfied, thence to the EMO, then the executive director, and finally to the Board of Directors. All appeals and discussions will abide by the guiding principles of being open, transparent, and public.
Member concerns may include:
Out of Scope. It is alleged that a Project is exceeding its approved Scope.
Dysfunctional. It is alleged that a Project is not functioning correctly or is in violation of one or more requirements of the Eclipse Foundation Development Process.
Contributor appeal. It is alleged that a Contributor who desires to be a Committer is not being treated fairly.
Invalid veto. It is alleged that a
-1vote on a Review is not in the interests of the Project and/or of Eclipse.
A variety of grievance resolutions are available to the EMO up to, and including, rebooting or restarting a Project with new Committers and leadership.
In the event of a conflict between this document and a Board of Directors-approved Project charter, the most recently approved document will take precedence.
As specified in the Bylaws, the EMO is responsible for maintaining this document and all changes must be approved by the Board of Directors.
Due to the continued evolution of the Eclipse technology, the Eclipse community, and the software marketplace, it is expected that the Eclipse Foundation Development Process (this document) will be reviewed and revised on at least an annual basis.
The EMO is further responsible for ensuring that all plans, documents and reports produced in accordance with this development process be made available to the Membership at Large via an appropriate mechanism in a timely, effective manner.
Changes made in this document:
Mentions of "Eclipse Development Process" changed to "Eclipse Foundation Development Process" #2
"Meritocracy" changed to "Meritocratic" in the Open Source Rules of Engagement to be more consistent grammatically with “Open” and “Transparent”
Fixed bogus references to the Bylaws. Specifically removed a quotation of an older version of the Purposes defined in the Bylaws. #6
Added section 3.1 which extends the options available to the EMO to mitigate the situation when committers fail to perform required behaviours or engage in practices that risk harm to an Eclipse project. Previously, the only option available to the EMO was to terminate the project #12
All references to the parallel IP Process
The "Revision" section (formerly 8.1) that had indicated the board meeting in which the specific revision was approved (this is is inconsistent with how we treat other documents).
Document title changed to "Eclipse Foundation Development Process" to make it consistent with other documents.
Section 4.7 renamed from "Committers" to "Committers and Contributors"
In section 4.7, the reference to "submitters" changed to "Contributors"
All references to the Eclipse Planning Council have been removed
The entire section 4.8, which quoted text from the bylaws regarding councils has been removed (the "Terms" section covers this)
A reference to the bylaws was added in the definition of the Eclipse Architecture Council.
A separate section that formally defines key terms has been added.
The notion of a Progress Review added to augment (and in some cases, replace) Release Reviews (Bug 496321).
Added a requirement that the Project Team must provide (either directly or indirectly) a link between the distribution form of Release artifacts and the corresponding source code.
A CHANGELOG based on "keep a changelog" https://keepachangelog.com/
Removed redundant restriction that Permanent Incubators cannot participate in the simultaneous release (they can’t release at all).
Removed discussion regarding specific labeling of Milestones and Release Candidates (replaced with an simple statement that Milestones and Release Candidates must be labeled as such with examples)
Converted document source format to Asciidoctor.
The time period for votes and reviews is expressed in terms of simple weeks rather than "one week of generally accepted business days" which is unnecessarily complicated.
Removed the unnecessary statement that "Major releases continue to go through release reviews." from the description of the Mature Phase.
Content in the Releases section has been reorganized.
Release Reviews have been recast as a special type of Progress Review.
The requirement that a project engage in a Release Review prior to a release has been changed to a requirement that project can only release within a year of successfully engaging in either a Progress Review or a Release Review. Further, the Project Leadership Chain is granted the ability to compel a project to engage in a Progress Review.
The requirement that the "the IP Policy has been followed and all approvals have been received" has been moved from being a requirement of a Release Review to being a requirement of a Release. This is a bit subtle, but important given that with the introduction of a Progress Review a project may issue Releases without engaging in a Release Review.
Content in the Releases section has been reorganized so that the three exceptions are grouped followed by the discussion regarding milestones.
The notion "public comments" has been generalized to "feedback" in the Reviews section (Bug 538613).
Change the title of section 2.3.1 to "Developers", and section 4.7 to "Committers" (Bug 484587).
References to "Bug fix Releases" changed to "Service Releases" in the Releases section.
Make the process of retiring/removing project members explicit (Bug 376001).
Streamline review requirements (Bug 415620).
Rewrite the section on requirements to be more clear and succinct (Bug 416185).
Appointed members of the Architecture Council are appointed to two (Bug 418208) year renewable terms.
Include "Freedom of Action" requirement in the EDP (Bug 471367).
Generalize the expected output of projects (Bug 477238).
Include definitions of terms required by other legal documents (Bug 480526).
Only one mentor required for an incubating project (Bug 463850).