Policy for empty module projects (namespace squatting)

I've been following this and have to respectfully disagree with #19. I don't believe that a corporation or private entity should be able to dictate what namespaces are and aren't available on Drupal.org.

By allowing private entities to sit on empty projects due to naming internal projects generically prevents open source contributors from creating projects that either have similar functionality or the same name with different functionality. For example, if I have a client and I build a module for migrating content from a geographical database into a content type and I want to name it "Geography," I shouldn't expect that I can create an empty project on d.o to make sure that my poorly named custom module will not have any namespace collision with another contributed module. For what it's worth, I try to name any custom module for a client with an identifier to prevent this exact scenario.

And in the spirit of open source, if it's something that can be contributed, it should be contributed.

In some ways an empty project is more useful than no project, if the Module repository doesn't let administrators see all the modules that exist it could always lead to the community adopting another source to obtain modules.

I think that one of the big draws to Drupal is that contrib modules are free and found in one place, unlike some of the other CMS offerings where plugins or extensions can be pricey and code can be closed source. I highly doubt that telling users that they cannot sit on an empty repo for an extended period of time is going to cause a mass exodus of people using d.o for finding modules.

I am not sure I follow #19. Composer allows you to specify a repository for specific packages and also the capability to exclude a package from a repository so you can exclude an internal drupal/foo project from the packages.drupal.org repo and supply your own and so it shouldn't be necessary to register the namespace just for this problem.

And in the spirit of open source, if it's something that can be contributed, it should be contributed.

I think that one of the big draws to Drupal is that contrib modules are free and found in one place,

That was the bigger point I was trying to make in #19 (which ended up lost in the mud of the other side issues), not even all open source code can be listed on Drupal.org due to current policies, and because of that currently D.O. is not/can not be the one place to find modules unless empty projects were to be permitted. Though as I write that I I realize other FOSS licenses software (like GPLv3+) could do the same thing that commercial modules could do to be listed, write a shim module to be committed as GPLv2 and keep the majority of the code in a different repository.

I am not sure I follow #19. Composer allows you to specify a repository for specific packages and also the capability to exclude a package from a repository so you can exclude an internal drupal/foo project from the packages.drupal.org repo and supply your own and so it shouldn't be necessary to register the namespace just for this problem.

Personally I agree with you, long term that area shouldn't be what allows holding namespace. I was more placing it in so we acknowledge why its been done in the past. If every company did have an empty project for their 'name space' it would be a mess of a listing.

I do agree with @apaderno that the question of an 'unmaintained' module or a module with obsolete versions is a different one from a truly empty module.

I think we're all in reasonable agreement about what to do for a truly empty module.

I think we can continue the discussion about 'unmaintained' or otherwise obsolete cases either in this thread or another.

But in the meantime, I've gone ahead and updated the policy page for the empty module use case specifically:

https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →

I am OK with the proposed text.

The third bullet point under "Some examples of 'good faith' efforts include:" looks like a fragement, re:

• "If the existing maintain"

Fixed the sentence fragment. Thank you! And thank you for the initial proposed text. I definitely think it's still highly relevant to the issue of an 'abandoned' or 'obsolete' project with an old branch. Worth figuring that out as well.