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://wanderlusting.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
On Wednesday 19 March 2008 12:03:09 Nancy Wichmann wrote:
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.
This is IMO an insightful commentary and suggestion, and something that has happened with the Links module set that I created. There are a couple of other modules that work with web URLs, and I've corresponded with their authors about ways we can make the modules work together, and ways that they need to stay separate because they address different needs. I probably should do a better job of documenting this on the project page for Links, as Nancy suggests, however. Scott -- ------------------------------------------------------------------------------ Scott Courtney (Drupal user "Syscrusher") syscrusher@4th.com
One thing that comes to mind is use cases. Some modules will solve different problems in different ways because they have different use cases. They can be due to different requirements, different audiences, different work flows, and different needs. It's not just a matter of functionality but use cases. Take the simplefeed and feedapi modules. They do a lot of the same things. But, they have different needs that got them to different places. I would never suggest merging them into one module. Though, I might suggest descriptions on the module pages that talk about where to use them and other modules that accomplish similar things in different ways. Just a thought... Matt Nancy Wichmann <nan_wich@bellsouth.net>:
"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 <Greg@growingventuresolutions.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://wanderlusting.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 <sepeck@gmail.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/principles Thanks for your input. Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
"Sure, but we've also got a policy that inactive maintainers get replaced." IMHO, this policy needs to be updated (http://drupal.org/node/232602). Nancy E. Wichmann, PMP
Quoting Greg Knaddison - GVS <Greg@GrowingVentureSolutions.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 <sepeck@gmail.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/principles
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 <Greg@GrowingVentureSolutions.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 <sepeck@gmail.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/principles
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/
Just to throw my experience into this discussion - I primarily see two reasons why developers rather create new projects instead of joining forces: First and foremost: An existing project does not adhere to Drupal Coding Standards, contains almost no or meaningless documentation, or does not use Drupal's APIs. Second: An existing project looks and "feels" unmaintained. Its issue queue is bloated by unresolved and even unrecognized issues. If there are any follow-ups from the maintainer, they tend to be meaningless or ignorant. While the first one is a technical one and may be prevented/solved by automation (scripting), the second is more related to the personal opinion and/or available time of a maintainer, which can only be clarified in a discussion. AFAIK, we don't have a dedicated container at d.o to publicly discuss only such project/co-maintainer topics, where everyone is able to track them (RSS) and participate. Recently, I've seen a third cause for duplicate projects: New/novice Drupal developers who do not seem to check contributions for already existing projects - or - developers who wrote a custom module for client/project xyz without checking contributions for similar modules/APIs up front, which they really want to contribute back, possibly only to gain some "contributor points". Daniel
On Wed, 19 Mar 2008 20:32:50 +0100 "Daniel F. Kudwien" <news@unleashedmind.com> wrote:
Recently, I've seen a third cause for duplicate projects: New/novice Drupal developers who do not seem to check contributions for already existing projects - or - developers who wrote a custom
I wrote my own code in spite of installing already made modules because it took less to write code than understand what the module really did or compare it with modules with similar functionality. There are "established", well documented or just too big to be redone in a couple of days modules. With smaller modules sometimes choosing takes more than writing. BTW thanks to the people that pointed out http://drupalmodules.com Reviews and "related modules" are a nice addition. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote:
...it took less to write code than understand what the module really did or compare it with modules with similar functionality. ... With smaller modules sometimes choosing takes more than writing.
And isn't taking the time to evaluate existing functionality fundamental to participating effectively in an open source project? I'd argue that someone who is universally unable to so is likely to hinder more than help the community effort. For non-community use, such as for clients or other private projects, developers might create a custom module rather than using existing community code. These custom modules don't have much effect on the community because they don't reach the contrib repository. I don't support a policy that universally outlaws the creation of contrib modules that provide already existing functionality. I think some degree of overlap is to be expected and should be tolerated and in some cases embraced by the community. However, the act of contributing of a new project that provides overlapping or duplicate functionality should be one that is made deliberately, with an understanding by the contributor of why s/he is doing so. What is unhelpful to the community is contribution of "yet another module" that provides the same functionality as two or three other individual modules without a good reason, or at least an explanation on that module's project page. I propose that if a project is potentially a duplicate of another module, that an explanation of any differences and the reason for creating a separate module be required in that module's project description. This explanation does not necessarily have to be officially accepted by the community to meet this requirement, but project description pages that read, "Because I didn't check the contrib repository" (for whatever reason) can be evaluated in part, on that statement by the project's maintainer. Best, Ezra Gildesgame
On Wed, 19 Mar 2008 18:11:07 -0400 "Ezra B. Gildesgame" <ezra@pingv.com> wrote:
Ivan Sergio Borgonovo wrote:
...it took less to write code than understand what the module really did or compare it with modules with similar functionality. ... With smaller modules sometimes choosing takes more than writing.
And isn't taking the time to evaluate existing functionality fundamental to participating effectively in an open source project? I'd argue that someone who is universally unable to so is likely to hinder more than help the community effort.
Could be... but what about writing a module that requires more effort to understand what it does than writing another?
I propose that if a project is potentially a duplicate of another module, that an explanation of any differences and the reason for creating a separate module be required in that module's project description. This explanation does not necessarily have to be
Yeah... and who's going to check? You'd say "the community"... but well isn't it exactly the thing we would like to avoid? That people spend a lot of time looking through duplicates? duplicating their works to find duplicates? Larry was pointing out one problem of writing duplicates... waste of resources... but well first you'd be able to find if there is a duplicate module, then you've to evaluate it (compare it with more than one module), then you've to see if you can contribute[1] to the one you think is most similar to your needs. If you give easy tools to developers to help people spot duplicates and give tools to people to add metadata to projects... you'll avoid some work duplication and make it easier to compare modules. A thing that I think could be implemented easily would be to increase the level of the module taxonomy. There are categories that contains too many modules, once you read the whole list just to take out a couple of candidates you're tired enough. Another thing could be to put some metadata in the .info file. Relationship between modules as seen on drupalmodules.com is a good idea too. Project pages may start to contain a feature list (mandatory? this shouldn't stop dev to contribute). People should be able to add info to module docs easier but with some QA... this could be related on how you manage RTBC. The module SE should be improved. The policy: we will kill duplicate modules won't work... you're still putting too much work on the team that manage the cvs to decide if a module is duplicated. Just writing it somewhere doesn't help too much too. Suppose you find something that is reasonably easy to tweak than rewriting from scratch, but doesn't do exactly what you need. Would it help to add to each module page a quick guideline on how to contribute? I'd say that writing in each module page "if you want to contribute just place a patch in the issue queue" could help. If no one reply... you still have what you need and you may go further contacting the maintainers or asking to become the new maintainer. But sometimes the simplest advices are the most useful. [1] this depends on many factors: quality of code, people, documentation, responsiveness of the original dev, "burocracy" involved for a maintainer change.... -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Thu, 20 Mar 2008 10:20:17 +0100, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
Larry was pointing out one problem of writing duplicates... waste of resources... but well first you'd be able to find if there is a duplicate module, then you've to evaluate it (compare it with more than one module), then you've to see if you can contribute[1] to the one you think is most similar to your needs.
I think a lot of people are confusing different issues here. No, it's not inherently a problem that there are 4 different modules that handle images in 4 different ways. Yes, it is inherently a problem that there are 4 different modules that all try to un-break the input format system in very similar ways. Deliberate duplication is fine, and is a healthy part of open source. Unintentional duplication is a waste of time and energy and only leads to confusion for users. Let's try to solve unintentional duplication without making deliberate duplication impossible or overly difficult. "Vetting" of projects to avoid duplication is a no-go. Giving developers better tools to avoid unintentional duplication is a worthwhile investment. --Larry Garfield
On Thu, 20 Mar 2008 12:49:48 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
On Thu, 20 Mar 2008 10:20:17 +0100, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
Larry was pointing out one problem of writing duplicates... waste of resources... but well first you'd be able to find if there is a duplicate module, then you've to evaluate it (compare it with more than one module), then you've to see if you can contribute[1] to the one you think is most similar to your needs.
[snip]
Deliberate duplication is fine, and is a healthy part of open source.
Unintentional duplication is a waste of time and energy and only leads to confusion for users.
My point is that before you get to "intentional" duplication... you've to know you're duplicating... so knowing easier you're duplicating something should solve the later and put you a step further to the former. Any policy about duplication is just a burden on someone (the dev and/or the "controllers"). Tools and simple guidelines that help you to spot duplicates and contribute easier to existing projects[1] will do more than vetoing. Some of these tools shouldn't be too hard to implement (eg. metatags in .info files and deeper categorisation), others may be harder and with an unknown ROI (related modules, free tagging, reviews, scores, most popular download). [1] I've to admit I just recently thought about the issue queue of a module as a way to submit patches for features even if I did use the issue queue to submit some patch for bugs and I'm still unsure about what should be the halal way to contribute to modules (and to core?). -- Ivan Sergio Borgonovo http://www.webthatworks.it
So, I wanted to start discussion and get feedback on this topic from a broad group of folks. That part seemed to work. My personal belief (which I pushed forward via issues on duplicate projects) was a "collaboration or die" belief and I think a lot of other people have that to. I believe that this discussion shows that the situation is much more nuanced. While there were lots of great replies, I'm responding to Larry since he has hit on this nuance: On Thu, Mar 20, 2008 at 2:49 PM, Larry Garfield <larry@garfieldtech.com> wrote:
Deliberate duplication is fine, and is a healthy part of open source.
Unintentional duplication is a waste of time and energy and only leads to confusion for users.
Let's try to solve unintentional duplication without making deliberate duplication impossible or overly difficult.
"Vetting" of projects to avoid duplication is a no-go. Giving developers better tools to avoid unintentional duplication is a worthwhile investment.
I definitely agree with this perspective. There are times when the existing module just isn't quite right for a certain set of needs and then the best choice is intentional duplication. However, it's not just "develoeprs" that we need to be giving these better tools to it's all users. When we have overlap (intentional or not) basically all users of Drupal suffer because it makes it much harder choose between the modules. Shai is right that over time your "Drupal-sense" gets better and this process is easier, but it shouldn't be this hard... In the short term the solution is improved categorization of modules and improved explanation text in the body of the project node. Saying "This is just like Module X, but without the baggage" doesn't actually help anyone (to use a recent example). Saying "This is just like module X, but the thrombulated the widgetizer in javascript rather than doing it via a form override so that users have a more responsive interface" is something that might actually explain why there is a separate project in a way that helps the users decide which to use. Another short term solution is to do a comparison write up (e.g. http://www.civicactions.com/blog/similar_content_module_wrapup - thanks Owen!). Since we're all comparing modules on a regular basis, take the extra hour and write up the comparison. Your fellow users will appreciate it. In the longer run, the solution is the "Drupal.org redesign" and I hope that folks will go and help that effort if they can or at least be ready to support it in the future. http://groups.drupal.org/drupal-org-redesign-analysis Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
I believe that ugly, chaotic mess of multiple contributed modules replicating functionality is a wonderful thing. It is one of the many wonderful things that attracted me to Open Source, and specifically to Drupal. It encourages innovation. So what if 90% of the modules developed might be labeled as duplicate, poorly maintained, junk, or what have you. It's that wilderness that encourages the 10% to thrive. Related to this is the cry I've heard over the past few years for support for multimedia in Core. No, I say! Keep Core to its bare bone structure. I want 50 different ways to display an image! If the Image module had been in core, there would have been less incentive to create alternatives. Imagine Drupal for a moment if Flexinode had been put in Core. When we stop the creative flow of contributed modules, we are effectively making contributed Core. "You can't make that image handler that does it slightly differently, because there's already an image handler that does it well enough. So what if your use case is slightly different? Write a patch. Or force your site to work out of the box." We discourage module development when we tell people not to build module Y, because it already exists in module X. Yes, we end up with modules D, E, and G that do similar things, but as has been pointed out, they might be slightly different use cases. Also, some developers might have a different vision than others, and we nip that in the bud if we tell them not to bother, since it's already been done, or if we stifle their creativity by telling them to build a patch that ends up not getting accepted because the maintainer doesn't like the feature. If it is a real problem for users, then restructure the project pages to make it easier to sort. Or create a third branch: Core, Contributed, and Experimental/Universal or something. Whatever you do, don't cut off the wellspring of creativity and innovation that makes Drupal such an amazing beast. Enough rant. Back to work. Aaron Winborn
Beautifully said. Aaron Winborn wrote:
I believe that ugly, chaotic mess of multiple contributed modules replicating functionality is a wonderful thing. It is one of the many wonderful things that attracted me to Open Source, and specifically to Drupal. It encourages innovation. So what if 90% of the modules developed might be labeled as duplicate, poorly maintained, junk, or what have you. It's that wilderness that encourages the 10% to thrive.
Related to this is the cry I've heard over the past few years for support for multimedia in Core.
No, I say! Keep Core to its bare bone structure. I want 50 different ways to display an image! If the Image module had been in core, there would have been less incentive to create alternatives. Imagine Drupal for a moment if Flexinode had been put in Core.
When we stop the creative flow of contributed modules, we are effectively making contributed Core. "You can't make that image handler that does it slightly differently, because there's already an image handler that does it well enough. So what if your use case is slightly different? Write a patch. Or force your site to work out of the box."
We discourage module development when we tell people not to build module Y, because it already exists in module X. Yes, we end up with modules D, E, and G that do similar things, but as has been pointed out, they might be slightly different use cases. Also, some developers might have a different vision than others, and we nip that in the bud if we tell them not to bother, since it's already been done, or if we stifle their creativity by telling them to build a patch that ends up not getting accepted because the maintainer doesn't like the feature.
If it is a real problem for users, then restructure the project pages to make it easier to sort. Or create a third branch: Core, Contributed, and Experimental/Universal or something. Whatever you do, don't cut off the wellspring of creativity and innovation that makes Drupal such an amazing beast.
Enough rant. Back to work.
Aaron Winborn
-- Bill Fitzgerald http://www.funnymonkey.com Tools for Teachers 503.897.7160
On Wed, Mar 19, 2008 at 9:26 AM, Greg Knaddison - GVS <Greg@growingventuresolutions.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 <sepeck@gmail.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/principles
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/23789 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
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
Marc Doornik schrieb:
I completely agree, if you look at sourceforge, you have a project activity level and download count. At Mozilla plugins you have a ranking system. If we could get something like that for the Drupal modules, it would be easier for someone to decide if it is worthwhile to use or integrate a module in a site.
Otherwise it's just a bunch of modules....
Quality metrics is a different topic. Module/project duplication happens earlier in this process. As mentioned before, even if a module is popular, that doesn't mean someone won't create another one for the same purpose, just because s/he's unable to contribute, f.e. because of an ugly coding-style.
I agree that duplication is not necessarily bad, it just makes it a lot harder to browse the module section on drupal.org to find relevant content, and this is what is really wasting a lot of time for users and developers. It is my impression that the current "module categories" taxonomy is not really helpful because it has become too coarse to categorize the 2000+ modules that are out there, and a quick informal survey of my co-workers showed that others feel the same about this. Many of these module categories have a couple hundred modules, and their listing spans more pages than the average user is willing to read in order to find what they want. Would it be possible to simply turn this taxonomy into a free-tagging field, or add a separate free-tagging taxonomy? We would then have terms that can categorize modules much more specifically, but more importantly we would have a way to link similar modules together.
I know that when I talk to people about considering developing Drupal sites, I tell them that there is a bunch of time that you need to spend researching the best way to get something done. For some programmers "research" means going to an online reference with lists of function syntax. But with Drupal you have to add to that: reading issue queues, support requests, forum posts etc. (and writing to all those as well) to evaluate what the best direction is for a particular solution. The benefits of this process are great. You end up meeting great people and leveraging a huge amount of work created by others. But it does take an investment of time. As many have noted, d.o. can add all kinds of tools (the newly launched "recommended version" feature being just one -- go Derek!!!) to make this process easier and faster. And that will happen. I particularly like Florian's suggestion about free-tagging on the module pages. But being a good Drupal developer requires evaluation and analysis of a lot of moving parts: - feature set, - code maturity/quality, - development activity, - responsiveness of maintainer(s), - dependence on other modules These are the "moving parts." As daunting as it might seem to engage in such research, it does get easier, even as the number of modules grows. One begins to "know" modules and families of modules like you know friends (who is engaged to whom etc. :) I think part of the "problem" might be folks' expectation that things "should" be easier. I'm certainly for making things easier, but not at the expense of making the barrier to entry for module developers higher. I think it is a low barrier to entry that has contributed to harnessing a huge amount of energy. Overall, the quality and quantity of contributed code to Drupal is impressive. Shai content2zero <http://content2zero.com>
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 Wednesday 19 March 2008, Jakob Petsovits wrote:
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
Haha. I can't believe I did not try it before I sent that mail. Thanks for that. -Dave
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.
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@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
Yes. I will improve the "pivots" algorithm during the summer so that it can mine issues, group messages, etc. But the first thing is to go live on d.o. now :) I'm working with Narayan on that. On Wed, Mar 19, 2008 at 4:17 PM, catch <catch56@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.
Greg Knaddison - GVS 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.
Pardon my crankiness, but the best way to help the Drupal project has absolutely nothing to do with this statement at all, and everything to do with improving the tools on Drupal.org that everyone (both users and module developers) use to find modules they're looking for: module categorization, project browsing, search, metrics, etc. I'd be thrilled to see even 1/100th of the people who took the bait by responding to this thread direct some of that energy into these efforts instead: * http://groups.drupal.org/issue-tracking-and-software-releases * http://groups.drupal.org/drupal-org-redesign-analysis -Angie
Some modules are sledge hammers and some are scalpels... duplication isn't bad... making core more accessible for modules to implement features should be the focus of collaboration. Policing whether collaboration happens at the contrib module level or not is probably a tragic was of community resource and a further attempt to apply more structure to the very successful anarchist environment call cvs.drupal.org/cvs/drupal-contrib On Wed, 2008-03-19 at 11:25 -0300, Greg Knaddison - GVS 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
Not entirely sure how feasible this would be but... When I used media temple for hosting, and you had a problem, you'd fill in a form to get technical support, but you'd hit submit and it'd suggest some KB articles to look at that were 'similar'. If none of those really answered the problem then you could submit a new issue. In the same way when you submit a new module it would be cool if d.o somehow suggested similar modules (based on keywords maybe) and then rather than blindly creating a new module you'd get some help finding duplicates. Side note: Not having *any* metrics for projects on d.o is a very serious problem. On Thu, Mar 20, 2008 at 11:38 PM, Darrel O'Pry <darrel.opry@gmail.com> wrote:
Some modules are sledge hammers and some are scalpels... duplication isn't bad... making core more accessible for modules to implement features should be the focus of collaboration.
Policing whether collaboration happens at the contrib module level or not is probably a tragic was of community resource and a further attempt to apply more structure to the very successful anarchist environment call cvs.drupal.org/cvs/drupal-contrib
On Wed, 2008-03-19 at 11:25 -0300, Greg Knaddison - GVS 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
-- Regards Steven Jones
On Tuesday 25 March 2008, Steven Jones wrote:
Not entirely sure how feasible this would be but...
When I used media temple for hosting, and you had a problem, you'd fill in a form to get technical support, but you'd hit submit and it'd suggest some KB articles to look at that were 'similar'. If none of those really answered the problem then you could submit a new issue.
In the same way when you submit a new module it would be cool if d.o somehow suggested similar modules (based on keywords maybe) and then rather than blindly creating a new module you'd get some help finding duplicates.
By then it's too late; I usually write a module first, then add it to CVS, then go create the project node. In fact, you have to add the new module to CVS first, I believe. If you don't get a dupe check until you're creating the project node, all it will tell you is "guess what, you just wasted X hours on that module! Submit it anyway and be frustrated? Y/N" :-) Make modules more findable, and let developers use their judgment in a fully informed manner.
Side note: Not having *any* metrics for projects on d.o is a very serious problem.
Better no metrics than bad metrics. If, for instance, we rated module quality strictly on the number of open support requests there were in the issue queue, Views would come out as a module to never ever ever use. That would also be quite wrong. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Quoting Larry Garfield <larry@garfieldtech.com>:
On Tuesday 25 March 2008, Steven Jones wrote:
Make modules more findable, and let developers use their judgment in a fully informed manner.
We really need hierarchal tagging of the modules. Having more than 300 in Content on d.o/project/Modules doesn't help me find squat. And what is the difference between ``Content'' and ``Content display''? A search form for just the project nodes would be nice, then I could drill down better.
Side note: Not having *any* metrics for projects on d.o is a very serious problem.
Better no metrics than bad metrics. If, for instance, we rated module quality strictly on the number of open support requests there were in the issue queue, Views would come out as a module to never ever ever use. That would also be quite wrong. :-)
I agree. Any ratings would need to reset with each release as well. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (25)
-
Aaron Winborn -
Angela Byron -
Bill Fitzgerald -
catch -
Daniel F. Kudwien -
Darrel O'Pry -
Dave Cohen -
DragonWize -
Earnie Boyd -
Ezra B. Gildesgame -
Florian Loretan -
Greg Knaddison - GVS -
Ivan Sergio Borgonovo -
Jakob Petsovits -
Joshua Brauer -
Kyle Mathews -
Larry Garfield -
Marc Doornik -
matt＠mattfarina.com -
Nancy Wichmann -
Shai Gluskin -
Steven Jones -
Steven Peck -
Syscrusher -
Xiaodan "Daniel" Zhou