[development] D7 contrib module development

[Cog Rusty]

On Sun, Mar 8, 2009 at 4:57 AM, Daniel F. Kudwien
<news at 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...