councils/roadmap_v1_0.html - www.eclipse.org/org - Git at Google

 <!-- ----------------------------------------------------------------------------- -->
 <!--
 Project: Eclipse Test and Performance Tools Platform Project
 -->
 <!-- ----------------------------------------------------------------------------- -->

 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
   <head>
     <title>Eclipse Roadmap</title>
     <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
     <link rel="stylesheet" type="text/css" href="eclipse_style.css" >

     </head>

   <body>

     <div id="page_header"><FONT class=indextop>Eclipse Roadmap v1.0 (OLD)</FONT> <BR>
     </div>

   <br>
   <div id="section_header">IMPORTANT NOTE</div>
   <div class="content">
       <p><br>
       THIS DOCUMENT IS SUPERCEDED BY <a href="roadmap_v2_0/index.php">ROADMAP v2.0</a>
   </div>


     <div id="section_header">Introduction</div>
   <div class="content">
       <p><br>
       As required by the
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="../documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse Development Process</a>, this document describes the Eclipse Roadmap. </p>
       <p>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
       &quot;live&quot; version. Links that go outside
 this frozen copy are marked with the
 <img border="0" src="PC/external.gif" width="20" height="16"> icon to inform the
 reader that that information may have changed since this document has written.</p>
       <p>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. </p>
       <p>There are four main sections to this document:</p>
       <ol>
         <li>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. <br>
         </li>
         <li>The <a href="themes.html">Themes and Priorities</a> which has been developed by the Eclipse Requirements Council. <br>
         </li>
         <li>The <a href="PC/main.html">Platform Release Plan</a> which has been developed by the Eclipse Planning Council.<br>
         </li>
         <li>The <a href="AC/main.html">Architecture Plan</a> which has been developed by the Eclipse Architecture Council<br>
         </li>
       </ol>
   </div>
    	<br>
     <div id="section_header">Background</div>
    	<br>

   <div class="content">
     <p><br>
     As defined on our website, the role of the Foundation is:</p>
       <blockquote>
         <p><em>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.</em></p>
       </blockquote>
       <p>As defined in our
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="../documents/Eclipse BYLAWS 2003_11_10 Final.pdf">Bylaws</a> the Purposes of the Eclipse Foundation are:</p>
       <blockquote>
         <p><em>The Eclipse technology is a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools (the &ldquo;Eclipse Platform&rdquo;). 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 &ldquo;Eclipse Foundation&rdquo;), 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.      <br>
         </em>
         </p>
       </blockquote>
   </div>
 <br>
     <div class="content">
       <p><br>
       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.</p>
       <ol>
         <li>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.<br>
         </li>
         <li>Eclipse explicitly and consciously fosters the commercial adoption of its technologies. Although many other open source projects (e.g.
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.linux.org">Linux</a>,
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.apache.org">Apache</a>, 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.<br>
         </li>
         <li>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.</li>
       </ol>
       <p>These differentiators are positives. They help define Eclipse, and give it a unique presence in the broader open source community.<br>
         <br>
       </p>
   </div>
     <div id="section_header">Strategic Goals</div>
   <div class="content">
     <p><br>
     The following are the strategic goals of Eclipse. </p>
       <ol>
         <li>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.<br>
         <font style="font-size: 3pt"><br>
         </font>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.<br>
         <br>
         </li>
         <li>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.<br>
         <font style="font-size: 3pt"><br>
         </font>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.<br>
         <br>
         </li>
         <li> 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.<br>
         <font style="font-size: 3pt"><br>
         </font>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.<br>
         <br>
         </li>
         <li>To be ubiquitous. To be considered one of the important development platforms. In the limit, Eclipse wants its technology used everywhere, by everyone. </li>
       </ol>
       <p>&nbsp;</p>
   </div>

 <div id="section_header"><a name="Eclipse_Future_Directions">Eclipse Future Directions</a></div>
 <div class="content">
   <p><br>
     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.</p>
   <hr>
   <p>The following diagram provides an architectural representation of the Eclipse technology today. The<a href="AC/main.html"> Architecture Plan</a> goes into this in much greater detail. </p>
   <p align="center"><img src="AC/arch2.jpg" width="675" height="356">&nbsp;</p>
   <hr>
   <p>The <a href="themes.html">Themes and Priorities</a> document prepared by
   the Requirements Council describes a number of requirements and focus areas
   for the existing Eclipse projects. </p>
   <hr>
   <p>In addition to the <a href="themes.html">Themes and Priorities</a>
   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.</p>
   <ul>
     <li><strong>Extend coverage of the software development life-cycle</strong><br>
       <br>
     Eclipse today provides a great deal of coverage of the software development lifecycle. Projects such as
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="http://download.eclipse.org/tools/emf/scripts/home.php">EMF</a> support modeling.
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.eclipse.org/jdt/index.html">JDT</a> and
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.eclipse.org/cdt/">CDT</a> support development and debug.
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.eclipse.org/test-and-performance/index.html">T</a><a href="http://www.eclipse.org/test-and-performance/index.html">est
     and Performance</a> supports QA and post-deployment application monitoring. However, Eclipse's goal is to provide <em>complete</em> 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:
     <br>
     <ul>
       <li>requirements management,</li>
       <li>modeling,</li>
       <li>data management,</li>
       <li>deployment, and </li>
       <li> system management.</li>
       </ul>
     </li>
   </ul>
   <blockquote>
     <p>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. <br>
     </p>
   </blockquote>
   <ul>
     <li><strong>Extend the Rich Client Platform (RCP)</strong><br>
       <br>
       The
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/rcp/index.html">RCP</a> 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:
       <br>
       <ul>
         <li> 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.</li>
         <li>Examine alternatives for providing a more complete development for creating RCP applications.</li>
         <li>Enhance RCP with new functionality such as better update and management
         capabilities.</li>
         <li>Enhance the security capabilities of the RCP plug-in model.</li>
         <li> Provide application frameworks based on the RCP. <br>
         <br>
         </li>
       </ul>
     </li>
     <li><strong>Embedded</strong><br>
       <br>
       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:
       <br>
       <ul>
         <li>          Runtime analysis infrastructure to provide frameworks and  tools to monitor applications running on a device</li>
         <li>          Component configuration frameworks and tooling to configure operating systems, file systems and middleware</li>
         <li> Target connectivity frameworks to provide  mechanisms to connect to embedded devices</li>
         <li>          Hardware bring-up mechanisms for on-chip debugging and early development</li>
         <li>Board design tools <br>
         <br>
         </li>
       </ul>
     </li>
     <li>      <strong>Multiple language support</strong><br>
       <br>
       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 &quot;Java like&quot; 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?<br>
       <br>
       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.
       <br>
       <br>
     </li>
     <li><strong>Vertical market technology frameworks</strong><br>
       <br>
       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.</li>
   </ul>
   <p>If all of these future directions come to fruition, a future Eclipse architecture view could be:</p>
   <p align="center"><img src="future_architecture.JPG" width="671" height="527"> </p>
   <p>&nbsp;</p>
   </div>

         <div id="section_header">The Roadmap Process  </div>
         <div class="content">
   <p>
       </p>
 <p>The process of creating the Eclipse Roadmap is described in the
 <img border="0" src="PC/external.gif" width="20" height="16"><a href="../documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse Development Process</a>. The key pieces are </p>
 <blockquote>
   <p><em>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.</em></p>
   <p><em>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&rsquo;s perspective on priorities. The EMO orchestrates
               interaction among and within the three Councils to drive the Roadmap to convergence.</em></p>
   </blockquote>
         <p align="center"><img src="roadmap_process.JPG" width="795" height="555"></p>
         <p align="left">&nbsp;</p>
         <p align="left">This first version of the Eclipse Roadmap&nbsp;<SPAN
 class=203453704-21022005>has been </SPAN>developed by the three&nbsp;<SPAN
 class=203453704-21022005>c</SPAN>ouncils:&nbsp;<SPAN class=203453704-21022005>the </SPAN>Architecture<SPAN class=203453704-21022005> Council</SPAN>,&nbsp;<SPAN
 class=203453704-21022005>the </SPAN>Planning&nbsp;<SPAN
 class=203453704-21022005>Council </SPAN>and&nbsp;<SPAN class=203453704-21022005>the </SPAN>Requirements<SPAN class=203453704-21022005> Council</SPAN>. As this was&nbsp;<SPAN class=203453704-21022005>our collectively </SPAN>first time through the Roadmap process,&nbsp;<SPAN class=203453704-21022005>we evolved and refined </SPAN>the&nbsp;<SPAN class=203453704-21022005>process for producing this Roadmap </SPAN>document&nbsp;<SPAN class=203453704-21022005>as we went along</SPAN>. The&nbsp;<SPAN class=203453704-21022005>three </SPAN>Councils met face-to-face twice in 2004:&nbsp;<SPAN class=203453704-21022005>once </SPAN>in September<SPAN
 class=203453704-21022005>,</SPAN> and again in December. (The minutes of these meetings are available on the
 <img border="0" src="PC/external.gif" width="20" height="16"><A title=http://www.eclipse.org/org/council.html
 href="../council.html">Councils page</A>.)&nbsp;<SPAN
 class=203453704-21022005>Subsequent discussion of the Roadmap was done through numerous individual phone calls, and&nbsp;more numerous emails amongst the Council members.</SPAN></p>
         <P align=left><SPAN class=203453704-21022005>The information flow we managed to achieve in this first draft was:</SPAN></P>
         <UL>
           <LI>
             <DIV align=left><SPAN class=203453704-21022005>from the membership (both the membership-at-large and the strategic members) to the Requirements Council</SPAN></DIV>
           <LI>
             <DIV align=left><SPAN class=203453704-21022005>from the Requirements Council to the Planning and Architecture Councils</SPAN></DIV>
           <LI>
             <DIV align=left><SPAN class=203453704-21022005>from the PMC project plans to the Planning Council</SPAN></DIV>
           <LI>
             <DIV align=left><SPAN class=203453704-21022005>from the PMC architecture plans to the Architecture Council</SPAN></DIV>
           </LI>
         </UL>
         <P align=left><SPAN class=203453704-21022005>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.</SPAN></P>
         <P align=left><SPAN class=203453704-21022005>In summary,&nbsp;through </SPAN>lots of hard work<SPAN class=203453704-21022005> by everyone</SPAN>, the three groups converged on this&nbsp;<SPAN class=203453704-21022005>Roadmap </SPAN>document.</P>
         <p align="left">The Roadmap will be presented to the Eclipse Board of Directors on Monday, February 28, 2005. </p>
         <p align="left">&nbsp; </p>
         </div>
   </body>
 </html>
	<!-- ----------------------------------------------------------------------------- -->
	<!--
	Project: Eclipse Test and Performance Tools Platform Project
	-->
	<!-- ----------------------------------------------------------------------------- -->

	<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
	<html>
	<head>
	<title>Eclipse Roadmap</title>
	<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
	<link rel="stylesheet" type="text/css" href="eclipse_style.css" >

	</head>

	<body>

	<div id="page_header"><FONT class=indextop>Eclipse Roadmap v1.0 (OLD)</FONT> <BR>
	</div>

	<br>
	<div id="section_header">IMPORTANT NOTE</div>
	<div class="content">
	<p><br>
	THIS DOCUMENT IS SUPERCEDED BY <a href="roadmap_v2_0/index.php">ROADMAP v2.0</a>
	</div>


	<div id="section_header">Introduction</div>
	<div class="content">
	<p><br>
	As required by the
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="../documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse Development Process</a>, this document describes the Eclipse Roadmap. </p>
	<p>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
	<img border="0" src="PC/external.gif" width="20" height="16"> icon to inform the
	reader that that information may have changed since this document has written.</p>
	<p>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. </p>
	<p>There are four main sections to this document:</p>
	<ol>
	<li>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. <br>
	</li>
	<li>The <a href="themes.html">Themes and Priorities</a> which has been developed by the Eclipse Requirements Council. <br>
	</li>
	<li>The <a href="PC/main.html">Platform Release Plan</a> which has been developed by the Eclipse Planning Council.<br>
	</li>
	<li>The <a href="AC/main.html">Architecture Plan</a> which has been developed by the Eclipse Architecture Council<br>
	</li>
	</ol>
	</div>
	<br>
	<div id="section_header">Background</div>
	<br>

	<div class="content">
	<p><br>
	As defined on our website, the role of the Foundation is:</p>
	<blockquote>
	<p><em>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.</em></p>
	</blockquote>
	<p>As defined in our
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="../documents/Eclipse BYLAWS 2003_11_10 Final.pdf">Bylaws</a> the Purposes of the Eclipse Foundation are:</p>
	<blockquote>
	<p><em>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. <br>
	</em>
	</p>
	</blockquote>
	</div>
	<br>
	<div class="content">
	<p><br>
	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.</p>
	<ol>
	<li>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.<br>
	</li>
	<li>Eclipse explicitly and consciously fosters the commercial adoption of its technologies. Although many other open source projects (e.g.
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.linux.org">Linux</a>,
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.apache.org">Apache</a>, 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.<br>
	</li>
	<li>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.</li>
	</ol>
	<p>These differentiators are positives. They help define Eclipse, and give it a unique presence in the broader open source community.<br>
	<br>
	</p>
	</div>
	<div id="section_header">Strategic Goals</div>
	<div class="content">
	<p><br>
	The following are the strategic goals of Eclipse. </p>
	<ol>
	<li>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.<br>
	<font style="font-size: 3pt"><br>
	</font>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.<br>
	<br>
	</li>
	<li>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.<br>
	<font style="font-size: 3pt"><br>
	</font>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.<br>
	<br>
	</li>
	<li> 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.<br>
	<font style="font-size: 3pt"><br>
	</font>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.<br>
	<br>
	</li>
	<li>To be ubiquitous. To be considered one of the important development platforms. In the limit, Eclipse wants its technology used everywhere, by everyone. </li>
	</ol>
	<p> </p>
	</div>

	<div id="section_header"><a name="Eclipse_Future_Directions">Eclipse Future Directions</a></div>
	<div class="content">
	<p><br>
	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.</p>
	<hr>
	<p>The following diagram provides an architectural representation of the Eclipse technology today. The<a href="AC/main.html"> Architecture Plan</a> goes into this in much greater detail. </p>
	<p align="center"><img src="AC/arch2.jpg" width="675" height="356"> </p>
	<hr>
	<p>The <a href="themes.html">Themes and Priorities</a> document prepared by
	the Requirements Council describes a number of requirements and focus areas
	for the existing Eclipse projects. </p>
	<hr>
	<p>In addition to the <a href="themes.html">Themes and Priorities</a>
	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.</p>
	<ul>
	<li><strong>Extend coverage of the software development life-cycle</strong><br>
	<br>
	Eclipse today provides a great deal of coverage of the software development lifecycle. Projects such as
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="http://download.eclipse.org/tools/emf/scripts/home.php">EMF</a> support modeling.
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.eclipse.org/jdt/index.html">JDT</a> and
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.eclipse.org/cdt/">CDT</a> support development and debug.
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="http://www.eclipse.org/test-and-performance/index.html">T</a><a href="http://www.eclipse.org/test-and-performance/index.html">est
	and Performance</a> supports QA and post-deployment application monitoring. However, Eclipse's goal is to provide <em>complete</em> 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:
	<br>
	<ul>
	<li>requirements management,</li>
	<li>modeling,</li>
	<li>data management,</li>
	<li>deployment, and </li>
	<li> system management.</li>
	</ul>
	</li>
	</ul>
	<blockquote>
	<p>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. <br>
	</p>
	</blockquote>
	<ul>
	<li><strong>Extend the Rich Client Platform (RCP)</strong><br>
	<br>
	The
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/rcp/index.html">RCP</a> 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:
	<br>
	<ul>
	<li> 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.</li>
	<li>Examine alternatives for providing a more complete development for creating RCP applications.</li>
	<li>Enhance RCP with new functionality such as better update and management
	capabilities.</li>
	<li>Enhance the security capabilities of the RCP plug-in model.</li>
	<li> Provide application frameworks based on the RCP. <br>
	<br>
	</li>
	</ul>
	</li>
	<li><strong>Embedded</strong><br>
	<br>
	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:
	<br>
	<ul>
	<li> Runtime analysis infrastructure to provide frameworks and tools to monitor applications running on a device</li>
	<li> Component configuration frameworks and tooling to configure operating systems, file systems and middleware</li>
	<li> Target connectivity frameworks to provide mechanisms to connect to embedded devices</li>
	<li> Hardware bring-up mechanisms for on-chip debugging and early development</li>
	<li>Board design tools <br>
	<br>
	</li>
	</ul>
	</li>
	<li> <strong>Multiple language support</strong><br>
	<br>
	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?<br>
	<br>
	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.
	<br>
	<br>
	</li>
	<li><strong>Vertical market technology frameworks</strong><br>
	<br>
	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.</li>
	</ul>
	<p>If all of these future directions come to fruition, a future Eclipse architecture view could be:</p>
	<p align="center"><img src="future_architecture.JPG" width="671" height="527"> </p>
	<p> </p>
	</div>

	<div id="section_header">The Roadmap Process </div>
	<div class="content">
	<p>
	</p>
	<p>The process of creating the Eclipse Roadmap is described in the
	<img border="0" src="PC/external.gif" width="20" height="16"><a href="../documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Eclipse Development Process</a>. The key pieces are </p>
	<blockquote>
	<p><em>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.</em></p>
	<p><em>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.</em></p>
	</blockquote>
	<p align="center"><img src="roadmap_process.JPG" width="795" height="555"></p>
	<p align="left"> </p>
	<p align="left">This first version of the Eclipse Roadmap <SPAN
	class=203453704-21022005>has been </SPAN>developed by the three <SPAN
	class=203453704-21022005>c</SPAN>ouncils: <SPAN class=203453704-21022005>the </SPAN>Architecture<SPAN class=203453704-21022005> Council</SPAN>, <SPAN
	class=203453704-21022005>the </SPAN>Planning <SPAN
	class=203453704-21022005>Council </SPAN>and <SPAN class=203453704-21022005>the </SPAN>Requirements<SPAN class=203453704-21022005> Council</SPAN>. As this was <SPAN class=203453704-21022005>our collectively </SPAN>first time through the Roadmap process, <SPAN class=203453704-21022005>we evolved and refined </SPAN>the <SPAN class=203453704-21022005>process for producing this Roadmap </SPAN>document <SPAN class=203453704-21022005>as we went along</SPAN>. The <SPAN class=203453704-21022005>three </SPAN>Councils met face-to-face twice in 2004: <SPAN class=203453704-21022005>once </SPAN>in September<SPAN
	class=203453704-21022005>,</SPAN> and again in December. (The minutes of these meetings are available on the
	<img border="0" src="PC/external.gif" width="20" height="16"><A title=http://www.eclipse.org/org/council.html
	href="../council.html">Councils page</A>.) <SPAN
	class=203453704-21022005>Subsequent discussion of the Roadmap was done through numerous individual phone calls, and more numerous emails amongst the Council members.</SPAN></p>
	<P align=left><SPAN class=203453704-21022005>The information flow we managed to achieve in this first draft was:</SPAN></P>
	<UL>
	<LI>
	<DIV align=left><SPAN class=203453704-21022005>from the membership (both the membership-at-large and the strategic members) to the Requirements Council</SPAN></DIV>
	<LI>
	<DIV align=left><SPAN class=203453704-21022005>from the Requirements Council to the Planning and Architecture Councils</SPAN></DIV>
	<LI>
	<DIV align=left><SPAN class=203453704-21022005>from the PMC project plans to the Planning Council</SPAN></DIV>
	<LI>
	<DIV align=left><SPAN class=203453704-21022005>from the PMC architecture plans to the Architecture Council</SPAN></DIV>
	</LI>
	</UL>
	<P align=left><SPAN class=203453704-21022005>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.</SPAN></P>
	<P align=left><SPAN class=203453704-21022005>In summary, through </SPAN>lots of hard work<SPAN class=203453704-21022005> by everyone</SPAN>, the three groups converged on this <SPAN class=203453704-21022005>Roadmap </SPAN>document.</P>
	<p align="left">The Roadmap will be presented to the Eclipse Board of Directors on Monday, February 28, 2005. </p>
	<p align="left">  </p>
	</div>
	</body>
	</html>