Software as a Service

Three Open Source Ticketing Systems

Print
Check out this page on Dell.com! Email
Rate
1 out of 5
2 out of 5
3 out of 5
4 out of 5
5 out of 5

By: Joe 'Zonker' Brockmeier (7/29/2010)

If open source folks know anything, and they do, it’s how to build tools that enable collaborative development. Case in point: ticketing and issue tracking systems. If your shop needs a reliable, flexible, and scalable ticketing system take a look at Bugzilla, Request Tracker (RT), or Trac to find the best tool to keep your projects on track. You’ll find a number of proprietary and open source issue trackers that can fit your business, so what gives open source offerings the edge? The first benefit that comes to mind, of course, is cost. What does it cost to deploy Bugzilla, RT, or Trac? Not a penny, in terms of licensing or support costs. You can pay for support if you like, but the licenses allow you to deploy each of these tools without spending a cent. And, of course, your developers can (if needed) extend and customize each system to fit your particular environment. But that, alone, isn’t enough. Trac, Bugzilla, and RT are projects that have been widely used for years by hundreds of organizations and open source projects. Open source developers may not always be the best at developing user friendly interfaces, but they’re very good at creating developer-friendly systems. And issue trackers are where most open source communities live. Bugzilla, Trac, and RT have been battle-tested in the open by a very diverse and demanding group of technical professionals. Open source developers have a saying: “With enough eyeballs, all bugs are shallow.” Imagine the scrutiny that open source issue trackers receive; they’re the tools that open source developers use to develop other tools. Narrowing the Field All open source ticketing systems are not created equal. Bugzilla, RT, and Trac are three of a field of open source issue trackers. Why choose these three? The Bugzilla, RT, and Trac triumvirate are some of the oldest and most widely deployed systems for open source projects. Bugzilla and RT have been around since the late ‘90s; Trac is a relative newcomer, having been introduced in 2006, but already is widely deployed and well-loved by many projects and companies. I also chose these because of the respective health of the projects. Each project has a healthy community and company behind it. In the case of RT and Trac, you’ll find companies that focus on offering support and services for the projects. Bugzilla’s primary sponsor, Mozilla, doesn’t have commercial support. However, the project is so widely deployed and deeply ingrained in so many open source projects that its continued development is virtually assured. If outside expertise is needed, it shouldn’t be difficult to find consultants who can lend a hand with support or customization. Bugzilla The first contender is Bugzilla, and you’d be hard pressed to find a project with a more impressive (or demanding) list of users. Bugzilla is deployed by Apache, OpenOffice.org, Eclipse, Red Hat, Novell, NASA, Facebook, and more than 1,000 others. As a Mozilla project, Bugzilla is freely available under the terms of the Mozilla Public License. Bugzilla is, as the name implies, primarily about tracking bugs and is very well suited to development environments. This is not to say it’s unsuitable for use by a help desk or another team that needs a ticketing system, but Bugzilla is most famously and widely known as a bug tracking system. Let’s take a look at some of its strengths. Bugzilla is capable of handling thousands upon thousands of bugs, and multiple projects. A single installation can support multiple databases, so if your organization is supporting internal and external projects, Bugzilla is a good fit. Written in Perl, Bugzilla works with Oracle, MySQL, or PostgreSQL and with several Web servers – though Apache is recommended. As one would imagine, Bugzilla supports detailed tickets divided up by products and components. A product might be something like Firefox® 3.6 or openSUSE 11.2, and then components are parts of the larger project. So an organization might have its main Web site classified as a product in Bugzilla, then include different sections of the site as components. Developers can interact with Bugzilla via its Web interface, or via email, depending on how it’s set up. Bugzilla can also be set up to “whine,” or to send the results of predefined searches via email at specific times. One might set Bugzilla to “whine” at users every Sunday night about their open bugs that are considered blockers for a product. Another helpful feature in Bugzilla is time tracking. This can allow managers to see how developers and other staff are spending their time, and which features or problems are sucking up the most time. Out of the box, Bugzilla has a sane set of fields for filing bugs. But if your organization needs to track information that’s not one of Bugzilla’s default fields, Bugzilla 3.0 and later support custom fields. For many years it was necessary to hack Bugzilla itself to extend the platform. This was unfortunate, as many open source projects needed to add features, and found themselves deviating from the core release – and therefore it was difficult to upgrade to later releases. The 3.6 Bugzilla release that came out in April of this year added extensions, so now it’s possible to extend Bugzilla without modifying the core Bugzilla code. It also means that optional community developed extensions are beginning to appear that enhance Bugzilla’s features. Another upside to Bugzilla is that it has quite a few supporting applications. You’ll find plenty of browser extensions, add-ons for Thunderbird, Eclipse plugins, and even integration to IRC clients like Colloquy, and quite a few other third-party tools and support applications that make Bugzilla easier to interact with. You can even find tools to integrate Bugzilla with Microsoft Project, though the tools are not open source. Naturally, Bugzilla integrates well with Mozilla’s automated build system tool, Tinderbox, and with Bonsai CVS query application. Bugzilla has been very widely extended and supplemented by its community of developers. The downside to Bugzilla is that it’s complex. Very complex. Even though work has been done to streamline and improve its interface, the system is still one that only a techie could love. It’s inadvisable to deploy Bugzilla for any projects or teams that have non-technical users submitting and working with tickets unless you’re willing to supply a great deal of training, hand-holding, and an early happy hour. Unlike the other offerings I recommend, Bugzilla’s main sponsor doesn’t provide commercial support. However, it’s possible to find quite a few consultants who happily provide support if needed. Trac Though Trac is much younger than Bugzilla, it’s become popular in very little time. In part this is due to its more minimalistic approach to tracking issues. It’s possible to migrate bugs to Trac from Bugzilla, Sourceforge, Mantis, and a few other ticketing systems. Trac is published under a modified BSD-style license which means that there’s very little limit on what you can do with the software and no real restrictions on redistributing modified versions. This is probably not a factor for most organizations, but if you’re thinking about shipping an issue tracking system as part of a project or offering it to your customers, this means you don’t need to offer patches upstream. Written in Python, Trac integrates with SQLite, MySQL, or PostgreSQL and is well-integrated with the Subversion version control system. It also works with Git, Mercurial, Perforce, and other source control systems with plugins. Trac has a fairly healthy set of plug-ins for everything from creating Gantt charts to providing an XML-RPC interface for remote applications to work with Trac. Though popular, Trac doesn’t quite have the third-party ecosystem that Bugzilla enjoys. The default tickets in Trac are streamlined and much simpler than in Bugzilla. Whether this is considered a feature or not, depends on the team using it. Trac is probably better suited than Bugzilla for non-development teams and IT projects that aren’t development-related. For instance, if you’re looking for a ticketing system for a team of administrators, Trac is a good option. Trac is also good for development teams, of course. In addition to tickets, Trac has a good default reporting system that allows you to view things like milestones, and timelines by tickets and changes in the code repository. Trac also includes a repository browser so users can view code stored in a repository attached to Trac along with the changes attached to tickets. If the default reports don’t cut it, it’s possible to write custom reports using standard SQL statements. Documentation and Trac go hand in hand. It has a built-in wiki, and several open source projects use Trac not only to power their issue tracking and to view their repositories, but also to provide user documentation about the projects. Search is simple with Trac, simply enter any term and go. Results can be narrowed to changesets, tickets, wiki, or milestones, so if you only want to search the wiki or milestones, and not the Trac tickets themselves, it’s a piece of cake. Trac is not as robust or full-featured as Bugzilla, but it’s a bit simpler to deploy and probably a better choice for smaller projects. Request Tracker Last, but certainly not least, is Request Tracker, usually referred to simply as RT. Developed by Best Practical, RT is written in Perl and works with Apache or Lighttpd, with a MySQL, PostgreSQL, Oracle, or SQLite backend. It’s available under the GNU General Public License (GPL) for deployment on your own servers, and Best Practical provides hosted versions of RT as well. Of the three, RT is probably the best choice for helpdesks and non-technical teams. RT can be used to create custom workflows and tracking systems that are suitable for all sorts of projects, not just for development. It started life as a help desk system for Wesleyan University in 1994 and has grown tremendously since. RT is used by development teams, help desks, and even youth counseling groups. In short, RT should be your first stop for a non-technical team that needs a ticketing / workflow system. It has an add-on called RTFM for providing documentation, and plenty of community contributed extensions as well. RT can be modified using “scrips” and the project provides a bunch of pre-written scrips that you might find useful in your environment. The 3.8 release that came out this May added dashboards to the mix, which provide users with a quick picture of their assigned tickets, unassigned tickets in the queue, and more. Like Bugzilla, RT provides time tracking and reporting features that any pointy haired boss would love. RT is heavy on email support. It’s possible to set up RT so that you submit tickets via email (good for customers who don’t need an account in RT) and to automate replies to users when tickets are received, resolved, escalated, etc. Like Bugzilla, RT’s flexibility also comes with complexity. Installing RT shouldn’t be difficult, but actually taming it for your organization will take a bit of time. The freely available documentation is also a bit disorganized. It can take some time poking about on the wiki to find what you’re looking for. The good news that there’s a RT book available via O’Reilly, though it is probably not quite up to date with the 3.8 release from May. Nothing Like a Test Drive For large-scale development projects, I suggest making a beeline for Bugzilla. For helpdesks and admin teams, Request Tracker would be the first tool to test, and for smaller development projects and non-development projects I’d look to Trac first. The beauty of open source is, though, that you can take each application for a test drive before deploying it and you never have to deal with licensing hassles or sales calls. Grab the source, slap it on a test server, and see how it handles. One of these three projects is bound to suit your team. Related Information From Dell.com: Solutions and Services to Maximize IT Efficiency.

