Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Geir Magnusson Jr.
On Dec 19, 2003, at 3:33 PM, Costin Manolache wrote:

Ted Husted :


[SNIP]

I agreed w/ every word from Costin.

And look what's happening with logging: Now that it's a TLP, they are 
bringing-in the various Log4J compatibles. Now, there can be one 
Apache logging project serving every platform. That's 
community-building!

Is logkit included in the logging TLP ? What about commons-logging ?

I agree with you that the logging TLP does define a community ( just 
like  jakarta or httpd ). It's a separate PMC bringing togheter 
different codebases and people.

It remains to be seen if log4j as a TLP will be better than log4j as 
part of jakarta. There are plenty of TLPs - like apache-commons - that
don't seem to be much better than sub-projects like jakarta-commons.
Agreed.  JC is a vibrant sub-project with ties to may Jakarta 
sub-projects.  I think that important and valuable.  I think log4j will 
do fine, and they can always come back.  It's not clear what kind of 
synergy the log4* projects will bring together, but will be interesting 
to watch.

I had such mixed emotions about log4j leaving, as I think it's going to 
take a bit of our community away.  On the other hand, I support the 
freedom of the log4j community to choose it's own path, and that wins 
out with me.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[OT] [JOKE] Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Brian McCallister
Holy war time:

IoC TLP's

public class Log4J implements JakartaAware, LoggingAware
{
...
}
public class Log4J
{
public void setJakarta(Jakarta jakarta) { ... }
public void setLogging(Logging logging) { ... }
}
public class Log4J
{
public Log4J(Jakarta jakarta, Logging logging) { ... }
}
=)

-Brian

On Dec 19, 2003, at 2:04 PM, Craig R. McClanahan wrote:

Quoting Harish Krishnaswamy [EMAIL PROTECTED]:

Thanks Craig, this is elaborate, informative and puts the issue in my
perspective. May be this
should be put on the website too somewhere.
Here are my inferences so far...

inferences
ASF is a group of projects administered by the Apache board members. 
The
board delegates certain
responsibilities over to the PMCs of the individual projects while 
still
maintaining the authority
and management responsibilities. The PMC is responsible for a 
wholesome code
and community of the
project it oversees but does not have the authority to recognize new
projects.

Jakarta started out as a single project for a web container and has 
grown
into a foundation of
projects in itself without sufficient administration/organization.
/inferences

Waiting for the bureacracy to be created first is kind of antithetical 
to the
way most open source developers think :-).

Here are my thoughts distilled from a lot others'...

* I think the projects at ASF should be classified in some way 
(preferably by
technology like we
have now for xml, db etc.) into umbrella projects. All projects piled
together at the top level
would not convey very well. This is where Jakarta would need 
redefinition.
Seems like the inital
motivation, server side web development, is a good fit. And that 
would mean
some reshuffling.
The problem with graph shaped (single inheritance) hierarchies is 
that
sometimes a single project fits more than one place.  For example, 
where do you
put Cocoon?  It's clearly a thing that fits into an XML Technologies 
sort of
place.  It's also a thing that clearly fits into a server site 
technologies
sort of place.  The answer that Cocoon chose (the right one, IMHO) was 
to be a
separate TLP that is *linked* to both of those technology's web sites.

But, the more fundamental principle is that the legal organization of 
the ASF
need not have anything at all to do with how websites are organized 
and how
projects are made visible.

* I think each umbrella project or each project within could have a 
PMC and
each project should
maintain a PMC membership of atleast 51% of its committers to sustain.
That's pretty much the way that Jakarta works now (we've focused on 
expanding
the PMC membership over the last year to ensure coverage from all the
subprojects).  But, as a Jakarta PMC member, it's still a daunting 
thought to
be held responsible for oversight of all the code, and all the 
releases, across
all of Jakarta.  It's hard enough for me, for example, just to stay 
current on
the three projects I watch and try to participate in (Commons, Struts, 
Tomcat).
 I'm pretty clueless about what the Tapestry folks are doing, yet *I* 
need to
approve releases?

Having Tapestry committers on the PMC helps, but isn't sufficient.

* I think the website should match the organizational structure to 
avoid
confusion.
I don't agree.  The website(s) should be focused around making it easy 
for users
to  find out what Apache projects might have products that are 
relevant to
their needs.  The internal project organization is an implementation 
detail.

* I think the board should classify the newly adopted projects. 
Projects that
churn out of existing
projects should be brought back to the board for classification at 
the time
of creating new CVS
repositories.
* Each umbrella could have a commons and a sandbox to share and play.
* There could be a top level commons to house cross-umbrella 
components.

It seems like what we now have is pretty much in good shape and only 
means
that the following
actions take place...

* Reorganize Jakarta (and may be others??)
The interesting question is what Jakarta becomes after the subprojects 
that want
to become TLPs do so.  I suspect that keeping it as a brand is likely 
to be
helpful, but the brand has been pretty muddled too (is it Apache 
Struts or
Jakarta Struts?  Depends on which book title you read :-), and the 
earlier
perceptions that Jakarta had for high quality server side Java code is 
starting
to slip.

* Enforce project level PMC membership

IMHO, it's just not good enough to satisfy the oversight requirements 
delegated
to the PMCs by the ASF Board.

Just my thoughts.

Regards,
Harish
Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Geir Magnusson Jr.
On Dec 19, 2003, at 2:27 PM, Ted Husted wrote:

Harish Krishnaswamy wrote:
ASF is a group of projects administered by the Apache board members. 
The board delegates certain responsibilities over to the PMCs of the 
individual projects while still maintaining the authority and 
management responsibilities. The PMC is responsible for a wholesome 
code and community of the project it oversees but does not have the 
authority to recognize new projects.
I'd say it the other way around. The ASF is a collection of 
communities that create and maintain codebases. To obtain 
infrastructure support and some legal protection, these communities 
donate the copyright of its software and ownership of its brand to the 
Foundation. In order to provide legal protection and watchdog its 
copyright, the board assigns a vice president to oversee the project. 
A committee is also convened to assist the VP with oversight.
I think this is mostly right, and I say mostly because it's legally 
precise, but in practice, the community tends to be there first, rather 
than be convened later, and the community also tends to suggest to the 
board the individual they wish to 'oversee' (meaning the PMC chair).

The board doesn't always accept the community's recommendation, though, 
and indeed the selection of chair is legally the board's sole 
assignment, as you way.

Since the committee is formed by a resolution of the board, its 
members are eligible for legal protection in the event of a lawsuit.
I don't believe this is correct, although it will require someone else 
to give a definitive answer.  (I've been playing a bit in the legal 
sandbox re some ASF-related issues, so I've been paying attention to 
this...)

Indemnification is granted for directors, officers and members of the 
corporation (the ASF), or serving at the request of the corporation in 
some way.  Thus, the PMC chair, as an officer of the corporation is 
protected, but not all PMC members.  However, the structure of the ASF 
is such that the ASF is the holder of copyright and owner of the code, 
which provides a level of protection for committers.

Also, since the committee is the only formal body created by the 
board, only the votes of committee members are considered binding. 
In the normal course, most or all of the committers are also committee 
members. (Jakarta being an anomaly.)
100% correct

[SNIP]

A very subtle concept is that the ASF doesn't actually own the 
codebase. The codebase belongs to its community, and under the Apache 
License, that community can always vote with its feet. Since it is 
the community that gives the software its value (by using and 
maintaining it), there is an Apache belief that the community is the 
true owner of the codebase. The ASF just owns the brand and 
yesterday's copyright.
I believe that this isn't right - the ASF does own the codebase via the 
copyright, and the codebase is licensed at no cost to any entity that 
is willing to agree to the terms of the license.  That entity, 
community or otherwise, cannot remove that license or change it 
unilaterally.

I think that my understanding of these issues has been clarifying over 
the last several months due to my JCP work.  This stuff always is hard 
for us non-lawyers.  To that end, as I am not a lawyer, all that I said 
above could be completely wrong :)

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Tetsuya Kitahata

On Sat, 20 Dec 2003 07:36:20 -0500
Geir Magnusson Jr. wrote:

 One example might be a lawyer working closely w/ a community (for 
 whatever reason) - that lawyer might be providing tremendous input and 
 participation, but has no need/use for committership.  That person 
 could still be a member of the PMC.

Well said. Also, i think PMC members do *not* have to develop
source codes.
For example, look at ORO. I've heard ORO team does not have 3 *active*
committers, however, I believe some of PMC members (not ORO committers)
can vote at oro-dev and can take *responsibilities* to the codes,
when the vote of ORO X.Y.Z release.
ORO-dev archive (open) memorizes who vote(d) and who are/were
responsible to the votes.

Anyways, I think Jakarta can have Jakartan-Way.

Good luck, folks.

Cheers,

-- Tetsuya. ([EMAIL PROTECTED])


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Ceki Gülcü


