But now we know: OK, e4 is a place to showcase the experimental code and grow ideas about the Eclipse 4.0 platform, not some coup d'etat. OK, the perception is not reality, just unfortunate communication. OK, the platform team wants to solicit feedback from the community. OK, so you would rather show it in code than in colorful diagrams (given the audience, that makes sense).
My day job is in software architecture, and not in Eclipse at all (which makes me a very small fish indeed). However, it also gives me a different perspective in which to view this controversy: It's the architecture, stupid. The future of the Eclipse platform is not just about the code, it's also the scope, the requirements, the stakeholders, the constraints, the APIs, the process, the resources, and it's the dependencies and dependents of the very heart of Eclipse. In that respect, we still don't know anything about e4.
Eclipse is built on a strong architecture, and architecture is all about keeping the stakeholders happy, but it looks as if there's still serious uncertainty with a number of stakeholders:
- What is being worked on here? Are we talking runtime / SWT / RCP - stuff? Is this about the "IDE meat", where a lot of the identified "biggest architectural problems" reside)?
- Why is this going on? Or, which requirements or innovations are going to be driving the effort? Why is this more important than anything else?
- When is all this going to happen? (should we expect a 3.5 in 2009?)
- How are you planning to do this without creating adverse effects for stakeholders?
- Where will the impact be - will this be a distributed effort? Where will the parts which currently make up the Eclipse Platform end up (in case of a refactoring effort)?
- Who gets to decide and prioritize? And implement?
For humans, a common reaction to change and uncertainty about is to expect the worst, especially if you feel like you are out of the loop. OK, we know now that part of e4 is to find the answers to the questions above, except perhaps the first "who" which I would expect should be the architectural council (whose mailing list is just buzzing with e4 activity right now). There are processes in place to mend this.
But shouldn't we always start with the "why" rather that the "how"?
5 comments:
Very well put Jesper. I think you hit the nail on the head. The e4 team wants to show code. That's the way they think and the way they want to communicate. Unless you are like minded, though, it's pretty tough communication to receive and understand, especially since it doesn't explain the why.
And I have a feeling there will be a lot of disagreement on the why which makes me wonder if the code they are doing will be a waste of time in the end. A short document would have helped.
Jesper - Did you attend the E4 talk(s) at EclipseCon? I'm curious if you thought they did a good job of explaining the "why".
Alas, no, I didn't attend EclipseCon - my "day job" isn't around Eclipse, so going would be hard to justify... Next year, I hope!
I can see a broad selection of EclipseCon bloggers have liked the e4 presentation, so I'm assuming that they "got it", and were satisfied that this is indeed an open effort. As for the "why": I think I get it, but I hope that there can still be an overall discussion and a "vision statement" for e4, so that people like myself (contributor/committer/adopter) can understand the why's and how's and and perhaps even contribute (as skills and resources allow).
And I guess this is one reason why I was concerned that they waited until EclipseCon to make their splash. Not everyone who contributes can go.
I guess my take on it is that there isn't really a "why" for e4. There's a "why" for OTI and RAP participating in the web-ifying of SWT. And the conclusion is that that isn't the only thing going on in e4. Each of them has a "why".
In the end, there won't be an over all "vision statement" other than as a incubator to try new things and graduate them into the 3.x stream or into Eclipse 4.0.
It is getting clearer that "e4" is an unfortunate name for some interesting technology which does not necessary set a new mandatory direction for Eclipse 4.0. I was concerned with the direction and openness of far reaching changes to some of the core elements of Eclipse, and my concern has been addressed: The "why" is about code maintainability (I buy that!) and also about reaching new platforms (I buy that, too, but not as much).
In the end it's all about contribution. If I need an architecture overview so bad I'm willing to contribute towards making it, I'm sure I'll be welcome. If I can make do with the code, that's fine too!
Post a Comment