RE: Undermining the Incubator
Andrew C. Oliver wrote: All legal matters are for the Board and the Foundation's attorneys to address. Regarding audits ... There is a presumption of innocence in our legal system. I do not believe that due diligence requires an a priori presumption of fraud, and a investigation to prove its absence. Nor do I believe that due diligence requires all code to be subjected to http://www.catb.org/~esr/comparator/ across all published codebases, although that would be an interesting project. As I understand it, if we receive a signed CLA or Software Grant, there is a presumption that they had the right to provide it. In some cases, that may not have been the case, but such a situation would need to be dealt with at that time. However, the Incubator is in a position to learn from such situations, e.g., to remind people to be sure that they are not violating any work-for-hire issues. Code is audited as part of the Incubation process. That audit is done by the PPMC, as was done recently by several Avalon members for an incoming codebase. Early on, some GPL dependencies were discovered and removed. In the reverse situation, I cannot say what audit, if any, was done on codebases that bypassed the Incubator. We do know that no code grant was received, since that is one reason why the incident was belatedly brought to a PMC's attention. Finally, when concerns have been raised about a particular codebase, more people have looked. You are well aware that the code you are particularly interested in has been reviewed by people involved in the project, by people with no association at all with the project, by people with a vested interest in finding violations, and by tools looking for concordance. With respect to any follow-up questions you may have in mind, I remind you that all legal matters are for the Board and the Foundation's attorneys to address. you can read the archive for numerous hey what the heck are you guys doing other than yacking about status files and process). To put this in perspective ... The Incubator as not working well. The entrance of a project such as Geronimo forced changes within the Incubator. In excess of 1000 e-mails were expended putting together new rules and structures and ... and that pretty much sucked, too. In late November, Geir made a proposal that became the germ of the PPMC concept, and it clicked. As the concept was refined, the cruft was replaced with a simple concept: direct, collaborative, authoritative management, while still maintaining the Incubator's oversight. That is in the archives, too. :-) The Incubator is not perfect, but the structure is finally right. Now we need to work on operations, such as improving responsiveness with respect to resource creation. But that is not isolated to the Incubator. And the Incubator just started a review with each project of its STATUS, prepatory to its own report to the Board, which should help to get everyone on the same page. * Creates confusion. Most people will believe the project is an Apache project at the point of incubation. And it weakens Apache as a brand. It brings us all down. Thank you for confirming the importance of the Incubator branding. We agree. We will have to disagree about whether the ASF branding is weakened by the presence of quality projects in our Incubator. 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. Spam Assassin doesn't seem to have a problem with it. That would be an example of a mature project with an active, viable, community that is in the Incubator for a time to prepare for TLP status. And as soon as a project is ready, it leaves the Incubator. 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. Again, things no longer work that way. The PPMC votes to present the project to the Board. The Board must still vote to create a TLP. The Board doesn't want it until the PPMC says that it is ready, and the PPMC isn't authorized to create a TLP. 1-2 sponsoring members specifically interested in that project are essential. The Incubator PMC makes sure that there are multiple interested PMC members actively participating in the PPMC. See: http://incubator.apache.org/whoweare.html#PMC+%28Project+Management+Commitee %29. Out of the currently 20 PMC members, 18 are ASF Members and 5 are either current or past Board members. Any ASF Member interested in the Incubation of the ASF's future projects is encouraged to participate. 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
Re: Undermining the Incubator
On Tue, 13 Jan 2004 10:27:35 -0500 Andrew C. Oliver wrote: Except that it is not. I just think I'll bring it up in 6 months when there are more dead bodies floating around. Noel does a great PR job though. Oh, Dead Bodies? ... scared. I do not think there are dead bodies. However, i think you can shout/cry/scream/yell-out at such zombies if you insist it that there are dead bodies floating around just like you did 6 months / 1 year ago :) Perhaps it would be better for you to do them @ either Mt. Evans or Mt. Fuji... with Meditation/Yoga :) Happy year 2004. -- Tetsuya. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disregard Re: Undermining the Incubator
On Tue, 13 Jan 2004 22:22:17 +0100 Santiago Gala Pérez wrote: William A. Rowe, Jr. wrote: (...) | Many of us rant in email, delete, then recompose with some decorum. | Since many things that are discussed in community involve strongly held | personal opinions and beliefs, this safety measure ensures that intelligent | dialogs can be pursued and the best course of action followed. In this very spirit, 8 hours ago I was about to suggest Andy to put his outbox in a moderation queue, but then I thought my message was too harsh and I refrained from sending it... Oh, great. Nifty. By the way, maybe I could *invent* new medicine (patch form) which aids mitigation of the withdrawal symptoms of such *writing impulse* effectively -- USAGE: apply one patch which is effective 16 hours a day -- However, I am afraid I can not export it to the place where Andy lives in, because the ministry of health and welfare in japan is banning me from doing it or due to the failure of the delivery system. I could import nicotine patch from new zealand, though. ... Very sad ... ;-) -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Undermining the Incubator
Andrew C. Oliver wrote: From: Rich Bowen [EMAIL PROTECTED] ... First of all, thanks for this thorough resonse. Sure. True. This does belong on community@ I think it belongs in the Incubator, as the Incubator is exactly for these discussions (where constructive). Interested parties can subscribe to [EMAIL PROTECTED]@apache.org Andy, for one that rants about tricameral votes (which have been abandoned looong ago), you are pretty trigger-happy about cross-posting. :-PPP -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Undermining the Incubator
On Wed, 14 Jan 2004 12:33:00 +0100 Nicola Ken Barozzi wrote: Andrew C. Oliver wrote: From: Rich Bowen [EMAIL PROTECTED] First of all, thanks for this thorough resonse. Sure. True. This does belong on community@ I think it belongs in the Incubator, as the Incubator is exactly for these discussions (where constructive). For sure, as long as such interested parties would assure themselves that there might be no teachers in apache. Coaching and mentoring minds might be necessary for the incubation. Yes, i can see it that the incubator project itself is evolving. You do not have to behave as a teacher. If you want to become a teacher (or someone expect you to be a teacher), you are sure to be infected by the disease of bureaucratism. ... Oh, six months investigations and observations (perhaps I, observer, influenced upon the status of the community a lot deducted by quantum mechanics :-) completely made me very assured. Perhaps my own theory might be able to evolve in the future :-) The keyword might be awareness... (and symbiosis? :-) Thank you, brothers. Love. (Phila-delphia? :-) -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Undermining the Incubator
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
Re: Undermining the Incubator
In summary: Oh of course no problems exist, its all fixed and happy. Just don't mind the dead bodies floating in the pond. -- 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. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: community@apache.org Date: Mon, 12 Jan 2004 23:21:50 -0500 To: community@apache.org Subject: RE: Undermining the Incubator Andrew C. Oliver wrote: I suggested that Blojsom might be a good choice for hosting ASF project news and might also make a great ASF project as I know the author is already indoctrinated I didn't say it would be a good project for the incubator. The Incubator is how projects get into the ASF. I think the incubator is the #1 worst problem of the ASF presently. Two things reduce the effect of your statement: 1. The fact that your complaints demonstrate a lack of awareness regarding the current Incubator. 2. The fact that your proposal essentially outlines how the Incubator *does* work. We'll get to the latter shortly, but first ... The Incubator exists for the purpose of importing codebases and projects into the ASF. There are basically three cases: (a) an externally developed codebase intended to go into an existing project (b) an externally developed codebase intented to become a project within a PMC (c) an externally developed codebase intended to be a new TLP In the case of the (a), we need to clear the IP. The Incubator STATUS file provides an outline and diary for doing so. The Community issues are addressed because the code is going into an existing project. In the case of (b), we need to clear the IP, and ensure that the project has a viable community. Again, the STATUS file has the guidelines. Lastly, in the case of (c), we need to clear the IP, ensure that the project has a viable community, and that the community is ready to take its place as a TLP. In all cases, decisions are made by a group made up of the Incubator PMC, the project's committers, and the destination PMC (if any), and known as the PPMC. That is one group directly empowered to manage that project's decisions, reporting through the Incubator, and collaborating together as peers. When the PPMC decides that the project is good to graduate, based upon fulfilling the necessary criteria, it is done. Now, since I know that you had a bad experience with the old form of the Incubator, let's first address your complaints compared to the way things work now. It doesn't legally protect the ASF. The Incubator ensures that the proper paperwork is done regarding CLAs, code grants, etc., are filed. Something that the other projects failed to do consistently enough to result in the Incubator's formation. Ideally, the Incubator provides a focus and location, and the project(s) interested in the code perform the due diligance, but the process ensures that it gets done. * Exposes the Foundation to undue legal issues by protecting projects PRIOR to their legal issues being sorted out. As opposed, for example, to exposing the Foundation to undue legal issues when projects import codebases directly into releases without permission from either the Foundation or the author? That is one of the things the Incubator exists to prevent. In any event, only the Board should, and can, talk authoritatively about legal protection afforded by the ASF. * 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. In actuality, one purpose of the Incubator is to help prevent non-viable projects from becoming ASF projects, and to help projects become viable, when possible. We have a pretty good opinion as to when a project gets out or not. It is embodied in the STATUS document, and in the minds of the PPMC, which would vote for the project to graduate. * Has a number of people not involved in the project sitting roost over the project. The Incubator doesn't work that way. The people involved in the project are directly involved in the project's management. Ask the members of the Spam Assassin PPMC, the Geronimo PPMC or the Directory project whether or not there are a number of people not involved with the project sitting roost over them. * Hurts already healthy communities by putting them back into an alphaish state. Healthy communities with clean codebases are not intended to stay within the Incubator. Projects in the Incubator are there because
Disregard Re: Undermining the Incubator
The Send button is near the close button. I missed. -- 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. From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: community@apache.org Date: Tue, 13 Jan 2004 01:34:55 -0500 To: community@apache.org community@apache.org Subject: Re: Undermining the Incubator In summary: Oh of course no problems exist, its all fixed and happy. Just don't mind the dead bodies floating in the pond. -- 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. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: community@apache.org Date: Mon, 12 Jan 2004 23:21:50 -0500 To: community@apache.org Subject: RE: Undermining the Incubator Andrew C. Oliver wrote: I suggested that Blojsom might be a good choice for hosting ASF project news and might also make a great ASF project as I know the author is already indoctrinated I didn't say it would be a good project for the incubator. The Incubator is how projects get into the ASF. I think the incubator is the #1 worst problem of the ASF presently. Two things reduce the effect of your statement: 1. The fact that your complaints demonstrate a lack of awareness regarding the current Incubator. 2. The fact that your proposal essentially outlines how the Incubator *does* work. We'll get to the latter shortly, but first ... The Incubator exists for the purpose of importing codebases and projects into the ASF. There are basically three cases: (a) an externally developed codebase intended to go into an existing project (b) an externally developed codebase intented to become a project within a PMC (c) an externally developed codebase intended to be a new TLP In the case of the (a), we need to clear the IP. The Incubator STATUS file provides an outline and diary for doing so. The Community issues are addressed because the code is going into an existing project. In the case of (b), we need to clear the IP, and ensure that the project has a viable community. Again, the STATUS file has the guidelines. Lastly, in the case of (c), we need to clear the IP, ensure that the project has a viable community, and that the community is ready to take its place as a TLP. In all cases, decisions are made by a group made up of the Incubator PMC, the project's committers, and the destination PMC (if any), and known as the PPMC. That is one group directly empowered to manage that project's decisions, reporting through the Incubator, and collaborating together as peers. When the PPMC decides that the project is good to graduate, based upon fulfilling the necessary criteria, it is done. Now, since I know that you had a bad experience with the old form of the Incubator, let's first address your complaints compared to the way things work now. It doesn't legally protect the ASF. The Incubator ensures that the proper paperwork is done regarding CLAs, code grants, etc., are filed. Something that the other projects failed to do consistently enough to result in the Incubator's formation. Ideally, the Incubator provides a focus and location, and the project(s) interested in the code perform the due diligance, but the process ensures that it gets done. * Exposes the Foundation to undue legal issues by protecting projects PRIOR to their legal issues being sorted out. As opposed, for example, to exposing the Foundation to undue legal issues when projects import codebases directly into releases without permission from either the Foundation or the author? That is one of the things the Incubator exists to prevent. In any event, only the Board should, and can, talk authoritatively about legal protection afforded by the ASF. * 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. In actuality, one purpose of the Incubator is to help prevent non-viable projects from becoming ASF projects, and to help projects become viable, when possible. We have a pretty good opinion as to when a project gets out or not. It is embodied
Re: Undermining the Incubator
Except that it is not. I just think I'll bring it up in 6 months when there are more dead bodies floating around. Noel does a great PR job though. -- 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. From: Steven Noels [EMAIL PROTECTED] Reply-To: community@apache.org Date: Tue, 13 Jan 2004 08:58:35 +0100 To: community@apache.org Subject: Re: Undermining the Incubator On Jan 13, 2004, at 7:48 AM, Noel J. Bergman wrote: In summary: Oh of course no problems exist, its all fixed and happy. Just don't mind the dead bodies floating in the pond. In other words, because there were problems before it was fixed, it doesn't matter if it is fixed now or not? Yeah, and if we consider it fixed we don't have anything to rant about anymore. :-| /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Undermining the Incubator
From: Rich Bowen [EMAIL PROTECTED] Reply-To: community@apache.org Date: Mon, 12 Jan 2004 21:24:49 -0500 (EST) To: general@incubator.apache.org general@incubator.apache.org Cc: community@apache.org community@apache.org 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
Re: Disregard Re: Undermining the Incubator
At 12:36 AM 1/13/2004, Andrew C. Oliver wrote: The Send button is near the close button. I missed. Suggestion from an httpd/apr hothead to our community forum participants [NOT specifically ACO]... Delay sending messages: [30] (minutes) is a really great option to enable, well worth the effort to enable. I can't think of a modern email client that doesn't offer the feature. Many of us rant in email, delete, then recompose with some decorum. Since many things that are discussed in community involve strongly held personal opinions and beliefs, this safety measure ensures that intelligent dialogs can be pursued and the best course of action followed. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disregard Re: Undermining the Incubator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William A. Rowe, Jr. wrote: (...) | Many of us rant in email, delete, then recompose with some decorum. | Since many things that are discussed in community involve strongly held | personal opinions and beliefs, this safety measure ensures that intelligent | dialogs can be pursued and the best course of action followed. | In this very spirit, 8 hours ago I was about to suggest Andy to put his outbox in a moderation queue, but then I thought my message was too harsh and I refrained from sending it... ;-) | Bill Regards, ~ Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFABGGIZAeG2a2/nhoRAmKEAKDo5GNWeHw+37joT60c3e1EM1A+CQCcC1a1 j6ozIRgj0Re4jFQmV7iadFs= =zn7N -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Undermining the Incubator
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]