Log4j is not leaving. It is simply moving to a new room in the house,
a room with a different label but still located within the same house.
As any house, this house offers protection and comfort to its
inhabitants. It is a place where developers can unleash their creative
powers onto the world. But this house is unique in its degree of openness
and tolerance. Apache is a great place to be regardless of the room
you chose.
As for log4j, its developers will continue to be involved with
Jakarta. Many of us use Jakarta products in our daily work. Moreover,
without the software contained in Jakarta, there wouldn't be much use
for log4j.
So there are no goodbyes to be said, we are just next door. No need to
put on shoes, you can hang on to your slippers. Our door is open, you
don't have to knock when you come in.
At 07:23 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:

On Dec 19, 2003, at 3:33 PM, Costin Manolache wrote:

Ted Husted :


[SNIP]

I agreed w/ every word from Costin.

And look what's happening with logging: Now that it's a TLP, they are 
bringing-in the various Log4J compatibles. Now, there can be one Apache 
logging project serving every platform. That's community-building!

Is logkit included in the logging TLP ? What about commons-logging ?

I agree with you that the logging TLP does define a community ( just 
like  jakarta or httpd ). It's a separate PMC bringing togheter different 
codebases and people.

It remains to be seen if log4j as a TLP will be better than log4j as part 
of jakarta. There are plenty of TLPs - like apache-commons - that
don't seem to be much better than sub-projects like jakarta-commons.
Agreed.  JC is a vibrant sub-project with ties to may Jakarta 
sub-projects.  I think that important and valuable.  I think log4j will do 
fine, and they can always come back.  It's not clear what kind of synergy 
the log4* projects will bring together, but will be interesting to watch.

I had such mixed emotions about log4j leaving, as I think it's going to 
take a bit of our community away.  On the other hand, I support the 
freedom of the log4j community to choose it's own path, and that wins out 
with me.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Geir Magnusson Jr.
On Dec 19, 2003, at 10:33 AM, Andrew C. Oliver wrote:

Radical view: allow the subprojects to send 1-2 delegates to the PMC 
and
require each subproject to send one or die.
I think that the only problem w/ that solution (the first part) is that 
there could be doubt that 1-2 delegates would be enough to guarantee 
coverage, whereas 'more' should convince an outside observer (like the 
board or a court) that did our utmost to ensure solid. continuous 
coverage.

About the send one or die, that's a good, blunt phrasing of reality - 
if the project is unwilling to participate in the PMC it should go 
elsewhere.  Any ASF codebase *must* be overseen by a PMC.  If the 
problem for the subproject is specifically an unwillingness to 
participate in the Jakarta PMC, then it's free to apply for TLP status. 
 If the problem is the notion of PMC itself, it can't remain in the ASF 
for corporate oversight reasons.


 This would size the PMC, assure
that heart attack in the crowd syndrome doesn't take place and make 
the
discussion more manageable.  Have the sub projects manage their own 
policy
for who to send and for how long under threat of being closed.  This 
also
prevents PMC for life syndrome and makes sure that the PMC serves 
not only
the boards interests but the committers of the projects.  It also puts
pressure on PMC members to keep discussions public.
One compromise might be that each subproject choose one of the 
committers from that project on the PMC to be the 'voice' - IOW, when 
we decide how to manage this large a group, we will probably require 
that each subproject report to the chair what's going on, and that 
person reports.  That will keep the number of literal voices down, 
although any PMC member can speak up at any time

geir


-Andy
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are 
almost
definitely not shared by the Apache Software Foundation, its board or 
its
general membership.  In fact they probably most definitively disagree 
with
everything espoused in the above email.

From: Craig R. McClanahan [EMAIL PROTECTED]
Reply-To: Jakarta General List [EMAIL PROTECTED]
Date: Thu, 18 Dec 2003 22:26:44 -0800
To: Jakarta General List [EMAIL PROTECTED], Harish 
Krishnaswamy
[EMAIL PROTECTED]
Cc: Jakarta General List [EMAIL PROTECTED]
Subject: Re: Jakarta: Confederation or Single Project?

Quoting Harish Krishnaswamy [EMAIL PROTECTED]:

Could someone please explain the motivation behind the creation of 
Jakarta
and how it got to where
it is today? May be that would help answer some of the questions we 
have?

-Harish

These comments are going to be (like anyone's would be) colored by my 
own
personal experiences during the development of Jakarta -- including my
ignorance of a lot of the details in subprojects that I'm not an 
active
participant.  But it should give you a little feel for the history of 
the
place.

The gist of the creation of Jakarta was around three facts:

* Apache wasn't an incorporated entity (this is about
four years ago now), but wanted to be -- and was
formally becoming the Apache Software Foundation.
* Apache had a project to build a servlet container
(Apache JServ) at a website called java.apache.org
which created a trademark-use issue around java.
(I was a committer on Apache JServ, which is how I
originally got involved in open source software.)
* Sun wanted to contribute, and Apache wanted to accept,
the source code for the servlet and JSP implementation
called the Java Servlet Development Kit, and later
published by Apache as Tomcat 3.0.
Just as an item of slight historical interest, Jakarta was the name 
of the
conference room at Sun where a lot of the early discussions took 
place.

An organizational framework to focus on developing open source 
server side
Java
stuff was created to host these initiatives, and other related 
subprojects
got
proposed and added to the mix.  As the number of Jakarta committers 
scaled
from
the original 10 or so to where we are today (hundreds), the original 
charter
has
become, umm, somewhat stretched.

Ironically, it didn't take long at all for the scope of that original 
charter
to
get exceeded, because one of the little nuggets of code that was 
included in
the
original Tomcat contribution was a pure-Java build tool (to replace 
make)
called Ant ...

As more and more subprojects were added, there were some inevitable 
cases of
overlapping scope, and overlapping implementations of the same ideas. 
 One of
the best things we've done (IMHO) was purposely creating a subproject
(jakarta-commons) focused on making small, focused, reusable 
packages, and
encouraging the larger projects to use them.  Not only has this been
successful
within Jakarta -- there's been quite a lot of cross-fertilization 
among the
web
app frameworks

Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Geir Magnusson Jr.
On Dec 20, 2003, at 8:24 AM, Ceki Gülcü wrote:



Log4j is not leaving. It is simply moving to a new room in the house,
a room with a different label but still located within the same house.
As any house, this house offers protection and comfort to its
inhabitants. It is a place where developers can unleash their creative
powers onto the world. But this house is unique in its degree of 
openness
and tolerance. Apache is a great place to be regardless of the room
you chose.
Well, you moved out of the Jakarta suite to another part of the Apache 
house :)

As for log4j, its developers will continue to be involved with
Jakarta. Many of us use Jakarta products in our daily work. Moreover,
without the software contained in Jakarta, there wouldn't be much use
for log4j.
So there are no goodbyes to be said, we are just next door. No need to
put on shoes, you can hang on to your slippers. Our door is open, you
don't have to knock when you come in.


public_pestering type=obligatory
Can we have TRACE as a supported level?
/public_pestering

At 07:23 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:

On Dec 19, 2003, at 3:33 PM, Costin Manolache wrote:

Ted Husted :


[SNIP]

I agreed w/ every word from Costin.

And look what's happening with logging: Now that it's a TLP, they 
are bringing-in the various Log4J compatibles. Now, there can be 
one Apache logging project serving every platform. That's 
community-building!

Is logkit included in the logging TLP ? What about commons-logging ?

I agree with you that the logging TLP does define a community ( just 
like  jakarta or httpd ). It's a separate PMC bringing togheter 
different codebases and people.

It remains to be seen if log4j as a TLP will be better than log4j as 
part of jakarta. There are plenty of TLPs - like apache-commons - 
that
don't seem to be much better than sub-projects like jakarta-commons.
Agreed.  JC is a vibrant sub-project with ties to may Jakarta 
sub-projects.  I think that important and valuable.  I think log4j 
will do fine, and they can always come back.  It's not clear what 
kind of synergy the log4* projects will bring together, but will be 
interesting to watch.

I had such mixed emotions about log4j leaving, as I think it's going 
to take a bit of our community away.  On the other hand, I support 
the freedom of the log4j community to choose it's own path, and that 
wins out with me.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider The complete log4j manual
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Ted Husted
Geir Magnusson Jr. wrote:
I'd say it the other way around. The ASF is a collection of 
communities that create and maintain codebases. To obtain 
infrastructure support and some legal protection, these communities 
donate the copyright of its software and ownership of its brand to the 
Foundation. In order to provide legal protection and watchdog its 
copyright, the board assigns a vice president to oversee the project. 
A committee is also convened to assist the VP with oversight.


I think this is mostly right, and I say mostly because it's legally 
precise, but in practice, the community tends to be there first, rather
than be convened later, 
Yes, that's what it says. A collection of communities that ... *not* a
collection of codebases.
[SNIP]

