The 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.
