commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Commons - TLP
Date Sun, 21 Dec 2003 08:40:36 GMT
--On Saturday, December 20, 2003 4:20 PM +0100 Dirk Verbeeck 
<> wrote:

> Maybe Jarkarta should take up the role of a Java@Apache gatekeeper.
> Something like the java foundary at sourceforge but with the additional task
> to bring all the (independent) java communities together and provide a
> vision for the Java@Apache future.

For those of you that don't know me, hi, I'm currently Apache Commons PMC 
chair.  Nothing I am saying here is binding as it's my personal opinion.  As 
an ASF member, my only desire is for all ASF codebases to be given the 
opportunity to succeed - if it's in Apache Commons or not, that doesn't matter 
to me as long as the code has a chance to succeed within the ASF.

One of the comments that I have seen in this thread is that J-C is a package 
deal - that J-C shouldn't be split up - all of the J-C projects should share 
the same fate.  Please allow me to put forth some commentary on this.

I believe one of the prime motivations for the ASF is that the people who are 
doing 'stuff' get a say in 'how' stuff is achieved (meritocracy).  This is the 
main rationale behind the PMCs and TLPs - they should be composed of people 
who are actively contributing and providing direction and guidance to a 

However, an essential aspect of this guidance is motivated by the codebases 
involved.  So, what direction and guidance can be provided by a Jakarta 
Commons TLP?  The Apache Commons PMC has discussed how the Apache Commons can 
provide this direction and guidance at some length, so please let me provide 
our insights into this - perhaps it'll help frame your discussions.  The 
question I'd like to keep in the back of your minds is how would a Jakarta 
Commons TLP differ from an Apache Commons TLP?

Apache Commons has two desires: 1) build communities that can manage 
themselves around reusable codebases initially created *within* the ASF; 2) 
support smaller-scale projects that might not garner enough community interest 
to justify being a TLP but still worthy of the ASF's involvement.

The Apache Commons PMC has maintained that when a community gets 'big' enough 
(or groupings of components can be composed as one TLP logically), we're going 
to ask the involved committers (who'll be on the Commons PMC) to form a new 
TLP and stand on its own.  We believe there is no fundamental reason to keep 
projects that could manage themselves from doing so.  There are several Apache 
Commons PMC members that have been involved in the formation of TLPs within 
the ASF and can help communities realize when it's time even though they 
themselves may not yet realize they are 'ready' as they haven't been involved 
in the creation of TLPs before.

On the other hand, I honestly expect the fate of a fair number of the 
components in Apache Commons to be that they achieved their goal successfully. 
In this respect, Apache Commons would be very different than other TLPs which 
aren't supposed to have an easily attainable goal.  There's only so many ways 
to write a regex library.  Once it's done, there doesn't *have* to be much 
more work.  So, the policies and procedures adopted by Apache Commons PMC is 
geared towards supporting a large number of reusable components and sharing 
between them.  (This is one of the many reasons why Subversion was chosen for 
Apache Commons before the rest of the ASF switches to Subversion.)

Now, what happens when projects leave a 'community' (i.e. a codebase becomes 
part of a TLP) - do they really leave?  What's to stop people from being 
active in a number of different communities?  I think you'll find that a lot 
of ASF members are involved in multiple open-source communities (both inside 
and outside of the ASF!).  As you get involved with open-source projects, 
you'll find that you're going to run into a lot of familiar faces and then 
some not-so-familiar faces.  I believe cross-pollination is wonderful.

>>From my outsiders' perspective, this cross-pollination is present to some 
extent here in Jakarta Commons already (yay!), but I think there's a 
reluctance to admit that this mailing list is really many different 
communities at work - every [subject] line group *is* a different community! 
There may be a lot of overlap between these communities and these communities 
may be small in size, but I believe each one should be able to direct itself 
according to their independent wishes.

I know there's a lot of worry at the thought of partitioning J-C into 
codebases that may live in multiple TLPs or even in Apache Commons, but I'd 
just like to introduce some of the possible benefits and advantages of doing 
that.  It may seem scary to many at first, but I think the end result is far 
stronger communities.  Thanks!  -- justin

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message