incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <ge...@apache.org>
Subject Re: [VOTE] Graduate Derby from the incubator
Date Mon, 04 Apr 2005 14:39:01 GMT

On Mar 29, 2005, at 4:59 PM, Ted Leung wrote:

> -1
>
> I am surprised that people think the committer diversity issues are 
> not an issue for graduation.
>
> As far as I can tell, the distribution of committers in Derby is worse 
> than either Xerces-J, or Xalan-J
> both of which have been viewed negatively because of the number of 
> committers from a single organization,
> coincidentally, IBM.


I'm one of the +1 votes out there.   I thought about the issue before 
the vote was asked for (as a mentor/champion/thingy, Ken and I 
discussed), and have thought a lot about it since.  I had two concerns, 
with # of new committers being one of them.  I had the same concern 
with Geronimo when it went TLP, and we're solving it.  I think that 
Derby can solve it too.

I respect people's concerns about this, but have some thoughts, in no 
order :

0) Do we have a universal rule? What is it? Is it universally applied? 
What happens when a codebase violates that rule?  Do we take it 
offline? (I don't know, unknown, probably not, unknown, NO!)

1) Does Derby have a diverse and growing *COMMUNITY*?  (Sorry - not 
shouting... just no boldface or italics...)  Yes, I think it does.  You 
see lots of participation from people from Sun (a big company who has 
an active interest in using the project) as well as a diverse set of 
other people.  Is it great?  No.  Is it getting there?  Yes. It's true 
that Derby has been slow at adding committers.  Some it comes from the 
conservatism of the founding committers (people used to criticize us in 
Jakarta for handing out commit like candy and I'll note that 
conservatism has a cure :), and some comes from simply the fact that 
Derby is a mature, sophisticated codebase - it's hard, and requires an 
expertise that not many people have.  We've felt the same thing in 
Geronimo, due to complexity.  But I know you'll start seeing people 
working around the core - making it a standalone server, adding a OSS 
network driver, etc.

2) I try to think about people and contributions independent of their 
employer.  I didn't care how the people on the iBATIS project pays the 
rent, for example, and they are going to be a TLP.   I work for 
Gluecode, and we're basing our products and services on Geronimo, but 
I'd be the first to welcome another J2EE server project at the ASF, for 
example....  Leave it at the door....

3) Is it ok for an employer to have an employee (that is a committer) 
do things in the interest of the employer?  Of course it is. (It's not 
ok when a committer blocks things due to the business interests of 
their employer, but that's another issue totally unrelated to Derby)  
So if what the IBM-employee committers do is in the interest of IBM, 
that's fine.

4) What happens if IBM decides that it's employees can no longer 
contribute?  Well, we're not talking MySQL here.  It's code granted to 
the ASF, under ASF collective (c), under the Apache License.  I believe 
that strong community (anchored by a strong diverse committer base) is 
a primary factor in what makes open source valuable, and I think that 
with clear disclosure (i.e.  list of committers and employers, as is 
common on maven generated project sites...), users will be aware.  We 
don't really make any warranty about community, though.  it's something 
we strive for, and I'm comfortable that by having lots of attention and 
focus, the committer problem can be solved in DB.

Anyway, just some thoughts to chew on (or spit out...).  I think that 
derby has enough momentum, will keep adding people, etc.   I was going 
to try to do some work and earn commit status, but I guess that won't 
help until I quit my job, as jeremy and I work for the same place... :)

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org


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


Mime
View raw message