- Table of Contents
- 1. GnuCash
This popular GPL-licensed software is quite popular for use on Linux and other Unix -like operating systems for managing personal finances. It has increasing capabilities for some basic business accounting, too.
1. GnuCash
Major components being used and/or integrated into GnuCash include:
Scheme bindings have been created using G-Wrap so that configuration can be done in Scheme.
In a recent source code tree, there were 156 Guile scripts, adding up to 1.7MB of code; in the Debian GnuCash install, 148 of these, adding to 1.4MB of code, are included.
In contrast, the same source tree includes 433 C files, adding up to 1.85 MB of code.
It's probably fair to say that GnuCash is about the largest and most sophisticated application of Guile . Reports are almost exclusively implemented in Scheme, as is most of the QIF import code, as well as quite a lot of user interface control code.
GnuCash is implemented using the GTk library, and links in numerous other GNOME libraries. Originally, Xacc, the predecessor to GnuCash, was implemented using Motif , and GTk was initially created to replace Motif in the GIMP . But the links to GNOME have not remained terribly deep:
Originally, GNOME was to use Guile heavily as the "standard" scripting language. GnuCash has done that, enthusiastically, but no scripting language has really become ubiquitous for GNOME.
While there has occasionally been talk (I once submitted a " first draft" of some CORBA IDL ), CORBA hasn't been used for interprocess communications.
The Bonobo object embedding system has been discussed, but not used.
GNOME Canvas is a substrate for " drawing stuff"; GnuCash uses a complex custom " register widget" (that represents most of the C in the application), and reports are generated in what amounts to HTML.
The main GNOME application that GnuCash does use is Guppi, a graph plotting component.
People often come along proposing that it would be a wonderful idea to have a Qt / KDE front end for GnuCash.
On the one hand, since GnuCash is implemented as an "engine" that the front end communicates with, it would seem quite reasonable to have an extra front end.
On the other hand, the " register" code used to display and edit transactions on screen represents 900K, roughly half of the C source code, and is, far and away, the most complex part of the application.
And this is exactly the portion that would have to be completely reimplemented, from scratch, in C++, using a fairly radically different GUI toolkit, in order to have a KDE version.
Originally, GnuCash was called Xacc, and used the Motif toolkit, storing data in what amounted to dumps of C data structures to disk.
With the move to GNOME , XML libraries were introduced, and as the ultimate result of a lot of lobbying (including from me :-)), the primary storage format migrated to being based on XML.
As a result, data is stored as a " tree" of XML elements, with notable abstractions as <account>, <currency>, <transaction>, and <split>.
Since XML is intended to be extensible, there have been further extensions to support additional functionality such as transaction scheduling, where the system can "automagically " add transactions that recur on a regular basis.
Some might imagine that this use of XML would lead to some form of interoperability, but that is a fallacy here, as is normally the case; all XML really buys you is the ability to have a bunch of parsers that can read the data. In order to use data in an interoperable manner, you need agreement on the definitions of elements, where they occur, and what they mean. In practice, the only program that knows how to do this with GnuCash data is GnuCash itself.
There has also been some suggestion that, instead of XML, Scheme S-Expressions should be used. This would eliminate the need for an XML parser, and put the "burden " onto Guile, which already loads ~1.8MB of code into GnuCash. S-Expressions are certainly terser than XML, and easier to work with, in parenthesis-aware editors, like Emacs . Future interest is heading towards using SQL databases, which is a much bigger change.
There is now some integration of an SQL Relational Database, specifically using PostgreSQL .
There is an SQL schema for storing GnuCash data, with some 34-odd tables supporting the base transaction functionality. The schema has not yet been extended to support scheduled transactions, though that will doubtless happen, at some point.
A major merit of this is that this changes the nature of a set of books; with the XML format, the books are a " document", and you must save the entire document every session. In contrast, using a database, you " connect to the database", and " save" the information after every transaction.
If you are running a sizable business, you surely don't want to need to rewrite the entire set of accounting records every time you press a " save" button. If there are a million transactions, you may not have enough memory to load them all in to your computer.
Furthermore, if multiple people might want to update accounting records concurrently, the XML format is utterly unacceptable, providing no ability for multiple users to work with the data concurrently. " Concurrent access" is part of the RDBMS " raison d'etre", and is something PostgreSQL, with its implementation of MVCC (Multi Version Concurrency Control), is particularly good at.
GnuCash uses the Perl module
Finance::Quoteto download prices for the investments in your stock portfolio.Documentation originally was written in HTML . I translated that into DocBook SGML, and it has recently been redeployed into DocBook XML, which is then transformed into HTML to generate a consistent documentation "tree".
OFX Integration
Long discussed, a reasonable OFX loader has recently been getting usable.
OFX stands for Open Financial Exchange, and represents a set of specifications defined by a joint venture between CheckFree Corp., Intuit Inc., and Microsoft. It involves not one, but about three things:
A specification for data interchange. Originally, OFX data was defined using an SGML set of entities and attributes. More recently, it has been rewritten to use XML.
The data representation is fairly similar to the popular QIF (Quicken Interchange Format) , providing a SGML / XML schema to describe financial transactions. OFX is considerably more expressive, including tags to describe payroll deductions, stock transactions, loan payment transactions, and the likes.
Some financial institutions (generally the " early adoptors") use SGML; others use the XML form, so it's not safe to assume one or the other.
The other most visible manifestation of OFX technology is that of the servers implemented that generate OFX documents.
The OFX Consortium has a standardization program that encourages financial institutions and "billing companies" to implement servers to support OFX services, notably:
Banking
Which is all about enabling customers to download transactions from their financial institution
Bill payment
Where customers may submit OFX documents that describe payments they wish to make
Bill Presentment
Which is a fancy way of describing "electronic delivery of bills"
Investment
Which enables customers to download details about their investment accounts, including transactions, balances, and the likes.
There was supposed to be a certification process to validate that servers are correctly implemented, but this appears to have fallen by the wayside:
Typically, OFX clients work directly with the companies providing OFX services to assure proper OFX integration.
That's about what you'd expect to happen to a "standards" process when two of the three parties involved are Intuit and Microsoft.
The third piece of the puzzle is the OFX client, which everyone expected to be Quicken and MS Money and basically nothing else.
GnuCash is one of the few other products that use OFX
A read-only version of the CVS tree for GnuCash is available on the net. To access it, first, login thus:
% cvs -d :pserver:cvs@linas.org:/home/cvs/cvsroot login
The password is guest.
To get a copy of the source, do a
cvs -d :pserver:cvs@linas.org:/home/cvs/cvsroot checkout xacc
There is an archive of the gnucash-devel Mailing List
Several attempts were made to commercialize the development efforts:
When " Anything For Linux" could attract venture capital, the company Gnumetric was founded, and paid several developers, for a while, to work on GnuCash.
One of the better ideas they had to actually have anything to sell to attract money involved writing improved ("not-open-source") documentation, and using that as an excuse for selling boxed sets.
When the " tech bubble" burst in early 2001, there was no more faith that it was worth investing in the possibility of that happening.
Linux Developers Group, Inc.
Some of the GnuCash developers started this company, developing POS (Point of Sale) software to integrate with GnuCash , with the plan of making money selling the extras. Unfortunately, OpenCheckout didn't turn out to be sufficiently profitable to pay their bills.