Open Letter
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!
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
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
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
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.
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
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)
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)
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)
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
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
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
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.
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
Sandbox fight...
OK, your bucket is bigger than mine, but my shovel fills mine quicker....
Give it a rest folks!!!
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.
-- Kiam
Kiam la luno renkontas la sunon