A very subtle concept is that the ASF doesn't actually own the 
codebase. The codebase belongs to its community, and under the Apache 
License, that community can always vote with its feet. Since it is 
the community that gives the software its value (by using and 
maintaining it), there is an Apache belief that the community is the 
true owner of the codebase. The ASF just owns the brand and 
yesterday's copyright.


I believe that this isn't right - the ASF does own the codebase via the 
copyright, and the codebase is licensed at no cost to any entity that is 
willing to agree to the terms of the license.  That entity, community or 
otherwise, cannot remove that license or change it unilaterally.
It owns a static image of the codebase, but from an Apache perspective,
a codebase is a living, growing thing with a lifecycle that can endure
for decades.
The point is that without a community, even if it is a stable community
of users helping users, the codebase has no value, and there is nothing 
*worth* owing.

The board may sometimes disagree with a dysfunctional PMC, for the good
of the community, but I don't believe the board would ever deliberately
act against the community.
The point of the exercise is to create communities around codebases,
which means the community always comes first. (Else, there is no reason
to have the codebase to begin with.)
The essential difference between SourceForge and Apache is that
SourceForge is just about sharing code. Apache is about building
communities around the code we share.
The reason a true community (in the Apache sense of the word) has never
coalesced around Jakarta is that the subprojects were too coarsely
grained to share code. So, we invented the Commons.
The difference between Jakarta and Jakarta Commons is that the Commons
has codebases that are *designed* to be shared with a community of
developers and users.
The truly marvelous thing about Jakarta Commons is that its communities 
transcend Jakarta. Everywhere I go in open-source land these
days, I find other projects importing packages from the Commons. Thus, 
our license and style of management is exposed, and fresh blood is drawn 
into the Apache community, so that the cycle of life can continue.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Santiago Gala
El sábado, 20 dici, 2003, a las 14:00 Europe/Madrid, Geir Magnusson Jr. 
escribió:

On Dec 19, 2003, at 2:27 PM, Ted Husted wrote:


(...)

A very subtle concept is that the ASF doesn't actually own the 
codebase. The codebase belongs to its community, and under the Apache 
License, that community can always vote with its feet. Since it is 
the community that gives the software its value (by using and 
maintaining it), there is an Apache belief that the community is the 
true owner of the codebase. The ASF just owns the brand and 
yesterday's copyright.
I believe that this isn't right - the ASF does own the codebase via 
the copyright, and the codebase is licensed at no cost to any entity 
that is willing to agree to the terms of the license.  That entity, 
community or otherwise, cannot remove that license or change it 
unilaterally.


I think the point Ted makes, summarized as: The ASF just owns the 
brand and yesterday's copyright. is, actually, subtle:

Because of the Apache License, anybody wishing so can carry the code 
and keep the development outside of the ASF, with their own rules and 
licenses. This has only the brand and attribution restriction, as per 
our license.

So, even if nominally, as you say, the code is the ASF property, 
anybody can re-license under different terms, provided that the ASF 
license conditions, the brand, essentially, are met.

In the hypothetical event that the ASF would close our License 
(which, BTW, would be against the ASF charter), the commmunity could 
just stop contributing the same day (hence the yesterday's 
copyright), and keep the development elsewhere, with just a notice, a 
copy of the Apache License and a disclaimer (hence the brand).

This implies that those having easier ability or will to maintain the 
product are the effective owners of it. as in a rapidly changing 
environment, software rot takes care of static code bases.

Regards,
 Santiago
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Ted Husted
Santiago Gala wrote:

[SNIP]

This implies that those having easier ability or will to maintain the 
product are the effective owners of it. as in a rapidly changing 
environment, software rot takes care of static code bases.
Exactly. There is a saying from Dune:

Whoever has the power to destroy a thing, owns that thing.

(The case in point being melange.)

The community has the power to effectively destroy the ASF's codebase by 
defecting and reforming elsewhere, leaving the ASF project dormant.

Conversely, the ASF cannot destroy the codebase, since the community can 
just set up shop somewhere else under a new brand.

Meanwhile, the ASF cannot create or maintain the codebase itself, since 
it has neither the resources nor the will.

So, while the static copyright and the brand belong to the ASF, the 
living codebase belongs to the community that supports it.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-20 Thread Geir Magnusson Jr.
On Dec 20, 2003, at 11:36 AM, Santiago Gala wrote:

El sábado, 20 dici, 2003, a las 14:00 Europe/Madrid, Geir Magnusson 
Jr. escribió:

On Dec 19, 2003, at 2:27 PM, Ted Husted wrote:


(...)

A very subtle concept is that the ASF doesn't actually own the 
codebase. The codebase belongs to its community, and under the 
Apache License, that community can always vote with its feet. 
Since it is the community that gives the software its value (by 
using and maintaining it), there is an Apache belief that the 
community is the true owner of the codebase. The ASF just owns the 
brand and yesterday's copyright.
I believe that this isn't right - the ASF does own the codebase via 
the copyright, and the codebase is licensed at no cost to any entity 
that is willing to agree to the terms of the license.  That entity, 
community or otherwise, cannot remove that license or change it 
unilaterally.


I think the point Ted makes, summarized as: The ASF just owns the 
brand and yesterday's copyright. is, actually, subtle:

Because of the Apache License, anybody wishing so can carry the code 
and keep the development outside of the ASF, with their own rules and 
licenses. This has only the brand and attribution restriction, as 
per our license.
Well, it's not terribly deep, IMO.  They can fork and carry the code, 
but the code that is created has their own rules and license.  The ASF 
code still has the ASF license and thus the rules in that license.

I agree that the beauty of OSS is that anyone can continue w/ a project 
in their own way as they choose, but I just don't think it's that deep 
or subtle.  That freedom is one of the reasons we all are here.

So, even if nominally, as you say, the code is the ASF property, 
anybody can re-license under different terms, provided that the ASF 
license conditions, the brand, essentially, are met.
Not at all.  You can't relicense the code. The Apache Software License 
remains w/ the code.  *new* code can have different terms, but not 
ASF-licensed code.

In the hypothetical event that the ASF would close our License 
(which, BTW, would be against the ASF charter), the commmunity could 
just stop contributing the same day (hence the yesterday's 
copyright), and keep the development elsewhere, with just a notice, a 
copy of the Apache License and a disclaimer (hence the brand).
They can't close the license retroactively - that's one of the great 
things about the license.  There is no risk that in the future, the 
code you have now will become unavailable due to some kind of license 
change.

*Future versions* released under a *different license* may be, but that 
is totally different.  Using a version now doesn't require to use a 
version in the future.

This implies that those having easier ability or will to maintain the 
product are the effective owners of it. as in a rapidly changing 
environment, software rot takes care of static code bases.
However, you have to recognize that sometimes software is done.  Look 
at ORO and Regexp.  Do we use them because they are rapidly innovating, 
or because they do what they say they are going to do, and do it well?

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Michael Davey

Harish Krishnaswamy wrote:

How about Jakarta = Java Development? Then, they all seem in place, no?

Henri Yandell wrote:

Because it's wrong.

XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all
Java Development and not in Jakarta.

Jakarta is the *brand*.  It defines itself.  Jakarta brand development. 
A brand can give a unique identity and grouping to an otherwise 
disparate and commodity range of goods and services.  Think of any large 
brand:

McDonalds:  Fast food restaurants.  And accommodation.  And a childrens 
charity.

Nike: Sneakers (trainers).  And sports clothing.  And fashion clothing. 
And a sports team. And a college (American) football league.

Virgin.  Music label.  And music shops.  And hot air balloons.  And an 
airline.  And trains.  And mobile 'phones, drinks, health clubs, 
Internet service provider, credit cards, finance and car rentals.

Personally, I think the Jakarta brand has much much more to say about 
*how* the software is developed and *how* the community operates than 
*what* products are offered, *what* language it is written in and *what* 
languages can use the products.

So perhaps the Jakarta tagline should be ...it's in the process. 
...it's in the community.

--
Michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Ted Husted
Michael Davey wrote:
Jakarta is the *brand*.  It defines itself.  Jakarta brand development. 
A brand can give a unique identity and grouping to an otherwise 
disparate and commodity range of goods and services.  
Apache is a brand too, and, IMHO, a much stronger brand than Jakarta.

I believe Jakarta distracts people from the fact that everything we do 
here is on behalf of the Apache Software Foundation. We are not Jakarta 
Committers, we are Apache Committers. We use the Apache License, 
package our product for apache.org, check code into cvs.apache.org, and 
donate every line to the Apache Software Foundation.

I realize that there are people who have romantic notions about 
Jakarta and like to talk about preserving Jakarta for Jakarta's sake. 
But for the life of me, I can't see why. For me, it's always been about 
the codebase and its community. If a product I use is hosted at 
SourceForge, I work at SourceForge. If it's hosted at Jakarta, I work at 
Jakarta. If it's a top-level ASF project, then I work there. I go where 
my community lives; and my community is centered on a codebase, not a 
hostname.

