Aehso’s Output

On Eclipse.org project interaction (again).

Mike Milinkovich and Gunnar Wagenknecht picked up on my earlier post about Eclipse.org project disarray. It’s great to see the issue being discussed openly so I thought I’d clarify where I’m coming from (before someone jumps on me from a height).

On the topic of inter-project interactions, to me there are four main types of interaction

• pushing functionality down (”top down”) proposals
• promoting framework reuse by downstream projects (”bottom up” interaction).
• peer project driven cooperation (usually via refactoring to a common upstream project) as Doug describes.
• project “splitting” interactions, where a project splits to decouple unrelated components.

The comments on Mike’s blog have good examples of each and I suspect there are many, many more that might potentially make sense but have never even been broached publicly. I’ve witnessed obvious integration points being missed possibly out of ignorance - these top level projects are big, it’s hard to know them all inside out So, lots of interaction types.

To the external observer, the process for these interactions is to wait for one conscientious party to instigate ad-hoc discussions, perhaps on a PMC and/or a committer level (often facilitated by Bugzilla). We all know approach does work well for micro issues, years of practice in the OSS community proves that. It sometimes even works well for macro level issues where the parties know each other well and have a shared interest in cooperating.

But Eclipse.org is fostering frameworks that not only build on a common base platform (and sometimes shared sub-frameworks), it is publishing multi-tiered frameworks that commonly have interdependencies on each other. This is a more complex problem space to manage than, say, Apache Commons, or even Apache HTTPD. (That said, I do agree with John A’s comment that perhaps platform can be broken up a bit more - splitting Equinox was great, treating RCP as a separate top level project (away from IDE) might also make sense).

Macro level integration issues like proposing change of ownership of extensions or evaluating the risk of introducing dependencies on extensions developed elsewhere are sometimes contentious and they do not always progress via the above process. Sometimes they don’t progress at all and that in itself isn’t necessarily a problem, until the project hits 1.0. Then it has an API set to maintain that doesn’t fit with other Eclipse.org frameworks. The requirement to support 1.0 APIs is where the problem really starts hits home - before then projects are in their “honeymoon period” and I’m not sure the cost is fully evaluated by the younger projects. I think this is perhaps where the foundation (and Planning/Architecture Councils?) can perhaps facilitate a little more. Not necessarily driving or forcing these types of interactions, but mediating them, from the “bigger picture” perspective.

This point should be taken in the context of the recent explosion in growth of Eclipse.org, both in terms of new members and top level projects. It is a growing pain that the foundation needs to look at. As I mention above, the problem space that Eclipse.org is trying to govern is a little more complex than that of most OSS communities. Perhaps projects need to be monitored just a little in order to end up with a truely consistent framework.

1 Comment to On Eclipse.org project interaction (again).

1. 

   This all makes good sense. I didn’t refer to your previous post because I thought it was argumentative. I liked it, and thought it was asking some important questions that require an open discussion.
Mike Milinkovich on April 18th, 2006

Leave a comment