THIS DOCUMENT IS SUPERCEDED BY ROADMAP v2.0
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:
- 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.
- The Themes and Priorities which has been developed by the Eclipse Requirements Council.
- The Platform Release Plan which has been developed by the Eclipse Planning Council.
- The Architecture Plan which has been developed by the Eclipse Architecture Council
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.
- 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.
- Eclipse explicitly and consciously fosters the commercial adoption of its technologies. Although many other open source projects (e.g.
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.
- 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.
The following are the strategic goals of Eclipse.
- 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.
- 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.
- 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.
- To be ubiquitous. To be considered one of the important development platforms. In the limit, Eclipse wants its technology used everywhere, by everyone.
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.
- Extend coverage of the software development life-cycle
Eclipse today provides a great deal of coverage of the software development lifecycle. Projects such as
EMF support modeling.
CDT support development and debug.
and Performance supports QA and post-deployment application monitoring. However, Eclipse's goal is to provide complete coverage of the software development lifecycle with frameworks and extensible, exemplary tools. Some examples of possible new project areas which would extend this coverage include:
- requirements management,
- data management,
- deployment, and
- system management.
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.
- Extend the Rich Client Platform (RCP)
RCP was introduced by Eclipse with the 3.0 release of the Eclipse Platform in June, 2004. The RCP is a technology for building and managing applications with a rich user experience. Eclipse's goal is to make the RCP a mainstream development platform for both ISVs and enterprise developers. To do so, we plan to evolve the RCP technology in the following ways:
- Target RCP for additional operating environments. One example of this is the eRCP project which is evaluating the use of Eclipse for embedded constrained devices such as mobile phones and PDAs.
- Examine alternatives for providing a more complete development for creating RCP applications.
- Enhance RCP with new functionality such as better update and management
- Enhance the security capabilities of the RCP plug-in model.
- Provide application frameworks based on the RCP.
Eclipse has seen a great deal of success in the embedded marketplace over the past several years. For example, CDT has been used by a number of RTOS vendors as the basis for their tools platform. But there are many different
technologies currently not covered by Eclipse which would extend to utility of the Eclipse Platform for the embedded market. Some examples include:
- Runtime analysis infrastructure to provide frameworks and tools to monitor applications running on a device
- Component configuration frameworks and tooling to configure operating systems, file systems and middleware
- Target connectivity frameworks to provide mechanisms to connect to embedded devices
- Hardware bring-up mechanisms for on-chip debugging and early development
- Board design tools
- Multiple language support
Although Eclipse has been very successful in providing language tools for Java and C/C++, doing so still requires a great deal of effort. Improving the Eclipse frameworks to provide more consistent APIs for plugging in editors, debuggers, build environments, etc. for multiple languages is an important goal. There are several different views on what multiple language support can mean. Support for compiled languages, scripting languages and "Java like" languages such as JSP, SQLJ and the like are all related areas where work needs to be done. There are numerous trade-offs to be made as well. For example, JDT has been highly customized to provide a very rich feature set. Will an abstract language toolkit approach meet its needs?
From the perspective of the plug-in providers, there is a lot of interest in more easily enabling plug-ins for specialized components (debuggers, managed builds, editors) which work across multiple languages. Currently if an add-in provider wants to support both CDT and JDT separate plug-ins are required.
- Vertical market technology frameworks
We are seeing interest from vertical market vendors in basing their next
generation tools on Eclipse. Thus a future growth area for Eclipse is to
extend our projects to provide open source application frameworks and exemplary tools targeted at
standards in specific vertical markets such as
aerospace, automotive, and healthcare.
If all of these future directions come to fruition, a future Eclipse architecture view could be:
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 Council, the 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:
from the membership (both the membership-at-large and the strategic members) to the Requirements Council
from the Requirements Council to the Planning and Architecture Councils
from the PMC project plans to the Planning Council
from the PMC architecture plans to the Architecture Council
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.