Looking forward to GnuCash 2.4

The actual list of new features is surprisingly short; much of the work in this development cycle has been aimed at internal improvements. Near the top of the list is the ability to use WebKit to render graphs along with GtkHTML. Your editor will confess that he has not tested out this feature; HTML rendering is a tiny part of what GnuCash does, so the availability of an alternative rendering engine is not particularly exciting.

The other headline feature is more interesting, though: the GnuCash developers have added a database backend which is capable of interfacing with Sqlite, MySQL, or PostgreSQL. The XML-based native file format is adequate for personal finance uses (though it is quite bulky), but it does not scale well to the numbers of transactions seen in a typical business setting, and it is not well suited to a multi-user, integrated workflow. GnuCash had a database backend in the 1.6 days, but it was never well supported and it did not work with the GnuCash business features. The database backend in 2.4 has been redone from the beginning, and it supports all of the program's capabilities.

Those wanting to use this feature need to be prepared for a bit of a rough start, though; the related documentation is, one might say, sparse. Actually, this documentation does not exist at all. What your editor figured out is this: users should create an empty database (default name is "gnucash") to hold the accounts. The relevant libdbi drivers must be installed on the system. Then, opening GnuCash and selecting "save to" will yield a dialog with a pulldown at the top; the default value in that pulldown will be "XML". If GnuCash sees any database drivers, the associated databases will show up as options on that menu; selecting "postgres" will allow the accounts to be saved into the selected PostgreSQL database.

A couple of related notes: GnuCash looks in /usr/lib/dbd for the database drivers. Fedora x86-64 puts them in /usr/lib64/dbd. The result is that GnuCash behaves as if the database option simply did not exist. Your editor retains a longstanding grudge against whoever came up with the /usr/lib64 idea; it seems to break every application which it comes into contact with at least once. The other thing to bear in mind is this: if you give GnuCash a password for access to the database, it will store that password - in plain text - in your .gconf directory.

The database-backed mode looks and works almost identically to the file-backed mode. The biggest visible difference is probably the lack of a "save" button; when working with a database, all changes are committed immediately. The program will also populate the working directory with files named like translog.20100517132703.log. Leaving log files lying around is a habit GnuCash has had for a long time, but, in the absence of an accounts file, GnuCash has to improvise when it comes to the naming and location of the log files.

Working from a database should offer some performance advantages when doing searches through large accounts, but that's not the real reason your editor is interested in the feature. What is far more compelling is (1) interoperability with other business processes, and (2) multi-user access to the accounting database. Unfortunately, GnuCash 2.4 does not seem to properly support either of those features.

Even a small business like LWN generates thousands of transactions over the course of a year. Unsurprisingly, it can be quite difficult to find anybody who is interested in typing all of those transactions into the accounting system - especially when "the computer" already knows all about them. In the current system, getting this information into the accounting database is done through a bunch of glue scripts and the always hair-raising QuickBooks import process. Certainly it would be nicer to just store that data directly into the accounting database.

This sort of direct storage is certainly achievable with GnuCash, but it won't be easy. The database schema is surprisingly hard to find; there is a version of it available in an old mailing list posting, but that's about it. Said schema is heavily reliant on GnuCash's "GUID" type - a 32-character ASCII representation of a 16-byte internal object identifier. So even storing a simple transaction requires generating new GUIDs and digging around to find the other GUIDs necessary to tie the transaction in properly. It is, in other words, messy, error-prone, and just crying for a nice API that could be called at a higher level. One assumes that said API will exist in library form someday, but it is not there now.

Parallel access is not there either; the FAQ is clear on the subject:

This makes storing the accounts in a centrally-located database actively dangerous. If GnuCash cannot have two clients running safely with the same database, it should go out of its way to prevent that from happening (as it does with the file backend). But there are no checks for concurrent access in the current 2.3.12 development release.

While GnuCash does have some support for dealing with various tax regimes, it's still not where it needs to be to displace other applications. Among other things, it simply has no provision for storing some of the required information. LWN, being a US-based business, needs to track which of its authors needs to receive 1099 forms at the end of the year and produce those forms at the right time. The production side could perhaps be made to work relatively easily: GnuCash has a scripting engine which enables the creation of custom reports - as long as the user is not afraid of programming in Scheme. But, without the ability to track who needs those forms (and their tax numbers), the report generator simply lacks the information it needs.

Time for one final grumble. In current stable GnuCash, the QIF importer (useful for importing credit card transactions, for example) is fast, efficient, and flexible. In 2.3, importing has turned into a slow, click-intensive, error-prone process. Users are supposed to classify transactions without seeing the amount of each, for some strange reason. In general, GnuCash is moving forward in this release, but importing transactions has regressed.

Import dialogs notwithstanding, the general appearance of GnuCash has changed little in this cycle. It remains the solid, workhorse financial management program that your editor has used for years. For those who would like to see a bigger change, there is something on the horizon, though it doesn't look like it will be ready for the 2.4 release. The Cutecash project has set itself the goal of taking the GnuCash engine and putting a Qt-based interface onto it. It will be interesting to see where the developers go with this project.

Meanwhile, lest your editor seem just a little too grumpy, let it be said that GnuCash seems to be headed in the right direction. It has been more than good enough for most personal finance management for some time, and it is slowly developing the features it will need to compete in the business area. One of these years it should start displacing proprietary accounting tools in a serious way.