RE: [eclipse.org-planning-council] RE:[eclipse.org-membership-at-large]

["Gaff, Doug" <doug.gaff@xxxxxxxxxxxxx>]

Thanks for the comments David, especially about recruiting and making committers feel welcomed.

Folks, 

I want to point out one important quirk of the Eclipse Development Process here. When a new project starts, the proposed project lead picks the initial set of committers. They are then approved in bulk by the PMC. Hopefully (but unfortunately not always) the project lead attempts to recruit a diverse set of initial committers. There's not much of a meritocracy process at the beginning, and this initial list is really in "good faith". Subsequent committers must be voted upon by the current committers and must have a demonstrable track record of contribution -- the normal approach for adding committers.

This is a quirk, but it's necessary. After all, how does one establish a new project with new committers in the absence of a track record? Typically what happens after the initial committer creation is an eventual cleanup based on the actual activity of those committers, so it hopefully works out in the end. I've incubated 6 projects in DSDP so far, some less successful than others, and I've seen the diversity/activity thing play out first hand. I've certainly received multiple emails from Bjorn warning about lack of diversity on some of the DSDP projects in the past.

What is frustrating me about this project proposal is that there is already a track record for potential diverse participation. This isn't a brand-new piece of technology with no history, it's the evolution of an existing platform. This puts the project lead ahead of the curve, because he already has a list of folks he can tap to participate, hence the recruiting aspect. I wish all proposed projects were this lucky! And still, despite this fact, the diversity isn't really there. That's the problem, and it is eerily similar to the lack of diversity on the current platform project.

Projects have to want to be diverse, and they have to make it a priority. You may recall the arguments we had on planet eclipse after the PHP tools were released to 1.0 without demonstrable committer diversity. According to the dev process, diversity is supposed to be a gating factor in order to exit incubation. I've been holding a technically mature DSDP project (NAB) in incubation for over a year because of the lack of diversity and transparency. 

I do agree with Mike: "Diversity on E4 is a 'must have' for the future health of Eclipse." There is no other project in Eclipse right now where this is more important. I think E4 needs to set a goal of around 50% non-IBM participation to truly meet the diversity requirement. I would further say that the project shouldn't even be created until it's more diverse than the initial committer list currently reflects. Otherwise the architecture, feature set, workflow, frameworks, etc. will be IBM-biased. That's not good for everyone else who builds commercial products on top of Eclipse.

Doug G

