On 8/19/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Martin Cooper wrote: > > Perhaps. Perhaps not. But it's pretty much guaranteed that we would > lower > > the base of people who _could_ use them if they're not here. Some > companies > > (my current employer included) require approval for each and every open > > source component before it can be used within the company. > > FYI, I'm in the same boat where I am, and I know the hassles we go > through sometimes to get various libraries/components/whatever approved, > so I definitely know where your coming from with this point. In talking > to other folks, this doesn't seem to be unusual at all. > > > I disagree. I think it is just fine to distribute such code. If people > start > > to use it and have problems with it, then perhaps this will drive > additional > > contributors to it. Gaining additional contributors to it as part of > Struts > > seems much more likely to me than if it's off in the weeds somewhere. > > You mentioned the "...respected source such as the ASF" in the previous > paragraph, and I certainly agree. I think however that if the approach > was as you say, that potentially untested code, or more accurately code > not used to a great extent by active committers, which I believe is what > Ted was talking about, was coming out of a respected ASF project, it's > not hard to imagine that respect declining when a lot of bug reports are > opened for a particular plugin. One plugin could wind up ruining the > good reputation of the larger project.
We already have the notion of "experimental" pieces. I see this as being somewhere between the core and the experimental pieces. And if no one was maintaining and using that code to begin with, I think > it's a bit of a gamble to hope someone will be spurred into action by > some negative feedback. Maybe someone will be, but I don't think that's > a risk worth taking if you want to keep a good reputation and keep being > a respected project :) > > I for one see Ted's suggestion as a good compromise... you could almost > in a sense view the external location, wherever that happens to be, as > something of a plugin incubator... assure the code has a community of > developers willing to maintain it and ensure it's at a level of quality > that fits in with the rest of the S2 distro proper, and *then* roll it > in to the distro later. For any plugin that there's any doubt about > today (and I don't know which those are), they can be shifted there and > allowed to grow that community. And if some never do, it's not the end > of the world: they're still there for anyone that wants them. To address the concern you raised about approvals, I think it would be > important to make the external location an endorsed source of plugins. > Maybe it makes more sense to have a plugins subproject under Struts, I > don't know, but whatever the case, so long as people understood that > yes, this plugin repository/incubator/whatever was *the* approved place > to get plugins from, I believe the approval process would be eased a bit > for most users in that same situation as we are. I honestly don't see that we could point at some other project outside the ASF and say that we "endorse" the plugins produced by that project when what we are really saying is that we don't consider those plugins to be sufficiently worthy to live at the ASF. Plus, I personally would have a pretty fundamental problem with "endorsing" any one specific project outside the ASF in preference to any other. I suspect we could get into legal trouble over that sort of thing. -- Martin Cooper At the end of the day, it's always said that an ASF project depends on > developers who themselves are using the code. It's supposed to be code > for themselves that they happen to share with others, that's how I've > come to understand the underlying concept anyway. If that's true, then > it seems like keeping code in S2 that might not be maintained and > actually used by active commutters is a contradiction of that, and Ted's > suggestion offers a viable alternative that keeps the code alive, and in > fact presents (possibly) a better chance for it to succeed. > > > -- > > Martin Cooper > > Frank > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM/Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > Author of "Practical Ajax Projects With Java Technology" > (2006, Apress, ISBN 1-59059-695-1) > and "JavaScript, DOM Scripting and Ajax Projects" > (2007, Apress, ISBN 1-59059-816-4) > Java Web Parts - http://javawebparts.sourceforge.net > Supplying the wheel, so you don't have to reinvent it! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
