From Idea to Eclipse Project: How to Write a Strong Project Proposal

By Maria Teresa Delgado

If you’re considering bringing an open source project to the Eclipse Foundation, one of the first steps is preparing a project proposal. The proposal is the starting point for introducing your project, its scope, and its community to the Eclipse Foundation.

The proposal gives the Eclipse community, the Project Management Committee (PMC), and the Eclipse Management Organization (EMO) a chance to understand your project before it is created.

It doesn’t need to document everything your project will ever do. In fact, clear and concise wording is usually better.

During the proposal phase, the EMO reviews proposals and works with project teams to get them ready for community review. We tend to look for the same things: a clear purpose, a well-defined scope, an appropriate project name and home within the Eclipse Foundation, and enough context to understand who is behind the project and where it fits.

Here are some tips to help you get those things right.

This article focuses on proposals for EF projects. Many of the general tips also apply to specification projects, but these follow a different proposal process. If you’re preparing a specification project proposal and have questions, reach out to the EMO: we’ll be happy to guide you!

1. Start with a little background

The proposal form begins with a field for background. Share whatever your project team feels is relevant: how the project started, what motivated it, why you’re bringing it to the Eclipse Foundation, or any other context that helps us understand its story.

2. Tell us what the project does

Imagine that the person reading your proposal has never heard of your project.

Your first few sentences of the description should answer:

What does this project do?

This section deserves special attention because your project description continues to serve your project beyond the proposal process. When your project is created, the description becomes the main content on your project’s landing page in the Eclipse Foundation’s Project Management Infrastructure (PMI).

In other words, you’re not just writing for the people reviewing your proposal. You’re writing one of the first things that future contributors, adopters, and community members will see when they look up your project.

You don’t need to tell them everything. Give them enough information to understand the technology, what it is for, and the problem it addresses.

A good description:

• starts with a simple statement of the project’s purpose;
• gives enough context to understand why the technology exists;
• avoids unnecessary jargon and explains important acronyms;
• describes the technology rather than selling it; and
• works as a useful introduction to the project even after the proposal phase is over.

For example, instead of:

Eclipse Ushnuu is a revolutionary next-generation solution that transforms how organisations manage complex distributed environments.

Try:

Eclipse Ushnuu provides tools and libraries for managing configuration and deployment across distributed computing environments.

The second version may sound less exciting, but it tells us much more.

The goal is understanding, not selling. And remember: this is not just proposal text, it’s the introduction to your Eclipse project.

3. Give your scope some extra attention

The scope is one of the most important elements of a project proposal. It defines the boundaries of the project, not just what the project intends to develop today, but the areas of work that will remain within its remit as the project evolves.

A useful scope answers:

What does this project develop and maintain?

Focus on areas of development and responsibility rather than individual features or implementation details.

For example, avoid writing a roadmap disguised as a scope:

The project will initially develop a Java client, followed by a command-line interface and Kubernetes integration.

Instead, describe the broader area in which the project operates:

Eclipse Ushnuu provides tools and libraries for configuring, deploying, and managing applications across distributed computing environments.

The project scope should follow the pattern:

<project name> (provides|produces|manages) <something>

That leaves room for the technology to evolve without making the scope so broad that almost anything could fit inside it.

A few useful rules of thumb:

• Keep it reasonably short. One sentence is often enough.
• Start with the project’s formal name, including brand (e.g., “Eclipse Ushnuu provides …”).
• Write it in the present tense.
• Avoid tying it to a particular implementation when that implementation may change.
• Don’t turn it into a feature list or roadmap.

One final test: Would this scope still make sense three or five years from now?

If the answer is yes, you’re probably on the right track.

4. Write about the Eclipse project, not the company behind it

Many new Eclipse projects start life inside a company or another organisation. That’s perfectly normal.

But an Eclipse project is a vendor-neutral open source project, so the proposal should be written from that perspective.

Watch out for language such as:

• “our customers”;
• “our platform”;
• “our commercial offering”;
• “our development team”; or
• “the company will develop…”

Instead, talk about the project, its technology, and its community.

If you’re contributing an existing technology, the proposal is a good opportunity to start making that shift in perspective.

You are no longer describing your company’s product. You are describing an Eclipse project, in a vendor-neutral environment that a community can participate in.

5. Choose your project name carefully

Naming is another area where it’s worth doing a little homework before submitting your proposal.

As a general rule, Eclipse Foundation project names take the form:

Eclipse Something

Think Eclipse Temurin, Eclipse Jetty, or Eclipse Theia.

This convention reflects the fact that the Eclipse Foundation holds and manages project trademarks on behalf of its projects.

The “Something” matters too.

Ideally, choose something distinctive that can work as a project trademark. Very descriptive names can be difficult to protect, while a distinctive name can more easily become a recognisable identity for the project.

