I tried to put the 'who' back into the quoted material below. Apologies
if I got it wrong...
[EMAIL PROTECTED] wrote:
>
> > [EMAIL PROTECTED] wrote:
> >
> > > We are talking about _sharing_ a component between projects ( something
> > > like XMLConfig ), that was the problem we were trying to solve ( or at
> > > least that was my impression when we started this ). Not creating other
> > > separate projects and the associated mini-communities.
> >
> Federico Barbieri <[EMAIL PROTECTED]> :
> >
> > The huge difference is those mini-communities are composed by people
> > coming from the projects that use that piece of code so that even if the
> > component itself is separate it is deeply linked to those who use it.
> > It's not a sepatare tribe.
>
> I'm confused - you are now adding arguments for my point.
>
> That's exactly what I'm proposing - that each component should be managed
> by people comming from all projects that use the piece of code.
I disagree with the wording. 'can be'. Yes. 'should be' which to me
implies 'requires', I disagree. A user is as valid a member of a
'community tribe' as a committer. You know this better than I do, I am
sure.
I realize that you are supporting a different model for this project
that I do - therefore this is starting to be a hypothetical discussion,
as we haven't decided what 'library' will be. You claim 2 messages ago
(above) that sharing a component between projects is the problem we are
solving, and further, we are not trying to create separate project. I
disagree - I think this is the question we are still trying to answer.
That isn't the reason I got into this. I was and am interested in
seeing if we can take some of the common functionality shared across
Jakarta projects (my cannonical example, the DB connection pool...) and
make a separate project and mini-community surrounding it such that
Jakarta can offer it along side it's other offerings, *as well as* have
it be used by other Jakarta projects.
> It seems many people are voting for the other choice - where each
> component is managed by a "tribe" ( either the original authors, or
> some initial commiters plus the people they vote in ). And people from
> other projects need to get in the tribe first.
+1 Isn't that the regular Jakarta model?
> > I just think such an extended commiters community is going to be a good
> > place for brinstorming but can't efficiantly achive the goal of pushing
> > project to actually share the same code (when it makes sense to do it).
>
> So you are saying that if a component is maintained by people comming from
> all projects that are using the component, they will not use it in their
> project.
>
> And if the component is maintained using the classic rules for a project (
> it is a mini-project with a set of commiters, and people from other
> projects are treated as users - they need to be voted in, etc ) - then
> those people will choose to use the component.
>
> Few mails ago you were saying that if you are member of a
> "foo" project/community, you don't feel you are a member of the
> "bar" community - and I agree, that's exactly how I feel. But that's true
> for the shared components too - if the commiters in a project don't feel
> they are part of the community that develops the components, they'll be
> less likely to contribute or use the code.
I dunno if that's true. That says that the notion of open source code
resuse isn't scalable - i.e. its proven to work on long length scales
like Tomcat, Apache, Linux but not shorter scales like a DB Connection
Pool? Architecturally, Tomcat is just a component in a larger-scale
structure. And the number of people that use it is way larger than the
number of committers. Sure, you will take all reasonable comers as
committers, and that's great. But not everyone wants to be a
committer. They are happy to be a user and provide feedback either
vocally or silently (by going elsewhere...).
If a component has well defined goals, shaped by clueful people who
understand how that kind of component fits in a conventional
architecture, then I don't think a component project is any different
that an JCP spec driven project like Tomcat. The trick at first, I
think, is to get those clueful people interested and together working on
this.
Again, I know that we have different models in mind, but your claims
above seem to be more general in intent.
> > It may help sharing of ideas, not code.
>
> I think both. And more importantly - sharing a community.But one thing
> is easy to verify - the current situation is that code is not shared. And
> my guess is that this is because people don't feel they are part of the
> same community - we have different projects, with different communities.
>
> If the library will consist from yet another set of communities - what do
> we gain ? Even if some people will be both in the library and different
> projects, some projects commiters will be excluded and will need to be
> "voted in".
What's the goal? To me, the goal was to get code together in one place,
to make it widely available to the developer community at large, not
just the Jakarta developer community. (Users are always included as part
of the community... but many users of jakarta output aren't aware of it,
I think...) The Jakarta community is important, but without 'product'
usable by the outside world, it is kind of pointless, isn't it?
If there is a community problem, then maybe that should be approached
directly?
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
