30 October 2024

Greg Watson

1. Introduction

This document, written as part of the work of the Center for Open-Source Research Software Stewardship and Advancement (CORSA), describes the information that a particular software project needs to collect/have in order to apply to and then join Eclipse Foundation. Much of the content in this document comes from Eclipse Foundation documents.

The Eclipse Foundation provides a global community of individuals and organizations with a mature, scalable, and vendor-neutral environment for open source software collaboration and innovation. Its focus is to create an environment for successful open source projects and to promote the adoption of Eclipse technology in commercial and open source solutions. Through these services, the Eclipse Foundation provides communities with a proven model for open source development:

Some additional benefits from joining a foundation are discussed in Section 5 of Watson, et al., 2023.

2. Relationships with Eclipse Foundation and basic requirements

The Eclipse Foundation Development Process (EDP) is the foundational document for Eclipse projects and committers. It describes the manner in which they do open source software. The EDP does not prescribe any particular development methodology; it is more concerned with the larger-scale aspects of open source project life cycle, including such things as reviews, processes for running votes and elections, bringing new committers onto a project, etc. This document elaborates on some key points of the EDP.

The EDP follows the Open Source Rules of Engagement:

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.

The Open Source Rules of Engagement define a foundation for vendor neutral open source development. Vendor-neutrality is concerned with maintaining a level playing field that is open to all comers: no vendor is permitted to dominate a project, and nobody can be excluded from participating in a project based on their employment status.

3. Application requirements

When you move your project to the Eclipse Foundation, it becomes an Eclipse project. Specifically, it ceases to be your project and becomes a vendor-neutral community project that operates under the governance of the Eclipse Foundation.

This means, for example, that the open source project name and the names of any products produced by the project will be trademarks (either registered or common-law) of the Eclipse Foundation and you are required to follow the same trademark guidelines as everybody else when you refer to the project. If you were to, for example, contribute the “Woolsey” product to the Eclipse Foundation, you would be required to transfer all rights that you have to the name “Woolsey” to the Eclipse Foundation, and the use of the “Woolsey” name in your products, website, marketing materials, etc. would be then be subject to the trademark guidelines (you would be required to rename your products from “Woolsey” to “[Product Name] for Eclipse Woolsey” or similar).

If the name important to your organisation, consider choosing a different name for the Eclipse open source project.

It’s also important to know what new projects don’t give up. The project team retains control of the project’s direction by virtue of regular contribution to the project. The contributors to the project retain ownership of their contributions (those contributions are used under license by the project). Project leads are required to ensure that other individuals who present themselves to the project are given uniform opportunity to participate, but the project team gets to establish the rules for participation (within certain parameters). The project team is responsible for determining development methodology, establishing plans, etc. Existing owners of the project code retain their ownership

4. Joining requirements

Eclipse open source projects start with a proposal that must minimally include a description of the project, a declaration of scope, and a list of initial members (project leads and committers). The Eclipse Management Organization (EMO) will review the proposal and may provide feedback before initiating a community review period for a minimum of two weeks. At the beginning of the community review period, the EMO will announce the proposal on several channels (the Project Activity News page, Twitter, blog post, and an email note to the Eclipse Foundation members and committers). The EMO will also open a record in the Eclipse Foundation’s issue tracker — an instance of GitLab — to track the progress of the proposal; the proposal’s author, and project leads will be copied on that record. At the end of the community review period, Eclipse will undertake a creation review, and then provision the project resources.

A new project proposal can be created using a web form. Instructions are provided on the form. All new proposals are created in draft mode, and are accessible only by the original author and anybody designated as a project lead or committer in the proposal. Only those individuals designated as a project lead may edit the proposal.

When making the decision to initiate the creation review that will turn the project proposal into an Eclipse open source project, the EMO will consider the following:

Scope: Does the project have a technology scope and focus which will have a reasonable likelihood of success? Projects that are too big will definitely fail; projects that are too small are unlikely to be interesting.

Clear and Concise Description: If the community found any aspects of the proposal confusing, unclear, or using unfamiliar jargon, those areas must be clarified. This is a hard and fast requirement: because the Eclipse community must be able to evaluate the proposal. To do that, they must be able to understand the proposal and thus it must be clear and straightforward and free of marketing-speak.

Committers : The creation review serves as the new committer election for the initial Committers and thus the proposal must contain the same level of nomination justification and background as an election would. The committer biographies don’t have to be long or involved, but they should describe each committer’s relationship to and history with the incoming code, and/or involvement with the area or technologies covered by the proposal.

The project must have sufficient committed developers to achieve its goals. The Eclipse Foundation is not a place to “abandon in public” code; rather, the Eclipse Foundation strives to have active projects with active communities and thus enough developers to move the project along.

Communities: Does the project have a community of contributors and users, outside the core developers, who are willing to work towards making this a success? This is a bit of a Catch-22 situation because it is sometimes hard to attract a community before any milestones or releases, but it is also true that projects with limited developers and even fewer users tend not to have much technical impact.

Collaborations: Successful Eclipse projects are those that collaborate with existing Eclipse, or other open source, projects. Again, it can be hard to start a collaboration before demonstrating the technology, but at the same time it is never too early to start discussing collaborations with other projects. Additionally, it never hurts to join and help an existing project to start establishing those social networks that will make future collaborations on the new project possible.

Sufficient Time for the Community: Project proposals are held in community review for a minimum of two weeks. Anything less than two weeks of general accepted business days does not give the Eclipse membership sufficient notice of new initiatives.

Diversity: Is this a single company project or a multi-organization effort? If all the committers and contributors are in the same organisation or have financial ties to the same organisation, the project is at a greater risk of being de-staffed. Brand new projects are not required to be diverse, but projects cannot graduate from the incubation phase without appropriate diversity.

Trademarks: The Eclipse Foundation holds the trademark for all Eclipse projects. Trademark assignment is undertaken prior to the creation of any new project. If you already have a trademark on your project name, that trademark must be assigned to the Eclipse Foundation. Be advised that trademark assignment can be a time-consuming process (it can take hours, days, or weeks depending on the circumstances surrounding the name). If you currently hold the trademark, you will be asked to complete a Trademark Transfer Agreement.

When the project name trademark has been secured and the proposal contents are finalised, the EMO will schedule a creation review.

5. The project as a part of Eclipse Foundation

Once a part of the Eclipse Foundation, a project will be subject to the EDP. All Eclipse open source projects start in the incubation phase, and are expected to graduate into the mature phase. Eclipse open source projects will spend most of their existence in the mature phase. The intention of the incubation phase in the EDP is to establish a fully-functioning Eclipse open source project by focusing on developing the process, the community, and the technology. This phase is not about the quality of the project’s content, but rather about the project team’s progress in practising the open processes necessary to establish communities of developers, adopters, and users around the project.

Projects that have questions about foundations are welcome to contact CORSA by emailing PI Greg Watson. And those with questions that are specific to Eclipse Foundation should use the contact link on its website.