At we say:

"The Jakarta Project offers a diverse set of open source Java solutions and is a part of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license."

Our charter ( says nothing about scope.

The Commons charter says:

"Apache-Java and Jakarta originally hosted product-based subprojects, consisting of one major deliverable. The Java language however is package-based, and most of these products have many useful utilities. Some products are beginning to break these out so that they can be used independently. A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process."

In terms of scope restriction, all three are pretty empty.


I think our scope is:

Components that are,

a) written in and/or for the Java environment
b) too small in the long-term to be their own independent communities

Which isn't much, but I can't think of a lot more to add.

It's really the same scope for both Jakarta and Commons - the only difference is the concept of size. Currently in Commons, too small means too small to be a Jakarta subproject, while in Jakarta it means too small to be an Apache TLP.

In the direction I suggest we should take, too small means the latter - too small to be an Apache TLP.


That still leaves Incubator vs Sandbox issues. Commons Math is one such example - in scope it could be an entire open source foundation. We've occasionally talked about it becoming a someday, but currently it's only really just starting to approach the feel of a current Jakarta subproject in size (same number of lines of code as bcel for example). How do you draw the line on potential long-term scope vs likely long-term scope?

From memory, you talk about it on the mailing list until everyone involved
in the conversation is happy with the idea.


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

Reply via email to