Long-time LWN readers will be aware that your editor has an ongoing
interest in financially-oriented applications. This is only natural: in
the end, purveyors of beer can rarely be convinced to purvey without
receiving some sort of financial compensation in return. The simple task
of coming up with some beer money leads inexorably to the rather more
complicated problems of dealing with banks, tracking that money, running a
company, and so on. Until beer is free, one will need financial tools to
help with the process of earning, spending, and managing money.
Long-suffering readers will also be aware that your editor has not always
been entirely pleased with the state of the art of free software in this
Two projects working on financial tools have recently announced major
releases, so it seems like a good time to have another look at where things
stand with free financial applications.
The LedgerSMB project began as a fork
of SQL-Ledger in 2006; the
two projects have since diverged significantly. SQL-Ledger seems to have
settled into a slow release
pattern with occasional bug fixes and little else. LedgerSMB seems
rather more active, with an ambitious roadmap that calls for rewriting
almost everything by the time a future 2.0 release comes out. As of the
just-announced 1.3.0 release, that process
is well advanced but incomplete. Much of the work that was done for this
release is aimed at increasing the security of the system, but there are
many feature improvements as well.
LedgerSMB is not packaged by many distributions; in any case, it is a
sufficiently complex system that some manual installation and setup will be
required regardless. It depends on PostgreSQL and a big pile of Perl
modules; there is, at least, a helper script to collect the required pieces
Setup requires configuring the database, naturally; there is a script
to do some
of that work, but it did not work without some manual editing. There is
also some Apache setup to do; fortunately, the generated configuration file
worked pretty well in this case. Once all that was in place, pointing a
web browser at the local server yielded a login screen. Once the proper
credentials were supplied (they were not what the installation document
said they would be) LedgerSMB revealed itself in its full glory.
At its core, LedgerSMB appears to be a relatively complete and capable
accounting system. It has all the features one would expect, including
support for point-of-sale transactions, employee tracking, fine-grained
permissions and separation of duties, check printing, and complicated
product descriptions. Once everything is set up, LedgerSMB is undoubtedly
adequate to the needs of a number of small businesses. But it still falls
LWN, tragically, still keeps one Windows machine around, powered off almost
all the time. It exists to access the two remaining IE-only web sites that
running the business requires and to run a proprietary small-business
accounting system. Replacing that accounting system has been on the "to
do" list for years; it is mostly a matter of finding a system that can
readily do the same work. LWN cannot possibly be the only small business
in this position; the first open-source accounting system that
makes replacing QuickBooks easy seems like an almost guaranteed success.
LedgerSMB still cannot do that, for a number of reasons. The first is that
there is no way to import data from an existing accounting application; in
fact, there is no ready way to import data from financial institutions
either. The database schema is available, of course, so one could write
tools to do this work. When dealing with tools like QuickBooks, that might
mean a painful account-at-a-time process using exported files, but at least
it would be possible. The people who make money supporting LedgerSMB may
well have scripts to do that kind of work, but they have not contributed
them to the program itself.
The web-based interface often feels clunky; nice features like name
completion are not provided. Hopefully users remember exactly how every
vendor and customer's name was entered; the program will not help them.
It is easy to run into obscure error messages
that give no clue of how to proceed; see the screenshot to the right for an
example. The program can track vendors that
need to receive (for example, in the US) 1099 forms at the end of the tax
year, but it cannot generate those forms. Report generation is minimal,
and there is no provision for exporting data. And so on.
Your editor's conclusion is that LedgerSMB was designed to be - and is
being maintained as - a base on which support services can be sold. In
other words, companies selling LedgerSMB support are the real users for
this project. For them, it seems nearly ideal: a solid platform on which a
company's accounting system can be built, or which can be used to implement
hosted accounting services. But actually getting the system to a
functional point in an existing business will require somebody who knows
what they are doing. It thus differs significantly from QuickBooks, which,
for all of its many (many!) faults, can be set up and operated with little
or no outside assistance at all. LedgerSMB might be suitable as a
supported next step for a company that is outgrowing QuickBooks, but it is
not, at this time, a good substitute.
Your editor has looked at a number of personal finance applications, but,
somehow, had never stumbled across Skrooge
before the recently-announced 1.0
release. Skrooge is not a business application; it is meant for
personal financial management much like GnuCash, Grisbi, or KMyMoney. Like
KMyMoney, it is a KDE application; it offers a surprising degree of
slickness, but will not, at this point, become your editor's new tool of choice.
Once again, the first step is importing data; Skrooge is able to import
accounts in a number of formats, including the formats often used by banks
and the GnuCash on-disk format. In the GnuCash case, though, one needs to
ensure that the file name has a .gnucash extension, or Skrooge
will fail to import it with mysterious error messages. Once past that
little obstacle, the import process works well; it is easy to get started
with Skrooge using existing financial records.
Unlike GnuCash, Skrooge is not a double-ledger accounting system.
Most users are unlikely to care, but, for those who are concerned about
what is going on underneath the GUI, that may be a concern. It provides
the operations that one would expect: entry of transactions, scheduled
transactions, budgeting, forecasting, reconciliation, portfolio tracking,
and so on. The reports are slick,
with all the pie charts one could ever want. Pretty much all of the
functionality expected from a personal finance program is there.
Your editor found that entry of transactions was a slow process. Skrooge
does not remember transactions the way GnuCash does, so every payment to
the same vendor requires specifying the amount and category. Payments and
deposits are not separated, so payments must be entered explicitly as
negative numbers. The handy shortcut of hitting "+" to get the next check
number does not work. It does not appear to be possible to enter a
transaction without using the mouse. There are also performance issues:
when run on data imported from a
multi-year GnuCash file, Skrooge required a few seconds to actually enter
each transaction. For those with a lot of transactions to enter (all
payments, alas, in your editor's case), this all adds up to a slower, less
Some other details are missing as well. For example, when importing
transactions, Skrooge is unable to detect duplicates - though it does have
a facility for manually merging duplicates after the fact. It also suffers
from the scourge of "tooltipitis" - it can be difficult to actually see
what is going on in the window because there are always tooltips in the
Skrooge just doesn't seem to have benefited from years of optimization for
everyday use like some other programs have.
That said, it seems to be a capable tool that will be more than adequate
for the needs of a large group of users. Once upon a time, Linux users had
no real choice when it came to capable personal finance managers; at this
point, there are several entirely acceptable options. At this level, at
least, free software developers have managed to scratch this itch in an
entirely satisfying way.
Comments (18 posted)
It's been a while in coming, but CyanogenMod (CM) has released an update to its
alternative firmware for Android devices. CM
7.1 doesn't contain a huge number of new features—though it has
some, along with a few bug fixes—but it does add support for two
dozen new devices, along with experimental support for a half-dozen more.
While the project (and its users) may lament the six-month gap between 7.0
and 7.1, just the
sheer amount of work to build and test the code for a total of 68 devices
had to eat up a fair chunk of that time.
CM 7.1 is based on the Android 2.3.7 ("Gingerbread")
source code, which is the latest version that Google has released. Android
2.3.7 is, itself, a fairly minor upgrade from the 2.3.3 that was
incorporated into CM 7.0. Big changes to the Android core can't really be
expected until Google releases the 4.0 ("Ice Cream Sandwich") code. 4.0 is
to be announced soon and will merge the phone-oriented functionality of
2.3.x with the tablet-oriented features of Android 3.0 ("Honeycomb"). It
is also expected that Google will release source code for 4.0 sometime (hopefully,
shortly) thereafter. It will be interesting to see how quickly CM comes
out with a release that incorporates that code.
In the meantime, though, there are a number of interesting things to try in
CM 7.1. One feature that may not be so important to regular users is a
real boon for reviewers: a screen shot option in the power-button menu.
Screen shots could be taken using the SDK in previous releases, but this is
much more convenient.
Holding the power button for a second or so brings up the usual CM menu
choices for things like power down, reboot, airplane mode, and so on, but
it now has a screen shot option as well. Choosing that
option will take a shot a second or two later (after the power-button menu
A more generally useful feature, at least for privacy-conscious users, is
the ability to revoke individual
permissions for apps. Android has a set of permissions that apps can
request, but the user only has a choice to either approve them all or not
install the app. CyanogenMod has taken a different approach that allows users to
individually revoke permissions from installed applications.
In order to do that, one must enable the "Permission management" option in
the CyanogenMod application settings dialog. Doing so brings up a scary
warning about apps malfunctioning and exiting. Additionally, the warning
is very clear that CM doesn't want to hear bug reports about misbehaving
apps when their permissions have been revoked. Clicking through the
warning allows a user to manage the permissions granted to an app via
"Manage applications" in the
Applications settings menu.
The actual interface is a little non-obvious. Permissions are listed with
a check mark next to them, which would seem to indicate whether they are on
or off, but touching the check mark doesn't do anything. Instead, touching
the actual text of the permission will put a strike-through line over the
text (seen at right) and turn off the corresponding permission. Turning
off "Network communication" and "Your location" for Angry Birds didn't
cause any noticeable problems—unless one misses the ads. It's not at
all clear why the game needs location information, anyway (though one might
guess it is for geo-targeting the ads). Likewise, turning off the location
permission for a Rugby World Cup app seemed completely benign.
One can imagine that turning off permissions for storage or things like contacts
might make some apps misbehave. But it would seem that apps already need
to deal with the possibility that
networking and location information may not be available. K-9 Mail, for
example, just gives an error when checking for mail with its network
permission revoked. Apps can certainly be written to be robust in the face
of errors, but, based on the warning, it would seem that many are not.
Perhaps that's not surprising since those errors are "impossible" given the
assumption that the permissions requested are always granted.
One of the main "selling" points of CM is its customizability. Lots of new
things have been added to the "Settings" app, beyond just permissions
revocation, but it can be a little difficult to figure out what's new. The
log for the release (scroll down a ways) can help. Coupling that with a Google
search for the features mentioned there can also shed some light on how to
actually use the new settings. A depth-first
search through the settings tree is always an eye-opening experience as well.
Some of the new settings were immediately, and obviously, useful to me.
Those include hiding the "hold" button in phone calls (so that it can't be
inadvertently ear-activated), some new lockscreen widgets and options, and
binding the up and down swipe gestures to particular actions. The new
ADWLauncher transitions when switching between desktops are amusing, but
hardly mission-critical. The LED notification system has been completely
overhauled for CM 7.1, which allows users very detailed control over which
apps can use the LED, which color it should use, the blink rate of the LED,
Some additions to the camera app are likely to be popular, including the
a self-timer. The touch-to-focus feature is one that has appeared and
disappeared in the CM 7.0.x series, with numerous requests to see it
return, and it has. Both of those features can be accessed from the
settings button in the camera app. Muting the shutter-click sound is
another new option, but it is accessed from the "Sounds" menu in the
"CyanogenMod" section of the settings app. Doing so does bring up a
warning about the feature's possible illegality in some jurisdictions,
Installing CM 7.1 on a Nexus One and a Nook Color was quite simple using
the Rom Manager app, but it can also be done by placing a zip file on the
SD card (after backing things up using the ClockworkMod recovery tool, of course). The release has proved quite stable over a few days use on both
devices, and it would seem that some annoying audio bugs I had experienced
with CM 7.0 on the phone were excised as well. Though swiping
notifications to remove them seems to be working better than it did before,
doesn't work consistently for me, which starts to make me suspect a
dexterity problem with the user rather than a bug.
CM 7.1 is a nice incremental update for folks that are using CM 7 and
definitely makes a good replacement for those still running stock
Android—though one has to guess that the only Android-using LWN
that are stuck with phones that can't be jailbroken, or aren't
supported by CM. What CM (and Android) users are really waiting
for, though, is a version that incorporates the latest code from
Google. Once that code drops—if it doesn't, Google will really need
to admit that Android is not open source—folks will be waiting
with bated breath for CM 8.0 (or whatever it is called). That clock
hopefully starts soon ...
Comments (24 posted)
The GNU project officially gave
its blessing to GNU Health at the end
of August. The application (which was formerly known only as "Medical") is
a free software environment designed to run a medical clinic or small
hospital — including patient records, administration, and resource
management. It is the flagship application of the Argentina-based GNU Solidario effort.
At the front desk
In terms of scope, GNU Health focuses on two key areas of hospital or clinical practice: electronic medical records (EMR), and hospital information systems (HIS). The site also lists "health information system" as one of its bullet points, although this term does not have as clear of a definition. Generally speaking, GNU Health focuses on what it calls "family and preventative medicine," which includes treatment for ongoing conditions, nutrition and immunizations, basic lab tests and screening, and prenatal and newborn care. Support for advanced functions one might find in a large hospital (such as drug trials or medical imaging) is spottier.
In the early days, Medical was based on OpenERP, a modular GPL-licensed enterprise resource planning (ERP) package. When OpenERP released its 6.0 update, however, the project changed its licensing terms to adopt a custom OpenERP Public License modeled on the Mozilla Public License. At that point, the GNU Health team determined that the new license was not compatible with the GPL, and switched over to the Tryton framework for further development. Tryton is based on an earlier (4.2) release of OpenERP, but the two frameworks have diverged significantly since the fork in 2008.
Tryton is written in Python and uses PostgreSQL as its database layer.
Although for a while both OpenERP and Tryton were supported, the latest
release of GNU Health (1.3.3) runs only on Tryton, and requires Tryton
2.0.x. Tryton (and, thus, GNU Health) provides separate client and server packages; the only client option at the moment is a Python and GTK+ GUI, although a web front end is in development.
Getting and installing the latest GNU Health release is a bit of a
headache, in large part because the project is only halfway finished with
its transition from its previous hosting platform to the Savannah servers
provided by GNU. The documentation is split between the GNU site, the old
"Medical" project at SourceForge, and the GNU Solidario project site (which
includes an ominous-looking banner warning that the underlying hosting
service, Amazee.com, will shut down on December 23).
There are directions on the wiki, however, both for installing the latest Tryton release and adding in the GNU Health modules. The GNU Health package includes a configure script which did not work for me, but manually installing the modules seemed sufficient. Best of all, there is a demo data set in the GNU Health package, which allows you to explore the system even if you do not have an actual medical practice handy.
On the record
GNU Health's EMR side encompasses everything that could be called patient records: personal and family medical history, physical condition, prescription and treatment records, genetic and hereditary records, and test results. It can function as a "paperless chart" for office visits, and the administrators can perform statistical analysis on the population as a whole, for use in tracking historical trends or in epidemiology. The system does not directly incorporate test results from medical imaging scans (X-rays, etc.), although users can attach them as external files.
As far as the format of the records themselves is concerned, there is not an agreed-upon standard for EMRs, which can make exchanging records between institutions difficult. The closest thing to an interchange format is the Health Level 7 message format (HL7), which has been developed in the US since the 1980s and has been adopted in several other countries. GNU Health does not yet produce or consume HL7 messages, although lead developer Luis Falcón said it can export records in several output formats (XML included) which can be transformed into HL7.
GNU Health does take care to conform to existing data standards for
potentially tricky information types such as diagnoses and disease names.
It builds in the International Classification of
Diseases (ICD-10) for coding diseases and symptoms, GeneCards for genetics, World
Health Organization Essential Medicines for medicine, and various other
standardized scales and prediction rules (for example the Glasgow Coma
Scale for assessing a patient's level of consciousness) to normalize
input. Thus, even if GNU Health's data format is not based on an established standard, the hope is that at least its semantic data is.
Taking care of business
The system's HIS functions cover basic office management tasks and connecting to a billing system. For patients, this means scheduling appointments and tests, for doctors it means making schedules and alerting them to test results, and for staff it means scheduling the use of examination rooms or other facilities and managing inventory. GNU Health can track prescriptions, although it does not automatically place orders or send notifications for refills.
On the billing side, GNU Health can create invoices, but it does not yet include a full-fledged accounting program. Likewise (and for those in the US, more importantly), it can associate basic insurance plan information with a patient record, but the claims process must still be navigated manually. Human resources (i.e., managing employees and schedules) is supported, because it is a common enough ERP task to be included in Tryton by default.
In short, GNU Health fills out a solid system for running a small-to-medium-sized clinic or hospital, but might not meet the needs of very high-traffic or long-term care facilities. The insurance and billing systems are probably better suited for regions with less complicated medical/insurance industries, but this is certainly well in line with GNU Solidario's concern with building tools to serve underprivileged communities. The site maintains a list of institutions using GNU Health in the field, including hospitals in the Philippines, Tanzania, Argentina, and Indonesia.
At this point, what the project has the greatest need for is
documentation and translators. Making the project-hosting-transition is
undoubtedly a time-consuming task, but I learned of several key features of
GNU Health only through an email conversation with Falcón. For
example, the system is designed to peer multiple sites together, in a
single database, and he said that remote nodes are able to cope with
unreliable upstream connections. Both are extremely useful features,
particularly in rural or under-served areas of the world where power is
unreliable, but neither feature is documented (at least that I was able to
funds his development work on the code with a GNU Health consulting service
called Thymbra. In addition to Thymbra, there is a Tryton development
company which also offers
support to businesses using GNU Health.
Relationship to other free tools
My initial reaction upon reading the GNU Health announcement was confusion, because I remembered the existence of the similar-sounding GNUmed project, which is also still active, and also built with Python and PostgreSQL.
The two are different, however. GNU Health is designed to serve as a full practice-management suite, rolling the appointment scheduling, tests, prescriptions, and on up through invoicing into a single system. GNUmed is focused entirely on building an EMR system alone. Of course, there are always gray areas — because GNUmed is aware of clinic staff members (primarily for tracking tests and messages), it also has a very basic HR module. But many of the other practice-management tasks that GNU Health builds in directly — such as maintaining an appointment calendar — GNUmed hands off to external calendaring applications. In exchange, you do get a more complex EMR system from GNUmed, with health risk calculators, document sign-off, and direct import of imaging data.
At the other end of the spectrum is a high-end system like the US Department of Veterans Affairs' VistA, which we covered in March. VistA is a complete multi-site hospital-management system that incorporates far more than GNU Health, including inpatient care, electronic prescriptions, and much more. But it comes at the price of significantly higher IT overhead. In contrast, almost anyone who can install a web server can install Tryton and GNU Health.
Although it would be nice to see regular cooperation (or at least communication) between partially-overlapping projects like GNUmed and GNU Health, what is more important is that both are installable today, by people for whom the proprietary software alternatives are far out of reach.
Comments (3 posted)
Page editor: Jonathan Corbet
Next page: Security>>