On Sun, Mar 8, 2009 at 4:57 AM, Daniel F. Kudwien <news@unleashedmind.com> wrote: ...snip...
An example for this mess is the huge number of competing notification/subscription modules for D6 - each with a destinct feature set and of course incompatible to all others.
The reason for that is that someone thought he/she could write something better, wrote it, and ended up with something that already exists. From then on, happy developers continued to improve the pre-existing thingy, while some others installed the duplicated thingy and advanced on that. The end result is: two parties that think either approach is wrong and a massive croud of users that thinks "And this is why Drupal sucks.(tm)"
Removing the duplication requires that those module maintainers (finally) come to that conclusion.
I remember watching the relevant discussions. I think the issue of the different subscription/notification modules is good evidence that the problem is often organic and not just a result of incompetence, negligence, or lack of information. On one side, we have some fine developers who can allocate only so much time and energy on a particular module, and will refuse big patches which could make them lose control or delay or break the module if they don't do much more work than they intended to do. On the other side, we may have also good developers with some particular need at the time, who offer a huge chunk of code. This is always a tough call for a responsible module maintainer, who can't even predict if the newcomer developer can/will continue to work on the project or will move on to something else. In the case of the subscription/notification modules, so far both project seem to be doing fine. Eventually one may win the users, or they may take different directions. Much more often, the newcomer developer moves on, and the maintainer says "I told you so". What about the argument for banning duplicate modules? A reason that this is not possible is the antithesis between the responsibility of the maintainer who wants to have a working module within the constraints of real life vs the apparent needs of the newcomer developer. Introducing a third party who will decide the fate of a project unaffected by these realities isn't such a good thing, since that third party can't force anyone to work. I think all we can do is ask for documentation of the differences and put some pressure on the people involved to make them "think aloud" about the particular situation and make sure that they have considered the consequences and the options. ...snip...