Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 63344 invoked from network); 4 Apr 2005 14:39:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Apr 2005 14:39:06 -0000 Received: (qmail 55197 invoked by uid 500); 4 Apr 2005 14:39:04 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 54915 invoked by uid 500); 4 Apr 2005 14:39:03 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 54899 invoked by uid 99); 4 Apr 2005 14:39:03 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from chi.mobile-health-diary.com (HELO chi.mobile-health-diary.com) (128.241.244.71) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 04 Apr 2005 07:39:02 -0700 Received: (qmail 18473 invoked from network); 4 Apr 2005 14:39:00 -0000 Received: from ool-43560634.dyn.optonline.net (HELO ?10.0.1.33?) (geir@67.86.6.52) by b014.internal.mobile-health-diary.com with SMTP; 4 Apr 2005 14:39:00 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <42485243.4050109@Golux.Com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <491381EE-A517-11D9-B609-000A95D41A40@apache.org> Content-Transfer-Encoding: 7bit From: Geir Magnusson Jr. Subject: Re: [VOTE] Graduate Derby from the incubator Date: Mon, 4 Apr 2005 10:39:01 -0400 To: general@incubator.apache.org X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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