> From: Rich Bowen <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Mon, 12 Jan 2004 21:24:49 -0500 (EST) > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: Undermining the Incubator > > On Mon, 12 Jan 2004, Andrew C. Oliver wrote: > >> 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. >
Sure. > > 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. > If the folks have signed the code over to you via CLAs and you are serving it from Apache servers, is not the foundation liable? So if they violate licenses and contracts prior to us certifying that they aren't but we've already accepted the project it is not legal rocket science. "Oh its not my stolen car, I've already signed the contract and its on my property but I'm just considering buying it" >> * 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. > I just favor not accepting them at all until they've done their work. >> * 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. > Do you see these audits happening? > 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. > Thatıs already happened on a number of occasions (you can read the archive for numerous "hey what the heck are you guys doing other than yacking about status files and process"). Now that it has been monitored now what? >> * 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. > And it weakens Apache as a brand. It brings us all down. >> * 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. > Sure. If I had a mature project ready for production which had been so for a number of years and then I said "I want to be part of Apache".... You'd put it in the "incubator" and tell the world it needed incubation? Pretty ugly perception that pushes about a mature project. >> 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. > No place, leave the project where it is until it has proven it meets the requirements. Yes they are, and they have not changed much since before the incubator was created. >> * 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? > I'm outlining a different process. Yes it is. >> * 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. > However they are already our legal responsibility at that point. >> * 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. > The project must vote (or at least should). The Incubator PMC must vote. The accepting project or board must vote. Thatıs three houses voting for project promotion. >> 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. > That is why 1-2 sponsoring members specifically interested in that project are essential. >> 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. > I do. Interested sponsoring members should determine that. Not some...."administrator" or committee of them. -Andy > -- > 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] > -- 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]
