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

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.