Google code is a good place to host. Very fast to get started and you get a very clean website with all the basic tools. Bug reporting is simple so your users will be happy too. It uses SVN but google give you the option to host your repository somewhere else if you dont like SVN. However Google allows only a restricted set of licenses so you need to check their list of supported licenses.

launchpad is also an ok place to host code (and it allows any license) but it doesnt host wikis for example and some of the UI elements are rather radical and may not suit your taste. if you host on launchpad, you will need to host a proper website and/or wiki somewhere else.

Dont go with sourceforge. The site has become slow and full of ads which cover half your screen. The interface is clunky too.

edit : launchpad uses bazaar a distributed VCS.

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.

Thanks for the download.

Re: forking. I'm not really involved in PHP internals beyond keeping an eye on it, but there have been some really brilliant patches by a single guy that keep getting rejected because they're not of the "PHP mindset". Honestly, I think their mindset is a little f'd up. The namespaces in PHP 6(5.3) are ugly as hell.

We wouldn't be forking in anger, we'd just be posting the latest PHP with patches that make it useful. Use it if you want, that sort of thing.

Anyways, thanks for the feedback.

I'd say that "of the PHP mindset" is quite possibly one of the worst insults you can give code.

I'd recommend github for source hosting. I've got multiple open source projects that I run or use that use github for scm and use lighthouseapp.com for ticketing. These are fairly large OSS projects with many many contributors and it works great. http://github.com/wycats/merb-core/tree/master and http://github.com/evanphx/rubinius/tree/master as well as a bunch of other smaller oss projects.

Both github and Lighthouse will give free accounts to open source projects.

At Polar Rose we simply started to put projects on Google Code. Some are well documented, others are mostly code dumps and need more attention. We use subversion internally and Maven for working with well defined (Java) components/libraries. So there is not much difference between working on code hosted in the public or private repositories.

The most difficult thing was actually not a technical thing but a mindset issue: To teach people in the teams how they can identify components that can be released as open source. And to actually do it.

github is great for forking and the like, I'd go with that and lighthouse for tracking and google groups for a mailing list.

Or, you could just run your own git repo, trac, and mailman.

Just stay away from sourceforge.

Trac (at least the way most projects have it set up) is pretty new user unfriendly.

This is ok if your project is targetted at users who are developers, but if you want fresh blood and the less (initially) motivated to get drawn in a priority should be:

* A concise explanation of what the project is.

* A nice forum. Maybe even with no registration until you get established.

* Easy bug reporting. (Maybe not a bug tracker - a forum for bugs can be really effective provided the dev's or some support people read it.)

See, I was going to mention SF. It seems to be becoming less and less popular these days. Why is that? Do you think it's become too big for its boots?

My impression is that it's painfully slow and the UI is horrid. Six clicks to download a package and it's not very clear even then.

As a user of SF, I hate it. It's very unfriendly requiring more links than reasonable to get to the actual download. Also the ads are just horrible.

Slow. Advertisements. Lame mailing list archives. Lame issue tracker. Lame forums. Lame/oldskool SVN browser. Advertisements. Lot's of downtime.

On the topic of hosting, has anyone been able to get into [Codebase](http://codebasehq.com/) beta? It looks very cool on the surface but I couldn't find any hosted projects to play around with. I submitted our info a while back, heard nothing so far.

Thanks for the tips, was looking at github.

We have something on SF which we don't update often because of all the reasons you've read in other posts. The up-to-date code snapshot is hosted in-house on Subversion. Issues are tracked in-house with Mantis, user/developer mailing lists are run in-house with Pipermail, the code is built on the server with the help of Maven (since it's all Java, YMMV), and wikis hosted in-house with the help of Dokuwiki.

Why all the in-house stuff? Control, for one. We also ask for registration information before giving access to the source code. This comes around to lead generation when it's time to sell services (which is all the time).

Check it out: http://www.openclinica.org/index.php

I have a question that is along the same lines, if we have a project that we want to open source and basically make money on service contracts what is the best open source license to go with?

LGPL, we went with it for our code and have been doing okay by it. The only trick is that we use a number of other OSS packages as well and we have to do an audit every once a quarter to make sure the licenses are all in line with ours.

I'm hosting some projects on my own box. It's a mix of svn and bzr repositories fronted by Trac.

Trac is awesome, but it doesn't really understand bzr branches and such, so linking to code from inside Trac is a little weird. If you'll be using DVCS, shop around for something more congruent.

Also, browsing a bzr repo from Trac is pretty slow.

It would be best to package your PHP additions as an extension if you could, but I imagine you'd have done that already if it would work.

PHP on Ubuntu comes with the Suhosin patch installed, so there is at least one third-party PHP patch that has some significant distribution.

i did work on an open source J2ME api(BIZU ME) and stopped when I started working full time. I can say that sourceforge is ok for hosting since that is what I used for hosting and had no problems what so ever. The UI is weird to deal with but its alright once u get used to it. I haven't tried any other such as google code etc so I cant give u any feedback on those.. You will probably need a bug tracking tool such as jira for tracking your issues. Jira is really good and offers a free licence if your project is open source. Apart from that , you will need weekly updates or else people lose interest pretty quickly!

Trac is great, and I've used it a number of times, but if you are rolling your own platform then Redmine (www.redmine.org/) is worth considering as it is much nicer and easier to get started with.

A big thumbs up for Github. I've got OSS and closed source projects in GH and I absolutely love it. Pull requests are the new patch ticket.