module duplication in Drupal contrib

Hi,

"Modules that duplicate functionality available from an
existing
module are damaging to the Drupal project."

Please support or refute that statement and propose
strategies for
managing CVS applications and/or projects on Drupal.org in a
way that
will best help the Drupal project.

I'm using "Drupal project" in a very loose sense
so you should infer
that it includes lots of groups of people like new users,
site
builders, contributors, drupal.org admins, the security
team, etc.

Thanks,
Greg

-- 
Greg Knaddison
Denver, CO | http://knaddison.com
World Spanish Tour | http://wanderlusti
ng.org/user/greg

> "Modules that duplicate functionality available
from an existing module
are damaging to the Drupal project."

> Please support or refute that statement...

Support: Crell has a point about making the wheel better. If
combining
modules can accomplish this it should definitely be
considered.

Refute: Almost all blanket statements such as this are wrong
at some point.
Because "function xyz" is available from both the
"abc" and "def" modules
doesn't necessarily mean they should be combined.  There are
undoubtedly
other functions in those modules and it may be that an
adopter of one of
them simply does not need (or want) the additional functions
in the other.
It is also quite possible that the display format from
"abc" is more to
his/her preference than that of "def."

I've also seen users complain that "def" required
"ghi" and they only want
to install, and maintain, one module.  In a sense, such an
inter-module
dependency has thus "damaged" Drupal for that
user.

I personally have been told (not asked or recommended) to
merge one of the
modules I maintain with another. However the two modules
really have
different audiences even though the descriptions are
similar. Further, the
design of the two was so different that it would really have
caused a
complete rewrite of one or both of them, likely with a loss
of function.
Perhaps a statement comparing and contrasting the solutions
offered would
have been a more appropriate demand.

Nancy E. Wichmann, PMP

A monoculture produces no innovation.
Protecting the existing contributed modules which may or may
not have
active maintainers, which may or may not have maintainers
who
cooperate and/or may or may not have maintainers that share
a vision
is not good.
Forbidding innovation or competition produces a protected
class of
elite people who were first to arrive but may not actually
be doing
something now.

As this is not a new debate, I shall introduce a new one.
Fire is bad.  Support or refute this statement.

Steven

On Wed, Mar 19, 2008 at 7:25 AM, Greg Knaddison - GVS
<Greggrowingventuresolutions.com> wrote:
> Hi,
>
>  "Modules that duplicate functionality available
from an existing
>  module are damaging to the Drupal project."
>
>  Please support or refute that statement and propose
strategies for
>  managing CVS applications and/or projects on
Drupal.org in a way that
>  will best help the Drupal project.
>
>  I'm using "Drupal project" in a very loose
sense so you should infer
>  that it includes lots of groups of people like new
users, site
>  builders, contributors, drupal.org admins, the
security team, etc.
>
>  Thanks,
>  Greg
>
>  --
>  Greg Knaddison
>  Denver, CO | http://knaddison.com
>  World Spanish Tour | http://wanderlusti
ng.org/user/greg
>

I'm mostly just disagreeing so that we can investigate these
ideas fully.

On Wed, Mar 19, 2008 at 12:05 PM, Steven Peck <sepeckgmail.com> wrote:
> A monoculture produces no innovation.

How about "tends to produce less innovation."

>  Protecting the existing contributed modules which may
or may not have
>  active maintainers, which may or may not have
maintainers who
>  cooperate and/or may or may not have maintainers that
share a vision
>  is not good.

In the specific case of a project that is no longer
maintained we can
give maintenance to someone new, right?  I don't see how
that's an
argument to create (or allow the creation of) a new module.

>  Forbidding innovation or competition produces a
protected class of
>  elite people who were first to arrive but may not
actually be doing
>  something now.

Sure, but we've also got a policy that inactive maintainers
get
replaced.  So, I don't think your conclusion is entirely
accurate.

>  As this is not a new debate, I shall introduce a new
one.
>  Fire is bad.  Support or refute this statement.

It's not new, but it is something where there is some
disagreement in
the community. I'd like to have a discussion about this to
see if we
can come to a closer agreement.  If you can point to an
existing
decision on this topic, please do.  The closest I can see to
a guiding
decision is the last bullet on http://drupal.org/princi
ples

Thanks for your input.

Greg

-- 
Greg Knaddison
Denver, CO | http://knaddison.com
World Spanish Tour | http://wanderlusti
ng.org/user/greg

Quoting Greg Knaddison - GVS <GregGrowingVentureSolutions.com>:

