incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: [Tapestry-contrib] Re: Tapestry?
Date Sun, 05 Jan 2003 08:32:50 GMT
--On Friday, January 3, 2003 8:54 PM -0500 "Howard M. Lewis Ship" 
<hlship@attbi.com> wrote:

> Eventually, I'd like to change package names.  Yes, that would wipe
> out history as well.  I've already subjected users to this once:
> renaming com.primix.tapestry.* to net.sf.tapestry*.
>
> Renaming to org.apache.tapestry.* would be desirable.  I suppose

It seems that Tapestry has done well managing itself - why do they 
want to change that by being a part of the ASF?  It seems a foregone 
conclusion that Tapestry should be a part of Jakarta.   Why not a 
Tapestry top-level project?  They've already gone to a 2.1 release 
(or whatever).  Why should the Jakarta project increase their 
management burden when they already have problems managing what they 
have?

Perhaps the question I'm really trying to ask is: why should the ASF 
accept Tapestry?  I know Aaron asked this too, but I believe that the 
responses from Sam and Andy have avoided the question in spectacular 
fashion.  I'm just not seeing a compelling reason why the ASF should 
add Tapestry.

The fact that they are 'cool guys who will work on other stuff' isn't 
an answer.  Having a pet project not part of the ASF shouldn't stop 
them from being involved with any ASF projects.  It's all open for 
them to participate.  Participating in a non-ASF project doesn't 
forbid you from participating in an ASF project.  If they were really 
interested, they should already be participating!

While I'm glad that rearranging the Tapestry project structure to 
follow ours has proven to be a boon for Tapestry, that still doesn't 
seem a compelling reason.  In fact, I believe it's less of a reason - 
they've already switched.  What can we offer them in addition?  They 
already figured it out themselves!

I don't believe our infrastructure is a reason to merit inclusion. 
If we accepted every project that was merely fed up with 
SourceForge's infrastructure, our quality of service would decrease 
severely due to the load.  There has to be a compelling argument for 
the foundation to shoulder the burden of hosting a project.

A similar argument goes towards extending our brand name to a project 
to increase visibility of it.  It's great to have your project be a 
part of the ASF.  I'm sure there are lots of projects that would like 
to be a part of the ASF.  But, letting everyone join the ASF merely 
dilutes the brand.  Therefore, this can't be a reason, either.

Nor do I agree with the fact that there is project synergy with other 
ASF projects is a reason for inclusion.  I could say that about lots 
of other open source projects that we're not responsible for.  Not 
all projects under an ASF-style license have to be part of the ASF. 
Nor do all implementations of a specific class of product have to be 
found at the ASF.  The goal of the ASF isn't to house every open 
source project or to build a product line.  That's SourceForge's 
goal.  I believe *our* primary goal is to help develop new 
communities.

To me, Tapestry seems a bit too mature for the ASF, and I don't think 
we can add substantial value to Tapestry.  The word for this list is 
'incubator.'  This seems like an adoption rather than an incubation. 
If someone has a compelling argument for addition, I'd like to hear 
it.  But, I must say that I haven't seen one yet.  -- justin

Mime
View raw message