[development] D7 contrib module development

[Daniel F. Kudwien]

> So now the first time site builder who just wants his friends 
> to be able to decide if they want to receive email notice of 
> new content needs to download and enable the right 
> combination of at least 3 modules. Or he can just download 
> and enable notify module.

Now your users start crying for a feature that Notify module does not
provide.  You create a patch for it, it gets committed, and Notify module is
one more step closer to be a full duplicate of other notification modules.


> As a developer, sometimes it much easier for me to write my 
> own solution to my own simple problem than to take the time 
> to learn someone else's framework for a generic class of 
> similar problems. Sometimes, duplicating basic code is the 
> more efficient  process, especially in a system as complex as 
> you describe.

The real issue starts with module integration.  User-facing modules like
Buddylist, Guestbook, Organic Groups, Privatemsg, and a lot others integrate
either with one or the other notification module.  So you end up with
Privatemsg, which integrates with Subscriptions, and Guestbook, which
integrates with Notifications.

Now, module maintainers are either forced to integrate with more than one
notification module, or none at all - requiring the notification modules to
take over the integration.  Drupal users (not developers) most often cannot
do anything about it at all.  All they could do is to install more than one
notification module, but that would obviously be a pain for their site's
users and performance.

That's why duplication hurts the entire Drupal project and community.


> Also, the cost of change is factor in the real world. Even 
> though notify module is an inferior module on several levels, 
> it was easier to upgrade it to D6 than to switch to one of 
> the newer frameworks. Probably the only reason notify module 
> still exists is because it's the oldest of the solutions. If 
> someone wants to write a migration tool for the notifications 
> or subscriptions framework, and a UI module that duplicates 
> notify's simplicity, once these are included in the framework 
> download package, I will gladly shutdown notify.

As long as there is this duplication, this won't happen anytime soon.  Both
modules, Subscriptions and Notifications, suffer from their own duplication
- code-wise, feature-wise, as well as usability-wise.  The same applies to
other duplicated modules.

sun