Brian Behlendorf wrote on Thursday, July 08, 2004 6:35 PM: > In walking through the incubation documents (helping a couple of > groups who have asked me about how to do this) it struck me that > there was no requirement that the proposal provide a link to download > and evaluate the code around which a project is being proposed - in > fact it appears the code itself could be kept secret until project > acceptance into the incubator. It seems to me that any honest > assessment of the merit of accepting a proposal should include a look > at the code itself, if only to get a gut-check on how maintainable > and evolveable that codebase might be going forward. Many proposals > have provided just such a link despite it not being required. > Requiring it would also avoid the situation where someone says "if > Apache approves it *then* I'll release the code". > > Thoughts?
+1 If someone wants to propose a project, I think it is quite reasonable for them to show the code that would be the basis of the project. However, I think the interesting stuff is in the details here. For instance: Q: must the source be licensed under the Apache License before project acceptance? IMO: no Q: must the source be licensed under an OSI-approved open source license? IMO: I could see arguments either way. If the purpose is to assess the merit of the code itself, any legal mechanism that provides for anyone in the community to conveniently read the source should be acceptable, even if the license restricts distribution, for instance. However, if the purpose of this new rule is also to require commitment to open source that isn't dependent on the Apache brand, then we would specify the code must be available under an OSI-approved license prior to proposing. Q: what would this mean for project proposals that do not include an initial code base? IMO: While some might say that no project should start in Apache without an initial code base, I would personally like to allow for this possibility, depending on the make-up of the initial committers and related communities. Therefore, I would suggest that any proposal that suggests the new project would be built on some particular initial code base would need to have that code base available for review. Any proposal that does not suggest this (including those that might want to base a new project on some other piece of software without actually using the old source as a base) would not need to open any source. Q: if the bar to bring projects into the incubator is meant to be relatively low as long as the legal and community issues are reasonable, should we even be evaluating the code base at all? IMO: we could probably have long discussions about whether the best long term future for the ASF requires some degree of technical evaluation of projects or not; however, without diving into this issue for the moment, I would suggest that perusal of any significant code base could be done just for any glaring problems (potential legal entanglements with dependencies, inappropriate technical dependencies, etc). Problems that are found may not necessarily have to be fixed before project approval, but I think it would be nice to allow major issues to be discovered and responded to during the evaluation of the proposal. Q: how close must the evaluated code base be to the one eventually contributed after project acceptance? In other words, could a proposal show most of the planned contribution without having 100% of it ready? Could the contributor make changes to the source between the time of proposal and the initial grant (e.g. what about changing the license header? what about doing a little more than that?) IMO: we shouldn't put strict limits on this -- any abuse of the intention behind this requirement (such as a significant bait-and-switch with code bases) would probably be obvious and could be dealt with on a case-by-case basis. Cliff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
