Incubation in the Eclipse Foundation Development Process

By Wayne Beaton

Becoming an Eclipse open source project is a process, not an event: it may take your new open source project weeks or months to various adopt the principles, processes, and practices that the community have come to expect Eclipse open source project teams to follow and implement.

All new Eclipse open source projects start in the incubation phase; it is during the incubation phase that teams learn to be an Eclipse open source project. Incubation is designed to ensure projects:

• Adopt core Eclipse principles (openness, transparency, meritocracy);
• Successfully integrate with Eclipse legal and IP processes; and
• Establish sustainable community and security practices.

Let’s back up a bit. The Eclipse Foundation Development Process describes the phases of the Eclipse open source project life cycle.

Pre-proposal Phase. The pre-proposal phase is basically a non-existence phase. During the pre-proposal phase, you will assemble a project proposal that contains information about the project’s goals, identifies the initial list of committers (maintainers) and project leads, identifies issues or concerns, and otherwise informs the community about the project. During the pre-proposal phase, the proposal is kept private to you and your team. During the pre-proposal phase, the EMO will help you prepare the proposal, and – when everyone is ready – move the project into the proposal phase by publishing the proposal document and announcing it to the community.

Proposal Phase. During the proposal phase, the EMO works with your project team and community to provide feedback and gather all of the information that we need to create the project. When the project team is ready, we create the new open source project, engage with your committers to make sure that we have agreements in place, provision resources, and work with the project team to transfer their existing code and practices over to the Eclipse Foundation. At this point, your open source project enters the incubation phase.

Incubation Phase. The incubation phase serves as an onboarding period where your project team learns and adopts the principles and practices of the Eclipse Foundation Development Process. After establishing itself as a functioning Eclipse open source project, the project graduates into the mature phase. Note that the incubation phase is concerned with project teams adopting open source practices that are consistent with the Eclipse Foundation Development Process; the concept of incubation is related to code quality or stability: a project that has stable code base starts in incubation when it is moved to the Eclipse Foundation.

Mature Phase. Your Eclipse open source project will spend most of its lifetime in the mature phase, after your project team “learns the ropes” in incubation.

Archived Phase. During the archived phase, the project is, well… archived. When an Eclipse open source project has reached the end of its life cycle or is no longer sustainable, it may be terminated and archived.

Having established the project’s formal status, the following practices are the core responsibilities that every project team must diligently implement during the incubation phase to ensure a successful path to the mature phase.

Incubation Practices

Always remember that onboarding the project as an Eclipse open source project is a process not an event. Everyone knows that your project team won’t get everything right on day one. Steady progress is the name of the game.

While the project is in the incubation phase, your project team will engage in the following practices.

Collaboration and Governance

Operate transparently. Operating transparently is an early step in adopting open collaboration practices. Move your issue tracking into the public issue trackers provided for the project by the Eclipse Foundation. Use your issue tracker to create issues for features that you are implementing anyway.

Operate openly. Develop a habit of using public issues to discuss features, bugs, and other project level discussions. Learn to frame discussions in a manner that invites others to participate.

Operate meritocratically. Provide an environment in which others can contribute and develop a reputation. This is tightly coupled with operating transparently and openly. Make growing your communities a priority: set up the project to encourage contributions (pull/merge requests) and be prepared to interact with contributors and accept (merge) contributions. Help contributors develop reputation and elect them as committers. Ensure that meritocracy is based on the contributions of an individual, not the goals or hiring practices of any specific organisation.

Operate in a vendor-neutral manner. Vendor neutrality is the natural consequence of operating transparently, openly, and meritocratically. A sure sign that a project is operating in a vendor-neutral manner is having committers and contributors who represent the interests of more than one organisation.

Give up absolute control. When you move the project to the Eclipse Foundation, it ceases to be yours alone. Sharing control with the other developers who “show up” is an important part of growing a community around the project.

Technical and Infrastructure

Use infrastructure provided by the Eclipse Foundation. Switching from internal development to working in the open can be challenging. It will be tempting for project teams who are not already familiar with open collaboration to continue development using internal resources and periodically pushing content out to the Eclipse project repository.

During the incubation phase, project teams must learn to collaborate in the open; developers must get used to pushing their commits directly to the project’s source code repositories and contributors – even those that work for the same company as project committers – need to get used to interacting with the project via pull requests; and everybody needs to learn to communicate both short and long term plans through public issues and other public resources.

Making it so that people who are outside of the core development team have the ability to access the most up-to-date version of the project code is an absolute requirement. To that end, your committers must push content directly into designated open repositories. Eclipse project committers must never stage to a private or semi-private repository and then periodically sync to the open repository; employing this sort of strategy raises a significant barrier for entry that makes it impossible for anybody else to participate.