> -----Original Message-----
> From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of
> David J. Orme
> Sent: Thursday, March 06, 2008 11:57 AM
> To: mike.milinkovich@xxxxxxxxxxx; eclipse.org-planning-council
> Subject: RE: [eclipse.org-planning-council] RE:[eclipse.org-membership-
> at-large] Eclipse Project AnnouncementandProject Review Schedule
> 
> I'm really glad to see this conversation happening.
> 
> Apologies in advance for the long post.  But I hope that an insider
> view
> from a Platform committer who had to earn those rights proves helpful
> here.
> 
> 
> Eclipse Data Binding is one example of an Eclipse Platform module that
> has successfully recruited committers from the community.  But it
> wasn't
> always that way.  How this happened is an interesting study in
> open-source at Eclipse.
> 
> - In Eclipse Data Binding, there was no hesitation to want to recruit
> new committers.  However, there was a lack of understanding about how
> this is accomplished.  New committers don't fall out of thin air. :-)
> 
> - I initially had to ask Boris if he would be interested in having me
> as
> a committer.  But when I did, and Boris and I talked about what that
> would mean, he was very comfortable with going to the next step.
> 
> - After I suggested to Boris that we be aggressive in all of our
> EclipseCon talks about recruiting new committers, Boris was like "Well,
> duh, of course".  This resulted in our initial outside committer who
> proved his value again and again for a year, until he got a new job and
> had to move on.
> 
> - Today, there is another outside committer and several other very
> helpful contributors.  Again, we had to explicitly cultivate these
> people.  Specifically, we had to work to help these people up the
> learning curve technically and culturally regarding what it means to
> commit to Platform.
> 
> - In both cases, I believe we had to approach the prospective committer
> with a "How'd you like to be a committer?" conversation.  In at least
> the first case, the committer didn't think he was good enough for the
> Platform team.  He needed some reassurance that he was doing fine and
> that we would work with him to help him over the remaining hurdles.
> 
> - Nobody likes processing Bugzilla bugs.  But it's the way you
> communicate with and cultivate your potential committer base.  Until
> you've got a bunch of good patches from some committer in Bugzilla, you
> can't go to the project mailing list and ask for someone to permitted
> to
> become a committer.
> 
> After I got Boris started down this path, he has been very good and
> very
> aggressive about continuing.
> 
> ---
> 
> What's the point here?  I suspect that the Eclipse organization may not
> be very good at understanding and following open-source rules of
> engagement.  This goes both for the existing committers and for the
> community.
> 
> ---
> 
> How do we move forward from here?
> 
> Eclipse at the Board level has been traditionally a pretty top-down
> organization.
> 
> If you want to start a project, you raise support for it, then you make
> a proposal.  Or you make a proposal, then raise support for it.  In
> both
> cases, this happens top-down.
> 
> Becoming a committer is a bottom-up process.  You establish trust with
> the existing committers and then they will *want* to invite you to
> joining them.  Then you build Cool Software that makes other developers
> *want* to join you.  That's open-source rules of engagement in a
> nutshell.
> 
> My *perception* is that the Board hasn't traditionally understood the
> bottom-up aspect of open-source very well.
> 
> I'm not sure that we will be able to mandate diversity from the
> top-down.
> 
> But I would be surprised if a company was determined to obtain commit
> access to Platform, yet unable to do it by following open-source rules
> of engagement.  Their developers would initially individually earn that
> access by submitting high-quality patches and (possibly) gently bugging
> the existing committers about earning their commit rights.
> 
> If gentle nagging after establishing a long history of contributing
> high-quality patches doesn't result in commit rights, then this can be
> escalated to the Board level.
> 
> If a bunch of companies earn their committer rights on Platform, then
> we
> will obtain the diversity we need.  And then those companies supporting
> those committers will be free to do the additional work in Platform
> that
> they want to get done.
> 
> 
> I hope this perspective is useful, helpful, etc.
> 
> 
> Best regards,
> 
> Dave Orme
> 
> On Thu, 2008-03-06 at 10:53 -0500, Mike Milinkovich wrote:
> > Doug,
> >
> >
> >
> > That is a really good question. And I hope it was meant seriously,
> > because it is a very important question for the Eclipse community.
> > Diversity on E4 is a “must have” for the future health of Eclipse.
> >
> >
> >
> > BUT: actions speak louder than words. And that applies to both sides
> > of this question.
> >
> >
> >
> > Anyone who has the ability to make the very serious time commitment
> to
> > becoming a committer on E4 should step forward. IBM, Innoopract and
> > Code9 have indicated that they are going to make highly skilled
> people
> > with significant time commitments available to move this project
> > ahead. It would be wonderful if others, including Wind River, find
> > themselves able to make the same commitment.
> >
> >
> >
> > I have spoken to the leaders on this project who happen to be from
> IBM
> > and they have told me that they agree with you. E4 provides an
> > opportunity to raise the diversity on the platform project. Over
> time,
> > it will be their responsibility to ensure that their actions back
> that
> > up as well. And yes, that does mean living up to the diversity
> > standard by which all other projects are judged.
> >
> >
> >
> > Actions, not words are going to make E4 successful.
> >
> >
> >
> >
> > At the risk of starting a fight, is anyone else bothered by the fact
> > that this initial committer list is composed almost exclusively of
> IBM
> > engineers?
> >
> >
> >
> > It seems that it’s time for the platform project to live up to the
> > diversity standard by which all other projects are judged. Perhaps
> > Eclipse 4.0 is the time to make that change?
> >
> >
> >
> >
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> --
> Dave Orme
> http://www.coconut-palm-software.com
> djo@xxxxxxxxxxxxxxxxxxxxxxxxx
> Coconut Palm Software -- Software Paradise in the Midwest
> 
> 
> 
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council