There are people who have called Jakarta a jewel. I'd agree that 
Cactus is a jewel, as is Lucene, and Velocity, and all the other 
*communities* we've built around our codebases. But Jakarta is not the 
jewel, at best it's a jewelry box.

All along, there have been people who envisioned a Jakarta community. 
But, what's the point of that, really? We already have the Apache 
community and the open source community. Why do we need another 
community within a community? What's the point of another layer of 
indirection?

In my experience, if you make a significant contribution to any open 
source codebase anywhere, its community will welcome you with open arms. 
We don't need hostnames to create communities. People create their own 
communities and forge their own relationships, by the simple virtue of 
their contributions.

And look what's happening with logging: Now that it's a TLP, they are 
bringing-in the various Log4J compatibles. Now, there can be one Apache 
logging project serving every platform. That's community-building!

The real, underlying issue with Jakarta is that most of our products are 
*not* about Java. They are about a feature set. Java was just a 
convenient implementation language, but most of our products could be 
implemented in other languages and made available to a broader community.

In fact, many have, but since they are not Java implementations, we have 
multiple communities around a product instead of one. A language-centric 
project like Jakarta doesn't create community, it dilutes it.

But I would not say that Jakarta is broken. I'd say Jakarta is finally 
starting to work. The proof that Jakarta is working is that products are 
finally growing up and becoming projects.

Every worthy parent's goal is self-sustaining children. The Foundation, 
like a good parent, has always tried to build self-sustaining projects 
-- projects that can outlive their creators. I'm happy that some of 
these projects were born at Jakarta and became great enough to join our 
top-level peers.

So, why are Ant, Maven, Logging, Slide, et al, graduating to top-level 
Apache projects: because they can :)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Geir Magnusson Jr.
On Dec 19, 2003, at 8:01 AM, Ted Husted wrote:

Michael Davey wrote:
Jakarta is the *brand*.  It defines itself.  Jakarta brand 
development. A brand can give a unique identity and grouping to an 
otherwise disparate and commodity range of goods and services.
Apache is a brand too, and, IMHO, a much stronger brand than Jakarta.
Not to Java people.  I agree w/ you that it should be, but Apache 
Jakarta serves just as well, just as Apache Httpd is a strong brand 
too :)

I believe Jakarta distracts people from the fact that everything we do 
here is on behalf of the Apache Software Foundation. We are not 
Jakarta Committers, we are Apache Committers. We use the Apache 
License, package our product for apache.org, check code into 
cvs.apache.org, and donate every line to the Apache Software 
Foundation.

I realize that there are people who have romantic notions about 
Jakarta and like to talk about preserving Jakarta for Jakarta's 
sake. But for the life of me, I can't see why. For me, it's always 
been about the codebase and its community.
Jakarta is also a community - while it may also be a romantic notion, 
it is a fact. Denying that fact serves well the high-minded notion of 
for the Foundation, but ignores the reality.

The ASF has seen the incredible growth of codebase, community and thus 
opportunity for participation in the projects like Jakarta, XML, 
WebServices, etc, all of which are larger umpbrella-like entities where 
like minded people can come together and work on whatever scratches 
their itch near and with others that also have the same interests.

Preserving those fostering communities is a romantic notion worth 
working for, and not at adds with the ASF or it's governance 
requirements.  It generates an opportunity for new ideas and 
collaborations to take hold, and a place go grow and live until the 
project wants to be a TLP.  Or doesn't.  :)

geir

P.S. And before you say Incubator Project,  the Incubator is by 
design not intended to be such an entity, but rather a mechanism to 
ensure health and accounting of IP and community of incoming codebases 
and projects, the protection of the ASF.

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Andrew C. Oliver
Radical view: allow the subprojects to send 1-2 delegates to the PMC and
require each subproject to send one or die.  This would size the PMC, assure
that heart attack in the crowd syndrome doesn't take place and make the
discussion more manageable.  Have the sub projects manage their own policy
for who to send and for how long under threat of being closed.  This also
prevents PMC for life syndrome and makes sure that the PMC serves not only
the boards interests but the committers of the projects.  It also puts
pressure on PMC members to keep discussions public.

-Andy
-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?

The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership.  In fact they probably most definitively disagree with
everything espoused in the above email.

 From: Craig R. McClanahan [EMAIL PROTECTED]
 Reply-To: Jakarta General List [EMAIL PROTECTED]
 Date: Thu, 18 Dec 2003 22:26:44 -0800
 To: Jakarta General List [EMAIL PROTECTED], Harish Krishnaswamy
 [EMAIL PROTECTED]
 Cc: Jakarta General List [EMAIL PROTECTED]
 Subject: Re: Jakarta: Confederation or Single Project?
 
 Quoting Harish Krishnaswamy [EMAIL PROTECTED]:
 
 Could someone please explain the motivation behind the creation of Jakarta
 and how it got to where
 it is today? May be that would help answer some of the questions we have?
 
 -Harish
 
 
 These comments are going to be (like anyone's would be) colored by my own
 personal experiences during the development of Jakarta -- including my
 ignorance of a lot of the details in subprojects that I'm not an active
 participant.  But it should give you a little feel for the history of the
 place.
 
 The gist of the creation of Jakarta was around three facts:
 
 * Apache wasn't an incorporated entity (this is about
 four years ago now), but wanted to be -- and was
 formally becoming the Apache Software Foundation.
 
 * Apache had a project to build a servlet container
 (Apache JServ) at a website called java.apache.org
 which created a trademark-use issue around java.
 (I was a committer on Apache JServ, which is how I
 originally got involved in open source software.)
 
 * Sun wanted to contribute, and Apache wanted to accept,
 the source code for the servlet and JSP implementation
 called the Java Servlet Development Kit, and later
 published by Apache as Tomcat 3.0.
 
 Just as an item of slight historical interest, Jakarta was the name of the
 conference room at Sun where a lot of the early discussions took place.
 
 An organizational framework to focus on developing open source server side
 Java
 stuff was created to host these initiatives, and other related subprojects
 got
 proposed and added to the mix.  As the number of Jakarta committers scaled
 from
 the original 10 or so to where we are today (hundreds), the original charter
 has
 become, umm, somewhat stretched.
 
 Ironically, it didn't take long at all for the scope of that original charter
 to
 get exceeded, because one of the little nuggets of code that was included in
 the
 original Tomcat contribution was a pure-Java build tool (to replace make)
 called Ant ...
 
 As more and more subprojects were added, there were some inevitable cases of
 overlapping scope, and overlapping implementations of the same ideas.  One of
 the best things we've done (IMHO) was purposely creating a subproject
 (jakarta-commons) focused on making small, focused, reusable packages, and
 encouraging the larger projects to use them.  Not only has this been
 successful
 within Jakarta -- there's been quite a lot of cross-fertilization among the
 web
 app frameworks, for example -- it's also created a fairly rich library of
 funcational packages that are widely used elsewhere.  But one could really
 argue whether something like Commons Digester (originally designed as an
 easy-to-use tool to parse XML configuration files) really fit the Jakarta
 charter.
 
 Over time, there have been more than a few, err, voluminous discussions
 about
 how to scale up Jakarta from an organizational perspective, and whether the
 fundamental organizing principle was still the correct one.  Does a focus on
 server side stuff exclude what could be some really interesting open source
 projects?  Does a focus on Java make sense when just across the website there
 are things like xml.apache.org that are focused on a technology, not on an
 implementation language?  Does it make sense to have community type projects
 that host individual software package projects at all?
 
 Coupled with these increasing concerns (at the ASF board level) about the
 ability of any oversight group (a responsibility delegated to PMCs in the ASF
 organizational structure), several original Jakarta subprojects (or even
 sub-sub-projects in some cases

Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Michael Davey
Ted Husted wrote:

Michael Davey wrote:

Jakarta is the *brand*.  It defines itself.  Jakarta brand 
development. A brand can give a unique identity and grouping to an 
otherwise disparate and commodity range of goods and services.  


Apache is a brand too, and, IMHO, a much stronger brand than Jakarta. 
The relative brand strengths aren't important to this discussion (I 
think we will have to agree to disagree in any case).  I was simply 
attempting to demonstrate two points:
 *  a brand can unify products that otherwise would have no business 
being together
 *  a brand can be used to give a concrete definition of otherwise 
abstract, ill-defined or hard-to-grasp concepts

I realize that there are people who have romantic notions about 
Jakarta and like to talk about preserving Jakarta for Jakarta's 
sake. But for the life of me, I can't see why. For me, it's always 
been about the codebase and its community. [snip] I go where my 
community lives; and my community is centered on a codebase, not a 
hostname. 
[snip]

All along, there have been people who envisioned a Jakarta 
community. But, what's the point of that, really? We already have the 
Apache community and the open source community. Why do we need another 
community within a community?
To me, there is a difference between the Jakarta community and the 
Apache community.  I think that the Jakarta community have a slightly 
different set of values than the wider Apache community.  The values 
aren't wildly different, but they are different none the less.  I think 
that this difference is most noticable in the discussions on lists like 
this.

