Open Source Project Infrastructure? 10
cpfeifer asks: "Russ Miles wrote about going through the pain of setting up his own infrastructure for his OSS project, AspectXML. He asks: 'Are there tools out there that make this process much easier, and perhaps ones that I could take advantage of by moving my own open source project to? Also what experiences have people had with the different community projects?' Should you start up your own gforge server, host it on Sourceforge, or perhaps look to one of the OSS groups like Apache, Codehaus or Tigris?"
In my experience (Score:2, Interesting)
Re:In my experience (Score:1)
For instance, I much prefer to setup a proper
Nothing wrong with amavis, but what does it do for me that I can't do myself with less efford and higher confiability?
I also prefer to edit a phonebook.txt then using some contact management software, use the least possible libraries when coding,
What you need includes.. (Score:3, Interesting)
What's great about sourceforge and the like, is that they provide you with all of those in one package, and the bug-management-thingies in the portals beat most alternatives any day.
If you want to setup your own tools, I think it's better to just run the set of services you need, and not bother with a full devel-site, since for one project such a site is going to be mostly bloat, but that naturally depends on the size of your project.
If you want to use one of the existing sites, then the criteria are either those of personal choice, political ones, or maybe a matter of convinience: many people already have accounts on SourceForge, some people on Savannah, and some (but probably fewer) on other sites. (This is only my intuition. There might just as well be sites with userbase much larger than that of Savannah).
Just my totally random .05 euro. Sorry, smaller coins aren't in use in Finland.
Re:What you need includes.. (Score:2)
The thing agout sf is that their bug tracker is ugly and sitll don't support subversion; not sure what's wrong with bugzilla, I find it quite fast and user friendly. Compared to sourceforges' bug thingy at least
Don't Use SF (Score:2, Informative)
Mabye use a groupware client (like phpgroupware).
Or better yet, use Mantis [mantisbt.org]. Its a great web-based bug tracker. But we use it at work to track all kinds of things. All you're really looking for is something to manage bugs, enhancements, etc. Install it, CVS, and ViewCVS, and you should have almost every
GForge (Score:1)
GForge don't host projects. You install it on your server, or use other one's server that you have permission (and trust) to host a project on.
Re:Don't Use SF (Score:2)
My experiances with Mantis are ugly and buggy some much that I decided to go back to the SF.net bug tracker.
Use the simplest tools that work. (Score:4, Insightful)
Mantis for the bug tracker. I use a downlevel, modified version (based on the 0.15.x version). Simple to use, which is the most important feature.
http://www.mantisbt.org/
PHPWiki for notes and design discussions. Very handy to be able to spell out the design of a module, get feedback and have history available (especially useful to prove who made the design change).
http://phpwiki.sourceforge.net/
Finally a good discussion board. We used PHPBB fine, except the patch of the week that was required for security for a while...
http://www.phpbb.com/
I was originally worried about intregration, but it turned out that hyperlinks were sufficent to reference back and forth (for example, to reference a discussion in the BB from a bug).
Start with sourceforge (Score:2, Interesting)
-Rob
Try the NetWinSite servers (DNews, DBabble, etc) (Score:3, Informative)
From my experience running this kind of thing,
I highly recommend discussions via newsgroups.
They are easier to use than most web boards,
which leads to better/easier user feedback.
The newsgroups are easy to set up,
for examples see www.netwinsite.com.
The servers provide full text search,
straightforward email-to-news gateways,
various authentications, chat, etc.
Once you have your newsgroups working,
ask your participants what they use
for bug databases, source systems, etc.
Use the tools they know and recommend,
and you'll likely get better participation.