GnuCash - A Call For Help

sedition writes "GnuCash developer Benoit Gregoire has written the State of the GnuCash Project. It is a call for help to the Open Source community regarding the open-source accounting software for Linux, Mac OSX, and more. GnuCash is one of the largest (287,853 lines of code), but least publicized Open Source projects. Now it needs developer support, as its future is uncertain."

Comments

Gnu/Cash?

[Anonymous Coward]

For a moment there I thought RMS was claiming to have invented money.

Re:Gnu/Cash?

[Gzip Christ]

For a moment there I thought RMS was claiming to have invented money.

No, that was SCO.

PS - they want it all back.

I've just donated

[Anonymous Coward]

10,000 GNU dollars to the project.

Why have the crispy US dollars backed by the Treasury and US Government when we can have GNUCash?

All by their lonesome?

[tevenson]

How did it get so many lines of code if it isn't very well known? Do we have one coder slaving away on this one?

Re:All by their lonesome?

[nutznboltz]

The Tao of Programming has two things to say about this:

1. There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: ``Which is easier to design: an accounting package or an operating system?''
   
   ``An operating system,'' replied the programmer.
   
   The warlord uttered an exclamation of disbelief. ``Surely an accounting package is trivial next to the complexity of an operating system,'' he said.
   
   ``Not so,'' said the programmer, ``when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design.''
   
   The warlord of Wu nodded and smiled. ``That is all good and well, but which is easier to debug?''
   
   The programmer made no reply.
2. A novice programmer was once assigned to code a simple financial package.
   
   The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, an artificial intelligence interface, but not the slightest mention of anything financial.
   
   When the master asked about this, the novice became indignant. ``Don't be so impatient,'' he said, ``I'll put in the financial stuff eventually.''

By George!

[Anonymous Coward]

I think they just came up with the missing part:

1. Write free software
2. Ask for developers on Slashdot to share the pain with you
3. Profit!!

Impressive!

Wish I could code...

[Pettifogger]

As someone who uses Gnucash (I'm an accountant, too) I had no idea the project was in trouble. This is one of the best programs I've come across in the Linux world, and I think it's superior to similar commercial packages. The operation is closer to how you're taught to do accounting, and I love it for that. Well, if someone out there knows how a sympathetic non-coder could lend a hand, let me know. Yes, I did RTFA, and I didn't see a way to contribute without knowing how to hack code.

Re:Wish I could code...

[wowbagger]

Maybe you could write a sort of "Why-To" - explain to people why to use a double-entry system like Gnucash as opposed to single-entry systems out there.

You could give folks some good advice as to what sort of accounts to set up so that when tax time comes around, they can better track what's what.

Re:Wish I could code...

[SuperBanana]

This is one of the best programs I've come across in the Linux world, and I think it's superior to similar commercial packages.

I agree it's a great package, and I love it- but there are several things which REALLY irk me.

• You CANNOT select multiple entries and sort them into one category at once. I could reconcile 6 months of activity in a few minutes if I could quickly slip down the list, clicking on all the gas station entries, and then on the last one, select "Auto:Gas". Navigating the expense listing is REALLY tedious, so there should be ways to reduce the # of times you have to use it!
• No support for auto-sorting items into categories. Quicken sorta 'fuzzy matches' imported QIF entries and the like. Ie, "Mobil station 1325325", if you've picked "Auto:Gas", will default in the import to, well, Auto:Gas :-) This is an ENORMOUS timesaver- and should at least be an option.
• No balance forecasting.
• Moronic defaults for the graphs(like the size, etc. Nothing displays right.) Should default to the size of the window, or a global pref. Not just "300x300" or whatever it is.
• Building it from source is virtually impossible, like most Gnome apps- it's a maze of dependencies that makes your head spin trying to get them all satisified. It has the most dependencies of any program I've ever seen, save Request Tracker(but at least RT's dependencies are perl modules, and MOST of that can be handled by CPAN- thank god, because you can end up needing over FIFTY perl modules for RT!) I REALLY want to be using the latest Gnucash, but there are no Mandrake packages, and I don't want to waste 5 hours of my life trying to compile it :-)

Don't get me wrong- I DO love the program, but sometimes(mostly when reconciling), I want to scream after modifying 100+ entries into various categories...arrrrg :-)

Often times packages like these develop cool little "better than the commercial package" features. Gnucash, unfortunately, don't really surpass(or even come close) to quicken's functionality set.

Now, what I DO like:

• Customization of the graphs is great. As is the HTML-like nature of them, where you can click on a wedge of a pie, and 'dive into' that section. Cool beans. The graphs are simple, but just look really nice- very clean appearance thanks to the gnome antialiasing libs. They're certainly presentation/executive material.
• Mandatory full backups. Every time you save, it writes a new copy of the file, dated, by default. This is actually a godsend- disk space is cheap, and even with 3 years worth of records the file isn't very big. But having snapshots is great in case I find out I was fucking things up for the last two weeks.
• It handles QIF, OBEX, etc with no sweat. Two bank's QIFs have imported with no troubles.
• Free! :)
• No update bullshit. No "won't read your files from last year's program" bullshit. No "we sold it to you, now you can go screw" tech support. Sorry, Quicken has some of the worst release engineering and support policies, not to mention worst QA, I've ever seen. Banks are always having to help their customers through quicken problems- which is NOT where the responsibility lies. My bank actually had a "if you are trying to use quicken with your Bank Boston account..." option...