If open source folks know anything, and they do, it’s how to build tools that enable collaborative development. Case in point: ticketing and issue tracking systems. If your shop needs a reliable, flexible, and scalable ticketing system take a look at Bugzilla, Request Tracker (RT), or Trac to find the best tool to keep your projects on track.

You’ll find a number of proprietary and open source issue trackers that can fit your business, so what gives open source offerings the edge?

The first benefit that comes to mind, of course, is cost. What does it cost to deploy Bugzilla, RT, or Trac? Not a penny, in terms of licensing or support costs. You can pay for support if you like, but the licenses allow you to deploy each of these tools without spending a cent. And, of course, your developers can (if needed) extend and customize each system to fit your particular environment.

But that, alone, isn’t enough. Trac, Bugzilla, and RT are projects that have been widely used for years by hundreds of organizations and open source projects. Open source developers may not always be the best at developing user friendly interfaces, but they’re very good at creating developer-friendly systems. And issue trackers are where most open source communities live.

Bugzilla, Trac, and RT have been battle-tested in the open by a very diverse and demanding group of technical professionals. Open source developers have a saying: “With enough eyeballs, all bugs are shallow.” Imagine the scrutiny that open source issue trackers receive; they’re the tools that open source developers use to develop other tools.

Narrowing the Field

