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