avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@apache.org>
Subject Re: [Avalon] Major Issues that are in Conflict
Date Wed, 21 May 2003 02:00:45 GMT
We all need to understand exactly where we are now, why we are there, 
where we want to go, and how to get there. The following are mostly 
random thoughts, but I felt they were apropos to the discussion at 
hand. Being silent and pushing things under the metaphorical rug never 

On Tuesday, May 20, 2003, at 08:07  AM, Berin Loritsch wrote:
> Perhaps I don't get what you are proposing, but I am always left with
> the impression that your version of empowering the developer is one
> of permitting the "us vs. them" mindset that is the problem in Avalon
> today.  Let me point out some things:
> 1) Apache has always about promoting community over code.  There are
>    reasons for this.  One of them is that a healthy community lasts
>    longer than an individual developer--no matter how good they are.

Are "empowering the developer" and "empowering the community" mutually 
exclusive? Yes, Apache puts community over developer, but don't 
developers inside a community need to be empowered to move a project 
forward? I think the two actually have a symbiotic relationship.

> 2) You sighted Jakarta.apache.org and XML.apache.org as examples of
>    where your ideas were in use.  However they are not applicable
>    in this case for the following reasons:

I think Jakarta and XML are similar to Avalon in that they have many 
projects underneath them. ... we have many different things going on 
under our roof, LogKit, Framework, Merlin, Phoenix, Fortress, 
Cornerstone components, Excalibur components.

The chance of an individual member of the community using all of our 
offerings is slim. Compare this to (for instance) Cocoon. Cocoon has a 
single deliverable (Cocoon itself). Yes, it is modular and there are 
lots of different pieces, all of which are not worked on by everyone, 
but everyone is at least peripherally involved with the evolving core.

Our core is Framework. Since v4 came out, it is solid (minus the 
Loggable->LogEnabled and s/Component/Service/ bits, minor evolutions).. 
there's no real "rallying point" for all developers to work around, to 
work *together* on.

Instead we're attempting to work together on what is essentially new 
development (AMTAGS, new container, container services, etc). 
Bootstrapping a new community project inside of a community where 
different members have different ideas of how the new project should 

I think we all need to be aware of the tensions that we bring upon 
ourselves when doing such undertakings. Yes, they are valid 
undertakings, very beneficial steps in the world of containers, but 
difficult in a community where you have three containers where the set 
of committers that works on two of the three is very small, and I think 
even an empty set for someone that hacks on all three.

Thus *of course* there are tensions when we start talking about 
cross-container concerns. Anybody that hacks on a codebase is going to 
feel an attachment to that codebase. Even more so when they are 
actively *using* that codebase. Yes, its not "mine", but one does have 
a feeling of "stewardship" towards the code. The _developer_ inside the 
_community_ that is playing mother to the code. Looking after it. 
Keeping it up-to-date and safe until the next developer to fill that 
role comes along.

I think the solution is just one that has been mentioned repeatedly.. 
we need to all develop a codebase together. Whether it be an existing 
one, or a new one (new has been proposed because it eliminates the 
stewardship concerns).

It is only by working on code together that the community can survive, 
and it is the active working on code together that keeps the community 

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message