Setting up an open source project.
SwellJoe: We've got a couple of projects at SourceForge.net, and I have to agree with everyone else.  It is slow, and it's interface has always been pretty clunky--dealing with tickets and the forums is pretty horrible.  I wouldn't use it today.For our newer stuff, we handle it internally...but we have a slightly odd situation of having a commercial branch and a GPL branch, and the commercial branch is private.  Open Source hosting places don't make that easy.If I were starting a new project today, I'd try both github and Google Code and see which one I liked better, and then I'd go with it.  git is really cool for highly distributed projects, but unnecessary for most projects with only a few developers--there are still some benefits, but if the Google Code tools work better for you, then the revision control choice probably doesn't matter enough to make a difference.For one company I worked for a few years ago, we ended up building out a code hosting platform based on trac, Subversion, Mailman, Virtualmin to manage it all on the backend and grant project owners their own web space, etc.  (SciPy.org is the result, and several Open Source Python scientific computing projects are hosted there.  It works pretty well, or did when I last dealt with it about three years ago.)Generally, it's more important to actually get the code out there than how you do it.  Documentation is the hard part of the equation, and it's more important than you'd think.  Your code will not be adopted without at least good documentation for installing it and getting it running.  People will put up with a lot once it's installed and doing something productive for them...but if the install doesn't work, you've lost them, and they'll very likely complain about your software to others.Forking a major project like PHP is dangerous mojo.  I don't blame you...whenever I work in PHP, I feel like someone is stabbing me in the eye every time I have to create an array by typing "array(1, 2, 3, 4)" or try to do anything even a little clever.  Have you talked to the PHP folks about possible inclusion in PHP 6?  I mean, I know their mental model for software development is deeply flawed, and maybe they won't be eager to incorporate such dramatic changes, but if you could avoid a fork and still get the code out there, it'd be a win.  Worst case, you should remain on friendly terms with the parent project--do not fork in anger, as it's bad for everyone involved.  Do what you can to insure your bugfixes go back into mainline and that you follow their code very closely so that compatibility is maintained except in the specific areas where you diverge.