> I'm mostly just disagreeing so that we can investigate
these ideas fully.
>
> On Wed, Mar 19, 2008 at 12:05 PM, Steven Peck
<sepeckgmail.com> wrote:
>> A monoculture produces no innovation.
>
> How about "tends to produce less
innovation."
>
>>  Protecting the existing contributed modules which
may or may not have
>>  active maintainers, which may or may not have
maintainers who
>>  cooperate and/or may or may not have maintainers
that share a vision
>>  is not good.
>
> In the specific case of a project that is no longer
maintained we can
> give maintenance to someone new, right?  I don't see
how that's an
> argument to create (or allow the creation of) a new
module.
>
>>  Forbidding innovation or competition produces a
protected class of
>>  elite people who were first to arrive but may not
actually be doing
>>  something now.
>
> Sure, but we've also got a policy that inactive
maintainers get
> replaced.  So, I don't think your conclusion is
entirely accurate.
>
>>  As this is not a new debate, I shall introduce a
new one.
>>  Fire is bad.  Support or refute this statement.
>
> It's not new, but it is something where there is some
disagreement in
> the community. I'd like to have a discussion about this
to see if we
> can come to a closer agreement.  If you can point to an
existing
> decision on this topic, please do.  The closest I can
see to a guiding
> decision is the last bullet on http://drupal.org/princi
ples
>

Greg, in principle I agree with you.  But to enforce the
principle 
changes to the d.o structure would need to be made and CVS
write access 
only be given at the module rather than the contributions
level of the 
directory tree.  An application process would need to be
implemented 
for new modules and someone would need to review the
applications to 
make a decision if something similar already exists. 
However, I don't 
think we want Drupal contributions becoming something
similar to 
SourceForge so what we have is a good solution that serves
the 
community well.  If you find modules with similar function
then as a 
community member you could begin conversations with the
module 
maintainers to try to come to common ground and combine the
best of 
each module.  If one of those modules is already defunct
then request 
that the project be closed.  Also realize there may be good
reason to 
have them separated that you are not aware of.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.
com/

In addition to the case of different means of accomplishing
the same  
or similar goals there is also a question of defining what
would  
really be duplication. This likely sounds like a silly
question but  
considering the eCommerce space... Are ecommerce and
Ubercart modules  
duplication? What about ecommerce and some of the paypal
modules?


---------------------------
Joshua Brauer


Our lives as we lead them are passed on to others, whether
in
physical or mental forms, tingeing all future lives
together.
This should be enough for one who lives for truth and
service
to his fellow passengers on the way. --- Luther Burbank

On Mar 19, 2008, at 11:13 AM, Earnie Boyd wrote:

> Quoting Greg Knaddison - GVS <GregGrowingVentureSolutions.com>:
>
>> I'm mostly just disagreeing so that we can
investigate these ideas  
>> fully.
>>
>> On Wed, Mar 19, 2008 at 12:05 PM, Steven Peck
<sepeckgmail.com>  
>> wrote:
>>> A monoculture produces no innovation.
>>
>> How about "tends to produce less
innovation."
>>
>>> Protecting the existing contributed modules
which may or may not  
>>> have
>>> active maintainers, which may or may not have
maintainers who
>>> cooperate and/or may or may not have
maintainers that share a vision
>>> is not good.
>>
>> In the specific case of a project that is no longer
maintained we can
>> give maintenance to someone new, right?  I don't
see how that's an
>> argument to create (or allow the creation of) a new
module.
>>
>>> Forbidding innovation or competition produces a
protected class of
>>> elite people who were first to arrive but may
not actually be doing
>>> something now.
>>
>> Sure, but we've also got a policy that inactive
maintainers get
>> replaced.  So, I don't think your conclusion is
entirely accurate.
>>
>>> As this is not a new debate, I shall introduce
a new one.
>>> Fire is bad.  Support or refute this
statement.
>>
>> It's not new, but it is something where there is
some disagreement in
>> the community. I'd like to have a discussion about
this to see if we
>> can come to a closer agreement.  If you can point
to an existing
>> decision on this topic, please do.  The closest I
can see to a  
>> guiding
>> decision is the last bullet on http://drupal.org/princi
ples
>>
>
> Greg, in principle I agree with you.  But to enforce
the principle  
> changes to the d.o structure would need to be made and
CVS write  
> access only be given at the module rather than the
contributions  
> level of the directory tree.  An application process
would need to  
> be implemented for new modules and someone would need
to review the  
> applications to make a decision if something similar
already  
> exists.  However, I don't think we want Drupal
contributions  
> becoming something similar to SourceForge so what we
have is a good  
> solution that serves the community well.  If you find
modules with  
> similar function then as a community member you could
begin  
> conversations with the module maintainers to try to
come to common  
> ground and combine the best of each module.  If one of
those modules  
> is already defunct then request that the project be
closed.  Also  
> realize there may be good reason to have them separated
that you are  
> not aware of.
>
> Earnie -- http://for-my-kids.com/
> -- http://give-me-an-offer.
com/
>

I see both sides point here. It is where the human
components that
have made this issue unresolved and probably never will be
fully
resolved.

There are many definitions of what an
"unmaintained", "defunct",
"different vision" module is. Some would say if a
maintainer answers a
few issues the module is still being maintained even though
it hasn't
been updated in a year. Some would say updates 2 times a
year is not
enough. Some would say that patches are denied means that it
should be
branched.As has been brought up of late, the Drupal
community is
growing at tremendous rates. With that growth comes all
kinds of
people.

