Open Enterprise

RSSSubscribe to this blog
About Author

Glyn Moody's look at all levels of the enterprise open source stack. The blog will look at the organisations that are embracing open source, old and new alike (start-ups welcome), and the communities of users and developers that have formed around them (or not, as the case may be).

Contact Author

Email Glyn

Twitter Profile

Linked-in Profile


Open Enterprise Interview: Mike Milinkovich

Article comments

A couple of years ago, I described the Eclipse project as open source's best-kept secret, and to some extent that's still true today. Even though most in the free software world have heard of Eclipse, they are probably unaware of just how far it has come from its origins as an integrated development environment for Java.

Today, the list of its projects is extremely impressive; more importantly, it has moved way beyond its initial focus on Java and development tools to address an increasing range of enterprise computing needs. The latest example of Eclipse's widening embition is Equinox, which joins the increasingly crowded runtime sector.

Here the Executive Director of the Eclipse Foundation, Mike Milinkovich, talks about how Eclipse has evolved, the component parts of the Equinox project, and why he hopes Microsoft will join Eclipse.

GM: It's very striking how the Eclipse project has evolved from relatively simple origins: why and how did that happen?

MM: That could easily be the subject of an entire book. Actually, I hope someday someone actually does write such a book.

Here is the most concise response I can devise: the secret sauce of Eclipse is that it has established the best available model for collaboration that spans both companies and individuals. I know that as developers we all typically focus on the technical innovations that Eclipse has delivered to the community. But it is the collaboration model that has spurred so many organisations to invest in Eclipse in terms of projects, committers and code. And that, ultimately, is what has driven the growth of the Eclipse community.

This model has allowed Eclipse to go through a series of evolutionary steps, starting as a Java IDE when it was first released, to a general purpose tools integration platform, then a platform for building rich client desktop applications, to where we are going now being a general purpose runtime environment for building and deploying applications on servers, desktops and embedded devices. The really interesting thing is that at each stage it was different community members that pushed Eclipse to the next step in its evolution.

GM: What has surprised you most about that evolution? Is there anything that you'd wish you'd done differently?

MM: The biggest surprise has been the speed with which the Eclipse community evolved from a handful of tool-focused projects to the over 90 that exist today. When I took this role at the Eclipse Foundation I was convinced that its ecosystem-based business model was the way of the future. But I honestly expected that growth would be slower and that it would take several more years to reach the stage we are at today.

The other thing that most people don’t appreciate is that the evolution is community driven. The Eclipse Foundation is not a software company that sets a strategy and then executes. We rely upon our community members to set the direction of the technology. It results in a very organicand dynamic environment that is very different from what I have experienced working in a corporate setting.

I am personally not one to harbour a lot of regrets. So no, there isn’t really anything I wish we had done differently.

GM: Obviously, the big news recently is the Runtime initiative: when and how did that come about? Who was pushing for it? How does it fit in with the rest of the Eclipse projects?

MM: EclipseRT is like one of those classical overnight rock-band success stories where the band had been together and touring for a decade. Now it is too early to claim that the project is a success, but it has clearly been several years in the making.

The starting point was probably the Eclipse 3.0 release in 2004. This is when the core development team decided to adopt the OSGi standard as basis of the Eclipse plug-in model. Out of this effort came the Equinox project that provided the light-weight component runtime that was the platform for running Eclipse but which has also proven to be very valuable for general purpose use. Developers in the community quickly discovered that they could take Equinox and use it as the platform for building rich client desktop applications. More recently, they started using it for server applications.

In parallel, organisations like comPeople (Riena), Innoopract (RAP), Oracle (EclipseLink) and Sopera (Swordfish) initiated Eclipse open source projects focused on server-side runtime technology on top of Equinox. As the number of runtime projects at Eclipse grew, it became obvious that coalescing this community into a single top-level project was the next step.

GM: Could you talk through the sub-projects - Eclipse Communication Framework (ECF), EclipseLink, Equinox, Rich Ajax Platform (RAP), Riena, and Swordfish - and say a little about what each does, and why you need them all?

MM: ECF is a framework that enables asynchronous point-to-point or publish-and-subscribe messaging and collaboration, e.g. chat, voip, p2p, in applications and tools.

EclipseLink is an object-to-relational and object-to-XML persistence framework that Oracle has open-sourced at Eclipse. The initial code contribution was based on the Oracle TopLink product. EclipseLink supports the full alphabet soup of Java-related persistence standards including SDO, JCA, JAXB and JPA. Within the Eclipse community, EclipseLink is breaking new ground as it is the reference implementation for JPA 2.0 (JSR317) and already has on-going project contributions from Sun.

RAP is a server-side runtime platform for creating Ajax applications. It allows developers to write applications in Java, using the Eclipse plug-in model, but with an Ajaxbrowser-based user interface. RAP provides a high degree of API fidelity with SWT so developers with experience in building Eclipse plug-ins for either tools or rich clients, RAP can quickly be productive with this project.

Swordfish is an extensible service-oriented architecture (SOA) runtime. The initial project contribution was based on code developed by Deutsche Post, and has been used for the past several years in mission critical deployments in their logistics business.

GM: What long-term impact do you think the Runtime initiative will have on Eclipse? What about on open source in general?

MM: OSGi is the component model for the next generation of innovation. And we are very excited to see a significant portion of that innovation happen at Eclipse.

In the long-term, this will make Eclipse relevant to many more parts of the enterprise IT organisation. Eclipse has been very successful at enabling an ecosystem of development tools vendors and service providers. This has allowed IT departments to build tools solutions to meet their needs. Equinox and our runtime initiative will bring the same level of flexibility to the runtime infrastructure. I also think it will generate a wealth of innovation in runtime technology, once a consistent and pervasive component model is used to assembling runtime stacks.

GM: What lies in the future for Eclipse beyond this latest initiative in terms of new projects and directions? What do you think Eclipse will eventually become?

MM: An important next direction is to involve more enterprises as first-class participants in Eclipse open source projects. Historically, the bulk of corporate involvement in open source has come from software companies. I expect we will see more industry-specific open source projects at Eclipse that involve committers that work at banks, insurance or automotive companies,

Eclipse itself will continue to be many things to many different people. However, at the core I firmly believe that Eclipse is really about how different organisations collaborate to build innovative and new technology. We have developed a model and best practices that seem to work and as organisations realise the need for more external collaboration, they will turn to Eclipse as the place to do it.

GM: When I interviewed you last year, you said that you would welcome Microsoft as a member of Eclipse: is that still the case? Has it talked to you about joining? Do you think it will join?

MM: Microsoft is definitely welcome to join Eclipse, as are all companies willing to participate under the same rules of engagement as the existing members. I don’t know if they will join, but I can say that I hope they do. There are a great number of interoperability issues that could be improved by working collaboratively at Eclipse.

GM: Internally there seem to be two warring factions at Microsoft: one that wants to play nicely with the OSI and open source, the other, very active around OOXML, that seems determined to fight open source and open standards tooth and nail. From your perspective, which faction has the upper hand at the moment? In the long term, how do you think Microsoft is going to deal with open source?

MM: I really cannot claim any knowledge of the internal dynamics at Microsoft. What I can say is that I am convinced that in the long term that Microsoft will realise that there is a compelling and profitable business model in open source. And when they do start to actively participate in open source, I hope they do so at Eclipse.

Email this to a friend

* indicates mandatory field






ComputerWorldUK Webcast

Advertisement
ComputerworldUK
Share
x
Open