Review: Free Software Project Hosting

I asked for suggestions a few days ago. I got several good ones, and investigated them. You can find my original criteria at the link above. Here’s what I came up with:

Google Code

Its very simple interface appeals to me. It has an issue tracker, a wiki, a download area. But zero integration with git. That’s not necessarily a big problem; I can always keep on hosting git repos at It is a bit annoying, though, since I wouldn’t get to nicely link commit messages to automatic issue closing.

A big requirement of mine is being able to upload tarballs or ZIP files from the command line in an automated fashion. I haven’t yet checked to see if Google Code exports an API for this. Google Code also has a lifetime limit of 25 project creations, though rumor has it they may lift the limit if you figure out where to ask and ask nicely.



Gitorious is one of the two Git-based sites that put a strong emphasis on community. Like Github, Gitorious tries to make it easy for developers to fork projects, submit pull requests to maintainers, and work together. This aspect of it does hold some appeal to me, though I have never worked with one of these sites, so I am somewhat unsure of how I would use it.

The downside of Gitorious or Github is that they tie me to Git. While I’m happy with Git and have no plans to change now, I’ve changed VCSs many times over the years when better tools show up; I’ve used, in approximately this order, CVS, Subversion, Arch/tla, baz, darcs, Mercurial, and Git, with a brief use of Perforce at a job that required it. I may use Git for another 3 years, but after 5 years will Git still be the best VCS out there? I don’t know.

Gitorious fails several of my requirements, though. It has no issue tracker and no downloads area.

It can spontaneously create a tar.gz file from the head of any branch, but not a zip file. It is possible to provide a download of a specific revision, but this is not very intuitive for the end user.

Potential workarounds include using Lighthouse for bug tracking (they do support git integration for changelog messages) and my own server to host tarballs and ZIP files — which I could trivially upload via scp.



At first glance, this is a more-powerful version of Gitorious. It has similar community features, has a wiki, but adds an issue tracker, download area, home page capability, and a bunch of features. It has about a dozen pre-built commit hooks, that do everything from integrate with Lighthouse to pop commit notices into Jabber.

But there are surprising drawbacks, limitations, and even outright bugs all throughout. And it all starts with the user interface.

On the main project page, the user gets both a download button and a download tab. But they don’t do the same thing. Talk about confusing!

The download button will make a ZIP or tarball out of any tag in the repo. The download tab will also do the same, though presented in a different way; but the tab can also offer downloads for files that the maintainer has manually uploaded. Neither one lets you limit the set of tags presented, so if you have an old project with lots of checkpoints, the poor end user has to sift through hundreds of tags to find the desired version. It is possible to make a tarball out of a given branch, so a link to the latest revision could be easy, but still.

Even worse, there’s a long-standing issue where several of the tabs get hidden under other on-screen elements. The wiki tab, project administration tab, and sometimes even the download tab are impacted. It’s been open since February with no apparent fix.

And on top of that, uploading arbitrary tarballs requires — yes — Flash. Despite requests to make it scriptable, they reply that there is no option but Flash and they may make some other option sometime.

The issue tracker is nice and simple. But it doesn’t support attachments. So users can’t attach screenshots, debug logs, or diffs.

I really wanted to like Github. It has so many features for developers. But all these surprising limitations make it a pain both for developers (I keep having to “view source” to find the link to the wiki or the project admin page) and for users (confusing download options, lack of issue attachments). In the end, I think the display bug is a showstopper for me. I could work around some of the others by having a wiki page with links to downloads and revisions and giving that out as the home page perhaps. But that’s a lot of manual maintenance that I would rather avoid.



Launchpad is the project management service operated by Canonical, the company behind Ubuntu. While Launchpad can optionally integrate well with Ubuntu, that isn’t required, so non-developers like me can work with it fine.

Launchpad does offer issue tracking, but no wiki. It has a forum of sorts though (the “Answers” section). It has some other features, such as blueprints, that would likely only be useful for projects larger than the ones I would plan to use it for.

It does have a downloads area, and they say they have a Python API. I haven’t checked it out, but if it supports scriptable uploads, that would work for me.

Besides the lack of a wiki, Launchpad is also tied to the bzr VCS. bzr was one of the early players in DVCS, written as a better-designed successor to tla/Arch and baz, but has no compelling features over Git or Mercurial for me today. I have no intention of switching to or using it any time soon.

Launchpad does let you “import” branches from another VCS such as Git or svn. I set up an “import” branch for a test project yesterday. 12 hours later, it still hasn’t imported anything; it’s just sitting at “pending review.” I have no idea if it ever will, or why setting up a bzr branch requires no review but a git branch requires review. So I am unable to test the integration between it and the changesets, which is really annoying.

So, some possibilities here, but the bzr-only thing really bugs me. And having to have my git trees reviewed really goes against the “quick and simple” project setup that I would have preferred to see.



Indefero is explicitly a Google Code clone, but aims to be a better Google Code than Google Code. The interface is similar to Google’s — very simple and clean. Unlike Google Code, Indefero does support Git. It supports a wiki, downloads area, and issue tracker. You can download the PHP-based code and run it yourself, or you can get hosting from the Indefero site.

