> My own hope is that each component be treated like a book, with it's own
> publication date, edition count, and set of authors and editors. 

And again - we'll act as librarians and make sure the book is available,
not as censors or authors of competing books.
 
> For this branch, we probably need a relevance criteria -- that the
> component is something that * could be * shared among other ASF
> subprojects. Though, I would think whether a product actually uses a
> component, or whether products use different flavors of similar
> components, is something the subproject committers have to decide for
> themselves. 

> We can lead the subprojects to water, but we can't make them drink. 

I believe we are trying to solve the wrong problem. 

I think the problem is not "reuse", but "sharing". It's not "making them
drink", but making sure the water is clean.

If someone chooses to duplicate a piece of code, maybe the problem is with
the way the code is written and shared. 

That's why I think a library would be very good - not because it'll force
people to read, but because it'll make authors to make their code more
reusable and deal with the sharing problems. It may eliminate all the ugly
dependencies between a suposedly "shared" component and the project that
hosts it. Or eliminate the claim that the component is shared. 

CPAN is great because it makes Perl writters to follow some conventions
( make the code modular, etc ) - it helps sharing the code. It doesn't
even try to choose or judge or create code... Nor to force people to
reuse.  


-- 
Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to