[development] Duplicated modules

[Ivan Sergio Borgonovo]

On Tue, 10 Mar 2009 22:24:05 -0400
Andrew Berry <andrewberry at sentex.net> wrote:

> On 10-Mar-09, at 6:41 PM, Morbus Iff wrote:
> 
> > To some degree, chx and I already started that with  
> > DrupalToughLove.com.
> 
> DTL looked to be very promising. I found the reviews done to be  
> practical in that even though they weren't my modules, they still

Jumping in here... not strictly related to these 2 posts.

There are thousands modules.
If you restrict your interest to 3 or 4 to evaluate a review is
useful.
If you can't even find the best candidates to compare, a review is
like someone donating you a Ferrari and leaving it in an unknown
place in Atacama.

What I'd find useful would be
- better categorisation system and better search system on categories
- a flag to check if a module provides an API or is just an
  application
- an activity index (average lines of code changed/time)
- a issue queue index (how many issues open, how much people
  subscribed to them, % of issues closed)

Asking developers to list similar modules is asking for good will.
Asking for good will generally is not enough, rewarding good will is
better.
If developers could classify better their modules it would be easier
to search for similar modules and developers could make easier to
find their own creatures too.
Coming up with a good categorisation system isn't easy. I think
debtag is trying to achieve a similar target, but I don't know how
successfully and how much of their efforts we could share.

In each project page there is a link to statistics... but if you're
comparing projects you've to open one more page for comparing and
the statistics aren't synthetic enough.

What I generally end up doing is open 2 to 4 categories, skim
through the modules, open several other tabs, read the description
of the modules I've opened, shrink the selection as much as
possible... download the modules and look at the code, README etc...
if really forced install the survivors.

Somehow once I have few candidates even if a review of the module
may be helpful the decision is going to be based on details that
hardly could be expressed synthetically and are very "context"
sensitive (specific to the situation I'm trying to solve).
At this level you just have to hope the maintainer of the project
spent some time to describe what makes its creature special to
select further before testing/looking at the code.
I don't think developers find very rewarding adding descriptions,
maybe they would find more rewarding adding feature lists.
Still developers may write modules for very different reasons.
I think having a community that *may* support your module *could* be
a good reason to promote the diffusion of your module... but it may
not be the case... and still you may be contributing in a valuable
way to drupal community.

Maybe we could let people (other than the maintainers) to
"categorise" the project.
After all every user have to read the list of projects before
choosing one, compare them etc... this efforts are collectively
repeated thousands time. It's a pity they get wasted.
Use cloud tagging for similarity and categories.
And this is rewarding for users... they are going to search through
modules more than one time... if they could tag them they would
lower their efforts the next time.

I hope that every module developer started as a potential module
user so he searched at least once in the projects to see is
something was fit for its need.
Even if I'm planning to start a "duplicate" I'm interested to know
other people's approach to my similar problem.

I really don't see duplication as a problem.

If you've bad developers... even if they could easily find similar
modules they may find silly reasons to start new ones.
But there may be thousands good reasons for duplication:
- a maintainer is not willing to accept changes
- framework modules vs. ready to use modules
- deadlines
- ...
A successful project is not determined by "code quality" alone and
not every time developers may have common interests.

Determining if there is no real good reason for duplicating the
functionality of a project is not an easy task.
There may be time when the developer is just an asshole... in that
case I doubt you can direct his efforts to a more valuable target
convincing him to submit patches to another project.
So the cost/missed return of one more project developed by an
asshole is just the cost in searching through modules, not the sum
of the cost of searching through modules and the missed contribution
of one more developer to an existing project.

On the other hand if you're not dealing with an asshole, he may have
had his good reasons to start a new project.

Consider that there are modules you could write in an hour and it
may take more than an hour to search through the project list and
learn how certain modules have to be used... and even when you may
find one that nearly fit your needs, it may not just fit your needs
as much the one you may write.

Of course this is going to happen for the very simplest modules but
still the effort of looking through all the list of available modules
impact the community much more than having few duplicates of small
modules.

Lowering the cost of searching and comparing will lower the
duplicates.

Furthermore... how can you cheaply know if a new module is a
duplicate without good search tools? Let alone evaluating if a
duplicate will negatively impact the community.

Every *effort* to regulate duplication of modules have to pass
through better tools to search through modules.
Every *effort* to regulate duplication is an *effort* and sincerely
the return looks dubious.

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it