Bugzilla vs Gnats free open source software bug and defect tracking database. Software installation, system configuration, user review and comments
Home > Bugzero > Discussion

Bugzilla, Gnats, and Bugzero

The following compares Bugzero Bug Tracking System with Bugzilla and Gnats bug databases, the two popular free open source software bug tracking systems, in terms of installation, configuration and customization. Click on the link for a more general overview of bug and defect tracking software.


Bugzero (Java/J2EE and database based, cross-platform):

  • install Java (jdk1.3+).
  • install any database system including MySQL.
  • install any J2EE or servlet engine.
  • install Bugzero with setup (gui-based).
  • Anyone with some Java/J2EE experience should be able to get it up and running in less than one or a few hours (see detail). If you already have the database and the servlet engine ready, it takes even less time.
Bugzilla (Perl and MySQL based, best on unix, open source):
  • install MySQL database.
  • install perl 5.6.1.
  • install many perl modules with perl -MCPAN -e 'install "<modulename>"'.
  • install Bugzilla with perl -MCPAN -e 'install "Bundle:Bugzilla"'.
  • Quoted from Bugzilla site:
    Someone with much Bugzilla experience can get you up and running in less than a day, and your Bugzilla install can run untended for years. If your Bugzilla strategy is critical to your business workflow, hire somebody with reasonable UNIX or Perl skills to handle your process management and bug-tracking maintenance & customization.

    If you do not have Bugzilla experience and do not have much perl skill, it may take you much longer time to install Bugzilla.

Gnats (c and file based, unix only, open source):
  • install gnatsd.
  • configure gnatsd.
  • install a gui front.
  • install some perl module.
  • Gnats is configured by editing some configuration files in various locations.


With Bugzilla, you'll probably need hack some code for doing things like adding custom fields, changing field data types, modifying the drop-down menu, configuring user access control, and etc.    With Bugzero, you can accomplish these tasks as easy as a few clicks!

Use Case 1:

    Adding or deleting fields to customize the bug report form.
Use Case 2:
    Modify the options in a field, such as the priorities in priority.
    Bugzero: you can easily configure it with the web-based admin tool, no programming skill is needed.
    Bugzilla: there is no user interface for adding/deleting fields. If you modify the options of a field, notably the one related to bug progression states, you need also adjust the program logic to compensate for the change. Obviously, any customization of Bugzilla will need some programming, particularly perl, skill.


Have you ever wondered why you have to type in the exact email address when you re-assign a bug to another person, instead of selecting a user from a pull-down menu? Do you notice that, the attached file in Bugzilla has no name and no visible file type and so if you ever want to save the file, you'll need to find out what file extension the file is?

Bugzilla can sort in one direction, and you cannot reverse it. If you have multiple stored queries (preset queries), and want them to have different show columns, then you are out of luck, because the change column action is global and applies to all queries.

These are usability issues. They are small, but may add up wasting a lot of your time.


Use Case 1:
    Developers should not be able to mark the bug as verified or closed. They should be able to change it to be resolved/fixed/analyzed. Only QA persons should be able to close/verify a bug, etc.
Use Case 2:
    An existing bug cannot proceed to state 'new'; only state 'fixed' can proceed to state 'closed'; state 'closed' can only proceed to state 'reopened'; etc
    Bugzero: you can easily configure it with the web-based admin tool.
    Bugzilla: you have to change the Perl code to make this possible. In most of the cases, if you need workflow, Bugzilla is probably not your choice.
    Gnats: not allowed.


Use Case 1:
    Your product is used by many companies or organizations (such as customers and partners on a beta list) and each company has several users. Users from the same company should be able to see all the issues raised by them, but not the issues that are raised by any other companies.
Use Case 2:
    Your product has some bugs submitted by customers and your development staff fixed them. The how-to-fix information should be entered in the bug tracking system and be seen by the internal staff, but not your customers.
    Bugzero: For use case 1, you can add a group with type "Group" for each company. For use case 2, you can add your customer's group to the denied groups for the how-to-fix field, this field will be no longer visible to them.
    Bugzilla: no solution. Bugzilla is most often used for open source software development and security consideration is limited.
    Gnats: no solution.