Here are my inferences so far...
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.
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.
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?
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>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]