Projects with no code

A) As I understand it, this "policy" has not just been Gerhard's personal crusade, but something Dries has supported as well. One of his frequently stated strengths of Drupal is the centralized repository for external contributions and the vibrant developer/contributor community. That said, we *could* have a central repository of projects even if the code didn't all live here.

B) One of the reasons people might oppose #3 has been "but what about update status?". While I'll grant that the following isn't easy, if someone had a compelling reason to host externally and still wanted update_status to work, they could:

• See Setting up a site to serve release history files used by the "Update status" module. You don't need to run project* at all, so long as you create the appropriate XML files.
• In the .info file(s) for your module (and/or in D6, theme), make sure you define:
  

  project status url = http://example.com/path/to/release-history
  project = unique_project_short_name
  version = 6.x-1.3
  datestamp = 1222517656
  

If you do that, update_status works great. Of course, you get all of this for free on d.o. Probably folks hosting externally aren't going to go through this trouble, so yeah, update_status isn't really going to work by default for case (3) in catch's original list. However, there's nothing hard-coded in update_status that *requires* the d.o infrastructure, so that's not really a valid reason to oppose externally hosted projects on its own.

C) If there are no release nodes for a project, it doesn't show up in the project browsing pages. So, if you just have a project page with a title, description, and issue queue, it doesn't help you *that* much to advertise the existence of your project. It might turn up in the "Search downloads" block, and someone might stumble upon it via other means, but folks aren't necessarily going to find it.

D) I'm afraid of allowing people to upload arbitrary .tar.gz or .zip files and attaching them to release nodes on d.o. *That* becomes a very nasty thing for the security team to try to keep track of. It's bad enough trying to grep the contrib CVS repo, but there's basically no way we could have any hope of preventing unsavory or malicious things from getting attached to release nodes. :(

Overall, I'm on the fence about this issue, too.

Nothing actually stops you from writing your own code and hosting it elsewhere. That d.o doesn't go out of the way to help people find your code if you don't want to use d.o seems pretty reasonable. I'm not sure I buy the "choking off the drupal ecosystem" argument. If it weren't for front page posts about it, no one would necessarily find Acquia Drupal on d.o, either, but that doesn't mean we're "choking off" Acquia's ability to host their own code.

OTOH, I'll admit that CVS is something of a barrier to contribute, and I wouldn't want only companies with lots of resources to be able to have a viable chance to host stuff externally that people still find out about and use.

So, at this point, I'm +0 to continuing to enforce this policy, but I'm totally available to help answer the technical questions that might inform this discussion and sway people one way or another.

Cheers,
-Derek

Closing old issues. Marking this as closed as it appears to have been addressed over the last few years, even if we're revising this whole topic again. Please re-open if needed.