My latest side project, the Omega Issue Tracker, turned 1 — that’s 1 year old and v1 — this past week. Issue tracking isn’t a very sexy topic, but every (good) software team needs it and some solutions are better than others. If you’re on a small team that wants to minimize overhead (like I am), then Ω is likely a good fit for you. It’s completely free, so try it out and let me know what you think.
In celebration of Ω’s birthday, here’s the lowdown on how it came to be.
It started as a joke
A year ago, two of us at Pulse Energy were pairing up on a new feature. It didn’t take long to realize we needed a way to coordinate what needed done and who was doing it, but we knew that JIRA (our usual issue tracker) would only slow us down.
So we start issue tracking via instant messaging. Something like this:
David: OMEGA ISSUE TRACKING SYSTEM David: Ω1 resource icons are misaligned David: Ω2 consumption chart not refreshing on resource selection David: hmm we need a way to assign issues… Neil: @Ω2 David: nice David: @Ω1 Neil: Ω3 title may overlap the building details on RHS …
And you know what? IM worked surprisingly well. We had a central place to record issues and chat notifications (Growl or its kin) kept us in sync without breaking stride.
The next project, with a larger team (group chat!), revealed that the approach scales poorly without automation. I was copying and pasting the issues list from Evernote at one point. Then a “Big Idea Day” came along (Pulse’s version of Fedex ShipIt Day) and, a few hours later, Ω was born.
Today, Ω is in daily use at Pulse. Even our marketing team has been using it.
Making it real
We decided to use this as an opportunity to experiment with node.js and websockets. See our package.json for the technologies we ended up using. Of course, many of those dependencies came later. Express, RequireJS and LESS weren’t needed until the app grew a little.
Early version of Ω. Notice any IM client similarity?
Avoiding featuritis
Most issue tracking software out there is bloated. Many so-called features end up slowing you down, and stifling productivity is never a feature. I hate to point fingers, but JIRA is such an easy target. In its latest incarnation, the “Create Issue” form has so many fields that it can’t fit on a single screen. Fun fact: JIRA is named after a giant mutant dinosaur.
One of our primary goals with Ω was to stay fast and light, adhering strictly to YAGNI. We started dogfooding as soon as possible and I think that helped significantly too. Thus:
Issues have descriptions, but no titles
Status is restricted to open or closed
There are no issue types (so no need to worry about bug vs feature)
The best part: you can always tag issues however you like.
What’s next?
There are lots of usability improvements on the roadmap:
Ω31: hit up to cycle through input history
Ω40: should be able to create issue references in chat (possibly shown as pseudo-comments beside referenced issue)
Ω43: inline editing of issues
One aspect of Ω that I’m currently dissatisfied with is that I can’t make our Ω dev project public. Instead, I have to partly rely on the Github issue tracker. That just feels wrong.
To open up our project to the world would require permissions, which means authentication. It’s a slippery slope. I really like the idea of a hosted app that everyone can use without worrying about security.
What do you think?