Jamie Holly wrote: > That group is very valuable, but it shouldn't be considered a solution > for this issue. The biggest complaint of Drupal is the "steep learning > curve" and when you read those complaints you commonly see reference to > the situation of multiple modules that provide the same basic features. > Sure if someone is patient and has the time they can download all > similar modules and see which one is the best for their situation, but > who really has that time? Also you get the issue of modules that don't > fully uninstall, leaving behind things like settings and sometimes > tables, so you end up with artifacts in the database. (Though I got to > admit, as someone who used to do a lot of work in PHPBB, the process > with Drupal is a lot less painful. Nothing like spending hours copying > and pasting in core changes to find out it wasn't exactly what you wanted) >
As a Drupal newbie but OSS veteran, I will say that Drupal's module system is a little frustrating at times, but FAR better than any other platform with such a diverse set of "modules". Generally I decide based on metadata first and foremost: maturity of the module, and activity level of the maintainer(s). Auditioning modules and worrying about uninstall has not been a problem for me, since I run a local development install and going back to a previous database dump only takes a few seconds. I love how flexible Drupal has been in that regard. I do however think that modules whose names are only different because of punctuation are extremely confusing. I've been through this with node access and site maps. Some kind of namespace duplication checking with an informational warning might be nice. However the most helpful thing so far has been the previously mentioned blocks on the module page describing differences to other modules, and for modules lacking that for some concerned party to create a ticket asking the author to describe the differences, like: http://drupal.org/node/583270 Thanks, JT
