Choosing a development hosting solution

I’m considering changing the development environment we use to host our projects in work and I’m not alone. The reason why will become more clear further down. To be honest this article is partly to help me work out what my priorities for this are, and to appeal to the lazy web for any other suggestions.

So first of all, here are the things I’m looking for in this project.

These are essential:

  1. must be free software;
  2. must have flexible issue tracking with user defined fields;
  3. must be able to handle multiple projects;
  4. must be extremely transparent to non developer users;
  5. must support svn and git and graphical front ends to them;
  6. must support some kind of announcement system.

These are desireable:

  1. should integrate in some way to mailing lists;
  2. should support ad hoc tar bar downloads from scm;
  3. should be easy to search issues;
  4. should graphically depict progress on releases;
  5. should have documentation (wiki like) integration;
  6. should handles news and download areas;
  7. should be able to exchange data (like issues) on projects;
  8. should actively maintained;
  9. should automate most sysadmin activity, account creation etc.;
  10. should be packaged for Debian ideally.

The contenders thus far are:

  • Savane, which we are currently using;
  • Fusion Forge;
  • Redmine;
  • Trac.

Let’s take these one at a time.


Savane currently supports all the essential features, with the exception of git support. Being a fork from the original SourceForge software it works in a similar way. A web front end (in PHP), with back end functionality (in Perl) that creates shell users and groups, interfaces with mailman and so on.

But there are some problems. First of all the official project seems to have ground to a complete halt. Fixes that were submitted by users are not applied, there seems to be no forward momentum whatsoever. This is a problem, the offical version needs patched (modestly) to run on PHP 5, and the code base is a mess, with a few pages still requiring register_globals to be on. Bad.

However, another fork was taken some time ago which addresses all these problems including git support, well actually, the code base is still probably in need or work, but most apps of a certain age have this problem. What I’d like to see in Savane is better graphical tools to monitor project progress, better documentation features and incidentally better Debian packaging, but I’ve signed up to the fork to work on the latter on the first instance (this looks like it will be quite a bit of work, it’s non Debian policy compliant in many ways right now). The new fork is going to be forked again by the way, into a Python version. Could be interesting.

Fusion Forge

Previously known, or descended from GForge, Fusion Forge is another fork of the original SourceForge source code. It is well packaged for Debian (naturally, it runs Debian’s own code hosting environment, Alioth) and well maintained. It has many of the features of Savane, which probably makes it puzzling why I didn’t choose it in the first place. Well, there’s one reason why, in my opinion the front pages of FusionForge are rather un-user friendly, I mean what the heck is “Code Snippets” doing there? They feel very aimed at developers, which is great… but I need a nice straightforward interface for less savvy users. Looking today, the navigation still feels it’s just too developer centric, but as these sites double as developer sites and user sites (to acquire the software, report bugs and so on), that’s not great. I really don’t know yet whether Fusion Forge has better graphical tools than Savane.

In a conversation about this last week, Noodles suggested I should look at the ease with which the interface could be changed. A sensible suggestion I shall follow up.


Written in Ruby on Rails and advocated by my work colleage Paul Vitty, Redmine is clean and elegant looking. It shows all the signs of benefiting from being a later generation project and has a plugin architecture that seems excellent too. It has easy clean wiki integration, graphical road maps and Gannt charts; and these things make a difference. I don’t think it’s as remotely scalable as the design of the first two systems, which isn’t a huge problem for me, but I mention it in passing.

On the other hand, it seems to have little or no automated integration into the backend, user and group creation, mailing lists and so on. on the other hand it has a very rich set of plug ins, so it may already have such support or it may be possible to implement it.


Written in Python, Trac feels like Redmine lite, and that’s in the wrong direction for me. It explicitly does not have multiple project support and that’s a deal breaker for me.

I haven’t come to a strong conclusion about this so far. I note John (whom I linked above) notes that Redmine is difficult to install and upgrade because of Ruby, this is a hassle I just don’t need, but he also thinks it may be the best of the field. For me, it is probably more trouble free to migrate to the fork of Savane or to FusionForge. More thought needed, and your thoughts are most welcome!


4 thoughts on “Choosing a development hosting solution”

  1. Hi Lee,

    Thanks for the thoughts. The problem I have is that my mainline job can sometimes keep me 100% busy for periods of time, so I need something that will, to the greatest extent possible manage itself. There are some creaks and groans and downright errors in the backend code for Savane, but I’ve mainly resolved those at least. I just haven’t looked into how much I’d have to write to backend Redmine. I think I’ll not have time to do any changeover now the semester has started anyway…

  2. Hi, what did you decide? I’ve been looking at the same forges and was wondering if you had decided, and if so how did it turn out.

Leave a Reply

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