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.