Mike Milinkovich, Executive Director, Eclipse Foundation

Mike MilinkovichThe Eclipse Foundation is one of the key open source development communities.

Its namesake IDE, according to a recent study, is widely used and expected to gain share.

But Eclipse is much more than just an IDE. The Eclipse Foundation’s

recent Callisto event marked the release of no fewer than 10 different Eclipse platform projects, covering IDEs, business intelligence reporting tools, data tools and a graphic modeling framework, among others.

Sitting at helm of the Eclipse Foundation is its Executive Director Mike

Milinkovich who has been in that position since it was created back in 2004. The position was created just three months after Eclipse became an open source foundation.

Milinkovich recently chatted with internetnews.com about his role at

Eclipse, why having paid developers matters and the differences between it

and other open source development efforts such as Apache, SourceForge.net and

Mozilla.

Q: What challenges do you face in your role as the executive director of the Eclipse Foundation?

My role is pretty interesting. A lot of people make the mistake of thinking

that my role is like being the CEO of a software company, but it’s actually

nothing like that.

You can sort of think of me as one of the visible

cheerleaders for Eclipse. We provide hosting, infrastructure and support for

the projects. I most definitely do not tell the projects what to do.

My challenge is really around trying to deal with the growth of Eclipse:

making sure that we have processes in place to ensure the cleanliness of the

code that is coming from the projects; that the projects are well served in

terms of their IT and infrastructure support and that they have what they

need to develop their projects.

And to provide a focal point for the marketing of Eclipse projects, raising

awareness and bringing on additional participation within the community.

Q: Eclipse has made its major releases on a predictable schedule for

three years now. Does the aggressive schedule mean that not everything ends up in the releases? Does it affect quality?

We actually think we ship high-quality software. No software is bug-free, but

there is a strong ethic within the Eclipse community that you do fix the

critical bugs.

In any software project, there are always three variables: the functions

you’re going to ship; the schedule you’re going to ship on; and you’ve got

the resource that you are going to be working with.

If you assume the schedule is fixed and the resources are fairly fixed, then

obviously the variable is the function. What is it that you’re going to fit

in to the release? What we try to do at Eclipse is to be fairly

conservative about the actual function that is promised as part of the

release.

Typically at the beginning of the year, there is a relatively small list of

features that are committed. The features that are absolutely going to be

there is a relatively short list. There is a fairly lengthy list of time-available features, where we’re hoping to get to them but we’re not going to

commit to it at this point.

As you go through the year, you see things move

from “time available” to “committed” as they are more confident that they can

get it done.

What we try to do basically is under-promise and over-deliver.

Q: Certainly Eclipse is an open source framework and an open source group,

but is it true that the bulk of all contributions come from large

enterprises and the bulk of developers is employed by those same large

enterprises?

It is true. But when you say large enterprises, it’s primarily large ISVs.

Roughly 85 percent of committers that work on Eclipse projects are full-time,

paid employees of member companies.

That’s not the visible norm within much of the open source community.

The thing about it is that it’s something that is working well for us. I’m

not sure it would transplant well to other open source communities. There are

certainly other open source communities out there that are very viable with

a strong ethic of having close to zero corporate involvement.

Some of the positives are the notion of predictably, which is much more

possible when you have full-time staff working on the projects. If you are

entirely volunteer staff, it’s a lot more difficult to hit specific dates.

Q: What about member company corporate agendas? How do you correlate the

ISV’s agenda’s for a given project with those of Eclipse?

It’s an interesting thing. My observation is that when people talk about

corporate involvement in projects, the concern is really around diversity to

a large degree. If one company changes their mind, then the whole project

goes into the tank.

We definitely have individual projects at Eclipse that are still largely

staffed by just one company, so we’re not perfect in this regard. But the

observation I’ve made is that if you have enough different companies

involved in a community so that, yes, they are still individuals working for

companies but you still have diversity at the organizational level, you can

still have a very diverse community.

Eclipse has a very open multi-organizational governance model where there is

no one company with a special vote or special authority. Having that open

transparent governance model coupled with a broad group of companies that

actually does work.

Q: Does Eclipse’s governance model help differentiate from other open

source communities such as SourceForge.Net or Apache for example? Or is it

Eclipse’s focus on tooling that is the differentiator?

We have historically been focused on tooling. But things like rich client

platform the new rich Ajax platform, we’re definitely getting out of tooling

and more into run-time scenario. The tooling thing is really just a point in

time.

That said I think governance is extremely important.

Apache is very volunteer-driven, and we frankly shamelessly copied a lot of

ideas from them about how to run open source projects, how to establish PMCs

[project management committees], focus on openness, transparency and

meritocracy. Those were ideas first formulated within Apache.

SourceForge doesn’t have a governance model per se. It’s a place where you

can go and build your open source project however you want to govern it.

Mozilla for example has basically turned into a software company with a

shareholder which is a non-profit. There is another unique model.

One of

the things that Mozilla does that we don’t is that the Mozilla company

employs full-time committers. Whereas, the Eclipse Foundation, we very

consciously don’t. We don’t staff Eclipse projects from within the

foundation.

Each one of these communities has a very unique history; there is usually

some correlation to licenses and business models, and I think it’s really

interesting the way open source has shown itself to be successful.

Q: Are you aware of any barriers to adoption for Eclipse?

Eclipse has a very good track record of being backwards-compatible from

release to release. From a pure technology point of view, one of the things

that differentiates Eclipse from other open source communities is that we

take the APIs for our frameworks very very seriously and do maintain them

from release to release.

To be honest I’m not aware of any specific barriers to adoption.

News Around the Web