Jump to: navigation, search

Development Resources/HOWTO/Starting A New Project

Code is very important at Eclipse. All Eclipse projects are expected to have code. But the responsibilities of an Eclipse project extend far beyond having code in an eclipse.org repository. Eclipse projects are responsible for developing a community of users, adopters, and contributors.

Before you bring your project over to Eclipse, you must have useful code and the beginnings of a community. Eclipse Labs provides a great place to host your project during this formative period. In fact, depending on the nature of your project, Eclipse Labs may be the right place to host your projects in perpetuity. If it is your intent to one day move the project to Eclipse, you should take the time to familiarize yourself with our processes to avoid surprises downstream (e.g. you should consider carefully tracking all contributions to the project).

Eclipse projects are expected to take necessary precautions to mitigate the risk to adopters; a company that integrates the code from your Eclipse project, for example, does so with confidence that the code in your project can legally be distributed under the agreed-to terms. The processes that we have in place are designed to support this. Ensure that you are familiar with the Eclipse Development Process (EDP), Eclipse IP Policy, and IP Due Diligence Process.

The EDP is mostly about community involvement. An Eclipse project is considered successful only if a vibrant community develops around it. While the reviews and processes described by the EDP may seem onerous, they are a necessary part of community development. You should anticipate spending a significant amount of time responding to questions posed in various forums (Eclipse Forums, mailing lists, or even Stack Overflow). You should plan on attending conferences (especially Eclipse Summit Europe and EclipseCon), presenting webinars, writing papers, etc to support your project.

There is tremendous value in the Eclipse IP Policy, but that value comes at a cost. It is important that you understand what is involved. Code provenance tracking is critical (we need to know the source of all code that ends up in our repositories). To that end, all new projects are required to make an initial contribution before any code is committed to an Eclipse source code repository (one implication of this requirement is that we assume that a new project starts from pre-existing code). The Eclipse IP Team will review your initial contribution to ensure that the code can distributed through an eclipse.org property. In effect, we review to code to make sure that it hasn't been copied inappropriately, that licenses are being used correctly, and so forth. As part of this process, the IP Team will research the source of all code; depending on the size of your contribution, this can be a time-consuming process. Furthermore, any third-party libraries required by your code will have to be checked and approved by the IP Team. As an Eclipse project you are expected to maintain an IP Log containing (among other things) information about all contributions and third-party libraries; you are required to submit this log for review and approval as part of the release process.

A project cannot make a release until the due diligence on the IP contained in that release is complete. Please review the Initial Contribution page for more information.

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

Here are some other links that should help you with the process:

This should sound like a lot of work. For many projects, the investment is worthwhile.

Overview of the Project Creation Process

ProjectCreation.png

  1. Use the provided Proposal document Template to assemble a proposal. Note that instructions are provided within the document. Send the completed draft of the proposal to the EMO.
    • The EMO will review the document and provide feedback. If there are timing issues with respect to "going public" let the EMO know (we can, for example, coordinate the public disclosure of the proposal with your marketing efforts).
    • The EMO will post a draft copy and request your feedback on the "live" version. At the same time, the EMO will open a bug against Community/Proposals and Reviews to track the proposal.
  2. The proposal will be posted for community review
    • It will appear on the "What's New" page.
    • If necessary, the EMO will request mentors from the Architecture Council via Bugzilla.
    • After we've posted the proposal, we need to let it sit for a minimum of two weeks to let the community review it. During that period, you should try to get as many people to look at the proposal and comment as possible. You should use this time to identify interested parties.
    • After that minimum two-week period, you can request a creation review.
  3. The EMO will initiate a 'trademark search on the project name.
    • The creation review cannot be started until after the trademark of the project name is secured
  4. Once the trademark search has been resolved, we'll schedule the creation review to run for a one-week (Thursday to Wednesday) period.
    • By this point, the review should really just be one more week for people to ask questions and comment.
    • Creation reviews tend to always be successful (they should be considered low stress as the hard work has already been done).
  5. When the review is declared successful, you'll be invited to provide provisioning information
    • the webmaster and IP team will use this information to provision space on our servers, create committer records, etc.
  6. When provisioning is complete, you can submit your initial contribution to the IP team for review
    • The IP team must give you approval before anything can be committed to any Eclipse VCS or download server. Your mentors can help you at this stage.
  7. With IP Team approval, you can push your initial contribution to Git
  8. You're off to the races
    • Projects must create a plan at the beginning of each development cycle
    • Projects must engage in a release review for all major/minor releases
    • Project committers are expected to abide by the terms of the Eclipse Development Process

Be sure to lean on your mentors for help, or for answers to questions. Make use of them, that's what they're there for.

After Creation

Before you commit any code into your eclipse.org repository, you must submit your project's initial contribution for review by the IP team.

Your project will start in the Incubation phase. Ensure that your project conforms to incubation branding requirements and you can take advantage of the parallel IP process.

Ongoing Responsibilities

Community development is a big part of life at Eclipse. It is strongly recommended that you identify somebody on your team to be responsible for community development activities. To cultivate a vibrant community of users, adopters, and committers, a project has to have somebody who is responsible for community development. Somebody has to own it. Everybody on the project team has to dedicate some significant amount of their time to community development, but one person on the team has to be responsible for it. For some projects, this may be a full time job; for others, it may be a huge part of one. In fact, may open source projects have more than one full time person working on community development. In some circles, this role might be called the project's evangelist, or maybe it's the project lead that manages community development. Whatever the title, the role should be that of making everybody else successful in community development activities. Please see Community Development for Eclipse Projects.

Projects must conform to the legal documentation requirements, naming conventions, and version numbering rules.

Projects must maintain their metadata. This information is used to drive our automated processes. Kept up-to-date, project metadata can reduce your overall project maintenance burden by allowing our automated processes (e.g. project summary pages, project summaries, Dash data, etc.) to generate and disseminate correct information about your project.

Before an Eclipse project can release any software, they must undergo a release review. This is a well-defined formal process.

Projects in the incubation phase can only do pre-1.0 releases (e.g. 0.7). Before creating a >=1.0 release, a project must undergo a graduation review and enter the mature phase. A graduation review is typically combined with a release review. Note that a project may make 1.0 milestone releases (e.g. 1.0.0M1) in the time leading up to their graduation review. Note also that projects may select a >1.0 number for their first Eclipse release if that makes sense for the project and their community (you might consider this if your already-established project has moved to Eclipse).

If you have any questions, or are unsure of your responsibilities as a project lead or committer, please contact your project mentors or EMO.

Reference Material

Here are some valuable links:

This page is moderated by the EMO.