[development] module duplication in Drupal contrib

[Kyle Mathews]

I agree we should let "a thousand flowers bloom" and then through simple
ranking methods, make it easy for people to pick out the best. This
discussion reminds me of arguments made against the blogs and other forms of
internet publishing. People complain that 99.9% of blogs suck but with
collaborative filtering sites such as Google, it's easy to find high quality
blog posts (and other internet content). Publish, then filter!

The below's a quote from an article by Clay Shirky:
http://www.shirky.com/writings/music_flip.html

"The curious thing about this state of affairs is that in other domains, we
now use amateur input for finding and publicizing. The last 5 years have
seen the launch of Google, Blogdex, Kuro5in, Slashdot, and many other
collaborative filtering sites that transform the simple judgments of a few
participants into aggregate recommendations of remarkably high quality.

This is all part of the Big Flip in publishing generally, where the old
notion of "filter, then publish" is giving way to "publish, then filter."
There is no need for Slashdot's or Kuro5hin's owners to sort the good posts
from the bad in advance, no need for Blogdex or Daypop to pressure people
not to post drivel, because lightweight filters applied after the fact work
better at large scale than paying editors to enforce minimum quality in
advance. A side-effect of the Big Flip is that the division between amateur
and professional turns into a spectrum, giving us a world where unpaid
writers are discussed side-by-side with New York Times columnists."


Kyle


On Wed, Mar 19, 2008 at 2:17 PM, catch <catch56 at googlemail.com> wrote:

> With the current number of contribs, it's not only hard for 'end-users'
> (whoever they might be) to find modules to suit their needs, it's also hard
> for developers. As others have noted, some (especially new) developers don't
> even bother to check before rolling their own and contributing it back.
> However I've seen well known names publish a module, have an issue in their
> queue that says 'is this duplicate?', then they've almost immediately joined
> forces and marked one or the other as deprecated. A lot of work gets wasted
> that way and it's not really anyone's fault, especially when it's people who
> always search first before they do any work :)
>
> The more modules there are, the harder it'll be to select one, so more
> duplicate modules will be written, so there'll be more modules, so it'll get
> harder to select one...
>
> We know none of this holds true for all modules, superficially at least -
> CCK and flexinode did similar things, but there's a reason why CCK,
> introduced later, is on it's way into core now, and the architectural
> difference was there from the beginning - so not really duplicate. Plus CCK
> and Views have eliminated a whole plethora of 'node modules' built for
> specific tasks - which can be replicated in a couple of minutes via the UI.
> However that tends to be the exception which proves the rule, especially
> when discussing smaller or more specific projects.
>
> A similar discussion came up last year (it was shorter than this one I
> think), and with tongue in cheek I suggested a "Duplicate modules Hall of
> Shame" somewhere in groups.drupal.org - where you could post up modules
> you think are very similar, discuss the differences, ways of collaborating -
> and in aggregate it might lead to us finding better ways to prevent this
> happening accidentally.
>
> As a side note, the 'pivots' work for module recommendations, which is
> targeted to mine the forums for information - I'd really, really like to see
> if this could be applied to Projects and Issues (and groups posts, since a
> lot of newer projects get more traffic there). That way you'd get "here's
> some similar modules/issues" when you view one, or even a list displayed as
> part of the validation on node submission (did you see these yet?). That at
> least might speed up the process of discovering accidental duplication of
> work.
>
>
>


-- 
Research Assistant
eBusiness Center @ BYU
kyle.mathews2000.com/blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080319/f7d42490/attachment.htm