It is hard to determine whether it is a module maintainer or
a patch
submitter is the the one in the right when it come down to
a
disagreement. As this is open source we have always put the
responsibility with the maintainer (as it should be). Some
people work
well with others, some people work OK with others, and some
do not
work well with others. I think that trying to force people
together is
not a good idea. Currently, we highly suggest it and it is
(as far as
I can tell) deeply ingrained into the community to not
duplicate. That
is enough I think.

I don't think that changing the "scratch your own
itch" method by
forcing module maintainers to be full software companies
providing
constant support and thinking of their users even when it is
not good
for them is the answer. I also don't think forcing others
that have an
itch to "take what there is" or to not be able to
take advantage of
the fine Drupal community and d.o resources just because
there is
another module that does something similar.

The main problem with this is from an end user's
perspective. Trying
to find the best module for what you need is hard to do. So
I think
the best solution to this is one that is focused on making
that
experience better without changing the open source model.
Many things
have been suggested in this area, ratings, download stats,
commit and
issue metrics, re-structuring the downloads section, similar
modules
blocks, forum chatter blocks, etc. I don't know the best
solution but
my bet is that it would be along these lines.

-- 
Alan Doucette
Koi Technology, LLC
www.KoiTech.net

On Wednesday 19 March 2008, Greg Knaddison - GVS wrote:

> "Modules that duplicate functionality available
from an existing
> module are damaging to the Drupal project."

Refute:

All these linux distributions duplicate functionality and
this is damaging to 
the progress of linux.  Imagine how much further along it
would be if we all 
embraced Slackware from the beginning.

Likewise MySQL.  What a waste of effort,  considering
Postgres was already 
mature when it was released.

True story... The first module I contributed to Drupal is
tac_lite.  I had to 
jump through hoops to get a CVS account, because my proposed
module had 
features in common with Taxonomy Access Control (TAC), but I
felt the modules 
worked differently enough that they should not be merged. 
Had I been denied 
the CVS access, I would have continued using tac_lite but
never shared it.  I 
would not have contributed to TAC, since my goal was to
simplify rather than 
add features.  And had I been snubbed back then, I may not
have gone on to 
contribute more modules.  (You can debate whether that's a
pro or con.  ;)

I strongly believe more modules and themes is better. 
Although we need better 
ways to rank and search them.  I'm surprised noone's made
drupalmodules.com 
yet.

-Dave

On Wed, Mar 19, 2008 at 9:26 AM, Greg Knaddison - GVS
<Greggrowingventuresolutions.com> wrote:
> I'm mostly just disagreeing so that we can investigate
these ideas fully.
>
>
>  On Wed, Mar 19, 2008 at 12:05 PM, Steven Peck
<sepeckgmail.com> wrote:
>  > A monoculture produces no innovation.
>
>  How about "tends to produce less
innovation."
>
>
>  >  Protecting the existing contributed modules
which may or may not have
>  >  active maintainers, which may or may not have
maintainers who
>  >  cooperate and/or may or may not have maintainers
that share a vision
>  >  is not good.
>
>  In the specific case of a project that is no longer
maintained we can
>  give maintenance to someone new, right?  I don't see
how that's an
>  argument to create (or allow the creation of) a new
module.
>

And we already do this in the case of modules known to be
unmaintained
because someone reported it.  However the remaining use
cases are
still valid.  While we encourage cooperation, we cannot
force it
without alienating a lot of contributors.

Some contributors do not play nice with others
Some contributors do not play nice with certain people.
Some contributors have different visions for the end result
of their modules
Some contributors have been burned by relying on others
contributed
modules for features/functions so are forced to duplicate
with their
own work
Some contributors merely contribute back with no intention
of changing
their module but still maintain it.

>
>  >  Forbidding innovation or competition produces a
protected class of
>  >  elite people who were first to arrive but may
not actually be doing
>  >  something now.
>
>  Sure, but we've also got a policy that inactive
maintainers get
>  replaced.  So, I don't think your conclusion is
entirely accurate.

I do.  New modules may duplicate functionality but in a
different way.
 That different way may not be readily appearent to the few
who
approve CVS accounts.

>  >  As this is not a new debate, I shall introduce a
new one.
>  >  Fire is bad.  Support or refute this statement.
>
>  It's not new, but it is something where there is some
disagreement in
>  the community. I'd like to have a discussion about
this to see if we
>  can come to a closer agreement.  If you can point to
an existing
>  decision on this topic, please do.  The closest I can
see to a guiding
>  decision is the last bullet on http://drupal.org/princi
ples

We encourage strongly cooperation and collaboration.  We do
not force
it.  Forcing it would certainly alienate any number of
contributors
and add significantly to the administrative burden of a
few.
http://drupal.org/node/2
3789

I do not have time to search the dev archives for the
previous
discussions and decisians but I believe this is a yearly
discussion in
some form or another.  I believe there is also a post on
Dries blog
regarding the subject.

>  Thanks for your input.
>
>  Greg

Steven Peck

On Wednesday, 19. March 2008, Dave Cohen wrote:
> I'm surprised noone's made drupalmodules.com yet.

Actually, someone has. Go check it out for yourself :P