Introducing Krash Accounts

We have some really talented people volunteering at Bristol Wireless. One of them is Jules, our treasurer. Jules got really frustrated at the lack of a decent accounts package for Linux. There is GNUCash of course, which we’ve reviewed in the past, and KMyMoney. However, neither of these is really up for doing a proper professional job, so Jules decided to start writing his own, which he’s named Krash Accounts.

Over the weekend, your correspondent interviewed Jules by email about Krash Accounts.

1. How did the name Krash Accounts come about?

Krash was so named after a Windows system I was running Quickbooks on crashed for the umpteenth time. I decided that rather than go through the “lets rebuild Windows and rescue the data” cycle yet again, it would just be simpler and ultimately more time and cost efficient to build a new system based on a reliable operating system such as Linux. It was originally called “Crash Accounts” but my accountant Germanicised the name with the “K” for reasons know only to himself.

2. How long has Krash Accounts been in development?

About four years, on and off. The earliest date I can find in the source code is March 2010, but this was an “update” to Version 1 standards of the very basic first system, so in the mists of time it’s actually a bit older than four years.

3. What persuaded you to develop Krash Accounts?

Apart from the continual Windows system crashes mentioned above, I also had a great need for a system that could be accessed “any time, any place, any where” so from day one Krash has been a web-interfaced, cloud based system. I was also fed up of being locked in by proprietary systems that I could not change myself to make them do exactly what I needed – no two organisations have the same needs and proprietary software just doesn’t recognize this. At best, it tries to be all things to all people and ends up serving nobody particularly satisfactorily.

4. I understand Krash Accounts has some unique features. What are they?

The first two client companies to run on Krash Accounts were a charity and a co-operative, so not your run of the mill commercial businesses! The charity needed UK Gift Aid processing of members’ donations and the co-operative had its own special needs too. None of this functionality was then available in any mainstream accounts package, so it was easier to write it into Krash Accounts myself. Also, as the system was always intended to serve multiple organisations and is thus fully “multi-company”. The one installation that currently exists and is active serves its diverse range of user companies from one single database and a single code base.

I then moved to America for a while and a business over there showed considerable interest in the package, with the result the whole thing had to be made to run in multi-currency mode and to handle US Sales Tax rather than EU VAT, both of which were major jobs that were completed two years ago and are both running very successfully now.

5. Why have you decided to release Krash Accounts as open source?

Apart from being an avid believer in Open Source software in principle, at this stage I believe that to Open Source Krash is the best business model and way forward for the project as a whole. To openly share the source code will allow the world at large to access and run the project and to provide their joint efforts and feedback into growing the system and making it bigger, better and vitally, more supportable. I have no wish to try and sell a system against existing commercial operators when I have neither the desire nor the infrastructure established to grow a product commercially and to support it single-handed. Why on earth would anybody want to base their business on a closely guarded product from a “one man band”?

Open Source is therefore the only way forward for a product such as Krash. By releasing it as Open Source, I am hoping there will be an extensive and rapid take up of the product by the Open Source community, without the need for an expensive marketing and promotional campaign and all that goes with it. There certainly appears to be a lot of interest in Krash Accounts out there already!

I did look at existing Open Source accounting software packages before I started writing Krash myself and whilst some offerings came close, there wasn’t one that did exactly what I wanted and had a usable interface. For example, American-designed systems simply don’t understand EU VAT properly and European-designed systems just don’t “get” US state-by-state sales tax either. Why should they? But a key understanding of the core processes is vital to database design, so unless this is correct from the start, you are kind of stumped from day one. However, by taking the Open Source route from a well structured beginning, programmers across the world can localize and enhance the product to meet their own needs – and the best ideas we can roll back into the core version to the benefit of all.

A lot of people have asked how we intend to finance the project on an on-going basis? Well, let me explain a little about the models for Open Source in general – the Open Source community will be already well aware of these practices – but many who are still addicted to proprietary software will need a little help and explanation, so the following paragraphs are for them:

Firstly, having launched the project as Open Source, I am hoping it will quickly build a small troop of core developers and users, who will take the project to heart, rapidly bring it forward, spread the word and provide a willing 24/7, world-wide support and development team. Whilst anybody, under the terms of the licence, will be welcome, entitled (and even encouraged!) to download and run the package on their own servers, we will also host the package on our own site on a “freemium” basis – that is, we will operate it free for smaller users who don’t need support, whereas for larger users or those requiring guaranteed support, we will make a small charge and use that income to support the project and its developers.

This is a similar model to that used by WordPress etc. but as with them, at no point is there any “vendor lock-in” and any user is free to download the source and take their own version forward on their own server at any time. Imagine Microsoft allowing you to do that! That’s the difference we are talking about with Open Source.

Secondly, not everybody is able to do their own programming – it’s a complex and time consuming job – so, we will offer to make the enhancements users want on a paid basis, which if relevant will be shared back into the core product for all to benefit from. We’ll probably do this on an auction style basis, where users can “bid” for the work they want done – either by starting a bid for a piece of work themselves or jointly, by pledging to the bids others have already made. It’s a democratic and efficient process – the work perceived by users in general to be of the most value will go to the top of the wanted list – and undertaking this work will enable us to support the project long term. Can you imagine Intuit or Sage opening up their development stream in that way? Not likely!!

6. Krash Accounts is currently a web/cloud-based accounts package. Do you have any plans for a desktop version?

None whatsoever actually! Krash Accounts’ natural interface is and always has been web based and with HTML5, that becomes even more practical to use. So anybody that wants to run Krash Accounts locally can just install it on their intranet server and get on with it. I really don’t see the physical lock-in that desktop apps enforce as really justifying a dedicated desktop app any more, except where the client processing load is exceptionally heavy, which it isn’t with straightforward transaction based systems such as Krash Accounts.

As Krash Accounts has had a basic HTML and Javascript interface from the outset, it is actually an ideal candidate for mobile, so if we are going to do anything on the app front, it’ll be aimed solidly at mobile. This is the way the world is going.

We’ve also looked at the needs of emerging markets, for example, Africa, where mobile use for commerce has sky-rocketed, but to the surprise of many in the Western world, this is mostly based on basic handsets and SMS text messaging. Old hat to people in the developed world, but still a heavily emerging technology in countries like Kenya. So I’m not saying that at some point, we won’t bolt an SMS-based interface onto Krash.

Watch this space – it’s all ultimately do-able through the power of the Open Source community.