Bug Tracker Blog by Corey Trager

BugTracker.NET versus CounterSoft Gemini

by Corey Trager 23. October 2007 01:35

This is the second in a series of posts that compares BugTracker.NET with other issue tracking systems.  This time, Gemini.

(BugTracker.NET version 2.5.7, Gemini version 2.2.2)

In 2005 somebody at http://vidmar.net/weblog/archive/2005/10/22/2305.aspx wrote

"There are literally hundreds of issue tracking tools out there so it's real pain to pick one. I needed a free one, web enabled and one written in ASP/ASP.NET. So I picked BugTracker.NET. It's small, fast, easy to install and it does what I need.

If I could pick again I would probably go with Gemini."

Those words have haunted me since I first read them in 2005. What does Gemini got that my precious BugTracker.NET doesn’t got?

People who are going through a round of evaluating issue trackers, if they look at BugTracker.NET, they probably also look at Gemini.   One reason is that Gemini can be free too.  It is free for up to 5 users, open source developers, non-profits, and schools. For commercial use, it’s only about $900 per server, no limit on the number of users, and that’s very reasonable.

Another reason why folks look at both is that Gemini runs on the same technologies as does BugTracker.NET: ASP.NET and SQL Server.  When BugTracker.NET and Gemini go head-to-head, I win some and I lose some.

So, why might sombody prefer Gemini over BugTracker.NET?

Well, I think it might be that Gemini is normal, conventional, which isn’t a bad thing. BugTracker.NET (like FogBugz) is unconventional. For example, both systems allow the user to choose which columns are visible in a grid that lists issues. To configure your choice of columns in BugTracker.NET, you edit raw SQL. Now, for folks who are comfortable with SQL, BugTracker.NET lets them express what they want directly, and powerfully, so it is not a bad thing, but it IS an unconventional thing. Even among programmers, only a subset is handy with SQL. BugTracker.NET is raw that way.

To configure your choice of columns in Gemini, you do it with a conventional "mover" – two lists side by side, the columns available for selection on the left, the columns already selected on the right. Just as most people would expect.

Another reason that I suspect leads to some people preferring Gemini over BugTracker.NET is that Gemini seems more ready for a structured, corporate environment where there are rules. BugTracker.NET is more of a rule breaker than a rule enforcer. Gemini has more fields visible, and more required fields – that is – more rules - out-of-the-box than does BugTracker.NET. When I think of BugTracker.NET, I think of words like "agile", "open", "powerful". When I think of Gemini I think, "structured", "controlled", "thorough". Not bad. Just different.

Features Gemini has that BugTracker.NET does not have.

The various issue tracking systems – commercial and free – are all evolving, so whatever features are missing in one today might be added in a couple months. So, if you are reading this a few months from now, October 2007, this might already be out of date. But, at least right now, here are a few features that interest me that Gemini has that BugTracker.NET doesn’t have:

  • Voting. Useful for an open source project that has a broad community.
  • The concept of public/private, or external/internal. For a software consulting business, if you wanted to share the issue tracker with a client, you don’t necessarily want to share all the internal comments, air all your dirty laundry.
  • Time Tracking. Also useful for a consulting business, so you know whom to bill what.
  • BugTracker.NET doesn’t have any means to enforce workflow. Gemini has the concept of creating valid pre and post states for a status. That is, you created a status "ready for testing" that has only the statuses "passed testing" and "failed testing" as valid statuses to transition to. Actually, not only have my users asked for the valid pre/post state concept, but they want different statuses attached to different user roles. That is, only somebody with the tester role is allowed to change the status from "ready for testing" to "tested". Oh, BugTracker.NET doesn’t have roles either. Gemini has roles.

What in Gemini doesn't match my taste

Gemini is under active development, so whatever negatives I write about here might be out-of-date by the time you are reading this. But here’s is what I don’t like about Gemini version 2.2.2:

I sometimes use an issue tracker as a to-do list too, so I want my tracker to allow me to get in, add an entry, and get out real fast. BugTracker.NET lets me do that. For Gemini, you first have to pick a project, then pick a component. Then enter a item, with both a short and a long description, and choose what type of item – bug, enhancement, etc. I'm so impatient, that's already too much.

The step that I don’t understand is picking the component. At my current job, we are working with a distributed app, clients create by one team, servers by another, and dlls used on both sides created by a third team. It can be a difficult to figure out which project/component a given bug is in. Why does Gemini make me decide up front? I don’t understand the concept.

I guess I could work around this obstacle by creating an "unknown" project, "unknown" component, and assigning everything to it as a placeholder. Whatever issue tracker you pick, you’ll have to adapt your practices to it a little bit.

A small thing that annoys me disproportionately is that when I enter a new issue, the screen real-estate is used in such a way that I have to scroll the page to get to the "Submit" button. That’s something that should be easy for Gemini to fix. I would think even the developers at Gemini would get annoyed.

