Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <20050422084042.T12410@paz.hyperreal.org>
References: <42485243.4050109@Golux.Com>
 <c3f63520432ad6ce4d03cb9cef35bd4b@sauria.com> <4250059D.5000603@Golux.Com>
 <d65bf7d0d55c424cf57d5b049975188c@apache.org> <42602405.8020201@Golux.Com>
 <20050415165333.D63791@paz.hyperreal.org> <4263D109.80509@Golux.Com>
 <c5e6325505041809595f315b2f@mail.gmail.com>
 <4A1017F8-B324-11D9-961C-000A95D41A40@apache.org>
 <20050422084042.T12410@paz.hyperreal.org>
Message-Id: <4dc3344c44819310c25b50ebd54d8786@gbiv.com>
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: [VOTE] Graduate Derby from the incubator
Date: Fri, 22 Apr 2005 12:37:07 -0700
To: general@incubator.apache.org
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Apr 22, 2005, at 8:55 AM, Brian Behlendorf wrote:
> It's not so much "dissonance" as an exception.  In an incubating 
> project, the developers are usually new to the ASF, and skipped the 
> meritocracy step by virtue of association with the project before it 
> entered Apache ("here's the list of committers"). Therefore it's 
> reasonable to ask the incubating project to prove that not only can 
> they write code, but they can build an active multi-participant 
> community.  If there really is still just one outside committer, then 
> in my opinion the community has not yet passed that test; and rather 
> than coding, those who care about that project should be advocating 
> its existance to others, giving presentations at conferences, getting 
> the middleware projects to support it as a peer to mysql and postgres, 
> that sort of thing - all in the name of getting more outside 
> involvement.
>
> This is actually not limited to incubator projects - we've had issues 
> before with projects whose committership was overwhelmingly from one 
> employer.  The issue wasn't the employer corrupting the decisions of 
> the employees so much as the employees communicating privately with 
> each other because they could, leaving out other developers; it also 
> meant they were not incented to reduce the learning curve on the code 
> or document internals, which would have increased outside involvement. 
>  The solution there is to slow down the pace of coding and do more 
> community development, and ask "why are there so few other 
> developers?".  Even if the project is widely, you should ask "why are 
> so few users of this software interested in becoming developers?".

Ditto (I am *so* lazy today).

> As others have said, what the ASF cares about is healthy developer 
> communities; good code is a resulting byproduct.

Right.  At the beginning of this thread, I asked that the status page
be updated because it clearly didn't reflect what I was hearing about
the community [which was all good].  It was updated, but I am surprised
that the update didn't change as much as I expected.  One new
developer is not a great sign of progress -- it is only a good start.
The hardest part of self-governance is the decision to give up some
control to a new person, and it isn't until a group has a legacy of
doing that, on the basis of merit instead of corporate negotiation,
that I am willing to vote them out of incubator.

  [side note: while I know this may not seem fair to the developers
   working on Derby, the fact of the matter is that IBM already burned
   us (the ASF) with false promises of community building in XML, and
   thus the cries of "Trust us, we'll get there soon" are not going
   to be heard.  This time, IBM has to go through the same process
   as all of the other groups who enter the ASF with a new project.]

We have the same problems as Derby within the Jackrabbit project,
though not only did we *start* with a far more diverse set of
committers, we actively encouraged new folks to take responsibility
for their own contributions.  Nevertheless, it is quite clear to me
that we haven't reached the point of graduation, and not just
because the JCR spec is unfinished.  There simply isn't enough
actively diverse participation to cause everyone to make all
design decisions on the list instead of in private mail or
hallway conversations.

Here's an idea -- how about encouraging a couple Derby developers
to participate in Jackrabbit (it is a database API after
all) and then convince some of the Jackrabbit developers to
participate on performance tuning Derby when used within a CMS.
Everyone wins and both communities become more diverse.

....Roy


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