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.
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.
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]