All open source ticketing systems are not created equal. Bugzilla, RT, and Trac are three of a field of open source issue trackers.

Why choose these three? The Bugzilla, RT, and Trac triumvirate are some of the oldest and most widely deployed systems for open source projects. Bugzilla and RT have been around since the late ‘90s; Trac is a relative newcomer, having been introduced in 2006, but already is widely deployed and well-loved by many projects and companies.

I also chose these because of the respective health of the projects. Each project has a healthy community and company behind it. In the case of RT and Trac, you’ll find companies that focus on offering support and services for the projects. Bugzilla’s primary sponsor, Mozilla, doesn’t have commercial support. However, the project is so widely deployed and deeply ingrained in so many open source projects that its continued development is virtually assured. If outside expertise is needed, it shouldn’t be difficult to find consultants who can lend a hand with support or customization.

Bugzilla

The first contender is Bugzilla, and you’d be hard pressed to find a project with a more impressive (or demanding) list of users. Bugzilla is deployed by Apache, OpenOffice.org, Eclipse, Red Hat, Novell, NASA, Facebook, and more than 1,000 others. As a Mozilla project, Bugzilla is freely available under the terms of the Mozilla Public License.

Bugzilla is, as the name implies, primarily about tracking bugs and is very well suited to development environments. This is not to say it’s unsuitable for use by a help desk or another team that needs a ticketing system, but Bugzilla is most famously and widely known as a bug tracking system. Let’s take a look at some of its strengths.

