Let me start by saying that I've just fallen foul of the duplication issue in my current project review, this isn't intended as an appeal but rather a request to understand the issue more widely.
I'll explain how I duplicated and why so you can understand where I'm coming from, and then phrase a couple of questions that I have that hopefully will clear a few things I'm not quite grok'in.
The Dupe
I submitted a theme for review with a feature included that allowed a header image to be uploaded from the theme settings. I was searching D.O. for a solution to uploading in this way when I found the Noggin module.. which did the trick nicely. However, I wanted the functionality to be within the theme rather than in a module, as to a "user" this would make most sense (from a UX perspective). Plus the intention was to extend it to include other images than just the header.
So taking a bit of time, I reused the modules code to add the functionality to the theme, at the time I was aware of module duplication being bad but did not deem this to be a duplicate of a module, as it was a theme. No way along the process did I claim or give the assumption that the code or functionality was radically different from the Noggin module.. so yes, the code was duplicated. Another interesting point here is that the Noggin module was originally code for Bartik, but it was too late to make it in (ergo, was originally intended to be in a theme.)
The Issue
Now this is where I get a bit foggy in my understanding about duplication within Drupal. [opinion on] I can see that straight module to module duplication will just lead to an over-crowded mass of half used modules, but reuse of code for another purpose or setting would seem to be acceptable due to everything being GPL'd.[opinion off]
That opinion, would seem sensible to me, but doesn't seem to be what's happening with Drupal.
The Questions
1) Are modules and themes treated as the same?
Themes are intended for "presentational" purposes, modules to extend functionality. However, is there a line that says xxx functionality can only be in a module if a module (of that nature) is in existence.
2) How is the line drawn between code duplication and reusing code?
I'm not an advocate of a "one way" to do things, but also think it's important that the wheel shouldn't need to be reinvented everytime someone wants to include a feature.
3) If duplication is generally bad, how can there be a snippets area within the docs?
It seems a bit contradictory to encourage users (new and old) to share, contribute and collaborate, but then throw in a caveat that their end result should not be published as it's a duplicate. Or even "thanks for all your work, however x module does that bit, so submit a patch over there". (note: i do see the benefit of supporting current modules and collab being a good thing for the ecosystem).
Thanks anyone who has the time to let me know their thoughts on any of this
Comments
What Is Duplication?
Cross posted from another discussion.
In this case, I agree with the decision that was made by the reviewers, but not necessarily for the reasons given.There are three issues here.
Another case of duplication
I reviewed a project in which 95% of the code was a direct copy of the cck text module. The author tried to use his own data storage, and when he had a problem with it, he filed an issue against cck. There is almost the same set of issues here:
Thanks for your input
Thanks for your input ccardea.
I would completely agree with your example about the cck text module duplicate, however I believe my case differs for the following reasons:
1) the inclusion was indeed duplication of functionality, the decision on my part was if the functionality would be classed as a theme function or suited to a module function. Looking at other themes with this functionality, and that it is directly related to a design challenge, I deemed this to be more suited to the theme over a module. In my opinion themes and modules should be considered with different scrutiny, for these reasons.
2) The Noggin module appeared to be unmaintained and unpolished. At the time of creating my theme the state was Noggin was "seeking co-maintainers" and had a development status of "unknown". This is still the current position. There has been no changes or commits since the module was created, patches are available but unused, someone had requested co-maintainership in early april and this still goes unanswered. And although I really like and appreciate the code, the issue queue looks like deadwood with no input from the maintainer.
3) To make this functionality work in a theme as opposed to a module requires some knowledge of the differences between modules/themes, the code as is could not just be copied and pasted to work. This aside, it was by belief that best practice within open source projects was not to "reinvent the wheel" every time something is needed, rather to utilise the good work of others where this provides additional benefits (ie. ease for the end user).
I've just spotted jthorson's post on the other thread and would particularly agree with the following points.
Taken from jthorson's post @ http://groups.drupal.org/node/149959
Our effort to 'simplify things' for the end users means that instead of simply installing the theme, they now have to install a theme AND A MODULE? How is this possibly better for the end user?
Proposed Solutions:
My thought on this one is that, when you consider it from the end user's perspective, the duplication does provide value and should therefore be allowed, on two conditions:
1) The functionality in question is definitively 'theme' related
Dreamleaf Media
good question.
A good question; one that will always be somewhat subjective.
As far as difference between Themes and Modules. Code duplication applies to both. As far as what should be in a Theme or a Module: a theme is almost entirely for changing the output that Drupal provides by default, and possibly providing some options and logic behind that. It's a fuzzy line and will always be, but overall, if it can live in a module, then it probably is a good idea, as it will then it could apply to all sites, instead of just sites that want to use that theme.
So, about code duplication. Think of the Drupal contributed space as a single project. On any code project, a good coder would not duplicate code and abstract things that would be duplicate. This is the same principle with the contributed (and core) space. Of course, once you put in the social/community layer it gets pretty fuzzy. So, the questions are more about what is the status of a contributed module and if/when patches can be applied.
For instance, if the Noggin module is not maintained or you had attempted to provide a patch or you attempted to be a co-maintainer and it fell on deaf ears, that is your argument for duplicating that code in your module or theme. (maybe you did all these things, don't have full context here). Pointing to specific, existing issues is key here.
Finally, on the issue of installing 1 (or 2 or 3) modules as being a problem for the end user, this is very much an issue with dependencies and module installation, and not an argument for or against code duplication.
--
zzolo