I Love These Building Blocks
Two months ago, after a lot of contemplation, doubt and internal resistance, I’ve started a small project to address some of the problems I had with how most of us do issue tracking in our projects.
A range of things bothered me. For example, weak offline operations support — even if I download a bunch of JSONs and read through them, I can’t really prepare a bunch of changes and send them out next time I am connected — not without some considerable amount of scripting.
Another, bigger issue for me was that issue tracking as we know it, is primarily linear. Changes to issues happen globally and can hardly accommodate the subtlety of development and release processes (such as backporting). Has this issue been closed just on master, or on release branches as well? Can we open issues on a subject X automatically once a patch introducing X has been merged in? None of that seemed to be particularly easy with existing tools (especially well-maintained ones).
Yet another concern was centralization of issue databases. It is not just a conceptual problem, but rather a practical one — outages are real, whether in your data center or Amazon’s. They happen to everyone. Say hello to #jiradown Fridays and #githubdown Mondays!
It is of course easier to develop centralized services because this is the most conventional approach, with the tooling and business models refined rather well. But the world and the internet are not “always on” — in fact, in reality, there’s always something broken. So, wouldn’t it be wise to find solutions that don’t come to a halt in a case of network disruption? At least when it’s feasible.
Am I done listing? Not quite. Operational complexity — many of these systems require maintaining a server — HTTP reverse proxy, application server, database, backups, firewall, operating system upgrades, etc. While it’s all fairly standard, there is a certain level of complexity that you will have to endure. Sure, you can solve this by outsourcing these operations to a hosted service, but that’s just a band-aid.
In the name of simplicity, the functionality of most tools in this space is rather limited or rigid. You can’t simply add a completely new feature without a considerable amount of work… if the solution is open source to begin with (looking at you, GitHub Issues). At most you can change fields and change the workflow. And I get it. You can’t satisfy everyone, so you’ve got to pick your fight. That’s the functionality you release. But the lack of the ability to easily adapt, re-compose and grow such solutions… has always left me desiring for more.
There were more reasons than I can safely share here without risking of scaring readers away from reading further. So you will have to take my word for it, and if you’re still curious — just ping me. I’ll be happy to share more.
Anyway. For all these mentioned and unmentioned reasons, SIT (or Serverless Issue Tracker), was born. It worked out rather well. The ease at which I was able to develop it was a good enough indicator for me that I am on the right track. It’s when things lead you to a dead-end or insurmountable problems you know your ideas might not have been the best. But so far, this project has only been filled with challenges that were rather exciting to solve. It’s already usable and provides some really nice workflows.
SIT is built on a very simple foundation of keeping immutable chains of records — simply as sets of directories, sprinkled with a reasonable number of conventions on top of them. Something not too dissimilar from event sourcing. It’s aspiring to be low-to-zero-tech in a sense that the stack of technologies is rather small, especially at the core. Even things like Git are not required — SIT stores the entire history itself (although it’s very useful to use SIT in combination with Git!)
Shortly after the releasing SIT 0.2.0, with no lack of immediate items to work on for the next releases, I instead slowed down because I had a rather important realization.
I realized that another dream of my own, a better version of plain-text accounting, would be much closer to reality if I just used SIT to run it. Why? Well, because what is accounting? It’s a record of transactions. So I can record these and invoices and whatever else I need in those SIT records and be able to produce meaningful output (such as balances, reports and so on) using reducers. And I get the rest of the functionality (decentralization, tooling, etc.) right from SIT, without any extra work. Isn’t that exciting?
And then I couldn’t just stop thinking about other use cases. I’ve long had an idea to organize a small community website to review and annotate scientific papers to bring more clarity and understanding in what they are useful for, how they can be used and what are they related to. But guess what? This also fits SIT pretty nicely as the annotations can be easily done as records.. and we can easily store the papers in SIT because every SIT record is nothing but a collection of files…
So, this is where I want to take SIT. The amount of changes that will be required is surprisingly small. Issues will have to be renamed to something like items. Support for explicit schemas will have to be added (we don’t want to be lost in the sea of incompatible and misunderstood objects). SIT will become an Information Tracker instead of an Issue Tracker and issue tracking will become one of its standard modules.
Gotta love those building blocks…
