Seeking a Balance
I just came across this post on John O’Shea’s blog. I think it raises a very interesting point:
Unfortunately, Eclipse.org is also starting to exhibit similar cracks. A cursory look at the architectures of many of the top level projects (WTP, STP, TPTP, BIRT etc.) shows the lack of intra-project cooperation is resulting in frameworks that simply don’t integrate with one another in they ways we all want them to. I’m not sure whether the PMCs are responsible for this failure or if it is also the committer’s responsibility to “fit in” to the larger Eclipse eco-system better.
My sense is that this is an interesting dilemma for Eclipse. On one hand, some want Eclipse to be a highly integrated platform with a seamless experience across platforms, languages and lifecycle. (Callisto is a modest step in that direction.) On the other hand, as an open source community some focus on diversity and innovation and are uninterested in the heavy hand of centralized authority.
Sort of a Cathedral versus Bazaar dilemma.
So what do you think? Where do we need to find the balance within the Eclipse community?
Interestingly, Callisto is an example of where the Bazaar worked in interesting ways. The idea to do Callisto came from the projects themselves. It was not an idea that came from the Eclipse Foundation.
Life at Eclipse 
Interesting question.The first example that comes to my mind are text editors. Long ago there has been a plan to pass functionality from the Java editor down to the platform. What happened? Now there is a structured source editor in WTP. Makes it more interesting to make both part of the platform.So how can we make it better? It’s all about process and human beings.Ever thought of giving committers the opportunity to work on a different Eclipse project in a different company for 3 months?
Gerd Castan
April 17, 2006 at 3:50 am
This is a great topic and something I’ve been concerned about as well. Having independent projects got us off the ground in a hurry, but to become truely great, the projects need to start working more closely together and share resources, solutions and ideas.We’ve somewhat run into this with the CDT and the projects that are working on similar things. They all want to leverage the groundwork that CDT has created and I am working hard to make sure these projects can leverage even more. I found the best way to do this is to involve them in what the CDT is doing, kind of making an virtual uber project around it. We can formalize some of this at the PMC level, but just having good relationships with members of the other projects can go a long way.
Doug Schaefer
April 17, 2006 at 9:01 am
I agree with Gerd here. It seems that alot of the popularity of Eclipse comes first from the Java editting tools. Other languages want to extend this area for there own use but they find it hard because the importat parts have not moved down to the platform. What does it take to make this happen? Shouldn’t that be encouraged from the Foundation level? Maybe the Architecure board?
Jim Adams
April 17, 2006 at 12:19 pm
Gred, Jim,To be honest, I don’t know how to make progress on migrating functionality from the Java text editors into the platform. We’ve been trying to encourage that from the Foundation level, and it has been discussed at the Architecture Council. But I haven’t seen any plans to do anything about it.Interestingly, where I see the most action along the lines of multi-language support is with Doug Schaefer and the CDT team. They’ve done a number of refactorings to make compiled language support easier on top of CDT, making it more of a platform.
Mike Milinkovich
April 17, 2006 at 12:29 pm
On the subject of pushing function down, I believe part of the problem is that the tree of dependencies between Eclipse projects is wide and shallow. For the most part, if two projects want to share some code, it must be pushed into the platform project because that’s the only common ground, even if the code in question is of absolutely no use in the platform itself. This leads to bloat within the platform, which does a great disservice to people in the community looking to use the platform to write lean and compact RCP apps.I wonder if, rather than a single monolithic platform, we could benefit from a “commons” sort of approach as taken by Apache. Plugins or features pushed into the commons could then be consumed by multiple projects as needed. The platform itself would only draw components from the commons that the base platform needs. Plugins in the commons would be stronly encouraged to have minimal external dependencies, so that those pulling components from the commons “a la carte” don’t end up sucking in the whole ball of wax. The commons would not be treated as a monolithic feature that other projects would incorporate as a whole.
John Arthorne
April 17, 2006 at 1:53 pm
John,I *love* that idea. How do you think we would go about making that to a reality?
Mike Milinkovich
April 17, 2006 at 2:48 pm
I can only support what John said, but it will be hard to solve. Funnily I have an actual current issue with Apache Commons itself – I need to use Apache commons source, so I wrap it in a package. But who does that for eclipse? Logically we need a (small) project to manage this – but who benefits? Who gets enough from the existence of the project to get involved? That’s my issue with John’s proposal – a great idea, but who actually wants to do it?
Grahame
April 17, 2006 at 10:26 pm
I think it’s not a question of who wants to do it. It’s more question of how flexible is the process behind it.I don’t think what we have a monolithic Platform today. Sure there are a lot plug-ins in the Platform but they are plug-ins. That means each one can be pulled out separately. When I build RCP apps I don’t pull out everything from the Platform. It gives me a free choice of what I wand to use it my project. This doesn’t sound like a monolithic Platform to me, does it?Anyway, the commons approach doesn’t make sense if there must be a complete new project environment created for it with a long process and discussion list involved. But it does make sense if there is enough support for it from all the other team and existing projects.I’d be happy to create this proposal and keep an eye on this just because I know the pain of not sharing code. I’ve filled a bugs and had a lot discussions about this topic in the past. But this project will not be a carte blanche for anybody to put anything on it and don’t feel responsible anymore.
Gunnar
April 18, 2006 at 7:27 am
I should first mention that I was only picking up on a relatively minor point in the discussion. While having a code commons may help, it doesn’t address the original point about problems with interoperability and consistency across top-level projects. Issues such as this sound like a discussion topic for the architecture counsel, or for discussions amongst the PMCs of the projects involved.I suppose starting a commons would be as simple as setting up a new project. It does sound similar to the tools and technology projects – technology being the incubator and tools being like the commons proper. It seems the main difference is the granularity of the components in the commons -is it a plugin, a package, a feature? In the Apache commons they say the granularity is packages, but in practice it tends to be a cluster of tightly related packages. In any case, it sounds like a good discussion to start *after* the Callisto release – I think everyone’s pretty swamped with getting that out the door at the moment 😉
John Arthorne
April 18, 2006 at 11:31 am
I think it was very sad the LDT proposal died. A part of that project was to migrating functionality from JDT (incl. text editors) into the platform (or the “toolkit” to be more precise).With a strong LDT as a part of the platform a lot of developer-oriented projects would not have to re-invent the wheel.
mortench
April 18, 2006 at 12:21 pm
John,I agree on all points. It is a larger topic that we need the Architecture Council to step up to. The commons idea is worthy of further discussion after we’ve all survived Callisto.
Mike Milinkovich
April 18, 2006 at 3:20 pm
I also like John’s idea of a ‘plugin commons’. It would be a natural ‘home’ for successful technology projects…but without the ‘undue burden’ of having to be adopted into the platform to get real usage across projects. Choosing between platform bloat and having otherwise good work be dead-ended is not necessary given Eclipse’s strong plugin nature, as Gunnar makes clear.Perhaps a ‘commons’ project could also have features that combine plugins from one or more technology/tools projects to address certain functional areas: e.g. ‘net’, ‘logging’, ‘vfs’ (these are from apache jakarta commons). More Eclipse-API-appropriate may be categories of API functionality like ‘messaging’, ‘identity’, ‘authentication’, ‘soa’, ‘modelling’, ‘persistence’, ‘model transformation’, ‘editors’, etc. I agree that surviving Callisto has got to be main focus for next two months, but I would hate to have this notion fall of radar.
ECF Team
April 18, 2006 at 11:34 pm
I have some thoughts here too. Decided to put them on my blog, if only to get more folks over there reading it. 🙂
John Graham
April 24, 2006 at 3:36 pm