In this post Mike refers (and answers?) to a blog posting from John O’Shea. John is complaining about the architecture and interoperability of several Eclipse top level projects (named WTP, STP, TPTP, BIRT).
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.
Honestly, I partly agree with John but more from a usability point of view. Ok, that’s another topic. 😉 But I think we have to remember that all these projects are very young projects compared to the Eclipse top level project itself. You can’t expect to get everything done in release 1.0, 1.5 or even 2.0. AFAIK the first goal was to successfully establish the projects on Eclipse.org and to create a vital user, developer and adopter community. With Callisto I’m expecting this goal marked as fixed.
I also agree that one of the next goals should be concentrating on areas where the projects can create more interoperability. But again, I have to remind that work on this topic has already started in the past. It’s is an ongoing long term goal that can’t just be solver over night or with the next release. For example, the common navigator framework and the tabbed properties view are two good solutions that were contributed to Eclipse as part of the initial WTP contribution and are now integrated into Eclipse 3.2.
On the other side, there are indeed examples of projects creating their own solutions to a very common problem that is better solved at a platform level. I accidentally came across such an issue on the weekend when I was talking to a guy on IRC. He just asked a question about a problem registering selection listeners to workbench parts. Well, I’m a curious guy and I was wondering why someone is watching part activation and registering selection listeners to every single workbench part when there is the workbench’s selection service. So I just asked him and we had a very interesting talk. During this conversation it came out that one Eclipse.org project was trying to create there own data binding framework. Well, that’s crazy and definitely not along the line of Eclipse.
But how to avoid this in the future?
In my opinion it’s all about communication, openness and transparency. This is the great advantage of open source development. But it can only be successful if it’s practiced by all involved parties. The issue above just turned out to be caused by a lack of openness and communication. They started developing their own data binding framework because they didn’t know about the JFace data binding framework. You now may ask why is this a problem of openness and communication? Let me explain.
Openness is not only about opening your software and your processes to a community. It’s also about opening yourself and your mind to the input from the community. The same goes for communication. Communication is not only about starting telling everybody what you are going to do but also about starting listening to the community what they do and what’s going on there.
Referring back to the post of John, he asks who is responsible for avoiding miss-interoperability at Eclipse. I think in the example above it’s hard to blame anybody. The project is really young and I bet due to the lack of communication the PMC didn’t know about this. I also don’t think that you ever can blame somebody specific for such issues. It’s the community including committers, leads, PMC members, Eclipse.org member companies and councils that has to demonstrate and practice their openness, transparency and communication skills.
1 thought on “Isolated solutions”