Now I'm not entirely sure I explicitly know both sets of values.  In 
part this is because there is a difference between what the community 
claims as its values and how the community acts and in part because many 
of the values that the Jakarta community claims aren't written down.

Certainly, the Jakarta community tend to go about their business in a 
slightly different way to the wider Apache community.  Sometimes, the 
Jakarta way seems to work better or seems to be leading the way (for 
instance near-total transparency and openness, even when in means 
airing your dirty laundry, or commons and commons-sandbox) and 
sometimes the Jakarta way demonstrates that it hasn't learned the 
lessons that the wider Apache community learned the hard way (such as 
keeping secret the rationale for blocking an admision to a board of people).

Perhaps there is actually a The Jakarta Way that is similar to The 
Apache Way, that is not explicit right now.   Such a term could 
encapsulate the Jakarta process, approach to the community and values.

The real, underlying issue with Jakarta is that most of our products 
are *not* about Java. They are about a feature set. Java was just a 
convenient implementation language, but most of our products could be 
implemented in other languages and made available to a broader community. 
Agreed.

My fear is that if we don't work now to really understand The Jakarta 
Way, install the good bits into The Apache Way and document the problems 
and solutions to the bad bits, ASF may loose something of real worth and 
may not ever truely recover.  I am not sentimental about the Jakarta 
name, but I do recognise that Jakarta represents something unique that 
we are in danger of loosing.

--
Michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Harish Krishnaswamy
Thanks Craig, this is elaborate, informative and puts the issue in my perspective. May be this 
should be put on the website too somewhere.

Here are my inferences so far...

inferences
ASF is a group of projects administered by the Apache board members. The board delegates certain 
responsibilities over to the PMCs of the individual projects while still maintaining the authority 
and management responsibilities. The PMC is responsible for a wholesome code and community of the 
project it oversees but does not have the authority to recognize new projects.

Jakarta started out as a single project for a web container and has grown into a foundation of 
projects in itself without sufficient administration/organization.
/inferences

Here are my thoughts distilled from a lot others'...

* I think the projects at ASF should be classified in some way (preferably by technology like we 
have now for xml, db etc.) into umbrella projects. All projects piled together at the top level 
would not convey very well. This is where Jakarta would need redefinition. Seems like the inital 
motivation, server side web development, is a good fit. And that would mean some reshuffling.
* I think each umbrella project or each project within could have a PMC and each project should 
maintain a PMC membership of atleast 51% of its committers to sustain.
* I think the website should match the organizational structure to avoid confusion.
* I think the board should classify the newly adopted projects. Projects that churn out of existing 
projects should be brought back to the board for classification at the time of creating new CVS 
repositories.
* Each umbrella could have a commons and a sandbox to share and play.
* There could be a top level commons to house cross-umbrella components.

It seems like what we now have is pretty much in good shape and only means that the following 
actions take place...

* Reorganize Jakarta (and may be others??)
* Enforce project level PMC membership
Just my thoughts.

Regards,
Harish
Craig R. McClanahan wrote:

Quoting Harish Krishnaswamy [EMAIL PROTECTED]:


Could someone please explain the motivation behind the creation of Jakarta
and how it got to where 
it is today? May be that would help answer some of the questions we have?

-Harish



These comments are going to be (like anyone's would be) colored by my own
personal experiences during the development of Jakarta -- including my
ignorance of a lot of the details in subprojects that I'm not an active
participant.  But it should give you a little feel for the history of the
place.
The gist of the creation of Jakarta was around three facts:

* Apache wasn't an incorporated entity (this is about
  four years ago now), but wanted to be -- and was
  formally becoming the Apache Software Foundation.
* Apache had a project to build a servlet container
  (Apache JServ) at a website called java.apache.org
  which created a trademark-use issue around java.
  (I was a committer on Apache JServ, which is how I
  originally got involved in open source software.)
* Sun wanted to contribute, and Apache wanted to accept,
  the source code for the servlet and JSP implementation
  called the Java Servlet Development Kit, and later
  published by Apache as Tomcat 3.0.
Just as an item of slight historical interest, Jakarta was the name of the
conference room at Sun where a lot of the early discussions took place.
An organizational framework to focus on developing open source server side Java
stuff was created to host these initiatives, and other related subprojects got
proposed and added to the mix.  As the number of Jakarta committers scaled from
the original 10 or so to where we are today (hundreds), the original charter
has
become, umm, somewhat stretched.
Ironically, it didn't take long at all for the scope of that original charter to
get exceeded, because one of the little nuggets of code that was included in
the
original Tomcat contribution was a pure-Java build tool (to replace make)
called Ant ...
As more and more subprojects were added, there were some inevitable cases of
overlapping scope, and overlapping implementations of the same ideas.  One of
the best things we've done (IMHO) was purposely creating a subproject
(jakarta-commons) focused on making small, focused, reusable packages, and
encouraging the larger projects to use them.  Not only has this been successful
within Jakarta -- there's been quite a lot of cross-fertilization among the web
app frameworks, for example -- it's also created a fairly rich library of
funcational packages that are widely used elsewhere.  But one could really
argue whether something like Commons Digester (originally designed as an
easy-to-use tool to parse XML configuration files) really fit the Jakarta
charter.
Over time, there have been more than a few, err, voluminous discussions about
how to scale up Jakarta from an organizational perspective, and whether the
fundamental organizing principle was still the correct one.  

Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Craig R. McClanahan
Quoting Harish Krishnaswamy [EMAIL PROTECTED]:

 Thanks Craig, this is elaborate, informative and puts the issue in my
 perspective. May be this 
 should be put on the website too somewhere.
 
 Here are my inferences so far...
 
 inferences
 ASF is a group of projects administered by the Apache board members. The
 board delegates certain 
 responsibilities over to the PMCs of the individual projects while still
 maintaining the authority 
 and management responsibilities. The PMC is responsible for a wholesome code
 and community of the 
 project it oversees but does not have the authority to recognize new
 projects.
 
 Jakarta started out as a single project for a web container and has grown
 into a foundation of 
 projects in itself without sufficient administration/organization.
 /inferences
 

Waiting for the bureacracy to be created first is kind of antithetical to the
way most open source developers think :-).

 Here are my thoughts distilled from a lot others'...
 
 * I think the projects at ASF should be classified in some way (preferably by
 technology like we 
 have now for xml, db etc.) into umbrella projects. All projects piled
 together at the top level 
 would not convey very well. This is where Jakarta would need redefinition.
 Seems like the inital 
 motivation, server side web development, is a good fit. And that would mean
 some reshuffling.

The problem with graph shaped (single inheritance) hierarchies is that
sometimes a single project fits more than one place.  For example, where do you
put Cocoon?  It's clearly a thing that fits into an XML Technologies sort of
place.  It's also a thing that clearly fits into a server site technologies
sort of place.  The answer that Cocoon chose (the right one, IMHO) was to be a
separate TLP that is *linked* to both of those technology's web sites.

But, the more fundamental principle is that the legal organization of the ASF
need not have anything at all to do with how websites are organized and how
projects are made visible.

 * I think each umbrella project or each project within could have a PMC and
 each project should 
 maintain a PMC membership of atleast 51% of its committers to sustain.

That's pretty much the way that Jakarta works now (we've focused on expanding
the PMC membership over the last year to ensure coverage from all the
subprojects).  But, as a Jakarta PMC member, it's still a daunting thought to
be held responsible for oversight of all the code, and all the releases, across
all of Jakarta.  It's hard enough for me, for example, just to stay current on
the three projects I watch and try to participate in (Commons, Struts, Tomcat).
 I'm pretty clueless about what the Tapestry folks are doing, yet *I* need to
approve releases?

Having Tapestry committers on the PMC helps, but isn't sufficient.

 * I think the website should match the organizational structure to avoid
 confusion.

I don't agree.  The website(s) should be focused around making it easy for users
to  find out what Apache projects might have products that are relevant to
their needs.  The internal project organization is an implementation detail.

 * I think the board should classify the newly adopted projects. Projects that
 churn out of existing 
 projects should be brought back to the board for classification at the time
 of creating new CVS 
 repositories.
 * Each umbrella could have a commons and a sandbox to share and play.
 * There could be a top level commons to house cross-umbrella components.
 
 It seems like what we now have is pretty much in good shape and only means
 that the following 
 actions take place...
 
 * Reorganize Jakarta (and may be others??)

The interesting question is what Jakarta becomes after the subprojects that want
to become TLPs do so.  I suspect that keeping it as a brand is likely to be
helpful, but the brand has been pretty muddled too (is it Apache Struts or
Jakarta Struts?  Depends on which book title you read :-), and the earlier
perceptions that Jakarta had for high quality server side Java code is starting
to slip.

 * Enforce project level PMC membership
 

