Why the Eclipse Research Labs
Creating an Eclipse project is a process pretty well described in the Eclipse Development Process handbook (https://www.eclipse.org/projects/handbook/).
You start with a proposal describing your project, the content of the code, the license used, the project leader and the first committers. The proposal is made available to the community for review. At the end of the community review period, the creation review begins with a brand review and mentor assignment. Then the project is created and provisioning can begin. Thus, the Eclipse teams move the code, listed in the proposal, under the Eclipse Foundation infrastructure, and the legal team checks the validity of the committers' papers. Once this step is validated, the project team can resume development of its code under the Eclipse umbrella even if the IP review is not done. Indeed, while the team is still developing, the IP team analyzes the code and its dependencies to identify potential problems: missing copyrights, copying code, or incompatible licenses between dependencies or with the license selected by the project. Finally, once the intellectual property review is complete, the initial contribution is released. It can be safely shared with the rest of the world.
For a single organization, contributing a single piece of code, this is fairly straightforward and takes between 2 weeks and 2 months. But as soon as it is a large piece of code and/or many contributors from different organizations, which is the case for a research project, this exercise can take a lot of time and effort. In a such context, the Eclipse Foundation has found that this can greatly slow down the project, which is not really desirable as such a task usually occurs in the last few months of the research project.
Some of the research projects in which the Eclipse Foundation is involved have been able to pass the initial contribution stage, then pass the intellectual property review, and even have their first release during the course of the project. The projects in question were managed by active members of the Eclipse Foundation with extensive experience in the Eclipse development process.
Unfortunately, at present, these are more the exceptions than the rule, mainly because (1) it is difficult to consistently have such a champion in a consortium (2) it is difficult to motivate ALL partners to collaborate openly. It only takes one passive partner to slow down the whole process.
For this reason, the Eclipse Foundation has adapted its Eclipse development process to research projects by creating an "intermediate chamber", the Eclipse Research Labs.
The Eclipse Research Labs added values
The purpose of this Research Labs is multiple: First, it provides an open infrastructure for the consortium to learn to collaborate openly, which is one of the pillars of open source best practices. Indeed, open collaboration is not always obvious in a research project. Partners are used to developing in their own environment, using their own development process, and only integrating their code once it is ready. This approach goes against one of the good practices of open source, which recommends integrating often and soon. This good practice also recommends automating the process with continuous testing and integration scripts to identify bugs or broken APIs as early as possible. Offering such an open infrastructure will allow to "Drive with open eyes", as the Eclipse development teams define it in "The Eclipse Way process" (https://slideplayer.com/slide/4828984/).
Second, it encourages the consortium to work openly. Often, some partners are shy, convinced that their code will be reviewed and criticized by external stakeholders. Open development allows them to realize that their code is in the middle of hundreds of millions of public repositories and, unless they reference and mention the relevant repositories, there is very little chance that anyone will find their code. Working openly means expressing your development plan clearly and openly throughout the process. It also means expressing your decisions clearly and transparently and avoiding drowning them in internal emails.
Third, it allows to identify and list from the beginning the contributors to the research project. Indeed, unless he has signed the Eclipse Contributor Agreement, a member of the Research Labs cannot push code in the Eclipse Research Labs repositories. This constraint allows to list all the contributors of the research project and especially helps the research project to know that all the contributors have signed the contributor agreement (https://www.eclipse.org/legal/ECA.php) which is in fact a Developer Certificate of Origin (DCO) thus protecting the other partners and the future adopters in the use of the resulting open source project.
Fourth, it helps the Eclipse partner analyze shared code as early and as often as possible to identify potential intellectual property issues, such as missing copyright headers in source files or third-party dependencies with incompatible licenses. In the first case, Eclipse can take care of the copyright by providing templates for use in the code. In the second case, the code owner has some time to find another library with a compatible license or to contact the library owner and ask him to provide a new version based on a business-friendly license. Last but not least, it promotes other interesting side effects: The development of the research project is not slowed down The research project works immediately under the Eclipse umbrella. The research project becomes familiar with the tools and interlocutors of the Eclipse ecosystem. The research project has more time to experiment and define the scope of the resulting Eclipse project(s) and thus decide if the whole project should or can be an Eclipse project or if only certain mature components, the "golden nuggets", can The research project creates its Eclipse project(s) when it is ready to do so. The creation followed by the IP review is done quickly because all the input data is ready and, for the most part, validated.
The Eclipse Research Labs process
You can consider the Eclipse Research Labs as an intermediary "chamber" with 3 phases:
Phase 1: The research consortium selects the parts of the project architecture that they want to open source. These parts are immediately moved to the Eclipse Research Labs.
Phase #2: The contributors are identified and/or designated and they are asked to sign electronically the Eclipse Contributor Agreement. Once the contributor has signed, he can immediately starts working on his code under the Eclipse umbrella. During this phase, the project can add any new contributors and also retrieve previous contributors who are not part of the project but who have contributed to the code. Last, not least, the project can list all third-party dependencies and identify any potential problems and take the time to resolve them.
Phase #3: Finally, step by step, during phase #2, the project is able to gather all the contribution agreements and get rid of any compatibility issues with the chosen license. Thus, the creation of the Eclipse project is only a formality in this phase. Golden nuggets Another advantage of this intermediary "chamber" is that we have noticed that a research project is based on several pieces of code that have not reached the same level of maturity at the end of the project. By having this intermediate "chamber", we can finally decide, which parts we keep in the Eclipse Research Labs and which part we want to grow into one or more Eclipse projects. This way, you don't have to push the whole project. You only push those parts that are sufficiently mature and ready to be maintained as well. This last point is very important.
Timeframe
Here is the kind of timeframe we can obtain:
In other words, we believe that with this approach, we can achieve the goal of creating an open source software project. The schedule is just different from what was planned. Instead of targeting M12, we should target M30. At this point, we will have enough information to know which parts of the project we really want to make an Eclipse project with and who is willing to maintain them.
The other components will, of course, remain accessible and open in the GitHub Eclipse Research Labs organization.