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....


-Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta 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
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?


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

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
stuff" was created to host these initiatives, and other related subprojects
proposed and added to the mix. As the number of Jakarta committers scaled
the original 10 or so to where we are today (hundreds), the original charter
become, umm, somewhat stretched.

Ironically, it didn't take long at all for the scope of that original charter
get exceeded, because one of the little nuggets of code that was included in
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
within Jakarta -- there's been quite a lot of cross-fertilization among the
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

Over time, there have been more than a few, err, "voluminous" discussions
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
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"
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.

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

"The absence of stress is death."

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


--------------------------------------------------------------------- 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]

Geir Magnusson Jr                                   203-247-1713(m)

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

Reply via email to