Level: Introductory Marc Erickson (mre@us.ibm.com), Eclipse.org Communications/IBM Liaison, IBM
Angus McIntyre (mcintyre@ca.ibm.com), Eclipse project member, IBM
01 Nov 2001 The Eclipse Platform is designed for building integrated development
environments (IDEs). It can be used to create diverse end-to-end computing solutions
for multiple execution environments. This article discusses the platform, and includes a list of questions and answers.
Introduction
When selecting an architecture, tool builders need three assurances:
- A level playing field and full disclosure with no hidden APIs and no hidden
tool-to-tool interfaces — Eclipse delivers by shipping open platform
source. Published APIs are tested by the cross-industry consortium to ensure code quality portability and performance.
- The freedom to enhance the platform to address new opportunities —
Eclipse delivers the ability to create derivative works, including redistribution of
the platform. The Eclipse Platform allows tools developers to focus on core
competencies and new models for development technology.
- Timely response to their requests for changes and enhancements in a controlled and
organized way — Through www.eclipse.org, you can make a difference by
collaborating and contributing to the platform.
Questions
What is the Eclipse.org?
Eclipse.org is an open consortium of software development tool vendors that has
formed a community interested in collaborating to create better development
environments and product integration. The community shares an interest in
creating products that are interoperable in an easy-to-use way based upon plug-in
technology. By collaborating and sharing core integration technology, Eclipse
Platform-compatible tool vendors can concentrate on their areas of expertise and
the creation of new development technologies.
What is the Eclipse Platform?
The idea of its Eclipse Project is to create an "Apache for developer tools"
— an open source framework that provides many of the underlying
services software developers need. This would be a "toolkit for designing
toolkits." Not just a set of APIs, the framework will consist of real code designed to do real work.
The Eclipse Platform is the foundation for constructing and running integrated
end-to-end software development tools. The platform consists of open source software
components that tool vendors use to construct solutions that plug in to integrated
software workbenches. The Eclipse Platform incorporates technology expressed through a
well-defined design and implementation framework.
Why did IBM open source Eclipse?
Open source is the only way to deliver an open platform for tool integration. But open
source also has several other advantages, including:
- Reuse — Reuse is the highest form of compliment. Why rebuild something when it exists in a
working format already? By using the open Eclipse Platform, tool builders can focus on
domain specific expertise and functions (thus focusing on what makes them successful),
while providing the tooling infrastructure for building IDEs. But reusing someone
else's code takes trust.
- Trust — Trust for any new architecture or platform is slowly earned.
For instance, it is hard to earn the trust of developers for tooling that contains
proprietary interfaces that limit the application to a single (for example,
Windows®) operating system. It is also hard to earn the trust of tool
builders when different levels of APIs are shipped with different levels of tool
offerings (for example, Community APIs differ from Enterprise APIs).
- Confidence — The Eclipse Platform builds confidence and trust by
providing the source code for the platform. Open source provides all of the APIs, without internal, proprietary or hidden
interfaces. Developers, whose trust is earned slowly, can look at the source
and learn. Trust the source, then launch innovation.
- Quality — Open source consortiums also can produce a higher quality of code. When code review
is collaborative, people put extra effort into it. The source that they contribute
becomes a reflection of the work that they do, establishing both individual and
corporate reputation. Trust the source, then launch market position.
- Clarity — Open source based upon clear specifications can deliver code
that is easier to understand. An Interface describes (in black-box terms) the promise
of component behavior. By directly inspecting the source, you can examine, line by
line, how the code works. It is hard to trust someone else's interface. Trust the
source, then inspect technology.
- Simplicity — Open source can be easier to debug. Late at night, when
encountering a bug, source code can speed identification of the root cause. It could be
your fault, or the fault of the platform and environment. With access to the source,
guesswork is eliminated. With access to a collaborative discussion forum, it's even
possible to compare notes with someone else familiar with the environment or problem.
If the problem appears to be in shared open source, it's easy to patch it and attempt a
workaround. Trust the source, then verify the base. It's difficult to work alone on
complex technology. Few tool builders want to take on the risk of pioneering new
tooling technology. Trust the source, then share the risk.
- Longevity — Tool vendors come, and tool vendors go. Corporate developers want to know that
a platform can provide long-term support. With the source code, corporations
can start quickly in the short term and sustain business for the long term.
Trust the source, then build a business.
- Flexibility — Flexibility is a fundamental value of Eclipse. With the
open Eclipse Platform, an unsatisfactory component can be modified to suit your needs.
For example, if the editor is inadequate, create your own, or plug in a popular one
created in the open component market established by the Eclipse Platform. Want to tie a
new deployment platform (for example, a set-top box) into existing end-to-end support?
Trust the source, then create a plug-in.
Bottom line: Open source — an open community and an open platform
— establishes the level playing field that tool builders large and
small need to support end-to-end development projects and explore new frontiers.
Still skeptical? See Frank Hecker's paper
on setting up shop for open source (see Resources).
What workstation platforms is the Eclipse Platform available on?
The Eclipse Platform has been released for and tested on Windows NT, Windows
XP, Windows 2000, Windows 98, Windows ME, and Red Hat Linux® V7.1.
Eclipse technology is written in the Java™ programming language, making it
easier to use on a wide variety of workstation platforms.
Will Eclipse be taken to other platforms?
This has yet to be determined, but that's the beauty of the Eclipse Platform.
Tool builders can take Eclipse technology and explore new frontiers, getting
there faster by relying on an industry-tested open tools platform.
What is the cost of the Eclipse Platform?
The Eclipse Platform is made available under a Common Public License (CPL). See
Eclipse.org for details.
But tool developers don't really want to have source code and can't take advantage
of it anyway.
Having access to the source often leads to faster problem determination and eliminates
duplication of work, speeding the completion of new compatible technology.
Wouldn't this lead to fragmentation of the product into incompatible versions?
The community has the right to designate and endorse "official" versions of the
Eclipse Platform. Community members also have the right to make modifications
and extensions to suit their purposes. However, as code bases diverge, creating
a private version outside of the Eclipse Project, the cost to port improvements
made in the official version to the modified private version become
increasingly difficult. It will be in the interest of all members of the Eclipse
community to collaborate on common and core Eclipse technology and infrastructure.
Will steps be taken to ensure that the official version is recognized within
products that ship it (for example, an ingredient brand like "Eclipse
Inside")?
The answer to that question is up to the Eclipse board or directors.
What about the risk to customer from private versions?
Typically, the official version of the Eclipse Platform, which undergoes testing
and review, is placed on Eclipse.org. It is this version that is supported
through the Eclipse.org. Private versions must be entirely supported by the
vendor and won't benefit from the collaboration of other members.
Won't tool builders be concerned with Eclipse technology open source code "tainting"
theirs if they use it within their own projects?
Eclipse ships under a CPL that does not taint other code
that calls Eclipse code using an openly defined API.
What about embarrassing things that people might discover in Eclipse source code,
like bugs?
Open source development increases the chances that major and minor bugs will be found
and fixed. They surface and are fixed either by the original developer or members the community.
Wouldn't releasing your source code expose confidential plans and strategies to
competitors?
Yes. In essence, we are sharing strategies with our competitors. Clearly, there is a
more important consideration. Developers are tired of integrating tools onto their
desktops. They are tired of wasting time figuring out how to make tools work together
in an end-to-end computing environment. With the Eclipse Platform, everyone
— tool developers and users alike — benefits from full
disclosure on how to integrate an IDE at an industry level. It is ultimately to
benefit the end-user developer that we are doing this.
Wouldn't people just use Eclipse source code and member expertise without the
Eclipse Platform getting anything in return?
Potentially, but sooner or later, interoperability will deliver more end-user
benefit than any stand-alone tool could deliver. In isolation, noncollaborative
developers will be left in the dust.
What about competitors who might try to "hijack"' an open source product for their
own purposes?
This could be attempted, but the CPL will protect the
community. The official version of the Eclipse Platform will continue. The
license has been defined in such a way that no one vendor could exercise undue
advantage. In contributing to the Eclipse Project, we want to help establish a
true level playing field for tool developers.
Where do I find information on how to integrate tooling with Eclipse
technology?
There are several white papers on Eclipse.org.
How does Eclipse work, and what functions are offered within the Eclipse
Platform?
The design principles that eclipse was written to are as follows:
- To facilitate seamless integration of tools within and across different content types and tool providers.
- To support the construction of a variety of tools.
- To support an unrestricted set of tool providers, including independent software vendors (ISVs).
- To support tools to manipulate arbitrary content types (including HTML, Java, C, JSP, EJB, XML, and GIF).
- To support both GUI and non GUI-based application development environments.
- To run on a wide range of operating systems, including Windows and Linux.
- To capitalize on the popularity of the Java language to write tools.
Will IBM turn the Eclipse Platform source over to a open community? When will
it do so?
Yes, the source is available today, under the CPL. IBM will turn
Eclipse over to an interim board of directors, who will manage the Eclipse Platform very shortly.
Who is on the interim board?
The interim board will be announced at a later date.
How do I join?
Visit Eclipse.org.
How do I become a board member?
Contribute, contribute, contribute (code, ideas, projects, fixes, knowledge and skilled participation).
How is the Eclipse Platform supported?
Through a forum and e-mail, on a voluntary basis using resources established by
the community. Visit Eclipse.org for details.
Is 24x7 support offered?
No.
How will the interim board members be selected?
With limited staffing, the Eclipse team could only interact with a selected few
companies who were dedicated to creating an open tools platform. Interim board
members were selected from the companies that have contributed to the platform,
whilst in prototype form. Three criteria were also used: Board members'
companies must use the Eclipse Platform internally. They must also use the
Eclipse Platform to create commercial offerings. Finally, they must support the Eclipse.org publicly.
Why did you wait so long before making Eclipse open source available?
When a company plans to ship source code that will be scrutinized worldwide, the
development team wants to be sure the first platform is as thoroughly developed
and tested as possible. Several alternate design concepts were tried in
products, some of which have already appeared on the market. Those ideas were
then shared with other tool vendors and improved upon. The Eclipse Platform is
now ready for its debut.
If IBM places technology into open source distribution, does that mean IBM is no
longer committed to it?
IBM is committed to taking the Eclipse Platform and using it as a basis for an
entire family of end-to-end IBM application development tools: the
WebSphere® Studio family of products. These products benefit from
integrated QA testing, IBM’s legendary product support, and our commitment to
stand behind our IBM brand. They use the same interfaces and build upon the
technology shared with the Eclipse Platform.
Where do I get whitepapers and more information about Eclipse?
Visit Eclipse.org.
How does this differ from Microsoft® .NET?
.NET is designed only for use with Microsoft platforms, through a proprietary
interface that is dictated by Microsoft. As .NET changes, developers must react. In a
world characterized by so much more than "wintel" technology, .NET is at a considerable
disadvantage. End-to-end computing projects that need to integrate servers,
workstations, embedded devices, and handheld PDAs run on many other mature and
cutting-edge execution environments. This involves many powerful CPU architectures and
operating platforms like OS/390®, Linux®, and QNX.
Since Eclipse is available through the open source CPL, with all APIs and extension
points clearly documented, it allows tool developers to support any number of runtime
environments, including those from Microsoft.
How does Eclipse compare with the open source initiative from Sun
Microsystems?
The idea of its Eclipse Project is to create an "Apache for developer tools"
— an open source framework that provides many of the underlying services
software developers need. This would be a "toolkit for designing toolkits." Not just a
set of APIs, the framework will consist of real code designed to do real work.
"In Eclipse, everything is a plug-in. The Java IDE doesn't have a special status and is
just another set of plug-ins demonstrating the seamless extensibility of the platform.
Turning the Eclipse Platform over to an open source initiative enables tools builders
to do the same and to not only contribute new plug-ins but to also help improving the
existing platform plug-ins," said Erich Gamma. "As a result, large enterprises and
enterprising individuals have a level playing field for tool integration."
What is the difference between WebSphere Studio Workbench and the Eclipse
Platform?
WebSphere Studio Workbench uses Eclipse as the foundation for providing tool-to-tool
integration for products that support the WebSphere software platform. WebSphere Studio
Workbench is an instance of the use of Eclipse technology from the Eclipse Platform.
Eclipse is an open source tool integration platform, available for tool builders to use
to target any runtime environment.
They differ on four major points:
-
Support
— Eclipse is supported through the Eclipse.org
consortium, whereas WebSphere is supported through standard IBM support structure
(PartnerWorld).
-
Licensing
— The Eclipse Platform is available through the
CPL, whereas WebSphere Studio Workbench is available through a license from IBM
PartnerWorld
-
Derivative works/Source code modifications
— The Eclipse Platform
allows tools developers to explore new frontiers, target new platforms and operating
systems by extending and changing the code received from the Eclipse Project. The
WebSphere Studio Workbench must be integrated and distributed as supplied by IBM.
-
Branding
— Eclipse technology is not centrally branded. As an
ingredient brand, it can be adopted by members of the community as they release
compatible products. WebSphere Studio Workbench includes its own brand identity,
partnership programs, and support offerings.
When would I choose Eclipse, and when would I choose WebSphere Studio
Workbench?
To assist tool builders in which technology to use when constructing products,
determine the runtime tool environment to be supported:
- WebSphere only? Choose WebSphere Studio Workbench.
- Others, or new technology extensions? Choose the Eclipse Platform.
- Both? Choose after you assess the amount of synergy with IBM and the IBM partnership programs.
Are you willing to support the entire offering, both the Eclipse code and my own?
- Yes? Choose the Eclipse Platform.
- No? Choose WebSphere Studio Workbench.
Are you delivering tools for platforms that are not supported by IBM?
- Yes? Choose Eclipse.
- No? A selection based on the above two criteria is needed.
And if you want the formal support and participation available from IBM’s partnership
programs:
- Yes? Choose WebSphere Studio Workbench.
- No? Choose Eclipse.
Resources Learn
Get products and technologies
Discuss
-
The Eclipse Platform newsgroups should be your first stop to discuss questions regarding Eclipse. (Selecting this will launch your default Usenet news reader application and open eclipse.platform.)
-
The Eclipse newsgroups has many resources for people interested in using and extending Eclipse.
-
Participate in developerWorks blogs and get involved in the developerWorks community.
About the authors  | | | Marc Erickson serves on the ANSI committee studying standards for the software development process, and represents IBM on the Java Community Process Executive Committee for J2ME. Marc is now serving on the IBM team providing liaison and support to Eclipse.org. Now in his 28th year at IBM, Marc was recently the senior technical lead for IBM's North American Workflow Competency Center in Raleigh, North Carolina. A graduate of Southern Illinois University holding degrees in Data Systems Management and Data Processing, he joined IBM's subsidiary, Object Technology International, as Project Manager in 1999 to focus on the embedded computing marketplace. You can contact Marc at mre@us.ibm.com.
|
Rate this page
| 