I initially was favorably impressed by Indefero, but as I looked into it more, I am not very impressed right now. Although it does integrate with Git, and you can refer to an issue number in a Git commit, a Git commit can’t close an issue. Git developers use git over ssh to interact with it, but it supports only one ssh key per user — so this makes it very annoying if I wish to push changes from all three of the machines I regularly do development with. Despite the fact that this is a “high priority” issue, it hasn’t been touched by the maintainer in almost a month, even though patches have been offered.

Indefero can generate files based on any revision in git, or based on the latest on any branch, but only in ZIP format (no tar.gz).

Although the program looks very nice and the developer clueful, Indefero has only one main active developer or committer, and he is a consultant that also works on other projects. That makes me nervous about putting too many eggs into the Indefero basket.



Trac is perhaps the gold standard of lightweight project management apps. It has a wiki, downloads, issue tracking, and VCS integration (SVN only in the base version, quite a few others with 3rd-party plugins). I ran trac myself for awhile.

It also has quite a few failings. Chief among them is that you must run a completely separate Trac instance for each project. So there is no possible way to go to some dashboard and see all bugs assigned to you from all projects, for instance. That is what drove me away from it initially. That and the serious performance problems that most of its VCS backends have.



Redmine is designed to be a better Trac than Trac. It uses the same lightweight philosophy in general, has a wiki, issue tracker, VCS integration, downloads area, etc. But it supports multiple projects in a sane and nice way. It’s what I currently use over on

Redmine has no API to speak of, though I have managed to cobble together an automatic uploader using curl. It was unpleasant and sometimes breaks on new releases, but it generally gets the job done.

I have two big problems with Redmine. One is performance. It’s slow. And when web spiders hit it, it sometimes has been so slow that it takes down my entire server. Because of the way it structures its URLs, it is not possible to craft a robots.txt that does the right thing — and there is no plan to completely fix it. There is, however, a 3rd-party plugin that may help.

The bigger problem relates to maintaining and upgrading Redmine. This is the first Ruby on Rails app I have ever used, and let me say it has made me want to run away screaming from Ruby on Rails. I’ve had such incredible annoyances installing and upgrading this thing that I can’t even describe what was wrong. All sorts of undocumented requirements for newer software, GEMS that are supposed to work with it but don’t, having to manually patch things so they actually work, conflicts with what’s on the system, and nobody in the Redmine, Rails, or Ruby communities being able to help. I upgrade rarely because it is such a hassle and breaks in such spectacular ways. I don’t think this is even Redmine’s fault; I think it’s a Rails and Ruby issue, but nevertheless, I am stuck with it. My last upgrade was a real mess — bugs in the PostgreSQL driver — the newer one that the newer GEM that the newer Redmine required — were sending invalid SQL to it. Finally patched it myself, and this AFTER the whole pain that is installing gems in Ruby.

I’d take a CGI script written in Bash over Ruby on Rails after this.

That said, Redmine has the most complete set of the features I want of all the programs I’ve mentioned on this page.



Savannah is operated by the Free Software Foundation, and runs a fork of the SourceForge software. Its fork does support Git, but lacks a wiki. It has the standard *forge issue tracker, download area, home page support, integrated mailing lists, etc. It also has the standard *forge over-complexity.

There is a command-line SourceForge uploader in Debian that could potentially be hacked to work with Savannah, but I haven’t checked.


Appears to be another *forge clone. Similar to Savannah, but with a wiki, ugly page layout, and intrusive ads.



Used to be the gold-standard of project hosting. Now looks more like a back alley in a trashy neighborhood. Ads all over the place, and intrusive and ugly ones at that. The ads make it hard to use the interface and difficult to navigate, especially for newbies. No thanks.


The four options that look most interesting to me are: Indefero, Github, Gitorious, and staying with Redmine. The community features of Github, Gitorious, and Launchpad all sound interesting, but I don’t have the experience to evaluate how well they work in practice — and how well they encourage “drive by commits” for small projects.

Gitorious + Lighthouse and my own download server merits more attention. Indefero still makes me nervous due to the level of development activity and single main developer. Github has a lot of promise, but an interface that is too confusing and buggy for me to throw at end users. That leaves me with Redmine, despite all the Rails aggravations. Adding the bot blocking plugin may just get me what I want right now, and is certainly the path of least resistance.

I am trying to find ways to build communities around these projects. If I had more experience with Github or Gitorious, and thought their community features could make a difference for small projects, I would try them.

