I think that this slightly misrepresents the problem, as it's not clear what 'power' needs to be restored. I agree that there could and should be more representation on the PMC for legal reasons, but that can be achieved with a bigger PMC.
The power to dictate for themselves what the project should be doing and its direction. I believe the Jakarta PMC does not do a sufficient job of oversight (if any at all). Most of the PMC responsibilities has been devolved to the committers, but without the correct organizational structure in place as mandated by the ASF bylaws. Does the board (and, indirectly, membership) have any reports on what J-C is doing?
This is far fetched - the Jakarta Commons has been *amazingly* successful in being a place for not-big-enough projects (we call them components) to be able to incubate and form. This aspect is what I fear will be lost - the huge collaborative effect that commons fosters. I don't always agree with the side effects (I mean, does every damn bean need to log via commons-logging????), but the success can't be argued with.
FWIW, I tend not to use the word components because it means something totally different to me in my ivory tower of academia. ;-)
I'm not debating the success of the J-C, but what I'm debating is that the Jakarta PMC has not been good about oversight or promoting projects to TLP status. And has been discussed, neither is Jakarta Commons sufficient for all languages. They would reject anything not written in Java (or they should be rejecting it as it directly violates their charter).
I'm not sure what you mean here. What do you define to be 'direct user interface'? In commons, there is a huge community, which was created and
Something a user interacts directly with. I think it's the easiest test for whether something belongs in 'Commons' or not. If you are writing an application the user executes directly, I don't think that belongs in Commons.
fostered to scratch the itch of another community, Jakarta. And within commons, mini-communities were formed around each component. There's an interesting fractal-like structure to it, and one that joins unrelated Jakarta subprojects in interesting ways. I think commons glued lots of jakarta sub-projects together. While I think that a-c could be a good idea, I fear the difference may be that the communities you are trying to bring together don't have enough in common. People have been learning this the hard way (for example, Yugoslavia...).
I think you're misunderstanding our goals here. We're not trying to force anyone to come together. We're offering an alternative organizational structure to J-C that may be more conducive to certain communities. If a component is happy in J-C land, it can stay there. But, if they want to truly be able to manage the project themselves (as I believe each project should), then I think A-C is a compelling alternative. -- justin