Re:Wish I could code...

[Keltus]

Maybe they're having trouble managing their finances. If only there was some sort of computer program...

The rest...

[RobertB-DC]

Here's the rest. I'm not posting AC because of the new troll technique (posting "creatively modified" mirror text).

What core developers should do to help future developers

There are many reasons for our difficulties to attract developers and other contributors, but it all comes back to the same problem: real or perceived, the barrier to entry is too high. To get more developers, we must make it easier to contribute to GnuCash. "Casual" hacking on GnuCash to scratch an itch is much to hard, even for an experienced developer.

Work on the developer documentation problem

There is no complete and current architecture and API reference. Now that we've put the doxygen plumbing in place, we must make sure that ALL functions that are in public headers ARE documented, even if only by saying "Document me!", so the doxygen docs become truly authoritative. Then put the docs on the web site. We must also write a report writing Howto: We already have some very powerful reports, but this is the single most common offer for help we receive "Hi, I'd like to write "foo" report for GnuCash, can someone help me or point me to documentation on that subject". Sometimes I wonder if anyone knows anymore... So the answer is always the same: 'there isn't any; use the source Luke'. We are wasting the chance to hook countless new developers.

Fix core capabilities in the engine

Existing developers should focus on architecture issues and completing existing core features that only they can realistically tackle, such as Lots (which are needed to support accounting periods) or fixing the problems in the scheduled transactions, so that new developers can build on that functionality.

Improve interoperability with other software or new modules

GnuCash has a great, powerful multi-user financial engine that many people ask to plug into. Unfortunately much of this power is locked away. There is no way to interface with a running GnuCash (the RPC backend and perl bindings have bitrotted), there is no way to start a new instance while passing parameters like "import this file". We need a wrapper that will start GnuCash if it isn't already started and pass API requests to it, with or without GUI. The current module system needs to be completed or replaced. It's hard for new developers to integrate new modules in the build and menu system (we need a howto on that too...). Also, data import isn't enough, we must also support export to inter-operate with other software. (LibOfx should get us there if I can just find time to work on it).

I think fixing/developing external interfaces and writing additional import and export support should greatly help our developer crunch in the medium term, by consolidating part of financial software development in the free software ecosystem. We have received many, many inquiries from people wanting to integrate gnucash with (name of web system, database, payroll, kde front end or whatever). We can't afford to loose these people, whether or not the core developers like their pet project. We must use the gnome 2 port as an opportunity to finish/cleanup/document our interfaces and from then on answer "I don't know if your idea will work, but you're welcome to try; here's the relevant documents to get you started."

What developers should do to help users and decrease developer load

