This is something I normally only talk about after a few beers at EclipseCon. But I think I need to get it off my chest, especially after seeing a recent e-mail on the eclipse-dev list. I’ll apologize in advance if I’m getting this wrong and feel free to correct me.

Now first of all, don’t get me wrong, I am one of the biggest fans of the gang at IBM’s OTI office (still more OTI than IBM they are) and a lot of them are good friends. The quality of the platform and the great extensibility it offers is what has made Eclipse what it is today. We’d all still be in the dark ages if it wasn’t for their great work.

And, you know, I think they’ve come a long way as far as working in the open goes. When we started the CDT, it was really hard to know what they were doing and many times we were surprised by API and functionality changes in milestone builds that required us to scramble to fix up. I think on both sides, CDT and Platform, we’ve gone that extra mile to make sure we communicate better as committers. We’ve even received patches from the Platform team to make sure we didn’t break when changes did occur.

The thing that has me concerned was highlighted in a mail that just came across on the eclipse-dev list from Kim Moir (sorry Kim, you’re just the messenger). “I just talked to McQ regarding the plan. This is what he said… -Component leads can make rules more strict as they see fit…” And the mail goes on a bit longer to talk about the endgame rules for accepting changes.

Now it is my understanding that it’s really up to the individual projects to decide what their development processes are, and I guess this is what the Eclipse project (or was it the Platform sub-project) has decided their processes to be. And you know, looking at the rules McQ has set out, they really are trying to give more power to the committers and my first was reaction was that this was a positive step in the right direction.

But, personally, in my role as the CDT Project Lead (which is also a sub-project which makes me a peer to McQ, who is IBM’s Mike Wilson, BTW), the last thing I want to do is dictate to my committers what the endgame rules would be. Actually the last thing I want to do is dictate anything. Maybe it’s just the way I am, but I feel the responsibility for the processes and guidelines falls with the committer group as a whole. If they don’t agree, I’m actually powerless to stop them anyway so I’m really just a facilitator. Mind you, to make sure we have rules, I usually suggest something and if I get no feedback, which happens a lot, we assume everyone agrees. But in the end it should be the committers that decide.

Obviously the Eclipse team is set up differently. A lot of it is historical and due to the organization of the team, both as an Eclipse PMC as an an organization at IBM. But I would really like to see the Eclipse team open up their processes and decision making more and be a bit more transparent.