On Mon, 12 Jan 2004, Andrew C. Oliver wrote: > >> 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.
First of all, thanks for this thorough resonse. > 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. True. This does belong on community@ > Problems: > > * Exposes the Foundation to undue legal issues by protecting projects PRIOR > to their legal issues being sorted out. Perhaps I misunderstood something somewhere. This is certainly not the intention, and if that is happening, I agree that this is a Bad Thing. The intent, as I understand it, is not to extend this kind of protection until they have graduated. However, I must defer to the Board and the Lawyer Types on this point, as I am utterly ignorant of the actual legal aspects. > * 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. Yes, I can see that as a potential problem. We need to be vigilant to not become sourceforge. A firm policy about jetisoning projects that are not making active progress towards graduation might be in order. > * Has a number of people not involved in the project sitting roost over the > project. The folks that are "sitting roost" are interested in very specific things. While I agree that a member of the community may be better able to determine whether it is a vibrant and sustainable community, it seems very evident that it necessary for an external party to be involved in the verification of the code legality. Audits *must* be done by external, disinterested parties for them to be of any credibility. So it would seem that this is both good and necessary. Now, if the folks that are involved in this process are indeed "sitting roost" rather than mentoring or coaching, then I could see that this is a problem. Once again, this requires careful oversight and vigilance to ensure that this doesn't happen. But I don't see this as a condemnation of the process, so much as something that needs to be carefully monitored. > * Creates confusion. Most people will believe the project is an Apache > project at the point of incubation. Yes, agreed. And I can see this contributing to the perception of your first point regarding legal protection. > * Hurts already healthy communities by putting them back into an alphaish > state. I just don't see this. Can you elaborate on this? We're verifying that they have certain qualities, not claiming that they don't. > Solution: > > * Disband the incubator. Not to give any false impressions, I should be very clear that I don't agree with you on this point, and, based on your following comments, I'm not sure you do either. Sounds like you want some pretty significant changes, but that you still want some process in place. Seeing as I don't give a damn what it's called, if you want to call it candidating, or something else, it's all the same to me. I think that a process needs to be in place, and it needs to address certain issues. What it gets called is of no consequence to me. Next, it's possible that I've misunderstood some details at some point, but it does not seem that your recommendations are so very far from what is in place. > * 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 Sounds reasonable. > * 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. OK. > * 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. That's already required, right? > * prior to the project's acceptance into Apache it has no Apache status > (legal/otherwise). I suppose we could give it a candidate logo. That's how it's supposed to be already, unless I grossly misunderstood. If legal protection is being extended to these projects, then, yes, I agree, that's a Bad Thing. That's why they're in the incubator - so that we can verify that it is safe to extend this umbrella. > 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. I never did understand your remarks about "tricameral" votes. The way that you discussed the vote happening, and the way that the vote actually is described in the docs, did not seem to have much in common. > 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. While I never got that impression, I can certainly see that we don't want to just throw open the gates and let the whole world in, as there are logistical issues in doing so. > 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). Accountability is a dirty word? That's unfortunate. I agree that the responsibility for getting stuff done needs to be shoved as far down the ladder as possible. But there needs to be accountability and oversight to ensure that it is, in fact, done. If it's not done, then we should not be extending our umbrella over them. Seems very reasonable to me. However, I would have to defer to the Board and the Lawyer-types on this, since I am utterly ignorant on that matter. > 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). Yes, request trackers are nice things to have around. > 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. The goal of the incubator is to help people in. Part of that is, necessarily, determining that some projects maybe should not come in. I don't see this as a bad thing. -- And everyone said, "If we only live, We too will go to sea in a Sieve - To the hills of the Chankly Bore!" (The Jumblies, by Edward Lear) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