But, the biggest missing piece in Gemini is that unlike BugTracker.NET (and FogBugz), you can’t send an email from the tracker.  You can’t associate an email thread with an item. There’s a risk for a team that uses Gemini that the "real" discussion about an issue will take place in a seperate email thread, outside of the tracker.  I like the trackers that funciton almost like discussion forums, that encourage the thread to stay within the tracker, associated with the item.

A little hard to learn

Gemini has a lot of features. It is mature. There’s a lot to discover, experiment with, get comfortable with. All the more reason why it would be helpful if the designers there could present the features in a way that makes the learning go faster. There's room for improvement here. (Hey, I'm just getting around to the task of creating documentation for BugTracker.NET.  I'm only 5 years late.  But now that I'm doing it I have all self-righteous zeal...)

Gemini does come with a "User Guide" in PDF format that also doubles as its help file. The parts I read were clear enough. But, there’s no HTML help, no help that you can bring up that’s related specifically to the page you are working on Wherever you are, whenever you click on help, you have to wait for the Adobe Reader to load and then you have to use the search within Adobe to find occurrences of the word you are interested in. And if the text in the PDF says, "See the Customization Secton", then you have to hunt for that. It’s clunky.

Even better than HTML help would be verbiage on the page that would make help unnecessary. There is some, but there could be a lot more. For example, here is a snippet from a [web page] and a snippet from their [User Guide].  The User Guide, with just a couple of sentences, makes the concept of status pre/post states clear.  If the Gemini developers could spinkle a few dozen of these sentences throughout the pages, my first experience of Gemini would have been smoother. They could win even more of those head-to-head comparisions with BugTracker.NET

So, have you recently evaluated BugTracker.NET and Gemini both? Please post your comments here.



10/24/2007 1:44:45 PM #

I did evaluate BugTracker.NET vs Gemini (v0.9.something), must be already 2 years ago. I did choose for BugTracker.NET:
- mainly because the features were complete enough for what I wanted to achieve
- because it is open source code, so in the event I wanted/needed to change/fix something, I could
- it was free

This was in a time where the company I used to work for, did not even understand the idea of a bug/issue/work item tracking. Excel was their thing, stored on a shared folder. The development manager was so conservative that I had to find something I could install on a development server without him needing to approve anything. So I did, and after several months, me being able to provide excellent lists of solved vs open issues, remaining work planned, etc. they decided that they wanted a company-wide solution.

So thanks to your work, I was able to lift the level of professional software development in that company.

For the company-wide solution however, I knew that BugTracker.NET would not stand a chance, these people would not trust this tool. I even offered my knowledge and suggested to go with Team Foundation Server (as it integrates Planning, work item tracking and source control all straigt into the VS IDE), but they just ignored all that and went for a Java-based solution. And that for a company that is fully Microsoft SQL oriented.

On a small note of criticism, I did never get comfortable with the 'all in-line code'. I haven't really looked at how the code is organized these days, but that really threw me off a few times.

So thanks for this tool, its a great tool to get started with Bug/Issue/Work item tracking.

Rudi Larno |

10/29/2007 6:43:49 AM #

Rudi - The code is still all in-line. I started coding with just the SDK and a text editor, the same way I started with Java in its early days. The SDK explains the C# language, the library, and the tools. It never mentioned code-behind. That is stricktly a Visual Studio concept which I didn't own at the time. So, I just coded it like classic ASP. I'm not advocating that approach. It's just...what happened.

You can use Visual Studio with it.  It compiles.  You can debug.

You very courteously wrote "small note of criticism". Many other folks have not been so nice. One guy wrote that I should be boycotted because of my coding style!

About the experience in your company: sounds familiar. The human condition.

Which Java solution did they choose? Why?

Corey Trager |

10/29/2007 6:41:47 PM #

Also about Gemini: I really like its screen capture utility.  FogBugz, Gemini, and BugTracker.NET (others?) all have utilities that make it easy to do a screen capture, annotate it, and post it directly to the tracker as a bug or attachment, but Gemini's is the only one that is useful as a standalone app:

Corey Trager |

10/24/2008 2:25:35 AM #

I understand why IT people in a business won't "trust" BugTracker.NET (or probably any software that is free): because they need support when there is an issue with the software they are using. And they believe they get support only when they pay someoneWink However, Having a developer is more expensive in this cases.

Codism |

4/29/2009 4:59:54 AM #

As a tester, workflows and searching are the two most important things in bug trackers. I need to know that when I log a bug, a pesky software engineer cannot just go and close it on me. It's my arse on the line. And searching so I can find bugs quickly, minimize duplicates and generally make my life easier!

Tester |

7/13/2009 9:32:47 PM #

Pingback from answerspluto.com

list of urls 4 « Answers Pluto

answerspluto.com |

Comments are closed

Powered by BlogEngine.NET


Comment RSS