As Chris and John describe later in this book, the Eclipse Project began in 1999 at IBM’s Object Technology International (OTI) subsidiary. At the time I was CEO and president of OTI and so was very involved in the decision to proceed with Eclipse, which was initially conceived as a successor product to the VisualAge family of software development tools. VisualAge, especially VisualAge for Java, was a commercially successful IDE. But it was also a closed environment built on proprietary APIs and did not integrate well with other vendors’ tools. Only the IBM/OTI team could enhance or extend the product. Beyond these issues, though, it was becoming apparent from customer feedback that more was required than a simple rewrite of VisualAge. There was growing demand for a tool integration platform—a programming environment that would not only provide kernel IDE functionality but also allow developers, third-party vendors, and users to seamlessly add their own extensions, personalizations, and enhancements.

The vision of the Eclipse Project team was to extract the essential infrastructure underlying VisualAge—or any other IDE for that matter—and to package and deliver it as a platform. In effect, the team wanted to strip out all the IDE functionality that was specific to a particular programming language, development task, or programming model. The hope was that there would be substantial residual function left behind that could then be restructured to form a content-neutral and programming language-neutral foundation on which IDEs and similar products could be built from components. It was a bold venture, as there was no guarantee that anything practically useful would result, and there was certainly a lot of soul-searching and hand-wringing in the early days of the project.

The result was Eclipse: a tool integration platform together with a set of components—“plug-ins” in the Eclipse vernacular—that could be seamlessly assembled into a wide variety of software development products. The Java development tools (JDT)—the Eclipse Java IDE—became our proof-point. It was built in parallel by a separate team, led by Erich Gamma of Design Patterns fame, that operated independently from the Eclipse Platform team. The JDT team had no special privileges; it had to use the same API as any other third-party product and was allowed no “backdoor” access to the Eclipse Platform. The intent was that, despite these constraints, the finished JDT should be indistinguishable from a purpose-built, vertically integrated IDE product like VisualAge. Of course, this goal was in fact realized, the Eclipse Project was a success, and the Eclipse community was born.

In the two years since the Eclipse code base was released into open source by IBM, its growth has been quite stunning, especially for those of us involved at the beginning of the venture. It has without question exceeded our wildest imaginings. Tens of thousands download the Eclipse SDK every week from more than 50 mirror sites around the globe. Thousands of Eclipse plug-ins are now available from open source and commercial suppliers. Software vendors are now shipping several hundred commercial products based on Eclipse. As of June 2004, approximately 50 companies are members of the Eclipse Foundation, which hosts Eclipse open source development. The first Eclipse Developer Conference—EclipseCON 2004—was held in Anaheim in February 2004, with more than 220 companies and organizations and nearly 25 countries represented.

Although I had a very amicable separation from OTI and IBM a couple of years ago, I continue to be actively involved with Eclipse. My main role today is leading the Eclipse Foundation Technology Project, whose mission is to engage the research and academic communities. And, of course, if you want to know more about this, Chris and John have provided a very nice section in the Official Eclipse 3.0 FAQs on this subject. It has been particularly interesting for me to see the uptake of Eclipse within the research community. In retrospect, one could perhaps have anticipated this. Software researchers necessarily build on the work of those who have gone before, and, of course, as time progresses our technology pyramids keep getting higher. Complexity is our nemesis—the low-hanging fruit was picked long ago, and most interesting problems are not simple anymore. Consequently, experimentation usually requires complex infrastructure, “plumbing” as we often call it. Most researchers spend far too much time building, rebuilding, and fixing this plumbing and far too little time developing new ideas. Given the nature of research, there are seldom any applicable standards for such infrastructure; these come only much later, when the research has matured into products. Consequently, researchers up to now have had to live and work in their own vertical towers, sharing their ideas but only infrequently sharing code. Eclipse has fundamentally changed this context, however, by providing a means to create and share that necessary common infrastructure, particularly for investigators in such areas as programming languages, tools, and environments. Researchers can focus more of their time on their real mission—innovation—and much less on the hated plumbing tasks.

So when Chris and John approached me to write this foreword to their new book, I was flattered and pleased to be asked but also, I confess, a bit perplexed. I had known and worked with both for many years at OTI and held both in high regard. I recruited Chris to help us start a new development lab in Amsterdam in the mid-1990s. The venture was a great success, and Chris developed into a very fine lab director, despite the usual hurdles and bumps along the way, which probably had a lot to do with the good friendship that developed between us as we worked our way through these. John joined OTI as a coop student and rose through the ranks, as it were, invariably choosing to get down and dirty working in middle- and low-level system code—making compilers work and that sort of thing. So even without seeing their book, I was sure that it would be a worthwhile addition to the Eclipse portfolio. But not having worked closely with either for several years, I was not exactly sure what they were up to or what the book was trying to accomplish.

It was a genuinely pleasant surprise when I looked at it. In my role as the “Eclipse outreach person” for research and academia, I get “How do I do this with Eclipse” questions continually, and I am a long way from being an Eclipse expert. In fact, as Eclipse has grown and become both deeper and broader as a platform, it is probably true that no one is an “Eclipse expert” any more. Official Eclipse 3.0 FAQs immediately struck me as a great idea. For one thing, I can, and do, use it myself. But more important, I hope that it will give the thousands of users and developers who venture into Eclipse for the first time the courage to just dive in and get started, knowing that they have a life jacket to keep them afloat and a compass that will guide them through the experience. For the more experienced hands, I suspect that this book will become a (virtually) well-thumbed desktop reference, there to remind you of all those things you know you know but can’t quite recall. For many, it will likely be the plug-in version that they will reference and use most often, although I suspect that a few Luddites are out there, who, like me, on occasion still enjoy the reassurance and tangibility of the printed page.

I also happen to think that the emphasis on the Rich Client Platform will prove to have been prescient. After a few years of experimentation with browser-based applications, there has lately been a resurgence of interest in old fashioned desktop apps—the “fat client” seems to be back but this time in the guise of a tonier, slicker, and more sophisticated “rich client.” The rich client has learned some ease-of-use and desktop-management lessons from the Web browser and aims to offer a much better out-of-the-box experience. It remains to be seen how this is all going to play out in the marketplace, but Eclipse seems very well positioned to provide a development platform for this new generation of rich client applications. As we have seen with the research and the academic communities, nothing succeeds quite so well as being in the right place, at the right time, with the right function. So the emphasis that Chris and John have placed on this topic is timely, to say the least.

Finally, I have to say that I think the decision to write the book entirely as a plug-in was very bold and very cool. It has a certain self-referential flavor to it which is very appealing to old Smalltalk programmers, such as Chris and John and yours truly. And it provides a very nicely integrated addition to the online documentation already available for Eclipse programmers and users. Whether you are an experienced developer, a newbie, an end user, or simply a curious bystander wondering what this Eclipse excitement is all about, I recommend this book to you. I guarantee that it will be both a good read and a great investment.