Policy for empty projects

+1 on this addition.

I also +1 this. Thank you for putting this together.

+1 with the recommendation we define "obsolete" to avoid future debate.

Unsupported projects and projects without branches for any supported Drupal version aren't empty projects. Namespace squatting is about projects without commits.

The proposed change should focus only on empty projects, for which no commit has been done; it should not become a site moderators can change project owner at their discretion policy.

If a user wants to become project owner, maintainer, or co-maintainer of a project that doesn't have branches for supported Drupal versions, the procedure to follow is already described in the actual documentation. Any exceptions to that procedure should be defined case by case, as in the case of the automatically created issues like #3234962: owlcarousel2 project open to new maintainer applications on 30 Sep, 2021.

@apaderno - so what are you suggesting? Are you suggesting that we don't need the new proposed text? Or that we should clarify/expand the Namespace Squatting section?

-mike

@ultimike The text should say Projects without commits in the last X months (where X is a value we choose) instead of Projects that are marked as "Unsupported", and projects with no branch for any supported version of Drupal.

This issue is about avoiding namespace squatting, which doesn't forbid to have a Drupal 6 module that is then ported to Drupal 11, for example. That means it should not be automatic, to give the project to another user, in such cases.

I know a user who wanted to port a Drupal 7 module to Drupal 8, but then decided to port it to Drupal 9 to avoid handling deprecated methods/functions, and then choose to port it to Drupal 10. I hope we aren't going to tell him he is squatting a namespace.

The used sentence is saying:

• Projects that are marked as "Unsupported" can be transferred to a new owner at the discretion of the site moderators
• Projects with no branch for at least one supported version of Drupal can be transferred to a new owner at the discretion of the site moderators

That is not describing empty projects, which are projects without commits. Please, let not muddy the waters.

Those projects are already handled by the current procedure, which is not site moderators will transfer the project to a new owner at their discretion.

Also, the title says this issue is about empty module projects, which means that distribution projects and theme projects are excluded. I don't see any reason to exclude those.

The way empty projects are handled by the existing procedure is that the namespace is not transferred if the owner of the unused namespace objects to the transfer.

That does not change the fact that empty projects are not projects marked Unsupported or projects with no branch for at least one supported version of Drupal.

If the target is empty projects, then the text must be changed accordingly, including specifying which empty projects are interested.
It should also say what users should do when they want to take over a project without commits (which essentially is to use the namespace or implement the original idea described in the project page, but that does not make difference) and which should still contain instructions to post an issue in the project queue. It should also say which replies from the project owner are accepted, what the project owner is supposed to do basing on that reply, and what site moderators will do basing on that reply.

Personally, I don't think that I am protecting on drupal.org a namespace I am using for a custom project users can download from another server. is a valid reason for not transferring an empty project created on drupal.org, but I also do not like a site moderators will transfer the project to a new owner at their discretion blanket for every empty projects.

Also, part for the text shown in the issue summary is about obsolete projects, which again are not only projects without commits.
Users could have created a Drupal 5 project that is not anymore necessary in Drupal 6 or 7 because similar code is part of Drupal core; users could have created a project for code that at the end they could not or did not want to publish on drupal.org. Those are obsolete projects.

Empty projects and obsolete projects should be kept separated.

Since we are talking about the policy for empty modules.

While I know the current policy is that maintain a repository without any code is not permitted I know I've seen at least one module where there was an adoption attempt and the maintainer refused because the was used internally/distributed to a group of organizations for internal use. If I recall correctly they were concerned a new module taking that space could pose issues if adopted.

In DrupalKernel::getModuleNamespacesPsr4() we force modules to use the Drupal namespace.

  protected function getModuleNamespacesPsr4($module_file_names) {
    $namespaces = [];
    foreach ($module_file_names as $module => $filename) {
      $namespaces["Drupal\\$module"] = dirname($filename) . '/src';
    }
    return $namespaces;
  }

This means module owners can not use my_org\my_module to create internal modules.

The Drupal\my_internal_module namespace poses a risk of a supply chain attack vector if left unregistered.

There is always the risk that the new project may be useful but can not be adopted because it collides with internal names.

The above two issues can be solved by removing the mandatory Drupal namespace, which is out of scope for this issue, but its worth in my mind keeping that in mind for how we treat 'name squatting'

Ignoring the 'internal use only' modules and addressing scenarios that impact D.O more directly, I think its worth talking about those who either don't want to or can't host their primary development and distribution on D.O. for various reasons. A random example may be that their code must be GPLv3+ which is fully compatible with Drupal's license but violates the D.O. GIT policy. These modules may be targeted and removed for 'spamming/advertising' or 'name squatting'

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.

While not transferring an empty project namespace may be considered fragmenting the community, not allowing the reservation of namespaces is in my opinion also fragments the community.

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...

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.

I am closing this issue, since the documentation has been already changed, and no changes have been proposed in the past two years.