Bugzilla is capable of handling thousands upon thousands of bugs, and multiple projects. A single installation can support multiple databases, so if your organization is supporting internal and external projects, Bugzilla is a good fit.

Written in Perl, Bugzilla works with Oracle, MySQL, or PostgreSQL and with several Web servers – though Apache is recommended.

As one would imagine, Bugzilla supports detailed tickets divided up by products and components. A product might be something like Firefox® 3.6 or openSUSE 11.2, and then components are parts of the larger project. So an organization might have its main Web site classified as a product in Bugzilla, then include different sections of the site as components.

Developers can interact with Bugzilla via its Web interface, or via email, depending on how it’s set up. Bugzilla can also be set up to “whine,” or to send the results of predefined searches via email at specific times. One might set Bugzilla to “whine” at users every Sunday night about their open bugs that are considered blockers for a product.

Another helpful feature in Bugzilla is time tracking. This can allow managers to see how developers and other staff are spending their time, and which features or problems are sucking up the most time.

Out of the box, Bugzilla has a sane set of fields for filing bugs. But if your organization needs to track information that’s not one of Bugzilla’s default fields, Bugzilla 3.0 and later support custom fields.

For many years it was necessary to hack Bugzilla itself to extend the platform. This was unfortunate, as many open source projects needed to add features, and found themselves deviating from the core release – and therefore it was difficult to upgrade to later releases. The 3.6 Bugzilla release that came out in April of this year added extensions, so now it’s possible to extend Bugzilla without modifying the core Bugzilla code. It also means that optional community developed extensions are beginning to appear that enhance Bugzilla’s features.

Another upside to Bugzilla is that it has quite a few supporting applications. You’ll find plenty of browser extensions, add-ons for Thunderbird, Eclipse plugins, and even integration to IRC clients like Colloquy, and quite a few other third-party tools and support applications that make Bugzilla easier to interact with. You can even find tools to integrate Bugzilla with Microsoft Project, though the tools are not open source.

Naturally, Bugzilla integrates well with Mozilla’s automated build system tool, Tinderbox, and with Bonsai CVS query application. Bugzilla has been very widely extended and supplemented by its community of developers.

The downside to Bugzilla is that it’s complex. Very complex. Even though work has been done to streamline and improve its interface, the system is still one that only a techie could love. It’s inadvisable to deploy Bugzilla for any projects or teams that have non-technical users submitting and working with tickets unless you’re willing to supply a great deal of training, hand-holding, and an early happy hour.

Unlike the other offerings I recommend, Bugzilla’s main sponsor doesn’t provide commercial support. However, it’s possible to find quite a few consultants who happily provide support if needed.

Trac

Though Trac is much younger than Bugzilla, it’s become popular in very little time. In part this is due to its more minimalistic approach to tracking issues. It’s possible to migrate bugs to Trac from Bugzilla, Sourceforge, Mantis, and a few other ticketing systems.

Trac is published under a modified BSD-style license which means that there’s very little limit on what you can do with the software and no real restrictions on redistributing modified versions. This is probably not a factor for most organizations, but if you’re thinking about shipping an issue tracking system as part of a project or offering it to your customers, this means you don’t need to offer patches upstream.

