Adopting bug tracking / project management software: To open source or not to open source?

Question

My manager has recently asked my team and I for our input about implementing a bug tracking / project management solution. From his perspective, he would like more visibility around where our projects actually are in the grand scheme of things as well as the ability to see some analysis on how bugs are being caught and addressed.

My old company, implemented Trac as a means to plan, track, and manage bugs. It worked great! However, my new company is a little more... how shall we say... averse- to implementing open source projects as our corporate solutions. There concerns are mainly concerning the amount of time we might spend maintaining and customizing the software to meet are needs.

They, management, are initially more in favor of a more "sturdy" product offering like Joel's FogBugz.

So, the question is-

• at what point does the flexibility and cost savings of implementing an open source solution get drowned out by the headache of maintainence and the creep of calls for constantly expanding functionality?
• Is there a clear line?
• And what can I say as a grunt to convince my managers of a Trac-like solution that won't end up being a nightmare for everyone?

Answer 1

In a lot of work-places all they really want is someone they can call up to fix problems if they arise, if you look at http://trac.edgewall.org/wiki/CommercialServices, you'll see there are a few companies who offer commercial support for Trac so that may help swing things that way.

Answer 2

I also like Trac (I'm using it for a hobby project with a couple of friends) but I think FogBugz and several other commercial PM/bug tracking software packages are probably better. If management is willing to pay for a commercial solution, where's the problem?

Answer 3

You ask:

at what point does the flexibility and cost savings of implementing an open source solution get drowned out by the headache of maintainence and the creep of calls for constantly expanding functionality?

Firstly, what maintenance? All the FOSS software I use just works - I certainly don't maintain it, any more than I maintain proprietory software. Of course, If I do spot a bug I'll report it and even try to fix it, but I don't have to do this.

Secondly, what calls for expanding functionality? You should only consider a FOSS solution if it meets all your needs. Once installed, you should no more consider expanding its functionality than you would for a proprietory solution, unless you want to, of course.

Answer 4

The question has to be answered in the context of your company's culture, background, development environment etc.

Are they familiar with and comfortable with Open Source?

Are they using Microsoft technology or Java?

Are you paying for the software out of your salary or is the company going to pay for it? :)

Is your immediate manager paying for the software out of his salary? :)

How much credit will your company give you for saving them some money?

How much flak will you get if an open source solution fails?

*** I think if you meditate on the last 2 points, go ahead and spend the money for a better supported solution. If they are a Microsoft shop, just go with their bug tracking system. If not, go with something like FogBuz. If it is a bank, go with Remedy.

Now, if it was your own startup, then open source would make a lot of sense. If the company is very comfortable with open source, it might also make sense. However, it sounds like they aren't and that you are setting yourself up for trouble going with open source. If anything goes wrong (and it may have nothing to do with it being open source) then fingers will be pointed at you saying "it was an open source solution". The operative phrase is CYA - Cover Your Ass.

Answer 5

This is to some extent a string-lenght question, but here are my random thoughts:

• Just because a piece of software is commercial and backed-up by a support organization, it isn't hassle-free to install and set up.

• Compare the licensing cost with the time needed to set up (and maintain) an open-source solution. Will the open-alternative be functional in a day, week or month?

• The problem with scope creep is really a management problem.

• If you aren't really sure what you need, trying out an open alternative first is a great way of building experience in what functionality is essential to your organization.