Add "Ensure your module is not a duplicate" back to security advisory coverage application checklist

I tend to agree, because I consider it one of the strengths of the Drupal community that we gather behind one project instead of competing with many projects. That said...
- Can you provide an example where the absence of the requirement has caused problems?
- Do you think the requirement should be enforced, and if so, how and by whom?
- Could there be downsides to re-introducing this requirement?

I also agree that there should be some sort of duplication check in the application process.

However, a partial or (in some cases) even complete duplication of functionality should not be a strict "no"...

Imho, it should be required for the applicant to first contact the duplicated module's author(s) and try to find an agreement and possible grounds for collaboration. If this is not possible (for whatever reason), it should still be allowed for the applicant to go ahead with their duplicated module IF they can proof that it provides benefits over the other module (or simply architectural differences that justify the duplication).

In case of a duplicated module getting accepted, I think the claims on the module description of the new module should be vetted. In the referenced issue, the author of the duplicated module that was submitted for approval didn't understand or neglected the very valid reason and justification for AJAXifying in the original module. They then assumed superiority of their module because of the lack thereof (and other objectively invalid reasons). Checking false claims like this should be part of the "duplication validation" process.

I also think it's a big strength of Drupals community to work together on solutions instead of everybody building their own stuff... Maybe a new duplicate module should always show a disclaimer of the alternative modules, the differences and a technical explanation why the new module was built.

Or maybe the developers of the older modules should be asked for any veto?

For the record, I was worried that crafter might have forked user_online_status without providing proper attribution. I compared the initial commit of user_status_online to the at that time latest revision of user_online_status, and I'm happy to report that, while user_online_status may have served as inspiration (indicated by a few shared trivial lines of code), the bulk of the module appears to be original work.

So while they might share the same purpose, user_status_online appears to be functionally different enough to not be called a "duplicate". To quote the mentioned passage that was removed from the checklist:

If the differences between your modules are not too fundamental for patching an existing one

I'd argue that in this case the differences are, in fact, too fundamental.

... to add some criticism: I know naming is hard, but taking an existing project title and just flipping two words should be a no-go, as this sort of duplication makes it hard to discuss either module without the risk of confusing one for the other.

I agree that some sort of duplication check should be reinstated in the security advisory coverage application checklist.

My opinions about this are pretty much the same as those expressed by fubhy in comment #5 above.

I.e. duplication should never block an application (and there certainly should be no "veto"-option offered to the developer of the older modules as suggested by k4v in comment #7).

However, a simple requirement for the applicant to contact the possibly duplicated module's authors and try to find possible grounds for collaboration should be on the checklist. If this does not pan out for whatever reason, the application shall be allowed to move forwards.

Also, there should be a requirement to acknowledge the older module on the application's project page if some functionality is duplicated. This attribution is just common courtesy and will also assist site builders to decide what project to use when more there one exist that offer specific functionality. This description must be factual and must not contain language that may disparage the older module or its creators.

I don't think introducing a requirement to try to contact and to document the existence of a possibly functional overlap will impose a too big a burden on applicants or volunteer reviewers. I will certainly be incentivised to participate as a reviewer if community norms beyond security are on the checklist for the review process.

Rather than "Ensure your module is not a duplicate", I think we should the softer language for the title of this section – for example: "Check if your module may be a duplicate".

I think chances are low that someone writes some hundred lines of code that just happen to be identical to some existing module. Let's assume that the contributor knows that it's a fork.

"Ensure your module is not a duplicate" is okay to emphasize that this is not the expected way for contributions. As long as the rules are explained in a nice way somewhere (we don't want to confuse/overwhelm users looking for a solution, we want to encourage collaboration/co-maintenance, ...)

As a frequent evaluator, I like the concept of explaining the differences with similar modules - thus I like the idea of making it a requirement for forks.

I'm in agreement on bringing this back as a required step of the process - we shouldn't encourage people to create duplicate modules just so they can pass the process.

If duplicating a module means cloning a project, and then slightly change its code, that should not be acceptable. If a user would do that, and nobody noticed the project was taking all the code from another project to just change the machine name where that is used (for example, the name of hook implementations) before the application gets approved, the given role should be removed.

If duplicating a module means creating a project that has the same purpose of an existing project, but it uses completely different code, I am not sure there is anything we can do.

This thread is about the security review process. There used to be a recital in the checklist that said: "Ensure your module is not a duplicate", with an explanatory text about our community preferring collaboration rather than competition. The ethos about duplicated projects on Drupal.org is this:

While not outright forbidden, duplicate projects are generally discouraged without good reason (such as a fundamentally different architectural approach).

kiamlaluno wrote:

I am not sure there is anything we can do.

Well, one thing that we can do is stated title of this issue. It says: 'Add "Ensure your module is not a duplicate" back to security advisory coverage application checklist'.

As I've already stated: I am strongly in favour of doing this, but with a bit softer language, such as ""Check if your module may be a duplicate" (i.e. not "ensure", as this suggest that duplicates are banned – and they're not, as is clear from the ethos quoted above).

Duplicate has a specific meaning. If the reason for not accepting an application is just that a project is "duplicating" the purpose or the idea behind another project, I don't see what should be done, given that the application's purpose is reviewing the code, not the idea behind the project, or its purpose.

Following the concept of duplicating the purpose, we should not have Drush and Drupal Console, then. Does that mean a user cannot "duplicate" another project when applying but can duplicate any project once obtained the vetted role?

In the original issue summary, there was a reference to "community standards" and then goes on to say: "No project duplication is one of them."

I think this sentence was unfortunate. The devil is in the details, and "No project duplication" has, AFIK, never been one of our community standards. The "community standard" in this area can be found here, and state that duplication should be "discouraged", but doesn't impose any actual restrictions.

I've linked to that page, and copypasted a quote into the issue summary to make it obvious what existing community standards are. I think this is what the OP originally wanted. I.e. to use the security advisory coverage application process to make applicants familiar with exisiting community standards – and hope this discussion hereafter can be about whether making applicants familiar with community standards should be re-introduced into the security advisory coverage process – and not on wheter we shall ban duplication (which I think never has been an issue).

kiamlaluno wrote:

I don't see what should be done, given that the application's purpose is reviewing the code, not the idea behind the project, or its purpose.

If that is given, I agree.

What is proposed here is that the application's purpose is reviewing the code and also make the applicant aware of certain community standards, such as licensing, attribution and collaboration.

If you I understand you correctly, you don't care about the "also" part, and that's OK. I care a lot about it, tho' – and that is why I want to see this implemented.

kiamlaluno wrote:

Does that mean a user cannot "duplicate" another project when applying but can duplicate any project once obtained the vetted role?

No, he/she can. And yes, he/she can.

If the proposal is implemented, applicants will be required to check for possible duplicates and kindly asked to consider collaboration if candidates exists. They can, if they wish, go ahead and duplicate another project if they wish – I just want them to be aware of the consideration.

This, of course, does not change after they gotten the role. I still would expect responsible maintainers to first try out if collaboration is possible before duplicating the functionality of an already existing module, and I think that it would help if they learn from working their way through the security advisory review checklist that this is the way be prefer to do things here.

Tips for ensuring a smooth review already has a Search for similar project and explain how yours is different point.

This demonstrates that you have taken the time to look for existing solutions, and you are aware of the Drupal's collaboration over competition ethos.
If you do find existing projects which are similar or related to the functionality of your project (even if only in name), expect reviewers to suggest providing your project as a feature or patch to the existing project. Be sure you've read the information given in that link and include your reasoning for the new project approach in your application.

That is not a requirement for the application to be accepted, though. It is one of the points to ensure a smooth review.