The biggest problem will occur with components that don't naturally fit a group, or fit more than one. But having some kind of divide is going to be necessary.
Sure. We need something, but remember that in a top-level project like this, all of the 'project' decisions occur within the PMC *not* the functional groupings. The functional groupings will not be responsible for oversight - that's the job of the PMC.
And, realize that the HTTP Server/APR PMC-style tends to have pretty much everyone on the PMC, so the 'project' decisions (i.e. new committers and/or PMC members) can indeed happen within the PMC rather than the developement list. That may be a subtle organizational shift for some.
As Robert said, when the functional group gets too large where they can essentially manage themselves, the Commons PMC is going to try to kick them out and force them to be their own TLP rather than staying within the Apache Commons. We'll struggle to find the right balance for a bit, but I'm confident we'll figure it out. ;-)
The one potential spanner in the works for me is subversion. When 99% of the world uses CVS, I really struggle with this one.
Have you tried Subversion? It really eases a lot of pain that CVS causes. Renaming files is just so, gosh darn, beautiful; copying between projects is painless and cheap. That said, if using Subversion is the *only* bottleneck preventing a Jakarta Commons project from coming to the Apache Commons, I'd be fine with them still using CVS if they were a pre-existing project.
*shrug* -- justin