IMHO, it's just not good enough to satisfy the oversight requirements delegated
to the PMCs by the ASF Board.

 Just my thoughts.
 
 Regards,
 Harish
 

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Ted Husted
Harish Krishnaswamy wrote:
ASF is a group of projects administered by the Apache board members. The 
board delegates certain responsibilities over to the PMCs of the 
individual projects while still maintaining the authority and management 
responsibilities. The PMC is responsible for a wholesome code and 
community of the project it oversees but does not have the authority to 
recognize new projects.
I'd say it the other way around. The ASF is a collection of communities 
that create and maintain codebases. To obtain infrastructure support and 
some legal protection, these communities donate the copyright of its 
software and ownership of its brand to the Foundation. In order to 
provide legal protection and watchdog its copyright, the board assigns a 
vice president to oversee the project. A committee is also convened to 
assist the VP with oversight.

Since the committee is formed by a resolution of the board, its members 
are eligible for legal protection in the event of a lawsuit. Also, since 
the committee is the only formal body created by the board, only the 
votes of committee members are considered binding. In the normal 
course, most or all of the committers are also committee members. 
(Jakarta being an anomaly.)

In most cases, the community's codebase is focussed on a single product, 
and so all the committee members and committers are in tune with what 
is happening with it. The ASF has also been exploring the idea of 
umbrella projects like Jakarta, XML, Database, and Web Services. At 
this time, there is no clear consensus of whether these umbrella 
projects can function as well as the traditional projects.

A very subtle concept is that the ASF doesn't actually own the 
codebase. The codebase belongs to its community, and under the Apache 
License, that community can always vote with its feet. Since it is the 
community that gives the software its value (by using and maintaining 
it), there is an Apache belief that the community is the true owner of 
the codebase. The ASF just owns the brand and yesterday's copyright.

The board is *very* sensitive to the needs of its communities. Software 
versions come and go, but communities endure.

-Ted.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Costin Manolache
Andrew C. Oliver wrote:
Radical view: allow the subprojects to send 1-2 delegates to the PMC and
require each subproject to send one or die.  This would size the PMC, assure
that heart attack in the crowd syndrome doesn't take place and make the
discussion more manageable.  Have the sub projects manage their own policy
for who to send and for how long under threat of being closed.  This also
prevents PMC for life syndrome and makes sure that the PMC serves not only
the boards interests but the committers of the projects.  It also puts
pressure on PMC members to keep discussions public.
I don't like this 1-2 delegates. All active committers in a subproject 
should be in the PMC ( unless they don't want to ).

The concern that there are too many people is absurd. What is missing is
a bit of discipline in proposals/votes - and that has nothing to do with 
the number of people.

As you said, all discussions should happen on jakarta-general - so each 
jakarta committer ( including those who chose not to be in PMC ) get to
participate and express their opinion. The vote should be on 
jakarta-general too ( counting as binding only PMC member votes, of 
course ).

The difference between committers who are in PMC and the other should be 
only in the counting of the votes.

The other argument - that nobody can or want to be responsible for 
codebases he is not involved with - is also bad. Each PMC member is
overseeing whatever he chooses to ( typically the projects he is 
involved with and some he voluunteers to ). Every member of the PMC
can vote on any issue - but it is common sense that those who are not
involved with a codebase will abstain ( unless they have a good reason 
not to ).

Costin











-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Costin Manolache
Ted Husted wrote:
Michael Davey wrote:

Jakarta is the *brand*.  It defines itself.  Jakarta brand 
development. A brand can give a unique identity and grouping to an 
otherwise disparate and commodity range of goods and services.  


Apache is a brand too, and, IMHO, a much stronger brand than Jakarta.

I believe Jakarta distracts people from the fact that everything we do 
here is on behalf of the Apache Software Foundation. We are not Jakarta 
Committers, we are Apache Committers. We use the Apache License, 
package our product for apache.org, check code into cvs.apache.org, and 
donate every line to the Apache Software Foundation.
We are apache committers - but each apache committer is also httpd 
committer or cocoon committer or jakarta comitter.

You can't deny that HTTPD has a community of people, just like jakarta 
- which is not identical with the whole ASF ( even if ASF was originally 
the HTTPD community ).

ASF is a collection of communities - some bigger, some smaller. Jakarta 
happens to be the bigger - and as long as you believe we are jakarta 
committers, you should also accept that jakarta _is_ a community just 
like httpd.

A lot of people seem to have a problem with us feeling part of jakarta 
- and at the same time denying that jakarta is a community.

IMO TLP is very closely related to community - in the sense that each 
TLP is or should be centered around a community.




I realize that there are people who have romantic notions about 
Jakarta and like to talk about preserving Jakarta for Jakarta's sake. 
But for the life of me, I can't see why. For me, it's always been about 
the codebase and its community. If a product I use is hosted at 
SourceForge, I work at SourceForge. If it's hosted at Jakarta, I work at 
Jakarta. If it's a top-level ASF project, then I work there. I go where 
my community lives; and my community is centered on a codebase, not a 
hostname.
I think it's not about codebase or hostname, but it is about community.

As long as a project choose to remain part of jakarta - and refer to 
themself as jakarta committer - they are part of the jakarta 
community, just like an HTTPD committer is part of the httpd community.

And a community with people from struts + tomcat + velocity + taglibs + 
cactus + POI +  ( whatever projects choose to remain part of jakarta 
) is IMO stronger that N separate TLPs, sourceforge-style.




There are people who have called Jakarta a jewel. I'd agree that 
Cactus is a jewel, as is Lucene, and Velocity, and all the other 
*communities* we've built around our codebases. But Jakarta is not the 
jewel, at best it's a jewelry box.
The fact that people from velocity, struts, poi, etc are all involved in 
this discussion about jakarta should mean that jakarta is a bit more 
than a sourceforge.



All along, there have been people who envisioned a Jakarta community. 
But, what's the point of that, really? We already have the Apache 
community and the open source community. Why do we need another 
community within a community? What's the point of another layer of 
indirection?
And if each codebase in jakarta becomes a TLP - wouldn't this be another
level if indirection ?
Apache community and open source community are all great - but both of 
them are one way or another an umbrella for multiple smaller communities.

ASF is the real umbrella - not jakarta.

Jakarta has multiple codebases and it started as an umbrella - but we 
managed to act and be perceived as a community. Not a perfect community.



And look what's happening with logging: Now that it's a TLP, they are 
bringing-in the various Log4J compatibles. Now, there can be one Apache 
logging project serving every platform. That's community-building!
Is logkit included in the logging TLP ? What about commons-logging ?

I agree with you that the logging TLP does define a community ( just 
like  jakarta or httpd ). It's a separate PMC bringing togheter 
different codebases and people.

It remains to be seen if log4j as a TLP will be better than log4j as 
part of jakarta. There are plenty of TLPs - like apache-commons - that
don't seem to be much better than sub-projects like jakarta-commons.



Costin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-19 Thread Costin Manolache
Bill Barker wrote:
I'm sure that Craig or other will correct my mistakes (I haven't been here
quite that long :).
Jakarta started as Tomcat and friends after Sun donated Tomcat to the ASF
(hence the name 'Jakarta' :).  As the project grew (sign of success),
Jakarta grew to include projects that don't necessarily rely on Tomcat (but
could be used with), nor that Tomcat relies on.  This has been the
traditional server-side-java test.
Now, Jakarta has been having projects that want to leave to ASF-TLP status
(e.g. log4j, ant, maven, james).  This is calling into question what the
'Jakarta' name stands for now.  What this thread is about is trying to
answer this question:  what, if any, is the mission of 'Jakarta' going
forward.


I think Tomcat and friends remains an excelent definition :-)

( it's the friends part that is important - tomcat just happens to be
the first project in jakarta :-)


Costin



- Original Message - 
From: Harish Krishnaswamy [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 9:11 PM
Subject: Re: Jakarta: Confederation or Single Project?



Could someone please explain the motivation behind the creation of Jakarta
and how it got to where

it is today? May be that would help answer some of the questions we have?

-Harish



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Harish Krishnaswamy
How about Jakarta = Java Development? Then, they all seem in place, no?

-Harish

Henri Yandell wrote:

On Thu, 18 Dec 2003, Costin Manolache wrote:



IMO it would be sad if projects like struts or tapestry leave jakarta -
since they are closely related to web development and server side java
( compared with log4j or regexp for example ).


So, Jakarta = Server side web development is the subtitle.

Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and
FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in
that they don't focus on that subtitle.
Slide would be if a WebDAV TLP were to arrive.

Just as a flamebait suggestion :)

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Tetsuya Kitahata

On Thu, 18 Dec 2003 20:24:00 -0500
(Subject: Re: Jakarta: Confederation or Single Project?)
Harish Krishnaswamy wrote:

 How about Jakarta = Java Development? Then, they all seem in place, no?
 
 -Harish

+1. Agreed.

