Grumpy Editor's next project
When your editor posted
, he certainly did not anticipate that it
would take more than a year and a half for the next installment to be
written. Or that, even after all that time, the project of moving
LWN's accounting from proprietary software to free software would be
incomplete. But the world is full of surprises, even in places where
surprises are most unwelcome - like accounting. Happily, your editor's
surprises do not involve counterparty risk, credit-default swaps, or
anything else of that sort.
So why has this project taken so long? What it came down to is that your
editor concluded that he was not sufficiently qualified to rip out a
functioning accounting system and replace it with something out of a CVS
server somewhere. There is simply too much to know about how the
accounting system ties into the company's operations, how our accountant
uses it, and how it helps keep the tax agencies happy and the company's
officers out of jail. That latter point became especially relevant as
LWN's longtime bookkeeper and occasional contributor Dennis Tenney headed
off to pursue other opportunities, leaving your editor to take up the
legally-liable Treasurer position.
In other words, swapping out the accounting system isn't something to be
done on a whim, like, say, putting an -rc1 development kernel onto the
production server. Whatever is there has to work. So your editor
concluded that the first step in this process was to take over the existing
system and come to understand it well enough to be able to properly think
about a replacement. After closing out the 2008 books, your editor is able
to come to a preliminary conclusion: it is almost possible for a
small business to dump a system like QuickBooks and use a free
There is an interesting gap in the free software community's offerings
in this area. A very small business - one involving a sole
proprietor, for example - can use a tool like GnuCash to great effect.
Almost everything which is needed is there, and most functions work quite
well. On the other hand, a very large operation wanting to install a
full-scale ERP system has a wealth of options: Compiere, Adempiere, various packages based on
OFBiz, and more. If your operation
is willing and able to dedicate full-time staff to developing a customized
ERP system and keeping it going, there are plenty of frameworks to start
with. These systems are not drop-in tools usable by a small
Small businesses occupy a niche between the sole proprietor and the massive
enterprise. At this level, there's not a whole lot available from the free
software community. The most active projects appear to be SQL-Ledger, its fork LedgerSMB, and PostBooks. All three work on
top of a PostgreSQL database; SQL-Ledger and LedgerSMB are web-based, while
PostBooks is a Qt application. Your editor's sense, at this point, is that
PostBooks looks like the most advanced, most ambitious, and most
actively-developed project among these three. It is, however, tricky to
get running, its development model appears to be strongly cathedral-style
(there isn't even a project mailing list), and it is distributed under the
questionably-free (though OSI-certified) CPAL license. PostBooks has the
look of a classic piece of corporate-controlled open source.
Any of the packages listed above (and GnuCash too) will do basic
double-entry accounting. They can produce pie charts, reconcile accounts,
and so on. Since they use PostgreSQL with an open (if sometimes poorly
documented) schema, integrating them with the rest of the business should
be relatively straightforward. They are, in essence, almost everything
which is needed to enable a business to move away from a package like
The key word is "almost." As far as your editor can tell, there are two
crucial bits missing.
The key word is "almost." As far as your editor can tell, there are two
crucial bits missing: tax form printing and accountant interfaces.
On the first point: this is the time of year when LWN produces 1099 forms
for each of its guest authors - at least, for those who pay their tribute
to the U.S. A related form (1096) then goes off to the Internal Revenue
Service so they can
ensure that none of our authors tries to hide the vast amounts of money we
pay them. A tool like QuickBooks tracks payments to outside contractors,
and will happily print the requisite forms onto special stock which can be
purchased, at exorbitant prices, directly from the application itself.
There is no equivalent functionality in the free packages, currently.
In truth, this is an area where free software tends to struggle. The
printing of tax forms is just not a task which inspires hackers; it is
tedious, subject to highly finicky requirements, and is, for all that it
may be considered necessary, somewhat distasteful. This work must be
revisited every year as the requirements are subject to the whims of
legislators and regulatory agencies. And, lest that challenge seem
insufficient, one should also bear in mind that every country's
requirements are different, so all this work must be repeated many times
Creating this kind of code (and keeping it current) is not
fun, it requires some specialized domain knowledge, and it can carry
certain kinds of legal liabilities. So it's no wonder that a hacker with
some free time will, upon considering this kind of task, usually decide to
enhancing that Klingon translation of OpenOffice.org instead. The Klingons
tend to be more forgiving of bugs.
On the accounting side, the problem gets even worse. A typical business
accountant uses proprietary software which, in turn, contains a great deal of
the tax code. Not all countries have a tax system as twisted and complex
as the U.S., but the problem is never simple. Your editor believes that it
would be entirely reasonable to require governments to provide free
software which interprets its tax codes for ordinary citizens, along with a
guarantee that, as long as said citizens fed honest numbers to the system,
they would not be subject to penalties if the resulting tax calculation
were incorrect. In the real world, though, the job of providing such
software falls to companies with a squad of on-staff tax lawyers and a
firmly proprietary approach to software distribution. That situation does
not appear to be likely to change anytime soon.
For the accountant to use his proprietary tools to come to conclusions
about a company's tax situation, he must be able to enter quite a bit of
data about where the company's money came from and how it was used. There
are a couple of ways in which this can be done: (1) it can be manually
entered, at great expense to the company involved, or (2) it can be
directly imported from the company's accounting system for free. Small
companies tend to be quite sensitive to things involving increased
expenses, especially when the expense is for an already unwelcome task like
tax compliance. So there is great value in having an accounting system
which can export data directly to an accountant's tax preparation tools.
In an ideal world, there would be a nice, XML-based format involving large
numbers of acronyms which would make this interoperability possible. In
the real world, these formats are proprietary and undocumented. So
exporting data to the accountant is not really possible with free tools.
And that is the single biggest roadblock to the use of free accounting
software in any company whose accounts are even remotely complex. Until
free programs can export something which looks like the QuickBooks
"accountant's copy," they will not be usable in this context.
What makes this situation even more sad is that, as your editor can now
attest through painful experience, QuickBooks really does not have much
else to offer. Its interfaces are tedious and error-prone; in many ways,
free software has done a much better job. As an example, GnuCash will
happily import account data from a bank or credit card company, apply
default accounts (categories) learned from experience, filter out any
duplicate entries, and allow the user to verify and adjust the whole
operation before applying it. QuickBooks is, shall we say, nowhere near as
accommodating. Your editor ran into a bug (in QuickBooks 2009) which
causes the import operation to fail halfway through; a quick search turned
up reports of that bug from 2003. There are reasons why any discussion of
QuickBooks harps on the need to perform backups frequently - every fifteen
minutes or so is good. Your editor has had to restore those backups many
times; meanwhile, use of GnuCash over several years has never, ever
resulted in a corrupted database.
What it comes down to is that we have solved at least 95% of this problem,
and we have done a better job than the proprietary software companies have.
But the remaining gaps are crippling, and they are hard to fill.
Accounting file formats are more obscure than, say, document formats; there
is no effort to create an OpenLedger specification. Any attempt to create
files in those formats from free software is likely to involve reverse
engineering efforts, and that will be an error-prone process in an area
where errors are most unwelcome. So we may well be stuck with proprietary
accounting software for some time yet.
That said, your editor does not intend to give up. There will be ongoing
discussions with the accountant and continued tracking of free accounting
system projects. The free software community has solved no end of
difficult problems over the years; we should be able to find a way to
take care of this one too. Stay tuned; hopefully the next update will not
be so long in coming.
to post comments)