Make sure the mailing lists are easily searchable
And/or document how to properly search them (Google isn't cutting it).

Get more people write access to the website

We have received many offers to help, but turned most of them down for no good reason. The website is nice, but it isn't up to date, it's a source of frustration, misleading to users and future developers, and pointlessly increases traffic on gnucash-user and the #gnucash IRC channel.

Quickly implement a Wiki or similar system

This will allow us to have an effective place to point users on gnucash-user

Re:GNUcash sucks, Kmymoney2 better

[sharkey]

which behaves more like Quicken

It requires online registration, then writes that information to the boot sector of your hard disk?

Re:die die die

[getling]

Actually, although you are right about it having a Byzantine list of dependencies--it has NOT been ported to Gnome 2 yet (that is part of the problem!), plus it is the only application of its kind. In my mind this is a Killer App (TM), which is one main reason I have for using Linux and staying with it...I am certainly on my way over to #gnucash to help out as much as I can.

It's too hard to compile

[SnarfQuest]

I gave up on trying to use GnuCash long ago due to the impossibility of compiling it, and getting it to run.

They used large numbers of libraries, which you had to locate yourself. No links to the proper versions either. You needed specific versions of those libraries, some no longer available from that libraries web site, and some pulled from CVS at some unspecified time (and no other time would work).

The database it used was their own creation (why should we use an existing library for the database? That would only add another dependency, but here's another error logging library that we can't live without). It was unaccessable to mere humans, and messed up the database all too frequently.

After they added yet another round of libraries (several of them not yet available on the web), I finally gave up. It was simply unbuildable and unusable, and I could not forsee it as ever becoming usable, let alone ever be able to compile it.

GnuCash

[cookiepus]

I am not sure what affords GnuCash the title of "least publicized," as I've heard the title many times and infact it came with RedHat whenever I last installed that.

Some months ago I said on /. that two major things keeping me away from using Linux is the lack of any sort of decent finance management software and an Outlook-type thing. My whole life is in MS Money and Outlook.

I heard things about GnuCash being hopeless to install unless it came packaged with your distro, so I was excited when I found out that the version of RH about to come out will include it.

Thus began my most-recent attempt to switch to Linux. I exported my Outlook archives into Evolution, and my Ms Money accounts into GnuCash.

It lasted about a week. By the end of the week I was thoroughly dissapointed with the mediocrity of both of the pieces of software. Yes, they are usable. yes, GnuCash added up numbers together, but no,the user experience was mediocre compared to what I was used to with my Microsoft applications. That, and the shitty sound support, eventually made me say "fuck it" and switch back to Win2k and I'm happily using it since.

I think most everyone agrees that GnuCash is a critical piece of software for the Linux desktop. Yes. Absolutely....

GnuCash is a long program (well at work we deal with about 150 times that much code..) but from a user perspective of someone who's known better, it sucks. I am glad that the focus isn't only to find more coders. What this thing needs is some normal human beings using it and saying "you know what, it's NOT acceptable that window A obscures window B and freezes while window B is waiting for input from me." It needs, I am sorry to say, Quicken or MS Money users, who say "It was really easy to do X, Y, and Z, but here, I can't even figure out if it's possible,"

Good luck to this project, absolutely. Maybe - evnetually - projects like this will mature and become useful to people who don't care about open source and don't hate Microsoft. Yes, GnuCash appeals if you're maniacal about those things. It does not appeal if you're looking for better and more useable software. Unfortunately, a lot of Linux stuff can be described thusly.

Re:GNUcash sucks, Kmymoney2 better

[Ktulu_03]

Hi,

I'm one of the newer developers on Kmymoney2. We are currently re-writing the services layer to become a fully double-entry accounting program. We are looking to add support for investments, loans, mortgages, etc, and are switching to a XML file support instead of binary. We are also trying to keep up with the latest KDE3 widgets and adding QIF support as well. International support is also high on our feature list. (I apologize to any team members if I left out your feature that your working on.)

Our next version is probably a bit away, but it should make us much more competitive to GnuCash in the future (esp. with the double-entry accounting).

Yes, it does...

[Goonie]

First, I should add that whilst I was a GnuCash developer for a time, I have not been actively involved for nearly two years (though seeing the call to arms it might be time to roll up the sleeves againn. But there are very good reasons why GnuCash made some of the design decisions you mentioned:

GtkHTML -- do you really need a HTML parser in an accounting program?Why not just use Mozilla to display your HTML?

Just using Mozilla isn't good enough. Using GtkHTML makes the GUI far, far cleaner and lets us embed graphs in ways you simply can't do using Mozilla.

Gnome XML No one NEEDS to save their accounting data in some XML file format? What's wrong with the standard Quicken format that everyone is used to or even a nice, simple text file that I can munge with vi?

There are so many things wrong with the standard Quicken format that your comment is almost comical - chief amongst them being that there is no standard Quicken format. It is a complete clusterfsck, and I take my hat off the developers who managed to make head or tail of it. As for a text format, that's what XML is, and parsing it is a no-brainer in just about any language you care to name. Perhaps you'd care to write a robust parser for your wonderful error-free format?

As to the general thrust of your comments, yes, it would be nice if a few gnome libraries were merged IMHO, and in hindsight maybe Python would have been a better choice as a scripting language (not because of the merits or otherwise of Scheme - Scheme is a wonderful language) but because it would have lowered the barriers to entry for GnuCash development. But back when I was a developer, the general view was that it was our job to write software, and it was the job of distributions to package it up so that Joe Average didn't need to compile it himself. Debian always managed to make it a no-brainer install. Why can't every other friggin' distro manage it?