beware too many organizational layers. flat is best. having a single sub-project with many releasables artifacts sharing the same community space (mailing lists, committer lists, voting eligability and so on) has proved more successful (see jakarta commons) than a complex web of sub-sub-sub-projects. factor along community lines: groups working on different releasables being unhappy about sharing the same community space is a good sign that they are two separate projects. (most modern email clients have good filtering support so provided conventions are adopted, several different code bases can be easily support on a single mailing list. for those unwilling or unable to set up filters, using a news reader and www.gmane.org works well.)
+1
Don't be afraid of forks or duplication. If someone wants to try something out on their own, let them. But that doesn't mean you have to host it in the original project. There's plenty of space for similar and even competing software projects. A single project does not have to be everything to everyone.
Some other lessons I learned in working with Apache Avalon:
http://www.jadetower.org/muses/archives/000146.html
jaaron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