Before settling on a name, consider:

• Is it already the name of another software project, product, or organisation?
• Is there an existing trademark that is identical or confusingly similar?
• Is the acronym already widely used?
• Are there existing domains, logos, or other branding associated with the name?
• If this is an existing project, who currently owns the name or trademark?

If you’re bringing an existing project to the Eclipse Foundation and already use the proposed name, tell us early. The Eclipse Foundation claims all project names as trademarks and protects them as such on behalf of the community, acting as a guardian of the commons. If you want to continue using the name in your products (based on the open source project), then you should pick a different name for the open source project. There may be trademark or ownership questions to work through, and those can sometimes take longer to resolve than the proposal itself.

There are exceptions to the “Eclipse Something” convention, particularly in some Working Group contexts and for certain special Top-Level Projects. Those cases come with their own considerations, and that’s a topic for another article.

6. Find the right home for your project

Every Eclipse project operates under a Top-Level Project (TLP) and its Project Management Committee (PMC).

The TLP isn’t just an administrative category. Its PMC provides oversight and guidance for the projects under it, so choosing the right home matters.

When considering a TLP, ask: Does my project’s scope fit naturally within the mission and scope of this Top-Level Project?

Don’t worry if the answer isn’t obvious. You don’t need to become an expert in the Eclipse Foundation’s project structure before submitting a proposal. If you’re unsure where your project belongs, have a look here, or ask the EMO. We can help.

7. Tell us who is starting the project

Open source projects are about people as much as they are about code.

Your proposal identifies the initial Project Leads and Committers who will form the project’s starting team.

List the people who will actually participate in developing and governing the project as initial committers (maintainers).

A quick note about Project Leads: Project Leads are not “super committers” and do not have additional authority over other Committers (although they do have some additional privileges and responsibilities on GitHub and GitLab). Their role is primarily to serve as a point of contact between the project, its PMC, and the Eclipse Foundation. Project Leads must also be Committers, so anyone identified as a Project Lead should also be included in the proposal’s list of initial Committers.

And don’t worry if everyone initially comes from the same organisation. Having participation from multiple organisations is certainly valuable, but new projects aren’t expected to arrive with a perfectly diverse community on day one. Building a broader community is part of the incubation journey.

8. Give us the ecosystem context

Projects rarely exist in isolation.

Maybe your project builds on another Eclipse project. Maybe it implements an existing standard. Perhaps there is another open source project solving a similar problem, with different constraints. Or perhaps you’re moving an established project from another organisation to the Eclipse Foundation.

Tell us so.

In particular, mention important relationships if your project:

• builds on or complements another Eclipse project;
• overlaps significantly with another open source project;
• implements a standard or specification;
• is closely connected to a Working Group or other Eclipse Foundation initiative; or
• already exists elsewhere and is moving to the Eclipse Foundation.

Overlap isn’t automatically a problem, and dependencies aren’t either.

We simply need enough context to understand where your project fits in the broader ecosystem.

It may also help us identify projects or communities you should be talking to.

9. Ask someone unfamiliar with the project to read it

This might be the easiest and most effective proposal review you can do yourself.

When we have worked on a technology for months or years, it is surprisingly difficult to notice the assumptions we are making.

Ask someone who isn’t deeply involved in the project to read the proposal.

Then ask them four questions:

1. What does this project do?
2. What is inside its scope?
3. Where does it fit in the Eclipse ecosystem? (if you know)
4. Who is behind it?

If they can answer those questions after reading the proposal, you’re in good shape.

If they can’t, you probably don’t need more content. You need clearer content.

Before you hit submit

Here’s a quick final check:

• Can someone understand what the project does from the first few sentences?
• Is the description understandable without insider knowledge?
• Will the description work as an introduction after the project has been created, six months from now, and five years from now?
• Is the scope clear, concise, and written in the present tense?
• Have you explained important acronyms and specialised terminology?
• Have you avoided marketing and company-specific language?
• Does the project name follow the “Eclipse Something” convention?
• Have you considered possible trademark or naming conflicts?
• Does the mission and scope of the selected Top-Level Project align with the project’s scope?
• Are the initial Project Leads and Committers identified?
• Have you explained important relationships with other projects, standards, or communities? (if there are any)

If you can answer yes to most of these, you’re probably ready to submit your proposal. And if you’re unsure about a few of them, that’s a good time to reach out to the EMO, we’re here to help you work through it!

And remember: it’s a proposal, not a final exam

You don’t need to get everything perfect before submitting.

The proposal process is collaborative. The EMO will review your draft and may suggest changes, and the PMC and wider Eclipse community may offer feedback too. That’s what the proposal phase is for.

You don’t need to predict every feature or answer every technical question, just give your new community a solid starting point!