23 thoughts on “Review: Free Software Project Hosting

  1. First of all, I think you’re mixing software with services.
    Secondly, it’s surprising how Alioth & FusionForge are missing from the list, esp. since you’re a DD :)

    1. I am mixing software with services, and intentionally so. I don’t really care which I use, as long as it’s reliable and doesn’t take a lot of effort for me to use.

      I did consider mentioning Alioth, but didn’t because it’s very similar to Savannah but is not as easy for non-DDs to get projects hosted there. (Also there is more manual work involved to get Git source trees going). Alioth obviously has clear benefits for those that are doing Debian-related work, but I figured those people would already know about it.

  2. I was happy to read about the PHP based solution Indefero and went their to have a look. From a first look it seems to be crap again. Database table definitions directly in the code, no single index.php entry point but one PHP file for every actions, HTML build in the models, some obscure home grown PHP framework, …

    1. Thanks. I hadn’t looked at the code, and I’m glad to know that. The PHP framework is written by the author of Indefero; actually it sounds like Indefero is partly written as a way to promote the framework.

  3. An aside on your rails experience: I too was shocked at first as to how one is supposed to deploy rails. The major difference with cgi or php or whatever is that a rails app is supposed to stay running. After struggling with it over the years with cgi, fastcgi, mongrel, proxies etc – I think we finally have something close to a real solution with modrails/passenger (which actually deals with the lifecycle issues). And to develop and test locally, you just use the builtin webserver, no apache needed.

    The deployment story of Rails on Debian is still a bit of a mess: there’s a clear disconnect between gems and Debian’s packaging. I hope we’ll eventually get to a point that something like redmine can be properly packaged in Debian, so that it pulls in all the necessary gems, and makes the webserver work – automatically.

  4. Oh. Wow, that’s a big list. Thanks for mentioning all of them. even i was using redmine sometime back as it contains most of the features.

  5. Bitbucket a great project hosting alternative, 1 private repo in the free account, 150 MB, issue tracker and WIKI.
    Works with Mercurial

  6. +1 for hg+bitbucket, but if you like git, I can’t imagine you’ll like it.

    Am I the only person who finds Redmine terribly annoying to use? It seems to take 5x the number of clicks Trac does to accomplish any given task.

    I use a multi-project extension for Trac that works wonderfully. The timeline and milestones suffer a bit due to their inability to filter by project, but otherwise it works great.

    1. Can you post the URL of the specific Trac extension you are using? It is non-trivial to find multi-project trac stuff due to so many people talking about it…

  7. Not really an opinion, but more an observation: a couple of months ago
    Savannah had a case of Murphy’s Law.

    I found this sort of hilarious considered I’ve had to deal with similar
    experiences in my career as a sysadmin.

    As for opinion: I really dig Indefero. I really like Google Code from
    an end-user perspective. It’s simple interface really helps, and people
    seem to use it properly. Every project I’ve come across has a wiki w/
    good docco. If Indefero brings everything Google Code has to the table & more, then go for it! It looks awesome.

  8. Google Code will most definitely raise your project limit, and the place to ask is the Google Code Hosting group at Google Groups:

    For example, here is where I requested an increase, and they doubled my allotment:

    Also, they have a wiki entry on how to upload files from the command line:

  9. I’m using Redmine at work and we are all very happy with it. Even the customers who can adapt to using a ticket systems are happy.

    Deployment is much easier with modrails/ree and performance with a sensible configuration as well.

  10. The fact that Launchpad has human intervention before starting a git import is a bit of a bug, and the developers agreed to remove it. It’s a hangover from svn and cvs imports where people seem to commonly misconfigure them and doing so produces bad results (think about checking out the root of a svn repo.)

    The community features around merge proposals in Launchpad are pretty interesting, in my biased opinion ( but realistically if you’re using it on only git imports it’s never going to be seen at its best.

  11. Berlios:
    I’ve tried out most of them and berlios is the best. You should have done a more detailed review of it. It supports git, web hosting, downloads, everything else a *forge supports. It never breaks, it’s stable. Support for troubles is fast.
    The difference with all hosting out there is that you have access to the repository folders on their servers. Good visibility for your project. Though the interface is old it has the higher number of features over others and stability IMHO. Web hosting also supports CGI, so I guess you can deploy web sites with something other than perl there.

    Google code:
    its wiki is extremely limited, I’ve moved my project from there to berlios. Had lots of troubles with ssh and svn when making medium size commits to the repository.

    Source forge:
    the way they handle downloads and other stuff is like berlios, but more annoying. Berlios has an older interface than sourceforge, but sourceforge is so commercial.

    I use it only for temporarly development. After a project is ready I move it to berlios for the homepage, downloads, bug tracking and so on.

    it’s always been a pain for all hosting providers, and a limited wiki for all projects. Search is ugly and tickets are arranged so bad that there’re unuseful queries.

    it has nothing, it only appears cool, and it’s also slow.

    they have two kinds of wiki: their wiki and trac. It always bored me. They don’t have web hosting. Users get lost in your project.

    1. The only thing in that Berlios feature list that isn’t a typical *forge feature is the wiki. The rest seem to be pretty typical, or not of interest to me. Thanks for your comments though!

  12. John, thanks for taking the time to do this comparison. I find myself in a similar situation, except that I don’t have an existing setup (I just have a bunch of darcs and git repositories served over HTTP). I pretty much agree with your analysis: none of the options seems very good.

    Perhaps some of the distributed bug trackers that are emerging will help the situation, but I get the impression that none of them is really ready yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.