Reasons not to build your own bug tracking system [closed]

Question

First, look at these Ohloh metrics:

    Trac:  44 KLoC, 10 Person Years,   $577,003
Bugzilla:  54 KLoC, 13 Person Years,   $714,437
 Redmine: 171 KLoC, 44 Person Years, $2,400,723
  Mantis: 182 KLoC, 47 Person Years, $2,562,978

What do we learn from these numbers? We learn that building Yet Another Bug Tracker is a great way to waste resources!

So here are my reasons to build your own internal bug tracking system:

1. You need to neutralize all the bozocoders for a decade or two.
2. You need to flush some money to avoid budget reduction next year.

Otherwise don't.

I would want to turn the question around. WHY on earth would you want to build your own?
If you need some extra fields, go with an existing package that can be modified.
Special report? Tap into the database and make it.

Believing that it isn't difficult? Try then. Spec it up, and see the list of features and hours grow. Then after the list is complete, try to find an existing package that can be modified before you implement your own.

In short, don't reinvent the wheel when another one just needs some tweaking to fit.

Programmers like to build their own ticket system because, having seen and used dozens of them, they know everything about it. That way they can stay in the comfort zone.

It's like checking out a new restaurant: it might be rewarding, but it carries a risk. Better to order pizza again.

There's also a great fact of decision making buried in there: there are always two reasons to do something: a good one and the right one. We make a decision ("Build our own"), then justify it ("we need full control"). Most people aren't even aware of their true motivation.

To change their minds, you have to attack the real reason, not the justification.

Not Invented Here syndrome!

Build your own bug tracker? Why not build your own mail client, project management tool, etc.

As Omer van Kloeten says elsewhere, pay now or pay later.