In November 2001, IBM announced it was contributing what it termed $40 million worth of software that it had developed as an internal developers' workbench to an open-source project it dubbed Eclipse.

Last week, at the Embedded Systems Conference in San Francisco, the state of Eclipse was reviewed at a roundtable discussion of four participants in the project and an Eclipse user. They were:

The panel was moderated by Charles Babcock, InformationWeek's senior writer for integration/Web services.

IW: How is Eclipse different from a standard development environment?

Erickson: Eclipse is an integration framework itself. It's a microkernel. The core of the basic platform is built in the same way as all the tools that extend it are built. It was engineered as an environment where many different companies could come together to support one tools platform. More than 100 plug-ins exist for it right now.

It's a microkernel framework on top of which you can create an integrated development environment for Java. You can plug in a C++ IDE. Or a Smalltalk IDE. The architecture is agnostic. It doesn't care what you're working in.

IW: Who's using Eclipse?

Bialowas: We've evangelized Eclipse to our biggest customers in the telecommunications industry. Ericsson recently joined the Eclipse board. They're a company that has hundreds of projects and hundreds of tools. They believe Eclipse will lead to the tool interoperability that they've been looking for.

IW: That's fine for the IT shops, but does it help embedded developers?

Marineau: The embedded market has traditionally been very fragmented in types of tools and types of development environments. An embedded developer might have one tool to compile, one to debug, and another that lets him profile or analyze what's running on the target platform. Eclipse let's a lot of different tools fit into a workbench so you get a single integrated development environment.

Bauer: It's coopetition. It helps the embedded community.

IW: Speaking of coopetition, where's Sun Microsystems when it comes to Eclipse?

Erickson: Eclipse has extended the invitation for Sun to join. We've not had a response yet. But the door is certainly open.

IW: The big question is, where does Microsoft's .Net fit into Eclipse?

Erickson: The door is open for Microsoft participation. They're both [.Net and Eclipse] very advanced technologies. The biggest difference is you have to go into a partnership relationship to get access to [Microsoft's] layer that allows you to build a tool that interfaces with them. The Improv Technologies Inc. people in France are producing a C# development environment for Eclipse, which shows .Net technologies can be made to work with Eclipse.

IW: What's the difference between the Linux general public license and the Eclipse common public license?

Songer: As far as we're concerned, the GPL is the devil.

Bauer: As a Linux provider, I might disagree with that.

Songer: The GPL is very difficult to deal with because any time you add something to GPL code, you end up giving rights to that code to your customer and the right to redistribute... It's very hard to retain ownership of your core differentiation and the patents. The CPL is much easier to work with and retain ownership of [your intellectual property].

Erickson: The goals of the CPL were to make a level playing field and make it easy to participate with open source, yet have enough protection [to retain proprietary value].

Bauer: From an end-user perspective, there's no licensing issue. It's a tool, you license it from a provider [a typical commercial license from a value-added software supplier] or you download [an open source version] from Eclipse.org and plug things into it.

IW: Is there any synergy between the way Eclipse works and the way Linux works?

Bauer: There isn't really a set standard for development of embedded Linux. Tools tend to be specific to a vendor. Eclipse lets us come together. We didn't want to be in the business of building a tool box. We wanted to be in the business of building very specific tools, wrenches, screwdrivers, and hammers.

IW: Where can you go from here?

Erickson: We have built the base to take the development process further. The Object Management Group has a meta-object facility for interfacing a Unified Modeling Language object [a design of a software program in a standardized format for automated coding] to tools. We've incorporated a subset of that into Eclipse. We're seeing the technologies build upon one another right away.

IW: Is it helping in any particular area?

Erickson: Source control is amazingly fragmented. Everybody has their own preference. Some like Rational's ClearCase, some like Perforce Software's Perforce. Some like Merant's PVCS. In the end, the Eclipse framework allows all of these people to use whatever one they want.