Mike Milinkovich, Executive Director, Eclipse Foundation
Page 1 of 1
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.