incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: BPEL contribution from Sybase
Date Tue, 14 Feb 2006 02:42:28 GMT
On Mon, Feb 13, 2006 at 05:56:49PM -0800, Dain Sundstrom wrote:
> On Feb 13, 2006, at 5:34 PM, Greg Stein wrote:
> 
> >On Mon, Feb 13, 2006 at 12:42:58PM -0800, Dain Sundstrom wrote:
> >>...
> >>Sybase wants to donate to the service-mix community and the
> >>ServiceMix community wants to work with the code.  Any contributor
> >
> >It should be donate to APACHE. The various people can come to it.
> 
> I don't think anyone has said that this isn't a donation to apache.   
> Every donation I have seen to apache, has either come to a PMC and is  
> sponsored as a IP donation or incubated sub project, or comes  
> directly to the incubator without a sponsoring PMC and must find one  
> (which can be the incubator PMC).  This is exactly what is happening  
> here with the Geronimo PMC.

Of course they're all donations to Apache. But this is a donation that
is being overly-targeted, and (IMO) as a way to hit a specific subset
of people (servicemix) on the belief that it will be easier to control
access to the codebase. There is a lot of apparent resistance to the
concept of putting this code anywhere but for servicemix. "Why?", I
ask myself.

Yes, these things are donations. And the various PMCs (or the
Incubator itself, or rarely the Boar) pass this stuff to the Incubator
to manage. The Incubator has two jobs: IP clearance, and community.
The Incubator is required to manage these for the requesting PMC (and
that PMC must provide people/time/effort to assist). But the process
runs according to the Incubator's rules. It determines what will best
effect the two-job outcome. IP clearance is easy, and that is
happening now. Community is hard, and that's what we're talking about.

And what I'm seeing is that people are saying, "create a separate BPEL
community so that we get the best community."

> >To be frank, some communities can bias against newcomers. That isn't
> >right for the ASF, and it *absolutely* is not write for podling
> >communities within the Incubator.
> 
> Woha... There is no one saying the service mix community is biased  
> against new comers.

And I never said it was. I said "some communities". Do I think that
ServiceMix might have bias? I've got no data to support that, so I
didn't say it :-)  Do I suspect it, based on this whole string of
emails over the past couple weeks? Yes.

> I think it is the exact opposite.  They are very  
> welcoming and I think this is what excited them to donate the code.

Welcoming to Sybase, or to their ASF peers? Better be both.

> >This doesn't apply to just BPEL. I had the same reaction to the recent
> >Ajax proposals. "oh, sure, Dojo can come and join this new community."
> >Right. They'll feel like outsiders right from the start. "Euh. We have
> >some code? Yah, I know you have some, but will you look at ours?" Bah.
> 
> I think that is a different case.  In that case we are talking about  
> two competing communities.  In this case, we have a donator and a  
> community that *want* to work together.

That is not the case. We have at least two BPEL implementations, with
another two potentially on the way (per Noel's email). So we have four
codebases and some number of communities.

"some number of communities" is the problem. This is the Incubator.
There is no reason to have *divided* communities. More than one means
divided, in every sense of the word. As I've said before: we need
inclusivity, not exclusivity. And that means avoiding division. That
means bringing everybody together. And it is *especially* true within
the Incubator.

> >This isn't about control, this is about inclusivity. Targeting one
> >group of folks ("... to the service-mix community ...") over another
> >is exclusion, not inclusion.
> 
> I disagree.  That is like saying any contributor is exclusive because  
> they committ code to only one or two projects.

No. That is saying a developer has interest in just a couple projects.
And it may be that the developer likes the people on those projects.
But it is very different from targeting a community based on how they
are/will interact with others.

Targeting the servicemix community is a mechanism to work with just a
few people, unless it can be shown that the servicemix group is open
to outside contribution. And you know what? The first outside
contributor said, "hunh. that doesn't make sense there. let's move it
_over_there_", and that got rejected. Doesn't seem very welcoming :-P

> Sybase has some code  
> that want to integrate into the service mix code base because they  
> like the project and the community and want to work collaborate with  
> them.  They could have quietly showed up an built a new orchestration  
> engine in service mix, but instead they are offering some existing  
> code to start with.  What's the big deal?

And the concept of "do it quietly" also means "do it sneaky to avoid
oversight" which is maddening to me, just at the suggestion of it. Not
very confidence-building, I might add.

The big deal here is that a number of people want to work on BPEL and
(apparently) have zero confidence in being able to do that within
servicemix. Second, that we have several BPEL implementations to sort
through, and servicemix doesn't seem amenable to that. Third, that an
outside party is trying to target one group over others. Fourth...
dunno. I'm tired of writing.

If it isn't obvious, I support the notion of a separate podling where
all BPEL implementations can gather, be sorted out, and to establish a
great community and product. Picking one, and shoving that down inside
another codebase is not the answer. It feels like servicemix is being
used as armor against outside interference, and that sucks.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message