My last word on the whole e4 thing will not be about e4 at all (since I'm following going through the instructions for the demo, letting the code speak for itself), rather it will be restating what's been said so many times before: Eclipse is me.
Now, I'm not the most active Eclipse committer/contributor (Dave and Doug are doing all the actual work in the XSLT tooling in the WTP incubator), nor am I a prolific, insightful blogger by any standard. Yet, my posting regarding e4 did not go unnoticed within the community. I think that's a sign of good health, and I was pleased to see Mike M following up on it.
What befuddled me a bit however, was finding out Reg Developer linking to the post, essentially using it as a news source, as an exponent of a general sentiment. That was just ... unnerving, out of proportion, and misunderstood. Planet Eclipse is a great medium for following what's going on, but is does not fairly represent the minds of all ~1000 Eclipse committers and the many members doing the hard work. The planet should always be read with that in mind.
Eclipse is you, but take care to express how.
P.S: For a laugh, read the Reg Developer comments, and try not to think of XKCD.
Showing posts with label e4. Show all posts
Showing posts with label e4. Show all posts
Monday, March 24, 2008
Saturday, March 8, 2008
"It's the architecture, stupid!"
When I first read the e4 project announcement, I was puzzled as in "Am I misunderstanding something here?". Reading through the early e4 diversity and openness complaints on miscellaneous blogs, I was very relieved to see I wasn't the only one getting (what is now confirmed as) the wrong picture, as to the intentions of the incubation effort (I was even looking forward to Ed Merks' images of unbalanced ecosystems or the proverbial big and small fishes in the pond).
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:
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"?
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"?
Subscribe to:
Posts (Atom)
