[development] D7 contrib module development

[Matt Chapman]

Marcel Partap wrote:
>> If you really want to help improve contrib, then help by writing
>> more "comparisons of duplicated modules"
>> (http://drupal.org/node/266179 - though the handbook is a bit
>> messed up since the upgrade).
> Waste of time better spent on reimplementing functionality in the best 
> possible manner.

There lies the fallacy. I don't believe there is any 'one best solution' 
for most given problems, especially in Drupal.

Which is better: a simple solution that gives a few features out of the 
box, or a highly configurable, extensible solution that requires 
multiple configurations before it can be used? It depends on the site 
being built and on the site builder. In the realm of email subscription 
modules, for example, the needs of an internal documentation site versus 
a public news publishing site are very different.

Likewise, Site builders who are coders are going to be drawn to the 
module that describes itself this way:

"This is a complete Subscriptions/Notifications Framework aiming at 
extendability and escalability. It allows any number of plug-ins 
defining new event types or subscription types or a different user 
interface."

Site builders who are afraid of PHP will drawn to:

"This module allows users to subscribe to periodic emails which include 
all new or revised content and/or comments much like the daily news 
letters sent by some websites"

or, if they already know the drupal lingo and need more power, maybe:

"This module enables users to subscribe to be notified of changes to 
nodes or taxonomies, such as new comments in specific forums, or 
additions to some category of blog."

Duplicated modules aren't necessarily competing modules. I think it's 
good to have different modules focused on meeting the needs of different 
audiences. One size does not fit all.

It was suggested that some duplicated modules exist solely to feed 
developer ego. That's not the most flattering way to put it, but I have 
noticed that being the maintainer of a module does lead to business 
inquiries; I'm not keen to give up the publicity. One possible solution 
to this would be to have project pages list all the committers for a 
project, and not just the one owner. This would increase the value of 
collaboration and decrease the hesitation for developers to let a module 
die in favor or a new, truly better solution.

Best,

Matt