Provide project metadata and legal documentation. All members of the various communities that grow around the project expect to find a README file in the repository root with information about the project. The community will also expect to find a CONTRIBUTING file that describes how to contribute to the project (e.g., what branches are active, how to build, that an ECA is required by contributors, etc.). It’s also become standard to expect that Git repositories have a LICENSE file in the root that contains the full text of the project license.

The absolute low bar with regard to community development is to provide basic legal documentation for the project.

When technically feasible, include a copyright and licence header in all source files.

Release software. Projects in the incubation phase can issue major, minor, and service releases. Engage in at least one release while the project is in the incubation phase. Traditionally, a project in the incubation phase numbers their releases < 1.0 (e.g. “0.7”), but there is no requirement to do so.

Compliance and Risk Management

Engage in the Eclipse Intellectual Property (IP) Due Diligence Process. We set new Eclipse open source projects up for some early success: the IP Team will automatically engage in a due diligence review of the project’s initial contribution shortly after you move it in the project’s source code repositories, and will engage with the project leads if their investigation uncovers issues that require discussion. The EMO also ensures that committers and contributors are covered by agreements that ensure that the project is able to receive contributions under terms that are consistent with the project’s licence and the open source model.

During the incubation phase, the project’s committers will learn to initiate IP and vulnerability reviews for third party components (e.g., libraries that the project’s adopters require to use the code).

The IP due diligence process provides flexibility for projects while they are in the incubation phase; the implication being that there may be some modest increase in intellectual property-related risk (especially when combined with a new development team who don’t yet live and breathe the Eclipse IP Policy).

Establish security and vulnerability management practices. During the incubation phase, the project team will adopt processes for identifying, reporting, and responding to vulnerability reports and other security concerns (e.g., build chain security). Your team will build a relationship with the Eclipse Foundation’s Security Team and gain familiarity with how we manage vulnerabilities and work with the Security Team to publish official Common Vulnerabilities and Exposures (CVE) reports.

Engage in a successful progress review. As the name suggests, a progress review is the means by which the EMO and PMC check in on projects to see how they are progressing. Especially when a project is in the incubation phase, we’re looking for progress in adapting your practices to align with principles, processes, and practices that are consistent with open collaboration at the Eclipse Foundation.

Graduation

Graduate into the mature phase. The project can’t stay in the incubation phase forever: plan your graduation into the mature phase. The project is probably ready for graduation when your project team has demonstrated that they’re working in an open, transparent, and meritocratic manner; are otherwise engaged in activities that foster vendor neutrality; are faithfully engaging in the IP due diligence process and healthy security/vulnerability management; have engaged in a progress review; and are distributing software.

Key graduation requirements and their primary goal:

Graduation is a significant event and worthy of celebration. We’ll celebrate with you.

Incubation Branding

That a project is in the incubation phase serves, in part, as a flag for adopters and the community at large that the project team is still learning the ropes; it serves as a flag to adopters that the project team may not be correctly implementing the Eclipse Foundation’s intellectual property due diligence process, or may not be yet be operating in a fully vendor-neutral manner per the Open Source Rules of Engagement. This ensures adopters are aware that while the project is active, the IP review process (for third-party components, for example) is still being internalised by the new team.

Incubation is an invitation to potential adopters to take a closer look and take a little extra care before incorporating the project’s content into their products.

Incubation branding is one way that we ensure that adopters understand the project’s incubation state. Primarily, this takes the form of displaying the incubation logo in prominent locations, including the project’s major web properties and including the word “incubation” or warning that products shipped as part of a release may include incubating components.

Incubating branding includes:

• Display the incubation logo on the project web page;
• Display the incubation logo on the project’s primary download page;
• Include the word “incubation” in the filename of all downloadable files (when technically feasible) for builds; and
• When technically feasible, include the word “incubation” in features (e.g. about dialogs, feature lists, and installers).

There are no incubation branding requirements for any user-facing elements.

Conclusion

The incubation phase is a critical onboarding period for new projects at the Eclipse Foundation, designed to ensure project teams successfully adopt the fundamental principles of open, transparent, and meritocratic collaboration, alongside essential practices like vendor neutrality, use of Eclipse infrastructure, compliance with IP due diligence, and establishment of security protocols. It is a time for learning and demonstrating commitment to the Eclipse Foundation Development Process, with progress reviews and the requirement to release software serving as milestones. The incubation phase signals this transitional status to the broader community and adopters, underscoring that while the project is active, it is still maturing in its adherence to all governance standards before achieving the full confidence and stability associated with graduation into the mature phase.

Please also see Running a Successful Open Source Project

We’ve created this issue as place to post comments and discuss this article. If you have questions about Eclipse Project Governance, contact emo@eclipse-foundation.org.