>> So, like I said, I clearly missed what you suggested as fixes to the >> problems that you perceive. While I'm sure that this discussion belongs >> on the incubator list, rather than here, I have a strong suspicion that >> you're going to respond with a note to the effect that you've already >> been through this and don't want to again.
Okay Rich, I'll take you up on one. I don't feel like digging up the stuff I've noted on the JCP so lets talk about the incubator. Hopefully you don't mind me quoting that much publicly, if so I apologize. I feel this should take place on community@ as its a question on whether the incubator is serving the interests of the foundation and should exist at all. Seems kind of funny to discuss "should this thing be here" there. Problems: * Exposes the Foundation to undue legal issues by protecting projects PRIOR to their legal issues being sorted out. * Has a high potential to create a dead project zone over time (but this I guess we'll see) as we give hosting and a fuzzy idea with many different opinions on when a project gets out or not. * Has a number of people not involved in the project sitting roost over the project. * Creates confusion. Most people will believe the project is an Apache project at the point of incubation. * Hurts already healthy communities by putting them back into an alphaish state. Solution: * Disband the incubator. * A project must have at least sponsoring MEMBER willing to go join the project and help them adopt the voting rules, document legal issues by performing an audit * A project's acceptance is governed by a PMC accepting it or the members voting to create a TLP. This should be ratified by the board who should have veto power. * To propose the vote a project must prove that all CLAs are turned in and a license audit has been performed under the supervision of the said sponsoring member/members. * prior to the project's acceptance into Apache it has no Apache status (legal/otherwise). I suppose we could give it a candidate logo. This: * Protects the foundation * Makes the responsible people responsible and less "help" from the peanut gallery. * Makes members responsible. * Gives the "acceptance" to the project and the people accepting it. No more tricameral votes. Issues: What about how things were before?? The incubator sought to solve what was essentially a communication issue via more process. I suspect it was also created (I read this in emails by some of its proponents and Sam replied "thatıs not what I voted for as a board member" or something to that effect) originally as a flood gate to slow or prevent the growth of Apache. I think the communication issue (about oversight) has been solved. In fact I rather thing we've gone a little too far in the other direction. Some projects are just lazy and haven't done their auditing. Other projects are more vigilant. I think this is normal. What could be done about it I don't know for sure but the incubator doesn't further that, maybe the PMCization thing did, but I think moving the responsibility down the latter will do more, then some manner of accountability (dirty word I know in a volunteer organization). The incubator was also supposed to help projects obtain their base resources. What is really needed here is a request tracker for the infrastructure project (which should become more of a project and less of well what it is but that is a rant for another day). To reduce contention and further compromise, I support grandfathering. I'm not going after Geronimo. Let me go on record, I do not hate Apache or "the whole institution" I just think some of the decision made over the past year or so have been in conflict with the letter if not the spirit of the open in open source. I also want to help people in, not force them out. I think Apache has its place, of course we all have different opinions on what that is. -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
