GnuCash Project Goals

The people behind GnuCash aim to create a world-class GPL'ed Open Source Personal Financial Application for GNU/Linux and other Unix's. This page aims to review some of the technical and development issues surrounding this product, representing a sort of FAQ for developers and contributors, to suggest directions when developers are trying to determine how to implement new functionality.

To get a better idea of what GnuCash is and what it does, visit its home page.

There are currently several different versions of GnuCash.

The current stable, production release is gnucash-1.2.x and is based on the Open Group's Motif GUI library.
However, development efforts have almost entirely switched over to Gnome and GTK; the Motif version will likely fall by the wayside.
Note that some more experimental versions, such as one using the Qt library from Troll Tech FOR the for the KDE desktop, PalmComputing platforms, as well as a Java-based version have been discussed and/or started.

The latest Gnome version, and latest versions in general, are currently available only via CVS.

Precompiled versions are available, but usually only for the stable releases. Don't use the unstable versions unless you are ready for excitement and adventure, and are prepared to cope with a need to keep extensive backups.

This document is divided into several sections.

Architectural Goals
Feature Requirements
Features

Architectural Goals

There are some over-reaching design principles and philosophies that we intend to maintain. Some of these concepts and terms are introduced in this section.

Separation of GUI and Data

First, we must maintain a clean separation between the data structures and the GUI that manipulates them, along the lines of the Model-View-Controller paradigm.

Lists of accounts and the transactions in them can be thought of as a representation of financial data, a Model.
The GUI that adds, modifies and deletes these should be thought of as a manipulator of the data, a Controller.
Thus, the Motif or Gnome GUIs are merely two possible manipulators of the data; others, based on e.g. Qt/KDE, emacs, Java applets or Java servlets ought to be possible.
The View of the data is a subset or slice of the data described by the Model. The View may consist of only the transactions for the month of May, or only the account totals for certain accounts. The View is used in part to generate the reports and graphs, but it is also that which the Controller interacts with.

GnuCash also needs to deal with multiple distributed data sources: stock quotations from the net or transaction confirmations from online banks and brokerage houses, or from more mundane sources, such as file imports, or merger of data from several users.

Amongst these terms, the concept of a global Model-View is dated, and somewhat inappropriate. Rather, we need to be concerned about how data is represented in the local address space of the GUI, how the GUI manipulates it, how data is brought in and merged from external sources, and how that data is again output, whether to a file or a local or remote database.

Thus, the View essentially represents a local data cache of the data that is immediately present and being displayed, reported, and manipulated. The Model is the abstraction of that data that the GUI (the controller) can act on.

The Financial Engine

In GnuCash, the Model is implemented via the Engine API, and the View is the data that is currently in the Engine. Thus, the Engine is a set of programming API's that the GUI (or a script, or even a clever command-line-addict) can use to manipulate the data.

Currently, the Engine is fairly poor, and is tightly tied to the data structures that the GUI manipulates. These data structures include:

Transactions
Transaction entries (splits)
Accounts
Hierarchies of Accounts

The Engine has a very simple apply/commit model, and a simple query mechanism for generating reports and views.

The Engine currently handles only a small set of data sources:

It can import and merge in QIF's;
It can read and write its own binary byte stream;
It can get stock quotes from the net.

However, since the Engine is meant to be the interface between the GUI and the financial data, it is really intended to be able to do much more.

In particular, it should be possible to back the Engine onto an SQL database, and thereby enable multiple users and/or interface to more complex accounting systems. The engine should also be expandable to handle other sources of data, such as OFX, Integrion GOLD, the Open Trading Protocol, the OMG CORBA General Ledger submission, the IBM San Francisco business objects, or closer to home, Linux Kontor. In particular, it should be possible to use GnuCash not only to view data from these sources, but also to manipulate it and send it back.

Modularity, Extensibility and Customization

The above structure should leads us to view GnuCash not so much as a tightly integrated application, but rather as a loose confederation of component objects, libraries and interfaces.

In order to facilitate the gluing together of these parts, as well as simplify the questions of customizability, change and rapid development, GnuCash makes use of an extension language to glue the pieces together.

The extension language that is most central to Gnucash is Scheme, and in particular, the FSF implementation, Guile, although some of the interfaces are also available through Perl.

Markets and Users

Implicit in this desire for extensibility is the need to build financial applications supporting two major classes of users:

Home Users
Small Business Users

They may use some of the same financial terminology, and hopefully might share a fair bit of code, but have quite different goals and requirements.

Personal Finance Needs

Important properties of a personal finance system include:

Needs to be approachable to occasional users that are not terribly knowledgeable about accounting.
Ease of use by the naive is critical.
There is a need for a profiglate set of reports, graphs, charts, and tools for personal finance, such as mortgage calculations.
Budgeting support needs to be targeted at naive users.
Interfaces to on-line banking, shopping, stock systems.
Support for management of stock portfolios that may involve considerable sophistication, since individuals commonly have retirement plans that hold mutual funds, stocks, options, bonds, and the like.

Small Business Needs

With a business system, it is likely that there will be full-time users, which puts the emphasis on efficiency of user interface rather than on its approachability to naive users.
Business systems require network support, and the ability to support multiple simultaneous users.
Small businesses do not often have sophisticated investment portfolios; they instead need support for additional sophistication in such areas as:
- Payroll
- Inventory Control
- Shipping and Receiving
- Accounts Receivable
- Accounts Payable
- Asset Management
Support for calculations associated with accrual accounting.
Ambitions for the future might include interfaces to online shopping carts, credit card clearing interfaces, and ERP systems.

Reconciling Those Needs

A seemingly contradictory factor is that the kinds of sophistication that are required vary considerably. Consider:

A home user does not generally require most of the sophistication (sophistry?) of accrual accounting that is required by business enterprises.
Thus, home users don't need much of the sophistication of an Accounts Receivable or Payable system, or the bizarre depreciation policies that crop up in Asset Management systems.
On the other hand, home users are in increasing need of surprisingly sophisticated financial tools for managing stock portfolios, including:
- Mutual funds
- Retirement savings plans, with such identifiers as 401(k), IRA, Roth IRA, RRSP
- Corporate stock purchase plans
- Corporate option plans

It may be that these will require completely different systems, and that GnuCash cannot be "all things to all people." This remains to be seen.

Feature Requirements

Personal Financial Application

Below are listed the technical work items needed to implement the features that home users might hope to have. They are listed in approximate order of priority.

The right hand column shows a sizing guesstimate. pm == person-months

Small 0 to 4 pm
Medium 3 to 12 pm
Large More than 12 pm

Feature	Sizing

Internationalization	Small
Graphs, Reports	Medium
Simplified Stock Ledger	Small
Themes, Icons, Glitz	Medium
Books, Accounting Periods	Small
Check Printing	Small
User Preferences	Medium
Extension Language Support	Medium
Bonds and Interest Bearing Instruments	Small
401K etc.	Small
Annotate with Investment News	Small
Loan and Mortgage Calculators	Small
Budgeting	Medium
Alerts, Recurring Transactions	Medium
Quicken(TM) Export	Small
Stock Quotes, Price Quotes	Small
OFX, Online Banking, Trading, Billpay	Large
Multiple Currencies	Medium
Double Entry Accounting	Small
Tab-delimited ASCII export	Small
Tax Preparation	Large
Sync with Palm Pilot organizers	Medium
Emergency Records Organizer	Small