I love games, I really do. Just the other day, I found out I was in a game I didn't even know about. It's called the The Continuous Integration Game, and it's played on the Hudson instance on build.eclipse.org. And guess what, because I keep breaking the psychopath (XPath2) build, I'm placed almost at the bottom (that earns me -10 points), and dcarver who keeps fixing the build afterwards, is almost at the top (since a successful build gives +1 point and adding a test suite gives +1 per test. And who added the 8000+ tests from the W3C suite?)
I certainly have room for improvement - let the games begin!
Thursday, October 22, 2009
Friday, May 15, 2009
Know your project's "hangarounds"
(This post actually started as a comment to Dougs post about too few Eclipse hands but I think it merits a note of its own.)
It's only human to want more, and sometimes we want more for less.
As an occasional contributor, my impression is that there's just not enough people to review bugs and patches and keep ownership of the various components. In the projects I've contributed to, this has been a steady decline over the years. So, I agree with Doug, more cooks!
However: As a former (individual) committer who just wasn't active enough (life happens), I wish there was more time! I think there's an untapped potential in the project "hangarounds". People who have been following the project or component for a while, are power-users but also know the design codebase, but do not have the time to be a committer with all that entails. The hangaround.
By that, I mean a person who keeps up to date with the project or component, and is willing to assist the committers in a number of areas:
Often full-time Eclipse member committers are indeed colleagues working together on significant areas of new functionality, and they often optimize their communication by keeping it to themselves. This is unavoidable and mostly OK. Hangarounds wouldn't be "in the loop" for that kind of development, but their knowledge of the project or component make them valuable reviewers -- keep in mind that a large share of the Eclipse user audience are software developers, and should be accustomed to such tasks and hopefully welcome them.
While I don't know every project in the Eclipse ecosystem, I'm sure project hangarounds already exist, in practise anyway, and that their contributions are valued. However, I think it should be encouraged lots more, also so that the committers had a better feeling of which contributors to turn to for help.
I know, I know, code is the true measure of most things Eclipse, but even if you can't code Eclipse all day, you can still contribute. Let's not forget that.
It's only human to want more, and sometimes we want more for less.
As an occasional contributor, my impression is that there's just not enough people to review bugs and patches and keep ownership of the various components. In the projects I've contributed to, this has been a steady decline over the years. So, I agree with Doug, more cooks!
However: As a former (individual) committer who just wasn't active enough (life happens), I wish there was more time! I think there's an untapped potential in the project "hangarounds". People who have been following the project or component for a while, are power-users but also know the design codebase, but do not have the time to be a committer with all that entails. The hangaround.
By that, I mean a person who keeps up to date with the project or component, and is willing to assist the committers in a number of areas:
- Bug triage
- Spreading the good word about the project (superuser/ambassador)
- Fixing bugs
- Reviewing and testing patches, etc. from the contrbutors at large.
- Pushing initiatives like Bug Friday
- Extend test coverage
- Keeping [helpwanted] markers on bugs relevant and realistic
- Review and write documentation
- Participate on mailing list and/or newsgroup
Often full-time Eclipse member committers are indeed colleagues working together on significant areas of new functionality, and they often optimize their communication by keeping it to themselves. This is unavoidable and mostly OK. Hangarounds wouldn't be "in the loop" for that kind of development, but their knowledge of the project or component make them valuable reviewers -- keep in mind that a large share of the Eclipse user audience are software developers, and should be accustomed to such tasks and hopefully welcome them.
While I don't know every project in the Eclipse ecosystem, I'm sure project hangarounds already exist, in practise anyway, and that their contributions are valued. However, I think it should be encouraged lots more, also so that the committers had a better feeling of which contributors to turn to for help.
I know, I know, code is the true measure of most things Eclipse, but even if you can't code Eclipse all day, you can still contribute. Let's not forget that.
Monday, March 24, 2008
Surprise: Eclipse is me, too!
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.
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.
Tuesday, March 18, 2008
My EclipseCon un-schedule: Day 1
This year, I am also not at EclipseCon.
Rather than four days of Eclipse tutorials, talks, BOFs, and high quality chit-chat, I'm getting what should have been springtime in Denmark. Well, it isn't.
My un-schedule for today went like this:
Rather than four days of Eclipse tutorials, talks, BOFs, and high quality chit-chat, I'm getting what should have been springtime in Denmark. Well, it isn't.
My un-schedule for today went like this:
- 07:00: Why is everybody up now? I'm not running anywhere! Oh, breakfast.
- 08:00: Traffic Ballroom Z: "Model driving gets kids to daycare" 101, and more.
- 10:00: Coffee - I get that.
- 10:30: Managing my small company's general ledger with a cool RCP based ERP (no, that was OOo Calc)
- 12:00: Lunch and Eclipse smalltalk. Minus Eclipse smalltalk.
- 13:00: Improvised BOF meeting with other
Eclipse contributorspeople stuck in line in the hardware store. - 13:30: Heave 13 sacks (450 kg) of shredded bark mulch into family car. Prepare for contribution as foundation for the coming platform.
- 15:15: Daily General Meeting with kids being picked up from daycare.
- 15:30: Check Planet Eclipse for postings on EclipseCon.
- 16:00: "Introduction to PDE/Build", or make that finally updating my XSL workspace for M5. Noticing how "Project > Cleanup..." is still required for combinations of target, project, and CVS changes.
- 16:20: Fight against the snow build-up. It's not supposed to snow now that spring was here.
- 16:30: Check Planet Eclipse again. Hmmm.
- 18:00: ...
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"?
Thursday, January 31, 2008
Think globally, link locally (updated)
Today I attended my first meeting in the local (i.e. Danish) Eclipse users group called Eclipse.dk, today's topic being the use of Eclipse RCP for the primary front-office business-applications in a bank, such as teller systems and in call centers.
In Denmark, banks are rarely among the early technology adopters -- to say the least (I assume this is partly due to the severe regulation in the sector). Not just adopting, but broadly betting on Eclipse RCP for in-house development is thus a bold decision, even when it's warranted and desired by the business users. It goes against the grain of the ten year industry-wide push of browser-based solutions, and didn't happen without some amount of "idea sales"; the architect having to refocusing his/her language to the audiences at hand (easier when you stick to the facts and leave the evangelism behind.)
The meeting featured a presentation, a demo, and lots of discussions about design trade-offs, architecture, etc. amongst the apprx. 25 attendees. Useful, inspiring, and not doable by IRC! This kind of face-to-face meeting around such a focused subject is a rare event indeed.
My message is thus: Find and join your local Eclipse user group - if you can't find one, go start one yourself. Show up, share, discuss, link up with people with similar interests.
Update: The Eclipse Wiki contains a page of local communities.
In Denmark, banks are rarely among the early technology adopters -- to say the least (I assume this is partly due to the severe regulation in the sector). Not just adopting, but broadly betting on Eclipse RCP for in-house development is thus a bold decision, even when it's warranted and desired by the business users. It goes against the grain of the ten year industry-wide push of browser-based solutions, and didn't happen without some amount of "idea sales"; the architect having to refocusing his/her language to the audiences at hand (easier when you stick to the facts and leave the evangelism behind.)
The meeting featured a presentation, a demo, and lots of discussions about design trade-offs, architecture, etc. amongst the apprx. 25 attendees. Useful, inspiring, and not doable by IRC! This kind of face-to-face meeting around such a focused subject is a rare event indeed.
My message is thus: Find and join your local Eclipse user group - if you can't find one, go start one yourself. Show up, share, discuss, link up with people with similar interests.
Update: The Eclipse Wiki contains a page of local communities.
Friday, November 2, 2007
They grow old so fast...
Two years ago, I initiated the Mule IDE project, an Eclipse plugin for the Mule ESB. It was started as a hobby project back when "Mule UMO" was mostly a (popular!) community effort with a few dedicated developers working on it.
Since then, things have really taken off for the Mule ESB, and it's now the centrepiece of MuleSource, Inc. - arguably an Open Source success story. Meanwhile, Mule IDE hasn't received too much attention since the 1.3 version from February '07 (as I have too many other (offline) things going on)
But that's all changed, since Ted and Moosa joined the Mule IDE project. And now Mule IDE 1.4.3 is out, with none of my doing whatsoever. Congratulations, I'm looking forward to seeing what's coming next!
But at the same time, I can't help feeling that it's a little bit like sending a child off to school...
Since then, things have really taken off for the Mule ESB, and it's now the centrepiece of MuleSource, Inc. - arguably an Open Source success story. Meanwhile, Mule IDE hasn't received too much attention since the 1.3 version from February '07 (as I have too many other (offline) things going on)
But that's all changed, since Ted and Moosa joined the Mule IDE project. And now Mule IDE 1.4.3 is out, with none of my doing whatsoever. Congratulations, I'm looking forward to seeing what's coming next!
But at the same time, I can't help feeling that it's a little bit like sending a child off to school...
Subscribe to:
Posts (Atom)