Written in Python, Trac integrates with SQLite, MySQL, or PostgreSQL and is well-integrated with the Subversion version control system. It also works with Git, Mercurial, Perforce, and other source control systems with plugins. Trac has a fairly healthy set of plug-ins for everything from creating Gantt charts to providing an XML-RPC interface for remote applications to work with Trac. Though popular, Trac doesn’t quite have the third-party ecosystem that Bugzilla enjoys.

The default tickets in Trac are streamlined and much simpler than in Bugzilla. Whether this is considered a feature or not, depends on the team using it. Trac is probably better suited than Bugzilla for non-development teams and IT projects that aren’t development-related. For instance, if you’re looking for a ticketing system for a team of administrators, Trac is a good option. Trac is also good for development teams, of course.

In addition to tickets, Trac has a good default reporting system that allows you to view things like milestones, and timelines by tickets and changes in the code repository. Trac also includes a repository browser so users can view code stored in a repository attached to Trac along with the changes attached to tickets. If the default reports don’t cut it, it’s possible to write custom reports using standard SQL statements.

Documentation and Trac go hand in hand. It has a built-in wiki, and several open source projects use Trac not only to power their issue tracking and to view their repositories, but also to provide user documentation about the projects.

Search is simple with Trac, simply enter any term and go. Results can be narrowed to changesets, tickets, wiki, or milestones, so if you only want to search the wiki or milestones, and not the Trac tickets themselves, it’s a piece of cake.

Trac is not as robust or full-featured as Bugzilla, but it’s a bit simpler to deploy and probably a better choice for smaller projects.

Request Tracker

Last, but certainly not least, is Request Tracker, usually referred to simply as RT. Developed by Best Practical, RT is written in Perl and works with Apache or Lighttpd, with a MySQL, PostgreSQL, Oracle, or SQLite backend. It’s available under the GNU General Public License (GPL) for deployment on your own servers, and Best Practical provides hosted versions of RT as well.

Of the three, RT is probably the best choice for helpdesks and non-technical teams. RT can be used to create custom workflows and tracking systems that are suitable for all sorts of projects, not just for development. It started life as a help desk system for Wesleyan University in 1994 and has grown tremendously since. RT is used by development teams, help desks, and even youth counseling groups. In short, RT should be your first stop for a non-technical team that needs a ticketing / workflow system.

It has an add-on called RTFM for providing documentation, and plenty of community contributed extensions as well. RT can be modified using “scrips” and the project provides a bunch of pre-written scrips that you might find useful in your environment.

The 3.8 release that came out this May added dashboards to the mix, which provide users with a quick picture of their assigned tickets, unassigned tickets in the queue, and more. Like Bugzilla, RT provides time tracking and reporting features that any pointy haired boss would love.

RT is heavy on email support. It’s possible to set up RT so that you submit tickets via email (good for customers who don’t need an account in RT) and to automate replies to users when tickets are received, resolved, escalated, etc.

Like Bugzilla, RT’s flexibility also comes with complexity. Installing RT shouldn’t be difficult, but actually taming it for your organization will take a bit of time. The freely available documentation is also a bit disorganized. It can take some time poking about on the wiki to find what you’re looking for. The good news that there’s a RT book available via O’Reilly, though it is probably not quite up to date with the 3.8 release from May.

Nothing Like a Test Drive

For large-scale development projects, I suggest making a beeline for Bugzilla. For helpdesks and admin teams, Request Tracker would be the first tool to test, and for smaller development projects and non-development projects I’d look to Trac first.

The beauty of open source is, though, that you can take each application for a test drive before deploying it and you never have to deal with licensing hassles or sales calls. Grab the source, slap it on a test server, and see how it handles. One of these three projects is bound to suit your team.

Related Information From Dell.com: Solutions and Services to Maximize IT Efficiency.