[development] module duplication in Drupal contrib

[Joshua Brauer]

In addition to the case of different means of accomplishing the same  
or similar goals there is also a question of defining what would  
really be duplication. This likely sounds like a silly question but  
considering the eCommerce space... Are ecommerce and Ubercart modules  
duplication? What about ecommerce and some of the paypal modules?


---------------------------
Joshua Brauer


Our lives as we lead them are passed on to others, whether in
physical or mental forms, tingeing all future lives together.
This should be enough for one who lives for truth and service
to his fellow passengers on the way. --- Luther Burbank

On Mar 19, 2008, at 11:13 AM, Earnie Boyd wrote:

> Quoting Greg Knaddison - GVS <Greg at GrowingVentureSolutions.com>:
>
>> I'm mostly just disagreeing so that we can investigate these ideas  
>> fully.
>>
>> On Wed, Mar 19, 2008 at 12:05 PM, Steven Peck <sepeck at gmail.com>  
>> wrote:
>>> A monoculture produces no innovation.
>>
>> How about "tends to produce less innovation."
>>
>>> Protecting the existing contributed modules which may or may not  
>>> have
>>> active maintainers, which may or may not have maintainers who
>>> cooperate and/or may or may not have maintainers that share a vision
>>> is not good.
>>
>> In the specific case of a project that is no longer maintained we can
>> give maintenance to someone new, right?  I don't see how that's an
>> argument to create (or allow the creation of) a new module.
>>
>>> Forbidding innovation or competition produces a protected class of
>>> elite people who were first to arrive but may not actually be doing
>>> something now.
>>
>> Sure, but we've also got a policy that inactive maintainers get
>> replaced.  So, I don't think your conclusion is entirely accurate.
>>
>>> As this is not a new debate, I shall introduce a new one.
>>> Fire is bad.  Support or refute this statement.
>>
>> It's not new, but it is something where there is some disagreement in
>> the community. I'd like to have a discussion about this to see if we
>> can come to a closer agreement.  If you can point to an existing
>> decision on this topic, please do.  The closest I can see to a  
>> guiding
>> decision is the last bullet on http://drupal.org/principles
>>
>
> Greg, in principle I agree with you.  But to enforce the principle  
> changes to the d.o structure would need to be made and CVS write  
> access only be given at the module rather than the contributions  
> level of the directory tree.  An application process would need to  
> be implemented for new modules and someone would need to review the  
> applications to make a decision if something similar already  
> exists.  However, I don't think we want Drupal contributions  
> becoming something similar to SourceForge so what we have is a good  
> solution that serves the community well.  If you find modules with  
> similar function then as a community member you could begin  
> conversations with the module maintainers to try to come to common  
> ground and combine the best of each module.  If one of those modules  
> is already defunct then request that the project be closed.  Also  
> realize there may be good reason to have them separated that you are  
> not aware of.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.com/
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20080319/12f29b32/attachment.bin