Closed (fixed)
Project:
Drupal.org site moderators
Component:
Policy
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
1 Dec 2022 at 15:59 UTC
Updated:
22 Dec 2024 at 08:39 UTC
Jump to comment: Most recent
There is a growing trend lately where projects are being posted to drupal.org with very similar titles and project namespaces.
Here is a recent example:
https://www.drupal.org/project/projects_browser
This is not the "Project Browser" module and initiative which is happening here: https://www.drupal.org/project/project_browser - but someone recently reported in Slack they had mistakenly downloaded Projects Browser.
The first module has an 's' added at the end. I have seen this on a handful of other modules, where either its made plural or singular, depending on the original project name.
This is confusing to end users. Non technical people may often not know the difference, a simple typo with Composer can have you downloading the wrong module while thinking you have the correct one. In the cases where people are copying modules and making minor trivial changes (I.e. Menus Attributes) this potentially breaks any upgrade path from previous versions of Drupal instead of being made to merge the effort with the original project.
Here are a few other cases where I have noticed this that I can recall off the top of my head:
- https://www.drupal.org/project/filename_transliteration/issues/3216907
- https://www.drupal.org/project/menus_attribute was copied more or less directly from https://www.drupal.org/project/menu_attributes
There are likely others...
Is there a way to 'detect' this kind of behavior? In this very specific case (Project Browser), this only seems like it could get more confusing for users when results contain items of the same name, with the same description, etc.
Comments
Comment #2
fjgarlin commentedCreated #3324851: Confusion with initiative module Project Browser in the "Project*s* Browser" module to see if the maintainer is willing to change things up.
Comment #3
cmlaraI'll note that projects machine names CAN NOT be renamed on D.O. as it will break deployments.
Looking towards giving benefit of the doubt on the projects listed here:
Looking at projects_browser I could see an argument made that its a fill in for the D7 project_browser module which at the time did not have an equivalent D8 release and had announced it would be a massive overhaul for D8 to be used by the SI. It was a year later that project_browser initiative released an Alpha version, arguably the module could have possibly filled a role in that time (wether it did or not is a different discussion.) In this case there was no project to 'join force' with as the old D7 project had basically been taken over and marked as not to be continued for D8.
menus_attribute appears to be similar, on quick glance it appears to provides D8/9 support for menu_attributes features. menu_attributes has had a D8 issue open for 9 years #2174435: Port Menu attributes to Drupal 8. One could argue that joining forces is better and keep it under the same name, I have not checked the history to see if any attempts to do this were made. If what they have created is good menu_attributes could pull the code into their dev line and benefit from the side project, if code is not useful for menu_attributes purpose than developers would consider sticking with them and helping push their D9 issue along.
filename_transliteration from its own posts appear to acknowledge similarity and point out differences. Again transliterate_filename could pull in the code from filename_transliteration at any time if they so desired. The author agreed to mark their module deprecated if transliterate_filename adopted the differences. Those differences may be relevant now as multibyte overloading has removed in PHP8, https://www.php.net/manual/en/mbstring.configuration.php#ini.mbstring.fu.... Code that has worked in the past may not work on PHP8.
Much of this looks to be open source doing what it does, filling niches and allowing choices. Perhaps this points more to an issue in how D.O. project searches are laid out, needing to choose similar names to be relevant, and few projects with unique branding (without counting I believe it is fair to say the majority of modules are named after their function rather than a branded project)
What I'm personally much more concerned about is if any of these projects are indeed based off the previous project and they did not retain the commit history or at least document copyright information, that would be an LWG issue not a moderators issue however. I'll note that D.O. is especially bad for GPL compliance as it in ways pushes against the GPL's recognition of the individual as much of the process is geared to the projects being community assets.
Comment #4
avpadernoWe are already asking to list similar projects that already exist, even in the case the similarity is in the project name, or in the project purpose.
The only way to detect such cases would be in a submission handler for the form to create new projects, but I am not sure it would worth implementing it. There are surely cases where similar project names or project machine names are legitimate.
For example, the Imagick module and the ImageMagick module both implement an image toolkit, both based on the ImageMagick library, although the latter module could also use the GraphicsMagick library. The difference is that the first module uses a PHP extension, while the latter uses a CLI executable. I take this as example because I always picked up the wrong one: I went to the ImageMagick project page when I wanted to download and use the Imagick module. That would not be a reason for asking to one of the projects to change name, though. Any other name for those projects would be more confusing than their actual, similar, names.
Comment #5
avpadernoI am closing this issue, since it is a support request which got answered.