In the late 1990s, IBM began development of what we now know as Eclipse. Today we see high adoption rates and evidence of successful application of this technology across the software industry. The purpose of this article is to review the inception of Eclipse, to illustrate the role it plays in today's development tools, and to convey how we see the technology evolving over time.
The development tool landscape of the mid-to-late 90s
In the mid-1990s, a number of powerful commercial development environments were available; Microsoft Visual Studio was becoming a more general-purpose tools platform. A number of Java-based IDEs were also coming into play, including Symantec's Visual Café, Borland's JBuilder, IBM's Visual Age for Java, and others.
This period also saw the emergence of application servers designed to decouple a client-side programmer from the many details found in the operating system and associated interfaces. For Java development, the marketplace offered us IBM's WebSphere Application Server, BEA's WebLogic, and Sun's iPlanet suite. From Microsoft, MTS and COM+ were the runtime environments in play at the time.
IBM's primary goals
This landscape actually contained two worlds: one centered on tools that enabled Microsoft's directions on runtime execution support, the other focused on a more open industry approach centered on the Java platform. Confident that a more open approach to IT was the best way to ensure its customer's long-term success, IBM saw Java development tooling as key to enabling growth in the open community. So its goal at the time was to bring developers closer to Java-based middleware.
We wanted to establish a common platform for all IBM development products to avoid duplicating the most common elements of infrastructure. This would allow customers using multiple tools built by different parts of IBM to have a more integrated experience as they switched from one tool to another. We envisioned the customer's complete development environment to be composed of a heterogeneous combination of tools from IBM, the customer's custom toolbox, and third-party tools. This heterogeneous, but compatible, tool environment was the inception of a software tools ecosystem.
Building the technology: The emerging role of open source
In November 1998, IBM Software Group began creating a development tools platform that eventually became known as Eclipse. We first built a new Java IDE with resources from our Object Technology International (OTI) labs, along with the broader platform to go with it. The OTI team had extensive experience building several generations of IDEs with small, highly skilled teams. At the same time, the larger IBM began setting up additional teams to create new products built on top of this platform.
We knew that a vibrant ecosystem of third parties would be critical for achieving broad adoption of Eclipse. But business partners were initially reluctant to invest in our (as yet unproven) platform. So in November 2001, we decided to adopt the open source licensing and operating model for this technology to increase exposure and accelerate adoption. IBM, along with eight other organizations, established the Eclipse consortium and eclipse.org. Initial members included (then-partners) Rational Software and TogetherSoft, as well as competitors WebGain and Borland. Membership in the consortium required only a bona fide (but non-enforced) commitment to Eclipse to use it internally, to promote it, and to ship a product based on it.
The consortium's operating principles assumed that the open source community would control the code and the commercial consortium would drive "marketing" and commercial relations. This was a new and interesting application of the open source model. It was still based on an open, free platform, but that base would be complemented by commercial companies encouraged to create for-profit tools built on top of it. Most of the committers and contributors to Eclipse came from a short list of the commercial vendors, with IBM being the largest contributor of both content and financial and staff resources.
But is it really open?
By 2003, the first major releases of Eclipse were well-received and were getting strong adoption by developers. But industry analysts told us that the marketplace perceived Eclipse as an IBM-controlled effort. Users were confused about what Eclipse really was. This perception left major vendors reluctant to make a strategic commitment to Eclipse while it was under IBM control. If we wanted to see more serious commitment from other vendors, Eclipse had to be perceived as more independent -- more decoupled from IBM.
So we began talking to others about how a more independent concern could take control of Eclipse so as to eliminate this perception. Working with these companies, we helped formulate and create the Eclipse Foundation. We then announced the new foundation, just in time for EclipseCon 2004, as a not-for-profit organization with its own independent, paid professional staff, supported by dues from member companies.
Results to date
The move has been a success. The new and independent Eclipse Foundation shipped Eclipse 3.0, and soon afterwards, Eclipse 3.1; both were received with even higher degrees of interest and adoption rates than the prior version. Soon afterwards, Eclipse 3.1 was released to resounding interest. We've seen dramatic growth in membership at all levels, and a deeper commitment by all independent tools vendors and most platform vendors. The Eclipse Foundation and its members made a number of announcements at EclipseCon 2005, including the emergence of powerful Eclipse projects such as Rich Client Platform, Web Tools Platform, Data Tools Platform, Business Intelligence Reporting Tool, and a dramatically reduced level of fragmentation in our efforts.
We've seen exciting levels of growth in Eclipse commitment and support. There are now twelve strategic developer member companies, each of whom commits at least eight full-time developers and up to $250,000 annually to the Eclipse foundation. The Eclipse Foundation also has four strategic consumers who also make a similar economic commitment. There are sixty-nine companies serving as add-in providers, and another thirteen associate member companies. If you peruse the software industry, you'll find hundreds of commercial plug-ins and products for Eclipse. Eclipse is now the industry's major non-Microsoft software tool platform.
IBM and Eclipse
In December 2004, IBM Rational aggressively revamped its product portfolio to move to a more Eclipse-based foundation. We referred to the result as the IBM Rational Software Development Platform, which includes new and improved products from IBM Rational, all built directly on top of the Eclipse platform, as illustrated in Figure 1. The platform also includes other lifecycle support tools that were already integrated with Eclipse.
Figure 1: As of December 2004, IBM Rational tools for the major roles in the software lifecycle are built on top of the Eclipse platform.
In this new platform, the developer role offerings extend the base Eclipse IDE with additional functionality to make developers more productive. We also created tools optimized for other practitioner roles throughout the application lifecycle, and, by leveraging the underlying mechanisms of Eclipse, we expanded the applicability of Eclipse across the lifecycle. Eclipse has become our next-generation tools integration platform.
A look into the future
IBM created Eclipse and is more committed to it now than ever. Eclipse is stable, mature, and independently managed. Most companies no longer view Eclipse as risky and, in fact, are comfortable starting with base Eclipse and adding support services and additional tools in an incremental fashion. We see commercial vendors evolving to support this shift, poised to offer more componentized versions of both value-added tooling and vendor support services. And as Eclipse and its associated plug-ins continue to grow, the Eclipse Foundation will be well-positioned to manage that growth and resulting complexity.
Historical content for this article was derived from a presentation developed by Lee Nackman, chief technology officer for IBM Rational software. Product strategy and marketing directions were derived from market management materials developed by Gary Cernosek.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.