[development] module duplication in Drupal contrib

matt at mattfarina.com matt at mattfarina.com
Wed Mar 19 16:49:53 UTC 2008


One thing that comes to mind is use cases. Some modules will solve  
different problems in different ways because they have different use  
cases. They can be due to different requirements, different audiences,  
different work flows, and different needs.

It's not just a matter of functionality but use cases. Take the  
simplefeed and feedapi modules. They do a lot of the same things. But,  
they have different needs that got them to different places. I would  
never suggest merging them into one module. Though, I might suggest  
descriptions on the module pages that talk about where to use them and  
other modules that accomplish similar things in different ways.

Just a thought...

Matt

  Nancy Wichmann <nan_wich at bellsouth.net>:

>> "Modules that duplicate functionality available from an existing module
> are damaging to the Drupal project."
>
>> Please support or refute that statement...
>
> Support: Crell has a point about making the wheel better. If combining
> modules can accomplish this it should definitely be considered.
>
> Refute: Almost all blanket statements such as this are wrong at some point.
> Because "function xyz" is available from both the "abc" and "def" modules
> doesn't necessarily mean they should be combined.  There are undoubtedly
> other functions in those modules and it may be that an adopter of one of
> them simply does not need (or want) the additional functions in the other.
> It is also quite possible that the display format from "abc" is more to
> his/her preference than that of "def."
>
> I've also seen users complain that "def" required "ghi" and they only want
> to install, and maintain, one module.  In a sense, such an inter-module
> dependency has thus "damaged" Drupal for that user.
>
> I personally have been told (not asked or recommended) to merge one of the
> modules I maintain with another. However the two modules really have
> different audiences even though the descriptions are similar. Further, the
> design of the two was so different that it would really have caused a
> complete rewrite of one or both of them, likely with a loss of function.
> Perhaps a statement comparing and contrasting the solutions offered would
> have been a more appropriate demand.
>
> Nancy E. Wichmann, PMP
>
>
>




More information about the development mailing list