----- Original Message ----- 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>; "Harish
Krishnaswamy" <[EMAIL PROTECTED]>
Cc: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Thursday, December 18, 2003 10:26 PM
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) 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>
>

+1 (non-binding :)

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

Reply via email to