Morbus Iff has a nice rant about the quality, or at least the style, of code in Drupal's contributed modules. And he's right - I was looking for a simple vote up/down module this week and ran for the hills after looking at the source code. Part of the problem isn't really a problem - it's debatable whether contributed, third-party modules should use Drupal's code conventions or whether it's up to the author to use whatever suits them best as long as it's consistent (I'm leaning towards the latter, as I prefer to use single-line conditional clauses, for example, and some of the 'gold standards' set by core modules aren't particularly optimal).
I think a big problem with the third-party modules - and the same is true for Wordpress and other open-source projects that anyone can write extensions for (which is a good thing) - is feature creep. A lot of the time it's easier to have a look at someone's gigantic existing module that does everything and then write your own version that does just the thing you want and does it well. Drupal.org's issue queues for each module are full of feature requests, and authors feel the pressure to dump these features into the main module when they might arguably be better off adding hooks and implementing those features separately, so that anyone can still get the original, single-purpose module without worrying about bugs, security holes and untidy code in the mass of extraneous features.
As Morbus suggests, separate module ratings for 'features' and 'code quality' could be useful. In fact, a lot of Drupal - including the IRC channels - could do with a separate focus on 'third-party developer'-specific documentation, support and features. At the moment that channel is mixed in with each of the 'core developers' and 'GUI users' stuff, which makes development more difficult that it need be. Drupal can be impenetrable to say the least, and not having a dedicated support channel can be frustrating.
Comments
All fields are optional, email address will not be shown; no HTML, URLs are automatically hyperlinked.
I've never looked at any Drupal code, but as a general thing, I wonder if the architecture software provides for plug-ins and extensions can effect whether these plugins get bloated with feature creep, or stick to doing one thing well. If they do one thing well--will they be easily inter-operable with another extension that does another (perhaps related) thing well? Or if you want to do both things at once, do the author(s) of both things need to work so closely together than it's a lot easier just to make it one thing? Do you have to spend so much effort on the 'scaffolding' for your plug-in that when you want another feature, you don't want to go to the trouble of doing all that scaffolding again, it's much easier just to piggy back it onto what you already did before?
How can software be architected to encourage well-desigend (do one thing well) plug-ins, and make it as easy as possible for developers to do this?
I've been thinking of similar but different things lately, as I've gotten in the habit of taking single-maintainer single-user library-market software, and trying to adapt it to work better for true collaborative community open source model. There, I'm thinking about how to allow maximal localization without code fork, but the issues seem reminiscent.