Why don't Jakarta adopt EU-like governance style?
(Board = Secretariat of the United Nations:
Jakarta Sub-Projects can have the status of Nation
Jakarta itself is United Nations. Other TLPs are
Nations)

People often hold of the wrong end of the stick and assume that
bylaws is for bylaws. -- NO -- Bylaws is *for* the components
of each communities/organizations.

I'd like to see --
   Jakarta PMC: responsible for jakarta-site/jakarta-site2
   Tomcat PMC: tomcat and related code
   Struts PMC: struts and related code
   Jakarta Commons PMC: ...
   Tapestry PMC: ...
   ...
styled governance (what Noel mentioned) in jakarta tlp.

I am not a laywer, however, there might be no legal problem.

Regards,

-- Tetsuya. ([EMAIL PROTECTED])


 Henri Yandell wrote:
 
  
  On Thu, 18 Dec 2003, Costin Manolache wrote:
  
  
  
 IMO it would be sad if projects like struts or tapestry leave jakarta -
 since they are closely related to web development and server side java
 ( compared with log4j or regexp for example ).
  
  
  So, Jakarta = Server side web development is the subtitle.
  
  Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and
  FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in
  that they don't focus on that subtitle.
  
  Slide would be if a WebDAV TLP were to arrive.
  
  Just as a flamebait suggestion :)
  
  Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Henri Yandell

Because it's wrong.

XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all
Java Development and not in Jakarta.

If we go with this approach, we end up with the continuation of: should
digester be in jakarta or xml etc. Does XML take precedence over the fact
it's in Java, or does it just depend on which community creates or invites
the codebase. As they have to go through the Incubator now [or be
fast-tracked with the board's new scheme Greg mentioned], is the community
inviting them in as important as it used to be.

I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is
Java web development, but only indirectly I think, ditto for Avalon].

Hen

On Thu, 18 Dec 2003, Harish Krishnaswamy wrote:

 How about Jakarta = Java Development? Then, they all seem in place, no?

 -Harish

 Henri Yandell wrote:

 
  On Thu, 18 Dec 2003, Costin Manolache wrote:
 
 
 
 IMO it would be sad if projects like struts or tapestry leave jakarta -
 since they are closely related to web development and server side java
 ( compared with log4j or regexp for example ).
 
 
  So, Jakarta = Server side web development is the subtitle.
 
  Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and
  FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in
  that they don't focus on that subtitle.
 
  Slide would be if a WebDAV TLP were to arrive.
 
  Just as a flamebait suggestion :)
 
  Hen
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Harish Krishnaswamy
That's true, so back to Jakarta = Server side web development! But is it restricted only to Java 
web development or just plain web development?

-Harish

Henri Yandell wrote:

Because it's wrong.

XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all
Java Development and not in Jakarta.
If we go with this approach, we end up with the continuation of: should
digester be in jakarta or xml etc. Does XML take precedence over the fact
it's in Java, or does it just depend on which community creates or invites
the codebase. As they have to go through the Incubator now [or be
fast-tracked with the board's new scheme Greg mentioned], is the community
inviting them in as important as it used to be.
I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is
Java web development, but only indirectly I think, ditto for Avalon].
Hen

On Thu, 18 Dec 2003, Harish Krishnaswamy wrote:


How about Jakarta = Java Development? Then, they all seem in place, no?

-Harish

Henri Yandell wrote:


On Thu, 18 Dec 2003, Costin Manolache wrote:




IMO it would be sad if projects like struts or tapestry leave jakarta -
since they are closely related to web development and server side java
( compared with log4j or regexp for example ).


So, Jakarta = Server side web development is the subtitle.

Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and
FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in
that they don't focus on that subtitle.
Slide would be if a WebDAV TLP were to arrive.

Just as a flamebait suggestion :)

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Stephen Colebourne
Not really (my POV)

As people we naturally think in terms of the hierarchy
  ASF to Jakarta to MySubProject.
But the middle layer is artificial. It could just as well be XML or DB or
WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe
Bloggs works'. There simply is no one way of categorizing, hence there
actually is no one community either. (ie. 'the jakarta community' simply
does not exist in my eyes)

The alternative is a one layer structure
   ASF to MyProject
which gives full oversight, management and confidence both to the ASF and
the ASF. Separately, there is a search website that allows searches by all
the different ways that you might want to look things up.

After all, the one layer (TLP) structure didn't harm Ant or James, and
almost certainly benefitted Maven, Avalon and from the looks of it Log4J. In
the end, actions will speak louder than words.

Stephen


- Original Message -
From: Harish Krishnaswamy [EMAIL PROTECTED]
 That's true, so back to Jakarta = Server side web development! But is it
restricted only to Java
 web development or just plain web development?

 -Harish

 Henri Yandell wrote:

  Because it's wrong.
 
  XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all
  Java Development and not in Jakarta.
 
  If we go with this approach, we end up with the continuation of: should
  digester be in jakarta or xml etc. Does XML take precedence over the
fact
  it's in Java, or does it just depend on which community creates or
invites
  the codebase. As they have to go through the Incubator now [or be
  fast-tracked with the board's new scheme Greg mentioned], is the
community
  inviting them in as important as it used to be.
 
  I'd much rather find a real subtitle for Jakarta that fits well [Cocoon
is
  Java web development, but only indirectly I think, ditto for Avalon].
 
  Hen
 
  On Thu, 18 Dec 2003, Harish Krishnaswamy wrote:
 
 
 How about Jakarta = Java Development? Then, they all seem in place,
no?
 
 -Harish
 
 Henri Yandell wrote:
 
 
 On Thu, 18 Dec 2003, Costin Manolache wrote:
 
 
 
 
 IMO it would be sad if projects like struts or tapestry leave
jakarta -
 since they are closely related to web development and server side
java
 ( compared with log4j or regexp for example ).
 
 
 So, Jakarta = Server side web development is the subtitle.
 
 Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and
 FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in
 that they don't focus on that subtitle.
 
 Slide would be if a WebDAV TLP were to arrive.
 
 Just as a flamebait suggestion :)
 
 Hen
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Harish Krishnaswamy
I like the idea but does this mean we will be dumping the Jakarta banner? Or will it serve as an 
incubator for TLPs? The Jakarta banner has earned quite a reputation and would be a shame to dump it.

-Harish

Stephen Colebourne wrote:

Not really (my POV)

As people we naturally think in terms of the hierarchy
  ASF to Jakarta to MySubProject.
But the middle layer is artificial. It could just as well be XML or DB or
WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe
Bloggs works'. There simply is no one way of categorizing, hence there
actually is no one community either. (ie. 'the jakarta community' simply
does not exist in my eyes)
The alternative is a one layer structure
   ASF to MyProject
which gives full oversight, management and confidence both to the ASF and
the ASF. Separately, there is a search website that allows searches by all
the different ways that you might want to look things up.
After all, the one layer (TLP) structure didn't harm Ant or James, and
almost certainly benefitted Maven, Avalon and from the looks of it Log4J. In
the end, actions will speak louder than words.
Stephen

- Original Message -
From: Harish Krishnaswamy [EMAIL PROTECTED]
That's true, so back to Jakarta = Server side web development! But is it
restricted only to Java

web development or just plain web development?

-Harish

Henri Yandell wrote:


Because it's wrong.

XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all
Java Development and not in Jakarta.
If we go with this approach, we end up with the continuation of: should
digester be in jakarta or xml etc. Does XML take precedence over the
fact

it's in Java, or does it just depend on which community creates or
invites

the codebase. As they have to go through the Incubator now [or be
fast-tracked with the board's new scheme Greg mentioned], is the
community

inviting them in as important as it used to be.

I'd much rather find a real subtitle for Jakarta that fits well [Cocoon
is

Java web development, but only indirectly I think, ditto for Avalon].

Hen

On Thu, 18 Dec 2003, Harish Krishnaswamy wrote:



How about Jakarta = Java Development? Then, they all seem in place,
no?

-Harish

Henri Yandell wrote:



On Thu, 18 Dec 2003, Costin Manolache wrote:





IMO it would be sad if projects like struts or tapestry leave
jakarta -

since they are closely related to web development and server side
java

( compared with log4j or regexp for example ).


So, Jakarta = Server side web development is the subtitle.

Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and
FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in
that they don't focus on that subtitle.
Slide would be if a WebDAV TLP were to arrive.

Just as a flamebait suggestion :)

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Phil Steitz
Stephen Colebourne wrote:
Not really (my POV)

As people we naturally think in terms of the hierarchy
  ASF to Jakarta to MySubProject.
But the middle layer is artificial. It could just as well be XML or DB or
WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe
Bloggs works'. There simply is no one way of categorizing, hence there
actually is no one community either. (ie. 'the jakarta community' simply
does not exist in my eyes)
I agree that we probably can't define Jakarta in terms of content in a 
way that will make everyone happy.  I disagree, however, that this means 
that there is no community, or that Jakarta should be dissolved.  I would 
say that Jakarta = the community. What are called Products on the web 
site are what this community produces. Java is one common denominator, but 
so are some common release management and decision-making practices 
(currently under debate / revision).

