BOSTON --As developers gathered at EclipseWorld 2006 last week, Eclipse Foundation executive director Michael Milinkovich...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
sat down with SearchOpenSource.com for an update on his wildly successful open source collection of plug-ins for Web services and Web development.
In this exclusive interview, Milinkovich explains how his organization was able to effectively deploy 10 projects simultaneously to Eclipse developers while proprietary vendors struggled to even get their code out the door at times, and why having a lot of plug-ins is great so long as IT managers can find them effectively.
SearchOpenSource.com: The modular design of Eclipse is popular amongst developers, and recently you were quoted as being proud of the design's success. However, with the number of plug-ins available today via Eclipse, is there a danger for IT managers of being overwhelmed?
Michael Milinkovich: Absolutely. But I would characterize [it] differently. I don't think there is any such thing as too many plug-ins. You do want to create a very large ecosystem of components and open source projects and build components that fit within [the] Eclipse platform. It's not so much a danger of having too many; the danger is in terms of making the user experience too complex. I think we're already hitting that point. There is at least one Web site out there that has 1,000 Eclipse plug-ins in its catalog, and some of them are great and some are not so great. Some are very active and some have been sitting there inactive for quite some time. There really is no way to tell which is which at this particular Web site.
So what we're actively working on both at the Foundation and with membership and [the] vendor ecosystem is [to] make it easy for developers to find the right plug-in for the task at hand and make sure they are satisfied with the quality of what they're getting.
Can you get more specific about what you mean when you say you're working on making things easier for developers to choose the right plug-in?
Milinkovich: The first step was completed in June with the shipment of the Callisto simultaneous release. [Note: Callisto was a simultaneous release of ten Eclipse projects.] Why that was important was because for the first time we pulled together a significant subset of projects at Eclipse and sent them out together. This was done so we didn't have some of the urgent management issues with things like version mismatch plug-ins, and it provided a much better download experience for developers who wanted to put together an environment that had a number of Eclipse projects.
One of the other things we're doing is working with the Eclipse membership to make links to member downloads available on our site where we put together some sophisticated user interfaces to select the plug-in that a user wants and then bundle them together for them.
We've already scheduled another release train next year, and it looks like we'll be labeling it Eclipse Europa. We are still in the early days of that release, but I anticipate additional developer work on that release chain will provide better end-to-end user experiences when developers put together plug-ins on the desktop.
Eclipse has been praised for the smoothness of the Callisto release, especially when compared to similar efforts by proprietary vendors. How much of an impact did being open source have on this 10-project deployment?
Milinkovich: I would point first to the people working on all of the projects as opposed to the staff and Foundation. David Williams, who happens to be an employee of IBM, acted as coordinator of [the] release and spent a lot of hours making sure it was successful. The main difference [between Eclipse and close source vendors] is not the people, because there are a lot of proprietary companies with good people, but the technology, processes and the component model. Eclipse has a very nice, very clean component model, which allows projects to interact with a well-defined interface. The dividing line for what is a single project and what is combined work is very clear.
I think that in large companies there is a tendency to fall into a trap of making things too tightly coupled. For example, there are reportedly over 40 layers within Windows Vista that tie everything into a big hairball of code. If you ask me, I think the largest software company in the world has forgotten how to sell software.
Has JBoss's acquisition by Red Hat had any effect on the Foundation at all?
Milinkovich: None. Red Hat and JBoss were both members, and the net effect is that we lost one member. We're growing significantly, however, so it has not impeded our growth or resulted in financial hardship. Frankly, within software business, if you are not ready to roll with mergers and acquisitions then you are not paying attention to the way the world is going. I think in many ways [the acquisition] was a good thing because it's getting Red Hat more into the enterprise middleware space, and JBoss has been a strong supporter of Eclipse. To date, Red Hat's presence in Eclipse has been around C++ and not Java anyway.
How high is the level of interest for virtualization at Eclipse right now?
Milinkovich: At this point in time, virtualization at Eclipse is primarily in the very early stages of its lifecycle. There are some modeling developments, some tests, some monitoring, and we do expect to see Eclipse grow into the systems management space down the road. When that happens we do expect that virtualization is something we will have to take into account. Certainly in the embedded space and debugging tools for multi-core chipsets are some of the things we are actively working on today. Ultimately, the answer for virtualization is 'not right now,' but we do expect down the road it is something we will be involved in.