I thought I'd form a sort of target page to direct the assorted maintainers that have been listed in the Dupes. Just to ping into all their respective queues in a polite manner.
As opposed to Various attempts to compare enumerate, tabulate and choose between available modules and features, I think we should be encouraging these developers to merge efforts or voluntarily retire their modules in favor of more consistant solutions.
I was going to wikify this (and may still) but thought I'd throw it up for discussion input first. (Why is wiki/forum an either/or choice?)
Any re-phrasing is welcome.
.dan.
Dear Maintainers :)
A proposal to consolidate.
Everyones modules scratched an itch at some time, and we can assume that most of them did their jobs quite well, but it's possible that the originators were not aware of all existing efforts, or that later projects did he same thing differently or became more popular or supported. Some modules even logically expanded to include features that overlap another, producing conflicts where before there were none.
This memo is not about seniority of modules or module develpers.
It is about
- Gathering support for good ideas and features.
- Improving code quality by getting more eyes on shared code.
- Learning from each other. Recognising innovation.
- Increasing the popularity of your work by allowing more users to download a more common codebase.
- Reducing everyones workload.
- Making it easier for users to choose the best solution.
- Reducing the number of redundant or unported modules. (And making the Drupal project stats look better).
- Getting things ported!
I ask from anyone who has a module that appears to be overlapped by another, to please consider any of the following options:
- Documenting on the project page what distinguishes it from others that it may be confused with. Both being 'simpler' and 'having more options' are regarded as benefits to different people!
- Cross-linking from the your project page directly to competing or comparative modules to assist downloaders to make an informed choice.
- Identifying cool features in other projects that you could merge into yours.
- Identifying UI or configuration options that make sense and could be copied.
- Finding hooks or code style solutions that you can learn from or hadn't thought of.
- Contacting other module issue queues with suggestions and feature requests along with sample code and "here's how I managed to do this".
- Offering to come on board and merge your own code with theirs.
- Offering to retire your own module and endorse another solution.
The latter options are preferred... making your module more like the others is just a step on the path towards replacing them if that's your preferred path.
This is to make your maintainership easier by reducing your support responsibilites and increasing your support team.
Many good programmers on d.o. are receptive to constructive criticism, and even more receptive to assistance from people with a track record who have worked on the same problems they faced!
As an example, we found that insert_block.module had been overtaken by reptag.module and with little fuss it is now deprecated and suggesting that as a more general-case solution. (it would appear that block_filter.module is now in need of the same treatment :-)
As ever, no-one is required to co-operate, and if your offer of alliance is rejected, it won't help to press the point. The duplicated lists compiled on g.d.o. are just references compiled by outside observers trying to make things easier for users. We don't want to have to write and maintain more module comparison charts to fill in the gaps.
Please take these suggestions in the spirit they are offered!
Comments
awesome
This is great. I've probably got some comments on particular phrasing, but it's a great idea to have a form issue which we can post on project pages. Maybe we need a Duplicated Modules Hall of Shame sticker to go with it ;)
I love it. Give them a
I love it. Give them a badge!
druplicon in the stocks? Or just a blush?
Flag
It's great idea but it's hard to watch all modules.
If maintainers have no time-resouce to find similar modules - community need a tool to add duplicates and similar
Suppose there some ways:
1) Allow users to flag duplicate modules a-la abuse or flag or noderefs (community makes it's quicker)
2) Use drupalmodules.com or similar to aggregate module's posibilities and maintain list of synonyms
Awesome
This is my new favorite group. Killing duplicate modules is a past time of mine. Maybe public humiliation can encourage more collaboration. I've had several modules forked and then publicly claim on the project page, "This project is the same as X except Y". forehead smack
Open Letter support from Chart 2.0
To whom it may concern: https://www.drupal.org/node/2368793#comment-9345487
You don't need eyes to see, you need vision ...
I'm more a carrot man.
Love the goal, but can you get a better name? Still it seems popular, there must be a lot of angst out there about duplicate modules I guess.
Let's not stigmatize duplication
I agree with the options you list out, they're great for mitigating the negative effects of duplication and they're making it clear that in the long run you want to join efforts.
However, I really think this campaign needs a different name. I also stated this over at the slideshow list http://groups.drupal.org/node/20384#comment-73554.
Let's not stigmatize duplication. It's a source of innovation and a way of exploring approaches.
I think that the biggest problem with duplication is the confusion it causes for users, the post captures that. My big feature request for Drupal.org is module rating with comments. That would crowd source the problem of putting a module in context which currently is the sole and neglected responsibility of the maintainer.
http://www.twitter.com/lx_barth
http://www.twitter.com/lxbarth
agreed
I agree with everything said here. Some time ago I mentioned that I didn't like the negativity that sometimes gets kicked up in this group, but alex_b says it better than me.
Assumptions that there is duplication
The stated goals of this group I can agree with, but the title is shameful in itself, and reflects a dogma that says people should not scratch their own itch, they should scratch someone else's. There are many reasons why a "duplicate" module arises legitimately. And many of the so-called "duplicates" are only vaguely similar to others listed.
What this shaming does is discourage sharing, imho. Did a cool module for a client and want to contribute it? Don't do it, or you will be shamed for not stopping what you were doing, trying to get someone else's attention, trying to convince them of what you need done and that they should do it or take the time to review what you do.
The problem isn't duplication, imho. It's lack of tools for review and evaluation of modules publicly, and hopefully the redesign will help that happen. In many cases, the modules we are using today were "duplicates" of modules that already existed. Let's start with CCK and work our way down, shall we?
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
I agree with you completely.
I agree with you completely. When you talk about tools to review and evaluate it is also the problem with the enormous growth in the number of contributed modules. It is simply getting harder and harder to find the right module, or even find an existing module that does what you need. It might very well exist, but you simply don't find it using the existing site search and structure.
After reading this thread and commends I came up with Proposal: Module Relationships which I think could solve a lot of the problems discussed here. If implemented it will both make it easier to find a module with the functionality you need and also quickly review it without having to install and test. If there are any conflicts they will be clearly visible as a relationship and probably also with info on how to fix it.
--
/thomas
T: @tsvenson | S: tsvenson.com
Beat those who want to contribute about the head
I agree with Laura and others that the name of this group is shameful, indeed.
In the open source community, the only duplicates of shame are those that are direct copies of code and functionality. If two applications do similar functions, the response is typically that we now have choice, and that over time, the best application will win. Or not. In fact, people are encouraged to create applications, in order to learn, or to see if they could perhaps do a better job.
You see modules doing the "same" thing, but underneath the code could be quite different, and the future of the applications could eventually devolve. More importantly, "duplicate" module developers may not be aware of an existing module, and are only attempting to share what they've created, not necessarily to "duplicate". What you're doing is basically slapping them with a folded up newspaper, which I'm sure will discourage them from participating in the future.
This post does not demonstrate what I've come to expect from Drupal. I hope it isn't a harbinger of changes in attitude to come.
What about the users?
I keep hearing all this talk about how Drupal needs to be made more usable. And yet you folks are advocating a situation that makes Drupal more UNusable. Are you folks there in the trenches of support listening to the confusion this duplication causes? Do we really need 6 modules for putting "buddies" on your site? We have 4K modules and it's growing every day. Modules come out that do the exact same thing as other modules often because the person didn't even bother to look or simply wanted to do it their way. And now the user has to try and figure out which to use.
Or, if you dont' care about the confused users, what about the maintainers that have to write their integration code for 6 different modules? Or have users get annoyed at them when they decide they will support this one but not that one.
Sure, there are some exceptions. CCK is paraded around as why duplication is good. But I say that's the exception. Most of the time we just get yet another module doing the same thing in a slightly different but not really all that different way. And forums full of users asking "what do I use?"
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Do people at store fall
Do people at store fall apart in confusion and puzzlement when they are faced with ten different brands of coffee? Or are they capable of checking out the packages, the prices, and making a determination?
I think you sell the Drupal users short. If there are six "Buddies" modules, could not the person take a moment to see what each offers, how active support is for each, how many bugs and make a determination? And if people go to the forums and ask which to use, either choose to answer or not. Again, though, an effective search mechanism, and a way to do a "comparison" shop would probably eliminate many of these questions.
Regardless, I would rather six duplicate modules, then discourage a new module developer who may, someday, create a unique Drupal module all of us won't be able to live without.
A good search engine, a way of comparing similar modules side by side (like we can TVs and cars) would eventually help to eliminate duplicates by attrition. But "shaming" module developers? Trying to coerce module developers into being "one" with some other set of developers?
You've forgotten the open source way.
I haven't forgotten anything
I've just spent 4 years trying to help people with Drupal. I guess that doesn't count for anything.
I give up. I don't know why I bother fighting for the users anymore. Obviously I'm the only one that cares about them. So go ahead. Make more confusion. If that's the open source way, so be it. And users will continue to leave because Drupal contrib is a mess of duplicated modules. I'm taking a support break, anyway, so at least I don't have to try and help people through the mess anymore.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
I don't believe I said your
I don't believe I said your support doesn't count, more power to you for helping folks. But if you are fatigued than perhaps a break is good. Helping people should never make one tired.
If people are leaving Drupal because of duplicated modules, then I hope they don't expect to find a home with Wordpress, Joomla, or any other content management systems, because they all have duplicated plug-ins, code, applications that they pick and choose from. The only time you don't have duplication is when the extensibility is rigidly controlled, ala Apple. And even then, there are many duplicate applications on the iPhone.
There are a half dozen Linux installations, a good dozen browsers, multiple database systems, dozens of JavaScipt libraries, toolbar extensions--there's even multiple Twitter like application for people to use now. What you see as chaos, something to "protect" users from, is a natural event in the software application environment--a necessary event with open source.
Eventually, attrition determines "best of breed" when it comes to duplication in an open source environment. The best, the most promoted, the most popular whatever, eventually floats to the top and the also rans either continue their work, for fun or whatever, or they quit.
I would be willing to contribute time to improve module search, to better enable the users to help themselves. But I would never spend time "encouraging" any module developers to quit their work, or to force what should occur naturally.
So, where do we volunteer in order to help design and build a better module search system?
.
I meant "count" in the sense of maybe having a clue what I'm talking about. I don't know about the other CMSs. I've never used them. Perhaps they have a better system in place for choosing. We don't. Supposedly we'll get one some day when this redesign happens but, until we have a newbie usable system to pick which of two identical modules is better, we need to avoid having identical modules. And if that means putting a bit of pressure on people to work together, so be it. I don't agree with outright forcing people to abandon their work and have never suggested that. But encourge? Hell ya. I would much rather see one excellent module than 50 mediocure ones that do the same thing.
UR, FF, and FL are essentially the same. Same features with just a few minor differences. The whole reason for the existance of FL is the person thought his code was better. Most users don't care how pretty the code is. They just want to know what module to use to add friends to their site. This part could be helped somewhat by ratings, though I suspect the ratings will pretty much equal out if there's no gaming.
But the problem goes a lot deeper than survival of the fittest. There are some modules that can handle duplication better than others because they don't interact with any other modules. I picked "buddies" for a reason. They are very interdependent modules. There are a ton of other modules out there that have "buddy" interaction. And lots of duplicated code to make the other modules work with all of them. My module has code to work with UR and code to work with FF and I have a request to make it work with FL that I refused and got grumbled at and then there's also B2 and a few others that I think have finally died off. For every module that needs to do something based on "buddies" the maintainer has to duplicate their work. It's a mess.
So, yeah, I get a bit passionate about this. I love Drupal and this is a real problem area. So people coming along poo-pooing my concern angers me. Documentation, ratings, etc will help but the root of the problem is we have multiple modules that simply don't have enough differences for users to make a choice other than eenie meenie miney mo. And random chance will distribute the users across the modules so that they all just keep going with no clear winner.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Do people at store fall
Not with ten brands of coffee. However, they will confuse if you make them face houndreds of different coffee types from thousands of coffee brands.
Buddy list is not the only function of a SNS site. There are many functions! It means, many similar modules for many functions. Not everybody is a computer nerd with infinite free time who can spend all day in front of a computer to compare similar modules for each function. Drupal must be more userfriendly. Time is money. If I need to check 6 modules for each simple functionality, it is NOT good.
Open source way does not necessarily reinvent the wheel every time. Collaboration is not against open source.
I switched from Wordpress to Drupal around 3 months ago. As a newcomer to Drupal, even though I have experience on Web 2.0, I can definitely say that I am confused with duplicted modules of Drupal! Michelle's user support in the forums helped me a lot, so I am still working on Drupal. Otherwise, probably I would have given up on Drupal. Drupal should care more about the users and new comers.
"Open source way does not
"Open source way does not necessarily reinvent the wheel every time. Collaboration is not against open source"
But collaboration occurs naturally, from within not "encouraged" from without. I'm fairly new to Drupal myself, and have faced a plethora of Drupal modules. What frustrated me is there isn't a better search criteria to discover modules, not necessarily that there's so many. It actually pleased me to see so many modules, because I knew I wouldn't have to develop my own modules for most of my interests.
Now, if there was only some way of knowing which modules have active support, or large numbers of unsolved bugs, or which are popular -- at a glance, without having to manually dig through each. Or some way of seeing which modules need new developers, or a new leader.
If only this data weren't buried, we could try to come up with various solutions to the module problem...without having to get an official okee dokee. Then we might see innovative solutions.
Coffee
Well, to make this scenario more accurate: If you have a blue mug you need coffee X but if you have the red coffee maker you need coffee Y but if you want to use the red coffee maker with the green mug you need coffee Z. And then there's coffee A that doesn't actually work in any coffee maker but will work just fine with the purple mug if you can figure out some way to brew it. Oh and by the way, only some of this is documented. For most combinations you just have to try it and see if it will work. And once you have your perfect coffee setup, you need to hope that that coffee is made in a year and that your coffee maker is upgradable to the new version of water.
Would you give up drinking coffee?
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Everything you're saying is
Everything you're saying is that there needs to be better documentation of the modules, and a way to see this documentation more easily -- including dependencies. The problems you're discussing would happen even if there aren't duplicates, wouldn't they? If there's only one module that does a certain task, but we don't know what it is because it's not documented, and we don't know what its dependent on, or what depends on it, would it matter if anyone came along and duplicated the functionality?
I agree that a better documentation system, and a module search that allows one to search on multiple criteria, including dependencies would really make the whole module system much better. I would think a more comprehensive system would be better than advocating that we break the red and purple mugs.
Kind of late, but...
I'm strange but, I...
Also, we need that image of the scattered lego bricks with an arrow towards an image of a complete legoland structure as our logo. ;-)
number one complaint about drupal.org
The number one complaint about drupal.org http://buytaert.net/drupal-org-wishlist relates to finding modules.
Thanks for reminding us of the big picture, Michelle.
I've also changed the title of the group and did a little mission refactoring. We can certainly have spirited debate about duplicate without giving an immediately negative feeling.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
knaddison blog | Morris Animal Foundation
That's a finding problem, not a development problem
If people are having problems parsing sense out of 4000+ modules, that's a finding problem, and it's my hope that the redesign efforts and incorporation of some functionality from the drupalmodules effort will help that, so that similar modules can be tagged -- not for shaming, but for highlighting alternatives.
In the end, I think that will also help developers, because it will be easier to find similar modules and either patch them to do what they need or borrow from the best ideas and develop something new that perhaps even replaces the existing niche leader. I mentioned CCK before: We can all be thankful for CCK's "duplication" of Flexinode. Or imagecache's "duplication" of image module. Innovation has helped Drupal become what it is now.
And until then, as I said before, the goals of this group I agree with. It was just the name and the ethos behind it, that it is somehow shameful or bad to contribute a module that may overlap existing functionality of another, that I took issue with.
Kudos to the group name change!
Laura (who after posting will be joining this group)
pingVision, LLC (we're hiring)
PINGV | Strategy • Design • Drupal Development
imagecache's "duplication"
It is not the same thing. imagecache module has very different functionalities from image module.
Thank you for making my point! ;)
Laura
pingVision, LLC (we're hiring)
PINGV | Strategy • Design • Drupal Development
I'm a user, and I'm here to
I'm a user, and I'm here to tell you that the solution blessed by virtue of having the greatest number of users is hardly ever what I and my clients need.* So I keep looking, and, fortunately, am often able to find another, less popular module that does in fact do what we need.
The shaming nonsense has got to stop. It's incredibly off-putting.
--
*Most often I find them to be massively over-engineered / over-designed -- e.g., the fetish for turning absolutely everything into a node.
I think you'll find the
I think you'll find the shaming stopped many months ago, and as you can see the name changed - maybe more than a year ago? The current threads in this group are highly useful "compare and contrast" essays.
Richard Sheppard
http://uk.linkedin.com/in/richardsheppard
It stopped in this thread,
It stopped in this thread, but it's still going on out there in the issue queues.
links?
Do you have some links to particular issues where that's the case?
This is a volunteer community full of thoughtful and independent folks. There's not much we can do if some of them are strongly opposed to duplication aside from discussing it on a case by case basis and trying to win them over.
knaddison blog | Morris Animal Foundation
I see them frequently, and if
I see them frequently, and if I go looking, I can find them. Unless you really want me to list a bunch here, I'm not going to do that -- and if the point were to then have people go and shame the shamers (which I would not expect to be your point), I wouldn't do it then, either. But to me, module consolidationism is just one example of pressure to conform, with its implicit claim that the conformist knows what standard we ought to adhere to. In that regard it's of a piece for me with cultural conformity. (Indeed, I'd argue its a great example of cultural conformism in action.)
Make good software
The pressure as I see it is to make good software. A lot of the community, but probably not all, might see that as reducing duplication. IE. Do it once, but do it well. The whole "hall of shame" thing was really just tongue in cheek humour, but it's been dropped from the group name. More often than not, the goal is to encourage module developers to collaborate and create one great module instead of two almost great modules.
You posted here, so that makes you part of the community. If your philosophy is to let a million flowers blossom, then be sure to make your voice heard when discussion comes up on a particular set of modules.
http://cleaver.ca
First, it's great that the
First, it's great that the hall of shame business has been dropped from the name. But there were clearly a bunch of people into that as an approach, and "I was just joking" doesn't really cut it in my book. Sometimes (maybe even often) it's true; but too often, it's just an excuse.
Second, I see precious few cases where effort not expended on module A would actually go toward improving module B. Where it would, consolidation tends to happen. More often than not, though, there are reasons why the authors of a module wouldn't switch their efforts over to apply them to another module. Partial list:
"Let a million flowers bloom" is not how i would phrase it. I would say, let the Bazaar be the Bazaar.
User confusion
Are you volunteering to be the go to person to test all these duplicated modules and do writeups on which to use when? Because that's the real problem here. This isn't about forcing people to conform; it's about making one right solution instead of ten almost right solutions. I've been in this community for 5 years and I still struggle with which module to use in many cases. I can't imagine a new person to this community being faced with 6000+ modules and struggling to figure out which to use amongst many similar modules without any background knowledge of maintainers and such to help.
I'm still very much against duplication with some exceptions. Making a light version makes sense as long as it stays light. There's a clear difference there that can be explained on the project page. But, for example, making a module with the same features as another because you didn't care for the coding style of the original is not good for the end users who don't care about the code as long as it works and is secure.
So, yes, we should continue efforts to encourage people to collaborate rather than making yet another module that does the same thing. Shaming isn't needed but encouragement is. And if they flat out refuse to work together then the burden is on them to explain why their module exists and why users should use it instead of the existing solution, which is often the point of those issues that are filed.
Michelle
I really wouldn't have a
I really wouldn't have a problem if contributors don't want to collaborate. Just the very fact that there is discussion is valuable to me. If I'm scratching my head to decide whether I should go with FlexiWidget vs. Widget Construction Kit, then this group is somewhere I can get info to make my decision.
http://cleaver.ca
Group Homepage
I wonder if it's time to change the layout of the page? We have a lot of wiki/discussion nodes in our node stream. Would it be better to keep an ongoing list of generic use cases -> discussion/wiki pages?
example: slideshow, image display -> wiki topic link
http://drupal.org/node/266179
http://drupal.org/node/266179
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Great.
Let's cross link with a nice key phrase. As a side note I wonder what the analytics for viewing that page are. Seeing it now I know I've been there before. IMO d.o should have something similar, but styled all fancy-like within one click of the front page.
You're right, of course.
You're right, of course. There's always Comparisons of contributed modules then...
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Agree on user confusion
"I've been in this community for 5 years and I still struggle with which module to use in many cases. I can't imagine a new person to this community being faced with 6000+ modules and struggling to figure out which to use amongst many similar modules without any background knowledge of maintainers and such to help."
I agree. It's so hard to find modules you're not already aware of. It was hard enough with the original (and slow) modules page on d.o., and it's harder still with how it is now. Unfortunately the number of awesome people working on the "new d.o." are few in number, and other sites like drupalmodules.com really aren't designed for finding modules.
From a developer standpoint I feel terrible when I commit a new project to CVS and then a month later I find something remarkably similar or similar enough. It really depresses me. I have a module that I haven't started a new project yet because days before someone posted a similar project (and thus found another module!). Even though all of these are architected completely differently, and mine's a bit smaller in scope and usage. I think "shame" is only natural here, and doesn't need to be pushed. A developer is probably already trying to justify their commit anyway.
The best way I found to find modules is to help people translate RFP/site idea into Drupal-speak (shout out to BYS posters). Actually our next local users meeting is about this, mainly from a PM or client POV.
N.B.: What I find amusing is that just 9 months ago that 6000+ was at 4500!
False dichotomies
No, and that's a false dichotomy.
I see that as a contradiction.
To be fair, you add: "...instead of ten almost right solutions." Again, though, that's a false dichotomy. Given the variability of use-cases, it's not likely that you'll ever get one right solution. Instead, what you're liable to get -- and what I see a lot of with the large-scale solutions -- is one solution that's fairly sub-optimal for most things it tries to do, versus a lot of little solutions that are highly optimal for the one use-case they were developed to address. From the perspective of someone who has to maintain the site after I deliver it -- someone I have to train on using it -- a simple, specific solution is generally preferable to a complex, generalized one.
I would much rather have to evaluate several options, than have to struggle through the arcane and iffy configuration of a massive swiss-army-knife/shopsmith module that tries to do too much in the name of consolidation. In my own years of working with Drupal (earliest posts on the one site are dated 2004 so I guess it's about 6), I've had enough of the latter to last a lifetime -- and I anticipate having a lot more.
I wonder if you have some specific examples in mind. I can think of several that would loosely fit that description, and I have to say that in the examples I can think of, I'm extremely glad someone stepped in to do that. I'm thinking of a particular, high-profile project that has many passionate devotees who tend to use it for extremely simple things. It's so complex that I haven't actually been able to get it to work in two whole numbered versions, and since there's no upgrade path from the 5.x versions I have at least one client out there who's stuck on D5 until I can get them to sign up to spend the money it will take me to manually re-implement six complex pages using either the newer version of the same module or (preferably) a simpler module that does most of the same stuff that people actually use it for.
As I've said, I'm very glad that there are two alternatives now to that module that overlap with it quite substantially. Because, you see, I don't trust that module anymore. I don't trust it with my time or my clients' money. And I have to say, a lot of that failure of trust has to do with how I've seen documentation come out of that project (or rather more often, fail to come out of it). And I'm talking about basic stuff like "what does this module do?"
The "paralysis of choice" scenario is clearly one that is problematic for you. It's not that problematic for me by comparison with the problem of not having options. Yes, there is a findability issue; but consolidation efforts will not make that enough better to make much of a difference for findability. What's needed is better findability, which will most likely be a function of getting better meta-data.
.
It's not that big of a problem for me, personally. I'm just looking out for other Drupal users, especially newbies, who struggle with this. I see it all the time there in the trenches of support and I feel bad for them. If duplicate modules benefit your business, that's great. But I'm more worried about other people than what's best for me so I guess we'll just need to agree to disagree.
And, yes, I was referring to a specific module in my comment where the maintainer didn't care about user confusion but only about code perfection and added a new module to an already existing mess which he then abandoned after fracturing the userbase further. His choice causes problems to this day with some modules supporting his module and some supporting the other leading candidate and users wondering what to do.
Michelle
I was thinking of a different
I was thinking of a different module, but to be honest, yes, i've seen what you describe, more than once. I'm sure you've actually seen it more than once, too ;-).
Small consolation, but before I worked with Drupal I worked mostly with PostNuke and Xoops, and what you just described was more like the rule than the exception.
Title is fine
I have no problem with changing the title and giving it a more positive spin. I don't think people necessarily need to be shamed for making duplicates. What I resent is the attitude that duplicates are no problem and that I'm the one with the problem for trying to avoid duplication. I've spent years helping people who are confused and frustrated by modules that seem to do the same thing and they don't have the experience needed to tell them apart. To told I've forgotten how open source works because I am looking out for those people and trying to make their lives easier is a slap in the face.
Documentation is great but we also need to try and prevent dupes from happening to begin with as much as possible. No, it won't be possible or even desireable in all cases but in a great many of them the duplication really isn't beneficial.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
"So people coming along
"So people coming along poo-pooing my concern angers me."
I would never poo-poo your concerns, but I don't agree with the proposed solution. I do think it has the potential to cause harm rather than help.
There's competition for modules, then perhaps what's needed is competition for search. Why must all Drupal stuff live and breath at Drupal.org? If Drupal, the organization, would export metadata about the modules in a REST API, or even a daily data dump, we could derive multiple search engines for the modules, and eventually the best and most popular could, perhaps, become incorporated at Drupal. This would encourage the development of superior module search engines, which eventually should help bring about the events to create the natural attrition that would bring about few duplicate modules. At a minimum, it would help lessen the problems associated with duplicate modules.
Is this data available anywhere? I can't help thinking the Drupal/RDF folks could help with this.
When Drupal.org moves to D7
...maybe then we'll see some interesting uses of RDFa metadata. I would not expect it to happen before then, though, as infrastructure demands on D.o are pretty great as it is, and the redesign efforts for the existing site are well covered in http://groups.drupal.org/drupalorg-redesign-infrastructure-team and http://groups.drupal.org/drupalorg-redesign-implementers. (Am I missing anything?)
edited to add:
Shelley, your knowledge and expertise re RDFa would be extremely helpful and welcome in the D7 development as well perhaps even the redesign.
Laura
pingVision, LLC (we're hiring)
PINGV | Strategy • Design • Drupal Development
Thanks for the links. I
Thanks for the links.
I would be wary of coming in after not really being part of the Drupal inner community, and offering anything. I've never known such actions to work out well in the past.
It would be nice to see all of the Drupal pages annotated with RDFa, but I got the impression that was already underway with the Semantic Web group. I'll check the work out, see if I can drop some delicate feelers that won't get too much pushback.
future is now
You can get a lot of metadata about projects from http://updates.drupal.org/release-history/project-list/all (this page is big...)
You can get specific release information about a project from http://updates.drupal.org/release-history/drupal/6.x
You can help get even more data exposed by helping this patch get reviewed/committed: http://drupal.org/node/363466
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
knaddison blog | Morris Animal Foundation
Thanks for the links to the
Thanks for the links to the data. I was not aware of update....
I'll look at that patch, see if I can figure out what it's all about.
I am busy working on this stuff.
http://groups.drupal.org/node/21295
I am building a Drupal Ports system, kind of like the freebsd ports system and gentoo's portage.
It's basically an easily mirrorable directory tree of meta-information, with a lot of the extra info gleaned from the packages themselves. (ie: package x provides module-x_y and module-x_z).
It will also be able to handle adding your own sources, so you could produce a data source from your own svn / git / whatever repository, and just add it as one of the sources.
Keep in mind, this is for the command line, but it should be possible (and a lot slower, with all the network overhead) to build a Rest API for this stuff.
Re: the duplicate module situation
We could use the idea of meta-packages. a simple extra keyword in the module info file could be used.
ie: provides: somecommonfeature
lighten up!
Sorry to drop in without having read the whole thread; I expect what I have to say has already been said. Perhaps someone can start a "Duplicate Comments Hall of Shame."
But as someone who's written actual and alleged duplicate modules, I always thought the group name was tongue-in-cheek and never took offence. The whiners need to go have some milk and cookies and lighten up, although I do tend to side with the crowd that's in favor of letting natural selection run it's course. There are lots of good reasons to re-write code, and there are no good reasons to hinder the sharing of that code. But we absolutely do need a rankings/metrics system for helping non-technical users find the best choices for them more easily.
Best,
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Whining? Well, someone likes
Whining?
Well, someone likes to kill a discussion quick, don't they? Especially since everything you mentioned was already mentioned by the "whiners".
Perhaps next time, you might want to actually read the comments, first.
...
I think this is the sentence you should pay attention to. In particular the "although" part which modifies the whining comment.
No need to get offended if you did imo.
yeah, like that.
It's run it's course; I was just trying to put it out of it's misery with some dignity.
Perhaps next time, you might want to actually read the title to my comments, first.
:-)
Peace,
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Seriously
How do you expect to bring people together to accomplish something by first making negative comments about them by putting them into a Hall of Shame.
This is more likely to piss people off than to bring them together.
If you think this is just 'tongue-in-cheek' then you need to have some look at behavior theory. Take a look at the book Predictably Irrational to find out why people do things for no pay, it's called a 'social contract'. Pissing people off breaks the social contract and makes them not want to do anything.
Drupal evangelist.
www.CoderintheRye.com
Seriously
Lighten up on contrary opinions already. There are some of us who have written modules, and
That doesn't sound like breaking the social contract does it? In fact, a spicy name draws in other viewers who wouldn't have joined the group otherwise, and that helps them learn more. The group aims to collect level-headed developers and contributors who are more likely to work together than hot-headed would ever be.
It's a moot point now that the name has already been changed sadly.
Saving Barnes & Noble one satisfied customer at a time!
Can you recommend a book that can explain to me how exactly it is that a human being can get a lamp post stuck up their butt and completely lose their sense of humor? That's some behaviour that needs a theory!
PS - I realize that English is not the first language of many in the Drupal community, and that humor can be difficult to translate. To those who misunderstand me due to this, I can only ask forgiveness. To those who really just don't get it, we can talk about it over beers when you come through Los Angeles. A little Heineken will cheer up that frowny face!
Best,
Matt
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Sandbox fight...
OK, your bucket is bigger than mine, but my shovel fills mine quicker....
Give it a rest folks!!!
--
/thomas
T: @tsvenson | S: tsvenson.com
A Suggestion from a New User
I stumbled across this group as a result of Matthew Saunders post in the hope that it would help me find the 'right' modules!
I'd like to make a series of suggestions that may help people find what they are looking for more easily - as users and programmers.
ONE
As I understand that Dries and the D7 team are redesigning the menu bar perhaps the projects block on D.o could be aligned with these 5 categories as the top level of a hierarchy, grouping together the categories that are already listed there under that.
TWO
At the same time take those second level categories and run them by a few different groups of people: newbies, site developers, coders and see if they are intuitive to each. If so, keep them as they are, if not propose a new category name or division of contents etc. (As a new user they don't instantly tell me where I am going to find something).
THREE
Then ask for volunteers to take one second level category and come up with an amended set of tags for that group that would further detail the various types of module functions within each group accurately. [I am not sure who has the 'authority' to tag things on this site, but perhaps these volunteers could be granted permissions for the term of the project.]
FOUR
Then if it is at all possible, create a 'View' of each of these third level tagged (sub)groups as a list or teaser and publish them back over here. This is where further comparison, discussion and negotiation as I believe you have created this group for, would come into its own. You wouldn't be re-inventing the wheel and would be achieving something on D.o at the same time.
By at least doing steps ONE and TWO (possibly after code freeze), it will enhance the user experience on D.o whether or not the user is working with D7 or D6.
By moving on to THREE and FOUR after that it may stimulate co-operation between module owners and get them to reconsider joining forces in light of the D7 release in the new year. (I like the initiative seen on some modules already pledging they will have a D7 release).
I hope this is helpful, and if so, gets picked up by the right person/ people.
I am willing to put my hand up for TWO; and THREE of say, the 'Mail' category.
---
I am not 100% pro duplicated modules, but I also think that not having duplicates at all is not good.
Imagine for a moment a module that contains incorrect code, or that could be optimized; if duplicates modules would not be allowed, you could just open a bug report for the existing module, hoping that the code is changed. What happen if the module would not be changed to fix the bug? We would have a module that is not working, or not working in all situations.
It seems that avoiding duplicates takes to a situation where the first person who creates a module blocks the development of a project with the same purpose (or similar purpose). I don't think that is a good thing, but I don't think we should allow modules that differ for details.
To report the actual situation, I have seen a module that was created from an existing module being accepted.
prohibition techniques will
prohibition techniques will never work.
that violates the very principle of freedom, something the guys at SimpleMachinesForum didn't understood.
collaboration is great but isn't applicable or practical in EVERY case.
sometimes the development just has to reboot or take a new approach/methodology under a new name.
what needs to be done is continuing with the sensibilization efforts, contacting project owners and point them similar projects, ensuring that some do get merged and collaboration efforts are achieved, and providing the community accurate comparisons and recommendations, as it has been done so far, but more broadly and consistently.
btw, i joined the group and contributed some comparisons ;)
Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org
btw, i joined the group and
No kidding!
It's the LPCA-group here, today, or so it seems.
Your over abundance of posts have led to the creation of a filter on my mail so I don't have to see yet another.
FYI
sorry! i already had much of
sorry!
i already had much of the info compiled around so i gathered it all and just dumped it, post after post.
so i think i will not contrib that much as fast now, unless i get another surge of ideas ^^
Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org
Thanks
Thanks for your efforts. I don't know if the other poster meant it as harsh as it came out but I, for one, appreciate you taking the time to do that. I don't agree with the philosophy but I'm all for documentation. :)
Michelle
posting changed pages
posting changed pages here...
edited this post - Comparison of Layout editors
and edited this post as well - Comparison of Toolbar/Top/Administration Menus
another one - Comparison of Social Network connectors/Sharing modules
Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org
philbar and i are submitting
philbar and i are submitting ideas to the Drupal Infrastructure, to try to solve the Similar Module Review challenges
we're also dealing with upgrade paths between drupal versions.
the issue we created is here
Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org
take a look into this issue
take a look into this issue ;)
#328932 Modules and partial dependencies - "Enhanced by" field in modules .info file
Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org
The case of WYSIWYG modules
I asked the same thing for WYSIWYG modules (especially WYSIWYG.module vs CKEditor): http://drupal.org/node/606404#comment-3867974