I’m looking for information on Trac vs. Mantis for issue and bug tracking, and MoinMoin vs. Sycamore for wikis. By “information,” I mean comparisons and trade-offs thereof…
The issue tracker would be used by about 20 people, all within one company. The wiki would be used by up to 100 people, ditto.
Any experiences, anecdotes, informed opinions, or even uninformed opinions, out there?
Seek Nuance 
There is a great comparison of issue trackers, both open source and otherwise at the link below,
http://ifdefined.com/blog/post/2007/10/Links-to-other-comparisons-of-issue-trackers.aspx
On the other hand, this is blatant self-promotion, but if you can afford a modest cost, I would recommend you look at fixx, our bug tracking solution for software teams at http://hedgehoglab.com/products/fixx
Trac has an integrated wiki that’s not too shabby. Perhaps more important is that it has built-in markup help pages, but also includes an HTML escape hatch. The integrated linkage to ticket tracker or changesets is really nice.
It has rough-grained permissions for people to have access to the wiki but not tickets, or code timeline, etc.
I frankly don’t like MoinMoin at all, at least the version I used a few years ago.
FWIW, git does have some integration with Trac via plugin; I’ve tested it a little, it seems to work. 😉
@Sarat:
Thank you for the pointer!
@Jeremy:
Agreed, Trac’s wiki is reasonable, and the ticket integration is nice. OTOH, Mantis’ built-in wiki looks none too shabby either. Since I have no Mantis experience, I’m basically left with comparing the tools’ documentation, which won’t give the whole story. Hence, my question…..
Mantis tickets look spiffier than Trac’s, but I don’t know how much of that is useful in the long term. I was hoping that someone with equal experience in both would comment here and expound…
MoinMoin being written in Python was what first attracted me. And it seems to have a boatload of features. It uses flat files instead of a dbms, which means less administration hassles and easier recovery from screw-ups, at least in theory.
What didn’t you like about MoinMoin?
I’ve used MoinMoin twice now. Once as the very first wiki / collaboration tool in a product development engineering team. Company had a bunch of stagnant & over-built theoretical processes, while practically it was entirely ad-hoc. 17 guys plus or minus, doing software and hardware (mainly integration) development.
We used MoinMoin for general knowledge capture and to manage Tier III support. I found that when you get to Tier III – unexpected non-trivial functional errors with the product in the field – there is often a lot of investigation. Wiki fits that better vs. a completely defined workflow. Both the existing ticketing and support tracking systems were hostile to supporting capturing knowledge along the way.
MoinMoin did well for us, including email integration, some templating, and similar. This was on Windows OSes. We were looking at reworking the whole tool chain & development environment, so we might have gone for something else with that refresh. Better integration with builds, repository & defect and support ticket tracking would have been nice. We weren’t there yet.
This second time going on right now, we’re using MoinMoin to capture context info about a NOC. Even banged up Wiki login authenticated against LDAP with no problem. Interestingly, that location has Mantis installed, yet the concept of wiki / capturing folklore was news.
FWIW I picked MoinMoin the first time from a short list of competent wikis *because* it was written in Python, or more precisely “not Perl.” Leaving aside the language wars, I had Perl programmers on the engineering team – mobile VPN written in C++. By choosing a Python vs. Perl-based wiki I reduced the temptation to hack at its implementation.
I’ve heard good things about Trac, which if my memory serves is based on MoinMoin. Medio systems in town used it for some time, so if you know someone from there, they might have some insight.
I’ve used both Mantis and Trac. In my opinion, I think Mantis with friendly and useful issue reports is better for project maintenance, and Trac with timeline and SVN is better for project development.
However, in the latest version of Mantis, we can have wiki and SVN, so there is no more different.
And in the conclusion, I will choose Mantis 🙂
My company tried both Mantis and Trac and from my experience, i found Trac much harder to upgrade, customize and version 0.11 didn’t have support for Japanese and i’m sure other languages.
Mantis on the other hand is really easy to upgrade, customize and not only does i thave suppot for a whole bunch of different languages, it can be user based, so while i use english all my co-workers can use japanese.
In the end main reason we chose mantis was becasue the interface is much better developed, the japanese support and most importantly, Mantis’s development team is more active and has a strong community.
Last note… the mantis plugin system is by far superior to the trac one imo.
I’ve used mantis and it is nice piece of software.
I’m about to switch to trac bcs it is part of tools included in Kforge.
Realize this is dated, but which did you choose and how would you change now (or have you) given your experiences with the solution you chose? Thanks
I chose Trac, and we used Trac’s integrated wiki. It worked fine, although the administration of Trac and Subversion has a learning curve. If I had to do it again, I would look for a hosted solution (e.g., codebasehq) before choosing to administer it myself. I’d also choose to work for a company that wouldn’t lay off its entire Web division one year after forming it.