> > 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.
>
> 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.
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.
> 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.
> 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".
Costin
