IMPORTANT NOTE


THIS DOCUMENT IS SUPERCEDED BY ROADMAP v2.0

Introduction


As required by the Eclipse Development Process, this document describes the Eclipse Roadmap.

The Roadmap is intended to be a living document which will see future iterations. This document is the first version of the Eclipse Roadmap, so it is labeled as version 1.0. In order to preserve this document while the underlying information evolves, the pages have been frozen by copying them from their original project hosted locations. Each frozen document is labeled with its version and date and includes a link back to its "live" version. Links that go outside this frozen copy are marked with the icon to inform the reader that that information may have changed since this document has written.

The goal of the Roadmap is to provide the Eclipse ecosystem with guidance and visibility on the future directions of the Eclipse open source community. An important element in this visibility is that the Roadmap determines what projects will be accepted by Eclipse during the life of this revision of the Roadmap. In other words, new projects must be consistent with the Roadmap. This does not mean that every new project must be explicitly envisaged by the Roadmap. It does mean that new projects cannot be inconsistent with the stated directions of Eclipse. In particular, Eclipse expects that incubator projects created in the Technology PMC will cover areas not explicitly described in the Roadmap.

There are four main sections to this document:

  1. This Preamble provides some background on Eclipse and the Foundation, and identifies the strategic goals of Eclipse. It also provides a brief overview of the scope of future projects anticipated within the Eclipse open source community.
  2. The Themes and Priorities which has been developed by the Eclipse Requirements Council.
  3. The Platform Release Plan which has been developed by the Eclipse Planning Council.
  4. The Architecture Plan which has been developed by the Eclipse Architecture Council

Background


As defined on our website, the role of the Foundation is:

The Eclipse Foundation is a non-profit corporation formed to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.

As defined in our Bylaws the Purposes of the Eclipse Foundation are:

The Eclipse technology is a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools (the “Eclipse Platform”). Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself; Eclipse Platform tools are extensible in that their functionality is accessible via documented programmatic interfaces. The purpose of Eclipse Foundation Inc., (the “Eclipse Foundation”), is to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.



There are many open source projects and open source communities in existence today. Eclipse has strong relationships with many of these. There are, however, three key differentiators between Eclipse and other open source communities.

  1. The Eclipse Development Process describes a well-defined process whereby Eclipse will build and maintain a Roadmap which describes the future directions of Eclipse. The attempt to co-ordinate the activities of a large open source community with many projects by requiring its participants to share a common vision and release roadmap is unprecedented. This will create a predictable environment that is essential for the commercialization of the Eclipse technology.
  2. Eclipse explicitly and consciously fosters the commercial adoption of its technologies. Although many other open source projects (e.g. Linux, Apache, etc.) are enormously successful in terms of commercial adoption none directly support it to the degree that Eclipse does. One concrete example of this is the requirement that all Members ship a commercial offering based upon Eclipse technology within a year of joining the Foundation.
  3. A technical architecture that includes an extensible platform that when combined with a flexible licensing model make it easy to add commercial offering and encourage a third party ecosystem.

These differentiators are positives. They help define Eclipse, and give it a unique presence in the broader open source community.

Strategic Goals


The following are the strategic goals of Eclipse.

  1. To define an open development platform. As an open development platform, Eclipse provides support for multiple operating environments and multiple programming languages. The goal of Eclipse is to define for the industry a development platform which is freely licensed, open source and provides support for the full breadth of the application lifecycle, in many disparate problem domains, across the development and deployment platforms of choice.

    At Eclipse, it is not enough to provide an open source implementation of developer frameworks and their exemplary tools. The frameworks must be architected for extensibility. Doing so enables others to more easily build on top of the Eclipse technology.

  2. To foster a vibrant open source community well regarded for innovation and quality. Since its inception, there has been rapid growth in the number of developers working on Eclipse projects. This has accelerated since Eclipse has become independent.

    But simply measuring growth in terms of developers and projects is not sufficient. Eclipse needs to ensure that it the open source projects at Eclipse are building innovative software with a high degree of quality.

  3. To enable an ecosystem. The creation of a large community of commercial and open source organizations which rely on and/or complement Eclipse technology has been a major factor in the success of Eclipse.

    The high rate of adoption of the Eclipse technology can be traced to two key factors: great technology, and the ease with which it can be adopted by others, both commercial and open source. This ease of adoption has, in turn, several dimensions. The EPL and its CPL predecessor provide terms which are conducive to both commercial and open source use. The focus on extensible frameworks has made it relatively simple to re-use Eclipse Technology.

  4. To be ubiquitous. To be considered one of the important development platforms. In the limit, Eclipse wants its technology used everywhere, by everyone.

 

Eclipse Future Directions


The goal of the Roadmap is to provide the Eclipse ecosystem with guidance and visibility on the future directions of the Eclipse open source community, and to involve the Eclipse membership in a dialog about those future directions. In that vein, this section discusses our current vision of the future as a set of future projects that expand the value of the ecosystem for all of its members.


The following diagram provides an architectural representation of the Eclipse technology today. The Architecture Plan goes into this in much greater detail.

 


The Themes and Priorities document prepared by the Requirements Council describes a number of requirements and focus areas for the existing Eclipse projects.


In addition to the Themes and Priorities requirements on existing projects in 2005, we envision future growth in Eclipse projects in the following major areas. These are areas in which we envision starting new projects in 2005, not areas in which we envision having completed Eclipse-quality standards-based frameworks and tooling.

In addition, Eclipse will continue to focus on evolving its frameworks and exemplary tools to meet new development technologies and runtime environments such as web services and service-oriented architectures. Support for additional programming languages is also anticipated.

If all of these future directions come to fruition, a future Eclipse architecture view could be:

 

The Roadmap Process

The process of creating the Eclipse Roadmap is described in the Eclipse Development Process. The key pieces are

Creating or updating the Roadmap begins with the Requirements Council proposing a set of Themes and Priorities that realize the Purposes and that respond to requirements elicited from the Strategic Developers, Strategic Consumers, Add-in Providers, and other constituents of the Ecosystem. After review by the Board of Directors, these Themes and Priorities are provided as input to the Architecture Council and the Planning Council. The EMO ensures that the Planning Council and the Development teams have access to all requirements. Updates to the Purposes are likely to require updates to the Roadmap and its associated themes and priorities; proposed Roadmap updates may also be motivated by new technologies or opportunities.

The process of producing or updating the Roadmap is expected to be iterative. An initial set of Themes and Priorities may be infeasible to implement in the desired timeframe; subsequent consideration may reveal new implementation alternatives or critical requirements that alter the team’s perspective on priorities. The EMO orchestrates interaction among and within the three Councils to drive the Roadmap to convergence.

 

This first version of the Eclipse Roadmap has been developed by the three councils: the Architecture Councilthe Planning Council and the Requirements Council. As this was our collectively first time through the Roadmap process, we evolved and refined the process for producing this Roadmap document as we went along. The three Councils met face-to-face twice in 2004: once in September, and again in December. (The minutes of these meetings are available on the Councils page.) Subsequent discussion of the Roadmap was done through numerous individual phone calls, and more numerous emails amongst the Council members.

The information flow we managed to achieve in this first draft was:

We did not achieve all of the interactions between the various Councils we were hoping for in this first version of the Roadmap, although we expect to accomplish that in the next version.

In summary, through lots of hard work by everyone, the three groups converged on this Roadmap document.

The Roadmap will be presented to the Eclipse Board of Directors on Monday, February 28, 2005.