I am much less bothered than others about the fact that not *all* 
server-side Java in Apache is in Jakarta or that some Jakarta projects 
might belong elsewhere. I really don't see why this is a problem.

The only real problem that we have is making sure that we have sufficient 
oversight. The middle layer makes that look like more of a challenge, 
but that's only if you assume that oversight has to come from a small 
number of Jakarta PMC members.  Growing the PMC (as we are now) so that 
all community activity has has direct PMC oversight will solve the 
oversight problem.

Phil





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Jakarta: Confederation or Single Project?

2003-12-18 Thread Noel J. Bergman
Henri Yandell wrote:

 XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon,
 James are all Java Development and not in Jakarta.

 If we go with this approach, we end up with the continuation of: should
 digester be in jakarta or xml etc.  Does XML take precedence over the
 fact it's in Java, or [...]

There is an entire spectrum of possibilities between Jakarta as One Big
Project, and Jakarta as a Confederation of Projects.  And to be quite
honest, so long as there is proper oversight, I generally couldn't care less
where in the spectrum things get organized.  When you come down to it, we
ought to be facilitating an enlarged and healthy ASF Community, where
everyone feels welcome to participate in whatever project(s) they find
interesting.

The PMC structure is about oversight.  My view is that each subproject
should decide how it wants to participate in the structure, so long as it
ensures that proper oversight is provided.  And this is why, however the
projects decide to participate in a PMC, we should keep in mind that project
organization does not have to be reflected by the web organization.  If
project P decides to have its own PMC, and wants to be present on the web as
jakarta.apache.org/P, why should we say that it has to reside elsewhere?

In fact, client-side-caching and performance aside for the moment, imagine
if we had a new domain:

  my.apache.org

which was running some portal software, and allowed people to customize
their own view of the Apache Projects.  People who wanted to track commits,
news, e-mails, issues, and other information related to their favorite
projects could see their customized portal view of the ASF.

Perhaps impractical today, but just consider the possibilities when we stop
thinking of the web site structure as reflecting our internal organization.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Jakarta: Confederation or Single Project?

2003-12-18 Thread Noel J. Bergman
Costin Manolache wrote:
 Noel J. Bergman wrote:
 Geir Magnusson Jr. wrote:
 Noel J. Bergman wrote:
There is a difference between a hierarchy and a confederation.  There
is absolutely nothing that says that we cannot have:
 [list of PMCs]
All without a single change to the Jakarta domain.

No one should feel that there is any relationship between the
Foundation's legal structure, and e-mail/web addresses.

This is nothing I would encourage.  There's really no question that
it's legal.  But it does then make Jakarta a website, rather than a
community, IMO.  I'd rather see the community.

As I said in a reply to a message from Henri, I think that each project
should be able to chose how it wants to participate in a PMC, so long as
oversight is provided by the choice.  But I still maintain that the web site
structure does not have to, and should not be forced to, reflect that
choice.

 Actually - it's jakarta PMC that does the oversight for Jakarta commons
 and all other jakarta subprojects.

Hence my use of the terms de jure and de facto in my message.  We have
not made them the same, yet, but since we intend to do so, I see no need to
debate the current status.  :-)

 All committers who are active in jakarta are are willing should be part
 of the jakarta PMC.  That's how things work in httpd and this is the
 right thing to do.

 If tapestry ( or any other sub-project )  doesn't feel like beeing part
 of a jakarta community or doesn't like oversight by the jakarta PMC - it
 is free to apply for top level status.

I agree with both of those points ... so long as the second choice does not
mean that the choosing project must relocate its web presence, although it
may choose to do so.

 IMO it would be sad if projects like struts or tapestry leave jakarta -
 since they are closely related to web development and server side java

Agreed.  So are we agree that if one of them chooses to form its own PMC, we
won't force them out of Jakarta?  :-)

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Harish Krishnaswamy
Could someone please explain the motivation behind the creation of Jakarta and how it got to where 
it is today? May be that would help answer some of the questions we have?

-Harish



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Bill Barker
I'm sure that Craig or other will correct my mistakes (I haven't been here
quite that long :).

Jakarta started as Tomcat and friends after Sun donated Tomcat to the ASF
(hence the name 'Jakarta' :).  As the project grew (sign of success),
Jakarta grew to include projects that don't necessarily rely on Tomcat (but
could be used with), nor that Tomcat relies on.  This has been the
traditional server-side-java test.

Now, Jakarta has been having projects that want to leave to ASF-TLP status
(e.g. log4j, ant, maven, james).  This is calling into question what the
'Jakarta' name stands for now.  What this thread is about is trying to
answer this question:  what, if any, is the mission of 'Jakarta' going
forward.


- Original Message - 
From: Harish Krishnaswamy [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 9:11 PM
Subject: Re: Jakarta: Confederation or Single Project?


 Could someone please explain the motivation behind the creation of Jakarta
and how it got to where
 it is today? May be that would help answer some of the questions we have?

 -Harish



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta: Confederation or Single Project?

2003-12-18 Thread Craig R. McClanahan
Quoting Harish Krishnaswamy [EMAIL PROTECTED]:

 Could someone please explain the motivation behind the creation of Jakarta
 and how it got to where 
 it is today? May be that would help answer some of the questions we have?
 
 -Harish
 

These comments are going to be (like anyone's would be) colored by my own
personal experiences during the development of Jakarta -- including my
ignorance of a lot of the details in subprojects that I'm not an active
participant.  But it should give you a little feel for the history of the
place.

The gist of the creation of Jakarta was around three facts:

* Apache wasn't an incorporated entity (this is about
  four years ago now), but wanted to be -- and was
  formally becoming the Apache Software Foundation.

* Apache had a project to build a servlet container
  (Apache JServ) at a website called java.apache.org
  which created a trademark-use issue around java.
  (I was a committer on Apache JServ, which is how I
  originally got involved in open source software.)

* Sun wanted to contribute, and Apache wanted to accept,
  the source code for the servlet and JSP implementation
  called the Java Servlet Development Kit, and later
  published by Apache as Tomcat 3.0.

Just as an item of slight historical interest, Jakarta was the name of the
conference room at Sun where a lot of the early discussions took place.

An organizational framework to focus on developing open source server side Java
stuff was created to host these initiatives, and other related subprojects got
proposed and added to the mix.  As the number of Jakarta committers scaled from
the original 10 or so to where we are today (hundreds), the original charter
has
become, umm, somewhat stretched.

Ironically, it didn't take long at all for the scope of that original charter to
get exceeded, because one of the little nuggets of code that was included in
the
original Tomcat contribution was a pure-Java build tool (to replace make)
called Ant ...

As more and more subprojects were added, there were some inevitable cases of
overlapping scope, and overlapping implementations of the same ideas.  One of
the best things we've done (IMHO) was purposely creating a subproject
(jakarta-commons) focused on making small, focused, reusable packages, and
encouraging the larger projects to use them.  Not only has this been successful
within Jakarta -- there's been quite a lot of cross-fertilization among the web
app frameworks, for example -- it's also created a fairly rich library of
funcational packages that are widely used elsewhere.  But one could really
argue whether something like Commons Digester (originally designed as an
easy-to-use tool to parse XML configuration files) really fit the Jakarta
charter.

Over time, there have been more than a few, err, voluminous discussions about
how to scale up Jakarta from an organizational perspective, and whether the
fundamental organizing principle was still the correct one.  Does a focus on
server side stuff exclude what could be some really interesting open source
projects?  Does a focus on Java make sense when just across the website there
are things like xml.apache.org that are focused on a technology, not on an
implementation language?  Does it make sense to have community type projects
that host individual software package projects at all?

Coupled with these increasing concerns (at the ASF board level) about the
ability of any oversight group (a responsibility delegated to PMCs in the ASF
organizational structure), several original Jakarta subprojects (or even
sub-sub-projects in some cases) like Ant, Maven, and James decided to become
top level projects (TLPs) of their own -- this takes making a formal proposal
to the ASF Board that gets accepted, and the formation of a PMC for that
project.  Those sorts of discussions continue to this day.

Somewhat separately, but overlapping in time, it became clear that there needed
to be a way to incorporate new developer communities (and in some cases
existing codebases that were being contributed) into Apache.  The developers
(if they weren't Apache committers already) needed to learn the Apache way to
do things.  The code (if any) needed to be vetted for appropriate contributor
agreements to protect both the ASF and those that rely on our code.  Thus, the
incubator project was created as a place for these things to happen.  It is
also actively evolving.

personal-view
To a large extent, the stresses that are felt as the ASF grows are actually a
result of our success, and should not be looked at as signs of failure.  I
remember a statement from a consultant that one of my employers brought in
along the way to deal with some important decisions when we had no consensus at
all:

  The absence of stress is death.

So, here's to having some more stress!  :-)
/personal-view

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL