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.

Re:Gnu/Cash?

[WIAKywbfatw]

GnuCash? What was wrong with the old stuff?

Re:Gnu/Cash?

[shaitand]

GnuCash is freely copyable and distributable.

Re:Gnu/Cash?

[hankaholic]

That's essentially my point, that RMS insists that GNU forms a good bit of the OS simply because it really does.

People like to rag on RMS and the GNU thing, but if you take away GNU, you really don't have much of an OS left.

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?

[tmark]

Perhaps a more important question is, WHY does it have so many lines of code ? Unless it is written in assembly, I can't even imagine that the application NEEDS as many lines of code as perl or Postgresql. Maybe THAT is their problem.

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.''

Re:All by their lonesome?

[GnuVince]

GnuCash is written in C. There is your answer. Languages like Python, Lisp or Smalltalk would make it a lot shorter, but at the same time people would complain that it depends on "non-standard" languages (C and C++ are the de facto standards in Linux)

Re:All by their lonesome?

[GreyPoopon]

Perhaps a more important question is, WHY does it have so many lines of code ?

That might be one of the reasons why they feel it is becoming unmaintainable. I think all the contribution is cool, but it's probably time to stop adding new features and spend most of the time making the existing codebase maintainable and well-documented (they mention some of that in the article). It's actually something I'm highly interested in, and if I could find a way to get involved without getting even less sleep than I do now, I definitely would.

Druids?

[RobertB-DC]

Sorry, I know I'll get modded down to nothing, but I've got Karma to burn and this just cracked me up:

Mortgage and Loan Repayment druid and many, many others.

I imagined the barbarian horde from those Capital One "What's In Your Wallet?" ads fighting it out with the Loan Repayment druids, like something from Star Wars II or The Two Towers.

Re:Druids?

[Nightpaw]

It's how you know when you're winning!

Helping out a Slash-dotted friend...

[ansak]

gnucash.org seems to be "benefiting" from the publicity. Here's the first part of Benoit's post for those who care:

State of the GnuCash project, a call for help

The GnuCash project is having a hard time. I think most everyone agrees that GnuCash is a critical piece of software for the Linux desktop. It's also one the largest free software projects. How big is it? GnuCash currently has 287,853 physical source lines of code (SLOC). For example, had the current GnuCash CVS been included in RedHat 7.1, it would come in 21st position in code size (see http://www.dwheeler.com/sloc/). At that time, the current GnuCash CVS source would have been pretty similar in size to qt, postgresql or perl, about 60% of Gimp and between 12% and 16% of Xfree, Mozilla or the Linux kernel. Although GnuCash comes up in every discussion of needed software to get Linux on the desktop, the GnuCash project currently has only about seven active developers (active being used very loosely here, considering I included myself) and enjoys far less exposure than many projects of a similar size.

We may be headed for a dead end if we don't reorganize and refocus our efforts. GnuCash badly needs more manpower (not just developers), and needs to get it quickly.
How did we get here

Of course, every project could always use more developers, but the consecutive demise of both Gnumatic and Linux Developers Group caused the loss of most of GnuCash's core developers two years ago. The few volunteers that were left focused on new features, in the hopes of attracting users and hopefully also developers. We've managed to take it to 1.8.5 (to be released in a few days), and in the process GnuCash gained Small Business features, Scheduled Transactions, a completely new import UI with Bayesian filtering, OFX and HBCI support, Mortage and Loan Repayment druid, and many, many others. We are very proud of it and we clearly have more users judging from traffic on gnucash-users, and all should now be well in GnuCash-land.

Not quite. We didn't attract many new developers and all those new features have to be maintained and debugged. They also represent a huge tech support burden, since most of the features were not documented properly due to time constraints. GnuCash has grown too large for the current developers to properly debug and maintain the current code base, add new features and write documentation, all at the same time.

I hate to admit it, but in our quest for new features, choices had to be made and a lot of important things are currently being neglected. If the GnuCash project can't manage to attract more contributors and refocus the efforts of those it already has, it's going to become unmanageable. We often say that Linux would survive even if Linus got hit by a bus. Well, right now I am not too certain that GnuCash would currently survive if Derek Atkins got hit by a bus.

So now I'll try to suggest some solutions...

(that's as far as I could get)

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!

Solution: pay someone to develop this software

[danny256]

If this software is so important then why not raise some money and pay some developers to work on it. If the creators really believe in the project they should be confident that they'll make the spent money back in support (or at least t-shirt sales)

Re:Solution: pay someone to develop this software

[Pieroxy]

sorry coders but your ethics are being exploited

You don't seem to understand the GPL very well, do you?
The GPL doesn't say anything about charging for the distribution. Also, as any large accounting software, you can sell yoursef as a contractor to configure/maintain/install/blah/blah anything on any client interested.

The only thing you cannot do is charging for Licensing fees. It does not prevent you from making money off of your work any other way you see fit.

Re:Solution: pay someone to develop this software

[Pieroxy]

Hmm, I'm wondering how does Red Hat makes money. They sell only open source software. WAIT! Wait!!!! What did I say? They sell some free software!!!?!?!

Excerpt from the GPL:
When we speak of free software, we are referring to freedom, not price

Re:Solution: pay someone to develop this software

[Pieroxy]

Some other companies exploit users as well. Not for their ethics but for some other reasons. As long as people are ok to be exploited there will be people to do it.

Open source is just another way, nothing more.

GNUcash sucks, Kmymoney2 better

[CanadaDave]

GNUcash is so complex. Why anyone would want to develop or even usefor the GNUcash project is a mystery to me (maybe if you're an accountant). Better to develop for Kmymoney2, a nice KDE/Qt C++ app, which behaves more like Quicken and Microsoft Money, the two most popular money managment apps. Kmymoney2 is the only real alternative to GNUcash for the future in my opinion. Let GNUcash die, and some new apps will come...

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:GNUcash sucks, Kmymoney2 better

[UnknownQ]

Better to develop for Kmymoney2, a nice KDE/Qt C++ app, which behaves more like Quicken and Microsoft Money, the two most popular money managment apps.

(emphesis my own)
So since it looks, smells and acts like popular apps it must be good right? I hate this attitude because it stifles innovation. If you are always trying to play catch-up to the latest version of the hot software of the moment you will never become the hot app.
GnuCash brings a new method of money management to the table (accounts) and one I prefer much more to Quickens less organized check book clone. GnuCash is the best money management out there for Windows or Linux because it innovates, which is more then I can say for most software (especialy Kapps).

Re:GNUcash sucks, Kmymoney2 better

[Anonymous Coward]

GnuCash brings a new method of money management to the table (accounts)

How is this new? I took an accounting course back in high school, and Gnucash works almost exactly like what I learned (general ledger, accounts, etc.).

How do other popular applications handle things?

Re:GNUcash sucks, Kmymoney2 better

[CanadaDave]

GnuCash brings a new method of money management to the table (accounts)

True, but truly this method has not been successful, at least as implemented by the GNUcash team. Thus, let it die. I don't really see how GNUcash "innovates" as you say. The only real innovation I see is that they have one of the largest developer to lines of code ratios, have more dependancies than a handicapped person, and the program has managed to look roughly the same for the past 3 years since I first used it, with still no support for investments! Who really tracks their checking accounts using software anyways, the only things these programs are good for is tracking your mutual funds, stocks, bonds, and other investments, and to have it automatically tell you your capital gains for tax purposes and spew out the annualized return of all your investments in nice report form. I'm not sure what the GNUcash developers have been working on the past few years, when it is missing some key features.

BTW, I was never suggesting the GNUcash be a copy-cat app of MyMoney or Quicken. However, the features that those apps provide (ie. investments), are a benchmark for what other apps should provide, if they hope to grab any market/mind share whatsoever.

Re:GNUcash sucks, Kmymoney2 better

[Erwos]

Potential? GnuCash _works_. It has 250k lines of code written already. Frankly, it's one of the best Linux apps I've ever used, and has a very sane interface. Then again, I've never used Quicken, so what do I know?

Why you're advocating throwing away a perfectly good program that just needs some more developers and documentation is totally beyond me. A dedicated documentation effort for GnuCash would probably only take a month to do, max.

If I had to hazard a guess, you're not a software developer. Re-inventing the wheel every ten minutes is a bigger waste of time than trying to fix a slightly old, good one.

-Erwos

Re:GNUcash sucks, Kmymoney2 better

[Aadain2001]

A good test of a new program is how easy it is to use the first time you sit down with it.

With MS Money (now there's a scary term ;)), everything seemed logical, easy to use, and down right intuitive. Sure, they weren't perfect and they is plenty of room for improvement, but it was a good program that was almost fun to use.

With GnuCash, I had to fight to use the program. The whole layout/ideology seemed very odd if not completely stupid. I didn't want to spend half a day fighting with the program on setting up accounts or entering transactions just to do what MS money let me do in just a few minutes of setup. And just FYI, I hadn't used MS Money is about 3 years when I sat down with GnuCas just a few months ago, so the reason I was fighting the program was not because I was used the the MS way.

Make the money management program simple to use for simple things, and let it make complex things doable. GnuCash does not do this. Neither does MS Money. But at least MS Money let me do the simple things simply without having to fight it. I for one would be glad to see GnuCash follow MS Money in that respect, and then watch it surpass MS Money.

Re:GNUcash sucks, Kmymoney2 better

[ashridah]

Perhaps you need to ask an accountant for their opinion here, because this really sounds like a 'it's not familiar, ergo, it sucks' rant.

One of my collegues got his father (certified accountant of australia) to use gnucash. said accountant was VERY impressed with how much smarter gnucash was to use, and how much the druids helped. I'd do the same if i could get my father (a chartered accountant) to actually fucking sit in one place before running off.

obviously, if it doesn't do what you want, don't use it, or better yet, HELP SO IT DOES.

ashridah

Re:GNUcash sucks, Kmymoney2 better

[letxa2000]

Other applications (QuickBooks) suck. QuickBooks either sucks so bad it doesn't do a lot of the accounting stuff I "learned" in the university or they had a bunch of accountants write the software that know nothing about usability. This means that the software is about as easy to use and understand as the archaeic accounting programs that were developed in mainframe text environments or under DOS. Regardless, the end result is that I have not been able to make QuickBooks do everything I wanted it to and, quite frankly, constantly get the feeling that the program is either extremely limited or just so stupidly designed so as to make things too difficult to accomplish.

In the past QuickBooks has pretty much been it for small businesses, and is one of the reasons I bought Win4Lin when I migrated to Linux--so I could still run QuickBooks. But I hate it with a passion.

I've been wanting to investigate GnuCash for sometime. When I was on RedHat 7.3 I couldn't even get the damn thing to compile and I couldn't resolve all the dependency issues, so I eventually gave up. Now that I've upgraded to RedHat 9.0 GnuCash was one of the installable packages--and I installed it.

It is my intention to play around with it and see if I can migrate my small business finances to it and abandon QuickBooks altogether. Even if GnuCash were to suck as bad as QuickBooks I'd like to ditch QuickBooks just on principle. QuickBooks doesn't even support multiple currencies, which is just silly.

Re:GNUcash sucks, Kmymoney2 better

[tamnir]

GNUcash is so complex. Why anyone would want to develop or even usefor the GNUcash project is a mystery to me (maybe if you're an accountant). Better to develop for Kmymoney2 [sourceforge.net], a nice KDE/Qt C++ app, which behaves more like Quicken and Microsoft Money, the two most popular money managment apps. Kmymoney2 is the only real alternative to GNUcash for the future in my opinion. Let GNUcash die, and some new apps will come...

GnuCash is a full-fleged dual entry accounting system: you can run your business accounting with it.
Quicken and Money are not: they are just good for keeping track of your personal bank accounts.

The bold text above may not mean anything to you, and it meant nothing to me until about a year ago when I started learning some accounting stuff. I don't know why accounting is so excruciatingly painful to learn for us developers... but once you finally get it, you realize that it is actually not that complicated, and why it simply works. Now, while I'm still a developer and not an accountant, even for my personal finance, I will not do without dual entry. I tried Kmymoney and Microsoft Money, but they just don't cut it. Now I can't live without GnuCash.

Please, do not let GnuCash die. If you can help that project, by all means, please do.

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).

Re:GNUcash sucks, Kmymoney2 better

[shaitand]

Quicken sucks, the missing hole in the linux software array is a quickbooks/peachtree type app for accountants. This is what stops linux from entering the small business arena.

Re:GNUcash sucks, Kmymoney2 better

[shaitand]

your confused though, GNUcash really isn't supposed to be a personal finance app. It's supposed to be for accounting. This isn't a quicken/ms money replacement, this is a Quickbooks/peachtree replacement.

Re:GNUcash sucks, Kmymoney2 better

[Negative Response]

I think I just think that...

You sure you are thinking?

Re:GNUcash sucks, Kmymoney2 better

[Malc]

"GnuCash [...] has a very sane interface."

You're kidding me? It's using that abomination (GTK???) that GIMP, Ethereal, Every Buddy, etc use. I took one look at the screenshots the other day when I was looking for a free alternative to Quicken and went running and screaming from their site. I cannot stand that tool kit and its awlful UI and behaviour. I ended looking at the KDE apps, but nothing really stood out with the same stature. I guess I'm going to just have to make do without a open source solution. As with the GIMP, the UI is definitely a huge stumbling block, and I won't touch it whilst it looks and behaves like that.

Re:GNUcash sucks, Kmymoney2 better

[circusnews]

I've used GNUCash. I've tried to hack at the code. But its just about impossible to do without being ready to expend impossible amounts of time on it.

For what its worth, I really like parts of GNUCash. I think that it could use a rewrite to lower some of the barries to entry and use, but I think it could go a very long way to solving a LOT of problems for a LOT of people.

I like the idea of a C/S system for GNUCash. I would love to see a rewrite that puts the power of the current systems engin on the ''server'', tied to a standard SQL database, and accessed by ''cash clients'' that are designed to meet specific needs (e.g. home, generic small office, law office, etc). I could see a lot of groups tinker with a much thinned down client to make it do what they need. I can't see it with the current system.

Re:GNUcash sucks, Kmymoney2 better

[generic-man]

That's TurboTax.

If it behaved like Quicken, it would constantly nag you to pay $80 to unlock the "Premier" edition and advertise every co-branded financial service in existence.

Would you like a Quicken credit card? A Quicken loan? A free credit check? Free credit protector for 30 days? No? Then what do you want?

You want to reconcile your checkbook? Please wait while we charge your credit card to unlock Quicken Premier. Would you like 1045 free hours of AOL with that?

(sigh) I've been using Quicken since version 1, and I still remember the horror the first time I saw banner ads inside a program I paid good money to use.

Re:GNUcash sucks, Kmymoney2 better

[fucksl4shd0t]

obviously, if it doesn't do what you want, don't use it, or better yet, HELP SO IT DOES.

NOt that easy, not with this project. I volunteered my own time to add budgeting, said I would add it however they wanted it. They told me to whip up a proposal. I did that. Then there was some time spent ripping up the proposal on the list, making new oes, etc. Until finally someone said they'd work up a uml diagram to show me what they wanted, and I haven't heard anything since then. I no longer have the time, they lost my window of opportunity.

I realize it's not easy, especially when there's only 7 developers. But I wonder if they'd be better off tearing down and starting from scratch. There's lots of good stuff in there, certainly, but there's also just--lots. Lots of dependencies, and they have choices now that they didn't have before, etc.

I'm in favor of working up a financial app in XUL, making it Mozilla-based and completely cross-platform. Anyone interested? :)

Re:GNUcash sucks, Kmymoney2 better

[letxa2000]

Nah, many small businesses have to deal with multiple currencies. That used to be for the international "big boys" such as IBM, but that's no longer the case.

Re:GNUcash sucks, Kmymoney2 better

[Prior Restraint]

I don't know GnuCash's architecture, but what I'd like to see is a clean separation of front- and back-ends (perhaps into completely separate projects). A double-entry accounting system is a Good Thing (TM), IMHO, and if they just concentrated on the back-end, giving it a well-defined API, etc., we'd see front-ends all over the place.

I really like GnuCash, and I want to help out, but I don't have time to grok a quarter million lines of code.

Here's a workable solution

[Anonymous Coward]

Why don't we have GnuCash selling licenses to those who actually need and are willing to pay for it? This way the company can hire more people if the project turns out to be interesting and needed by many people. It's radical, but seems to work for lots of other little guys.

Re:Here's a workable solution

[zangdesign]

If businesses are going to run their books on this software, they're going to want someone to call when it doesn't work right, not poke around the internet for 6 hours.

I would say that applies to just about any Open Source business package or business package wannabe out there - and there's the problem: businesses want to know that there is a depenable, reliable, on-call support staff whenever they have a problem. You can buy some packages preconfigured (Apache, PHP, etc.) but accounting is not a fire and forget type of application. RedHat is off on the right foot and they seem to be doing pretty well, so in about ten years or so, businesses will trust them in the same way they trust Microsoft now, for better or for worse.

To a certain extent, this applies to all software that runs on Linux - when the tech support is finally there, then we'll see more and more businesses adopting it, but until then they're gonna rely on what they know - which is Windows and it's applications.

As for the marketroids, etc. those are absolutely necessary to hammer whatever message you have into the customer's head. It takes a lot of hammering (something that Microsoft doesn't have to do anymore because they've done it for so long that it's become the safe choice - and don't say you don't know what I mean).

It may be wrong, but the business world moves way more slowly than the tech world in certain areas and way faster in others. That's something that the Open Source community needs to learn.

Patience.

Re:Here's a workable solution

[Politburo]

Well then you've got a chicken and the egg problem. I wouldn't start a GnuCash support company without potential clients, and businesses won't use GnuCash until there are support shops for it.

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...

[infiniti99]

Maybe with a financial donation? Perhaps the GNUcash people could set up a pledge system where a bunch of folks can promise to pay some money and then when a certain number of pledges are made, everyone donates their part. The "keep GNUCash alive" fund or something.

And before anyone says that paying for open source software is backwards, remember that you're paying for software freedom. That is, you could spend $100 on a commercial accounting program for one copy, or you could spend $100 on GNUCash and have unlimited copies, plus way better support (you get to talk to the developers themselves, they actually listen to your feature requests, etc). Which would you rather have?

Most folks can't hack code. And even if they can, most projects have enough coders (remember what they say about too many cooks). However, the remaining 99.99% of the population can easily help by simply donating money. Not code. It's ok that you can't code. In fact, they'd rather you didn't. OSS projects need m-o-n-e-y.

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...

[Anonymous Coward]

Well, I am a professional coder, but I'll be the first to admit: I know next to squat about accounting. So it is hard for me to contemplate jumping into a project like GNUCash. I can find obvious bugs in a program (i.e. crashes, UI issues) but I don't know the intricate details of using this app.

I think as an accountant, you could be extremely useful if the powers-that-be on the GNUCash project teamed you up with a programmer (somewhat like a programmer - tester team). You can document how things *should* work, and explain it to the programmer who probably doesn't know accounting very well. Then he can get in there with the wrench and make those changes happen.

The programmer and the accountant would need to communicate on a regular basis but it wouldn't have to be anything more complex than email, really.

If you're really interested in the project, offer them a hand, even if you're coming at it from the accounting side. They might need you more than you think.

Re:Wish I could code...

[Keltus]

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

Re:Wish I could code...

[MrResistor]

Most folks can't hack code. And even if they can, most projects have enough coders (remember what they say about too many cooks).

RTFA

The big problem is that they don't have enough coders! Money is not the issue, fixing bugs and documenting the interface is.

Re:Wish I could code...

[Isomer]

Programmers are ALWAYS wanting help, usually *especially* non programming help. Some easy (and obvious) ways a non technical user can help:

• Documentation! Documentation! Documentation!

  Writing documents on how to do things (or why to do things, accounting is a black art to many). Help people out using the program. The article said that the programmers are spending a lot of their time answering questions instead of actually getting on and *doing* the job. Even simple things like "Tips and tricks" are a good start.

• Testing

  Programmers make awful testers. Non programmers seem to be able to break programs in new and mysterious ways. The trick here is to learn how to give the best information to the programmers about how to reproduce bugs. A Programmer will usually only be able to fix a bug they can see, if you can't make the programmer see your bug, it won't get fixed!

• System Administration

  If you aren't a programmer, but know Unix well, then you can offer to help manage the site, the article mentions that they are having trouble searching the archives, perhaps setting up a web based archive + htdig or similar would help.

• Advocacy

  You usually get developers because they use software and have an itch to scratch. I'd guess that GNU/Cash's biggest problem is that programmers don't use the software. Running Tutorials, presentations at local LUGs can be invaluable for getting a larger userbase (and therefore hopefully a larger developer base)

• Money

  If theres a feature you need (or want) or a bug you need fixed, consider putting a bounty on it. It doesn't have to be much, $10 or so. If enough people put enough bounty on one bug someone's going to bite, or a programmer can do lots of "simple" fixes/features and can make quite a few lots of $10 quickly.

• Feedback

  Providing feedback on what features are used, and what aren't is important to developers who may spend a lot of time on a feature they think is important instead of a feature that actually is important.

• Wiki

  If they are going to put the wiki up, go and define terms, and write pages about things. Write answers to FAQ's. Wiki'ing is very addictive and fun. And while you're at it, everyone learns! I run a wiki, we have over 6,000 pages. It's a lot of fun.

Re:Wish I could code...

[jandrese]

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 :-)

What's wrong with cd /usr/ports/finance/gnucash; make install clean ?

;)

Re:Wish I could code...

[SuperBanana]

Maybe I'm missing something, but why don't you enter the categories when you enter the transactions?

Sorry- should have been more specific. This is after I've imported(via QIF file from my bank) all the transactions. They've got names(comments?), but no expense categories. I'd like to quickly select multiple items to assign to one expense category, otherwise, there's not a huge time savings from importing the QIF in the first place, but the time i get the file downloaded, transferred over to the linux box(Mozilla doesn't handle their download wizard quite right, Safari does it), and imported.

(And why are you waiting 6 months to reconcile?)

Because I don't write checks, and I constantly monitor my account online(balance and history) so I know if something's wrong pretty fast. I use GnuCash to see where it all goes category-wise, what my spending habits are like, etc...and keep a nice electronic record for long term. Gnucash is not a necessity for me- it's a fun toy to help me get better at managing spending etc. Now that I'm consulting more, it'll help me keep track of where income is -coming from- better, not just where it's going :-)

Oh, and I was unemployed until recently, so activity on my account was practically nothing for the last 6 months :-)

Re:Wish I could code...

[molarmass192]

I think they're complaining about all the dependencies for compiling the app. The majority of the installs I've done are runtime only environments. Setting up a full development environment is overkill for the vast majority of not-so-techie users.

<rant>
That said, my beef with GnuCash is the same as my beef with KDE apps. Tying an application to a desktop is a carry over from the Win-word that I simply do not agree with. Code to GTK or QT unless your app is an integral part of the Gnome or KDE desktop.
</rant>

I do think GnuCash is a good effort and these guys have obviously poured their hearts into it. However, I switch between IceWM, TWM, Gnome, and KDE depending on the machine, day, task, etc. Because of this, I avoid apps that are tied to desktops for this very reason. I know they sometimes work but only by starting up a whole rarely even used subsystem. Maybe somebody here can enlighten me by giving me a good reason why the GnuCash team ported the original sources from Motif to Gnome instead of plain old GTK. I don't buy the "familiarity" excuse since happened in 1999 (Gnome 1.0 had *just* arrived), not 2003.

Re:Wish I could code...

[wowbagger]

Is double-entry bookkeepping necessary for personal finance?

Is computerized bookkeepping necessary for personal finance? After all, you could just use a shoebox and rubberbands - that's all some people use.

However, the nice thing about DE is that you can immediately see if you've screwed up somewhere, as it will show up as an imbalance.

You can directly see how much money flows through your credit cards.

You can directly print out what is tax deductable, and should the Infernal Robbery System ask to see the records, quickly dispatch them with your Report, +5 of Audit Slaying.

Re:Wish I could code...

[uberdave]

Double entry is an accounting method where an entry in one account is always balanced by an entry in another account. When you put money towards your credit card for example, you record that money left your bank account, and that money went into your credit card account. When you go to the store, you take money out of your chequing account, and it goes to your grocery expense account. There is always a source account, and a target account for every transaction.

The thing that I think trips most people up is that money never enters or leaves the system. The sum of all of the accounts is $0.00(unless there is a problem). What took me a while to understand was how income worked. People would say, create an income account and then move the money from the income account to your bank account. Fine, but how does the money get into the income account? I finally got it the other day. Income is a bad name for the account. Call it "TheWorld". When someone pays you, when you receive money, someone else somewhere in the world gets poorer, and you get richer.

The beauty of the double entry system is that if the accounts don't add up to zero, there is a problem with the data. With single entry type programs, like Quicken, you would never know if there was a problem.

Re:Wish I could code...

[AbbyNormal]

A very good write up explaining this idea in great detail can be found here: http://www.ncsysadmin.org/july2001/ncsa-gnucash-ta lk.html#toc1

Helped clear up a lot of misunderstanding in my book.

As a side note, I was looking into incorporating my business, and found that the IRS requires a Double-Entry system to maintain records. Sorry, I can't be more precise, that was more of a "Huh" fact that I can across.

Obviously what they need most is...

[siskbc]

...a decent web server.

Greetings, Developer...

[Tumbleweed]

"You have been recruited by the GNU League to defend the frontier against Gates and the Quicken armada..."

was it ...

[middle]

GNUCash calls for help ?

or GNU calls cash help ?

Re:Why?

[the_bahua]

I personally like the idea of having alternatives to proprietary software.

I tried it... Couldn't use it

[cvd6262]

I tried to get my wife to use it. She was taking a personal finance class that required Quicken. I thought we could give GnuCash a try and maybe save some dough/impress the teacher.

Boy was I wrong. I figured out the take-out-of-one-account-to-credit-another system, but I couldn't figure out how to put money into the system.

Anyway, we spent a few hours on it, but eventually just forked over the dough for Quicken and rebooted into Windows.

I'm not wishing death to GnuCash, but it is in need of huge improvements to be up their with the other accounting (personal and otherwise) that I've seen.

Re:I tried it... Couldn't use it

[CoughDropAddict]

Boy was I wrong. I figured out the take-out-of-one-account-to-credit-another system, but I couldn't figure out how to put money into the system.

Transfer money from an income account.

Money leaves the system when you transfer it to an expense account.

This is nice because it shows you where your money comes from and where it goes, instead of stipulating that it appears and disappears in your asset accounts (savings, checking, etc). I can tell you exactly how much money I've spent on automobile-related expenses since I started using GNU-cash. Or how much money I've made from my second job. Or how much money I've paid in FICA tax.

Re:I tried it... Couldn't use it

[sparrow_hawk]

Yes, but the idea here is that instead of having to find the option on the menu that allows me to get the pie-chart report of my expenditures, I can just look on the accounts page and say, oh!, I bought $143.04 worth of books this year! (Actual figure -- I just finished balancing my checkbook with GnuCash last night.)

*And*, if you go to Reports... Income & Expense... Expense Piechart, you can get the piechart for the whole year or whatever, plus all the other reports you could ever want.

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

Lighter alternative

[the_bahua]

...in brinance a command-line driven ledger app. I like it. Have a look.

Re:Gnucash sucks.

[MerlynEmrys67]

Wow so many lines of code! great...its so unreliable...

I must admit that I have NEVER had Gnucash crash on me. Not even once. No lost transactions, no corrupted files, nothing...

Of course I run Quicken, oh well

GNUCash would be great if....

[ErisCalmsme]

If only it worked with Gnome 2? I mean honestly, even after installing Gnome 1.4 in hopes of being able to use GNUCash, I got it to run only to notice that there was no text, anywhere. None. Maybe thats a problem that only I'm lucky enough to have, but I'm sure if it didnt take so much to use it, more people would. It seems silly to have to install an entire (or at least most of) an old version of a "complete desktop environment" just to run one app.

Important, but not sexy perhaps?

[HidingMyName]

I would really like a high quality well accepted Linux/Unix based accounting package. However, most programmers I know don't find writing accounting packages "fun", so they don't work on them except at gunpoint (or for a paycheck).

Thus, I think the ideal solution would be for the project team to generate revenue, either by support or find a paying customer (who would allow release of the source). Suppose they wrote a book and released a free CD of the source code with it? Would that generate enough royalties? This may be hard in the current economic climate, but I think it would give them their best chances. Would vendors who are making big Linux pushes be interested? Have the project leaders directly solicited input (and contributions) from these vendors (e.g. IBM)?

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.

Other projects that need help.

[Anonymous Coward]

There are other projects that need help, to succeed they need all the help they can get. Heres just a small list of desperate projects.

1) Mozilla, one of the largest projects in open source, bigger than KDE and Xfree86 combined.
2) GNOME, the popular desktop. It needs more help in polishing its rough spots and needs features.
3) XFree86, this thing needs a lot of help in cleaning up its messy codebase.
4) Konqueror. The web browser partially developed by Apple for KDE. Its getting good at rendering websites but it needs a clean up and a good debugging.
6) Bochs. If you want to be able to emulate more than a 640x480x4 display, then give it your code.
7) Abiword. This word processor needs better Msword support and proper table support.
8) Kbounce. Its the best game for linux! help those balls roll!
9) gnu/hurd. Will this thing ever get usb support? Maybe you could help.
10) Linux kernel. Want it to keep running reliable and support all the new goodies. Then download 2.6.0-test3-bk2 tonight!

And theres hundreds more. Instead of complaining on slashdot that your favourite probram isn't working properly, help fix it!

Gnucash is dependency HELL

[ksw2]

I love the software. I *don't* love spending an hour or more every time I need it to run on a new distribution, thanks to the assload of picky dependencies.

Why is Gnucash unpopular? Because 3 out of every 4 people I've talked with who've wanted to try it couldn't satisfy the dependencies for their distribution (most of these people aren't newbies to Linux either.)

That said, it truly is in a league of its own in the Linux software world, and I hope it finds what it's looking for in new developers.

Disclaimer: I haven't used it for a year or more, so it may have overcome some of this already

Re:Gnucash is dependency HELL

[Micah]

Yep.

nova root # emerge -p gnucash

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild N ] gnome-base/libghttp-1.0.9-r3
[ebuild N ] gnome-base/gnome-print-0.35-r3
[ebuild U ] gnome-extra/gal-0.24 [1.99.7]
[ebuild N ] dev-libs/slib-2.4.3
[ebuild N ] dev-libs/g-wrap-1.3.4
[ebuild N ] gnome-base/bonobo-1.0.22
[ebuild N ] gnome-extra/gtkhtml-1.1.10
[ebuild N ] dev-lang/swig-1.3.10-r2
[ebuild N ] gnome-extra/guppi-0.40.3-r2
[ebuild U ] dev-util/guile-1.6.4 [1.4.1]
[ebuild N ] app-office/gnucash-1.8.4

It would install, but it would downgrade to the stable version of GAL, of which I think I use the devel version for something else... :(

quarter million lines of code?

[codepunk]

Damn, imagine what I could do with a quarter of a million lines of python code. Seriously C is a great language for systems work, but writing accounting packages in C is just not the way to go.

Re:quarter million lines of code?

[Troll_Kamikaze]

Seriously C is a great language for systems work, but writing accounting packages in C is just not the way to go.

Exactly. Implementing non-performance-critical desktop software such as this in C or C++ today is asinine--it's practically begging for failure.

Experienced developers end up chasing memory handling bugs instead of implementing features or writing documentation, and many potential developers turn away intimidated at the sight of C. Additionally, compile-time dependency hell discourages potential users.

Sadly, this project is on a course of willful time wastage; the choice of C to implement an accounting application will consign it to the dustbin of history. I've seen the same thing happen to similar open source projects, but those who design and start open source projects (as opposed to those who stick with them and finish them) persist in their irrational devotion to C/C++ for application-level programming because it's "elite".

Re:quarter million lines of code?

[Micah]

> so you say using the QT or KDE libraries to develop an application is begging for failure?

They can be used from Python just fine.

C simply is not the right tool for end user GUI application programming, plain and simple. C++ is a *little* better, but it's still too complex.

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.

Re:It's too hard to compile

[foo1752]

This is also my biggest gripe about GnuCash. I tried building it a year or more ago (probably a few years ago, actually), and there were just SO many dependencies that it became a huge cluster to try to get working.

Now, don't get me wrong, I like building stuff from source as much as the next Slashdotter, but these guys just use way too many external libraries.

There current "Software Requirements" page lists these dependencies (some or all of which may be required):

• Gtk+, Gnome, Glade -- I have no problem with these as they're pretty much standard issue now
• Guile -- This is a complete bitch to build and install, in my experience. I understand the need for scripting in an application like this, but why not pick a good language like Perl :)
• G-wrap, slib -- some more Scheme stuff that just seems like crap they needed because they were too lazy to write some of their own code
• GtkHTML -- do you really need a HTML parser in an accounting program? Why not just use Mozilla to display your HTML?
• libghttp -- same thing here. HTTP isn't THAT complicated, especially for what they're using it for. Write it yourself and save us a download.
• 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?

Okay, I'm done complaining now.

I've actually been using Moneydance for the last few months to manage my finances. I know that it is Satan's accounting program, being written in Java and all, but you have to admit that its quite easy to download and install, especially if all you're interested in is balancing your checkbook a couple of times a year.

Re:It's too hard to compile

[Dr.Dubious DDQ]

I get the impression that a LOT of the Gn* programs have this problem to one extent or the other. "Unfortunately", a lot of 'regular' users never see this, because the get pre-compiled (and generally unoptimized) packages and never know that the person who put the packages together had to go out and track down a plethora of obscure libraries, and then update a few of the other obscure libraries to a newer version because the build complained.

I'm 'nerdly' enough that I like to compile a lot of my system from scratch to squeeze out more optimizations from them, which is how I noticed this. Just to compile the 1.3.x series GIMP (which looks nice, by the way, though I haven't had time to do much with it) I had to:

• Update to a more recent GTK+, which demanded that I:
• Update to a more recent GLIB
• and then the GIMP build commanded me to :
• Update atk, which commanded me to:
• update pango.....
• and somewhere along the way, I had to override XFree86's Xft, Xrender, and Freetype versions with updates...
• Not to mention an update of pkgconfig...

I did finally get it all updated and get things running, but it was a pain tracking down the updates, and frustrating that there didn't seem to be any 'up-front' listing of libraries and versions needed (so I had to wait until the ./configure script complained to find out what the NEXT library I needed to update was...)

I suspect if the libraries that the Gn* projects depend on got re-collected into larger 'chunks' of related libraries (much as the 'kdelibs' package does for KDE) this would be a bit more manageable...

Re:It's too hard to compile

[Webmonger]

You're complaining they use libraries for HTTP and XML? I say "good on them". Libraries are a way of pooling resources. If you use libraries instead of rolling your own, you get

1. More testing
2. More bugs fixed, more correct implementation
3. More features
4. More programmers who understand your HTTP/XML/whatever code

Re:It's too hard to compile

[shaitand]

ahem, I just installed gnucash, it was difficult,

open synaptic

click update lists (not needed, but hey it's a habit).

click applications/productivity
select gnucash and postgresql backend, click install on each

click the do it button

done.

that was the "user friendly way"

I could have used the nasty command line everybody says is hard:

apt-get install gnucash
As you command master, do you want me to orally pleasure you 81mb times as well? *sigh* if you must
done.

Re:It's too hard to compile

[Skjellifetti]

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

Yes. I am an economist turned coder. I understand investment theory and accounting, I've been building enterprise software for the past decade, and I have been looking for a finance/accounting project to hack on in order to add support for high-end investment management problems. GNU/Cash seemed ideal until I tried to build it. Bah! These guys don't seem to have any real experience with software design of medium sized systems.

GC needs to broken up into smaller pieces that can be independently studied and built with limited dependencies on external packages. I should be able to build a command line accounting system using a base set of transaction libraries without needing to have much else installed except the libs and precompiler for my chosen backend database. Same for reports. They should need only the db support libs and an XML lib for parsing XML defined reports. Everything else is just GUI convenience or eye candy.

Asking /. readers for help...

[cliffy2000]

Well, it sounds good in theory, but really, all you're gonna get is "In Soviet Russia, MONEY watches YOU!" comments and goatse.cx links hidden in the code.

God Help Us

[DesScorp]

"To get more developers, we must make it easier to contribute to GnuCash. "Casual" sex with Cmdrtaco to scratch an itch is much to hard, even for an experienced developer"

What if this wasn't a troll?

God Help Us!

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.

Mod parent up!

[Micah]

I was thinking of writing the exact same thing.

If it were in Python, I might volunteer to help myself. :)

Seriously, can anyone name ONE SINGLE advantage that C (or even C++) has over Python for this type of app? Certainly, Python is fast enough -- so what if it has to cycle through all your records once in a while. That's not going to take all day. With C/C++ you have to worry about all kinds of low level crap like buffer overflows. You shouldn't have to think about that kind of thing when writing applications that involve business logic. You should only have to focus on the application logic, something Python lets you do much better than C/C++ does.

Re:Mod parent up!

[Zach Garner]

Seriously, can anyone name ONE SINGLE advantage that C (or even C++) has over Python for this type of app?

Sure, at the time it started, more developers were doing C, GUI's were written in C, and so were many of the libraries they wanted to use. Another advantage is that the primary gnucash developers were familiar with it.

And by the way, they use Scheme for *a lot* of the programming via guile. You can google for a little article by Prof. Novig comparing Python and Lisp (short version: Python gives you lots of lisp's features in an easy-to-use syntax).

Re:Mod parent up!

[shaitand]

"especially with a good Sun or IBM box, which that type of app should be running on."

freaking peachtree on windows can handle that on an intel box. It sure as hell should be easily accomplihed on a lintel solution, though I agree about the sql, good thing gnucash has an sql backend...

"3. Each transaction will probably go to an SQL DB. The time to access that will easily trump any difference between C and Python."

yeah, unless I have to needlessly cycle through all my records (at least according to you) because of the nature of python for this type of work.

cycling through records is the most time taking task involved in this type of app, avoiding it is enough reason to develop in another language even if it is lacking in every other respect (which c is not, and with a few carefully written libraries you can code sloppy and still avoid 95% of buffer overflows... unfortunately most skip the former and still go with the later).

Re:Mod parent up!

[dododge]

I can't imagine ANY syntax being more complicated than LISP's brackets within brackets hell.

It's not complicated, it's just hard to type :-)

A language like C has a much more complex syntax, with many operators, special characters, and keywords that are all context-sensitive.

Re:Mod parent up!

[Petronius]

> ok, your a business that handles over a million transactions a month and has a couple hundred thousand customers... what was that about not taking all day?

if at that point you're not running Oracle Financials or SAP but still running GNUcash (or Quicken for that matter), you're smoking crack.

Re:Mod parent up!

[Micah]

> Static typing

Who cares? Yeah, that will fix a few errors more quickly, at compile time. But Python is much more stringent than, say, Perl, and if you're passing in the wrong thing, it will tell you about it eventually.

> better control over memory management

That's my biggest point. If you're writing business logic, the last thing you should have to worry about is memory management.

> tools availability

Ok, Python could do better in that regard

> speed.

Again, who cares? Python is plenty fast enough on today's hardware. UNLESS you are doing something that truly needs CPU horsepower, like ray tracing, Python is easily fast enough.

Documentation, documentation, documentation!

[Jerf]

This fits into my pet theory of successful open-source projects rather nicely; every single flaw except one boils down to a lack of documentation.

"Work on the developer documentation problem" - obvious

"Fix core capabilities in the engine" - the exception, though one could stretch and observe that a lot of the problem is probably that nobody has a clue what is broken due to lack of documentation.

"Improve interoperability with other software or new modules" - fundamentally, the fact it was "non-interoperable" in the first place boils down to a lack of documentation, because why bother adding hooks to anything if nobody can figure out how to use them in less then a year? Adding hooks is easy, relatively speaking, and the payback is huge; the only reason to not do it is if you realize nobody could possibly use them if you added them.

"Make sure the mailing lists are easily searchable" - obvious

"Get more people write access to the website" - obvious

"Quickly implement a Wiki or similar system" - obvious

"Spend less time answering some types of questions" - they should be able to point people at a FAQ, a common type of documentation

If it isn't documented, it doesn't exist. GnuCash's problem is an excess of non-existence, which is rather odd considering how many lines of code it has.

It is so much easier to start the documentation in the first place, and keep it up, then to get to 250,000 LOC and just then try to start. Sometimes clever coders can actually be a liability to a project, because they can plow on where lesser men and women would have needed to pause, document, possibly re-organize, and simplify.

my $s = 'DEVELOPERS, DEVELOPERS, DEVELOPERS, DEVELOPERS';

$s =~ s/DEVELOPERS/DOCUMENT IT/g;

Maybe sell it and raise money to work on it ...

[tjstork]

I don't mean for this to be a troll, but, really, Linux is never going to have applications for end users under the open source model if the applications being developed are not glamorous in some way.

GNUCash... what's that? What's sexy about accounting?

You aren't going to get people to work on that unless you pay them, or, they want to write their own business rules engine. So, either finish GNUCash on your own, or, someone else will step up to the plate with a better, more elegant model.

Throwing more bodies at a problem is a Microsoft approach and the whole idea behind oss is that hopefully someone will step up to the plate with that really radical idea that simplifies everything and gets you from 250k lines of crap to maybe 50-100k lines of sane code.

One of these days I'll learn to not post when I haven't had a beer...

Re:Gnucash sucks.

[wik]

Version 1.6 has crashed on me a few times. More frequently, my X server crashes (Xwin32 doesn't always enjoy GnuCash for some reason). When that happens, I lose the unsaved transactions. I'd like to see it either append to a lightweight transaction (if you have a large ledger) or save after each transaction is changed (better for smaller ledgers). This way, even if you do crash, you only lose the what you haven't entered.

It makes sense / it makes no sense

[Klync]

Well I admit I went ahead and read most of the comments while I was waiting for the server to respond.... And a lot of the criticism of the GnuCash team sounded reasonable. But, after reading the FA, I have to say... Go GnuCash, and that accountant guy who loves it so much should write a book about how to use it, in collaboration with the developers who are currently documenting the API.

Enough of the bitching from the /. community... they didn't come here, we (or, at least the /. editors) brought the story here. So, how about some constructive responses to their plan? I think if they can get half of it done in the next few months, the project will live and evolve for many more years. Sounds like the compromise of using C and Scheme could work great here (you Python developers are trolling), as long as the core and plugin functionality are well divided. Not knowing what their code looks like, I wondered how well that has been done to date.

On a related note, I would suggest one more thing to those who wish to see this plan bear fruit: Reduce the dependency tree!! That will need to happen, any way you cut it. I'm sure this is possible if the developers attack it from all possible angles.

Umm...

[Steve G Swine]

If I want to deal with a quarter million lines of dependecy-laden code that the original developers can't make serve the purpose... I just go to the office.

Pass.

(Or is it a quarter billion LOC? I can't tell the difference anymore either...)

Good luck, though. After you turn it around, be sure and drop us a note saying how, k?

online banking?

[no_choice]

GnuCash, from the begining, has suffered from a major disconnect between the developers and its (potential) users. Besides the absurd dependency problem which makes installing it nearly impossible, after six years in development, it STILL has no true online banking capability... how is this possible?

Yes, there are many barriers to implementing this capability. But the project has never given it the priority it needs (and seems to still be unlikely to... Gregoire says he will work on it "if I can just find time").

Re:online banking?

[benoitg]

Well since I am Gregoire, and you seem to think I am not giving it enough of a priority:

How is it possible?

Because I already spent MONTHS on it, I'm the author of LibOfx and also wrote most of the new import framework in GnuCash (Those who only import qif haven't seen it yet). I pretty much got it up to the "WebConnect" level people (including me) have been whining for years to get. But oups, now the rage is DirectConnect, which frankly shouldn't require much more work, except

-Like everyone I have to eat, and I'm already overworked.
-My own bank doen't support Direct Connect so I can't test what I work on, not to mention I now work on it for PURELY altruistic reasons, since it's obvioulsy of no use to me.
-Banks are completely uncooperative, they won't give out the url of their ofx server to their customers, nor tell them what to use as username or password. Ever wonder why in 6 years NO open source app has managed to get direct connect working? Believe me, others have tried, and they were far from incompetent.

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?

Re:Yes, it does...

[guybarr]

I'm not sure just how much of a part you played in GnuCash's development but your attitude confirms my opinion that it would be very dangerous indeed to use an open source product to store important dfinancial data

And this is backed up by your later arguments how ? please give rational, technical justifications for your claim.

The fact of life is that using the industry standard file format is incredibly important to acceptance of a product like this.

Gravity is a "fact of life". What you made was an estimate w.r.t. an engineering+marketting decision. Does have (perhaps) empirical implications, but, fact it is not.

(In the following I use "naive" in the SW-devellopment context:)

For which I will give you a competing estimate: File formats are, by themselves, not directly important to the naive user; as long as you provide the tools to transform between them.

Formats are, however, exteremely important to the knowledgable user (a.k.a. developper). And this is indirectly important to the users, as simpler, cleaner formats make for easier developpment and maintainance.

Try and get your head around two facts:

Again, saying something is a fact does not make it so.

Most accountants could hardly understand a word of your posting.

Most music lovers wouldn't understand the technical discussion between two conductors either, that does not mean they couldn't enjoy their music ...

All they would understand is that you think they are stupid for wanting Quicken compatibility.

No, they would understand there are things they do not know w.r.t. SW-dev. which is not the same as being stupid !
Importance of open-formats and vendor-lockdown can be explained to laymen just the same, though.

Most of GnuCash's "customers" are accountants.

Can you back this statement up with numbers ? A reference ?
I'm not saying you're wrong, I truly don't know.
I must say this will surprize me, b/c gnucash is a personal finance software.

Re:Yes, it does...

[Omnifarious]

You know, you have that almost completely backwards. It's kind of amusing to see someone with an opinion that's so totally wrong.

GNUCash imports and exports Quicken just fine. The core data is kept in XML, where it belongs. QIF is not an industry standard file format, it's a proprietary file format and is as byzantine and non-standard as you should expect of such a format. If you want real interoperability with other applications, XML is exactly the thing to do in this case.

The only times the file format matters to the accountant are these: when she's trying to get her Quicken files into GNUCash; when she's downloading a QIF file from her bank; and if she drops GNUCash for Quicken and wants her data back. Import and export of Quicken files is just fine for all of these situations.

Jerf...

[Goonie]

Please go and have a look at the GnuCash codebase before slagging the developers off.

It is not perfect, and maintaining documentation is hard work, but compared to many other projects the GnuCash codebase is extremely clean and relatively well documented, unless it's deteriorated horribly since I last looked which I doubt.

GnuCash's user documentation has always been pretty good, though I may be biased because I had a major hand in writing the docs in 1.6. The big problem with documenting GnuCash is that most people not only need to learn how the program works, to use any accounting software they need a tutorial in accounting 101, which is not simple and varies greatly from country to country and business to business.

AFAICT the biggest issue is simply the lack of people coding on it. Maybe people get scared off by Scheme, maybe it's lack of sexiness of accounting software, maybe it's that people assumed that Gnumatic/LDG were still funding development, maybe it's just that none of the GnuCash developers (except maybe myself at the time ;) )are fame-seeking publicity hounds. In any case, here's hoping some enthusiastic newcomers will help out.

It's not tied to the desktop...

[Goonie]

GnuCash runs fine under a KDE desktop, a TWM desktop, or any desktop you care to name provided you've got the right libraries installed. I really wish people would put this hoary old chestnut away.

The reason why we used the GNOME libraries is that they provide a bunch of stuff that otherwise would have to be recoded by the developers. Is that so hard to grasp? I am befuddled why anyone would develop Un*x end-user apps without taking advantage of the facilities that GNOME or KDE provide.

Re:It's not tied to the desktop...

[Prior Restraint]

The reason why we used the GNOME libraries...

I'm going to assume from your use of the word "we" that you're one of the seven (if not, my apologies). My question is this: are the front-end and back-end severable? That is: would it be reasonably simple for someone to write a front-end that uses the KDE libraries, if only to silence the critics? Something like:
"Download gnucash-back-2.0.0.tar.gz and your choice of gnucash-front-gnome-2.0.0.tar.gz, gnucash-front-kde-2.0.0.tar.gz, or gnucash-front-ncurses-2.0.0.tar.gz"

I use GnuCash all the time; I certainly hope there's something I can do to keep it alive.

Windows version needed

[Mustang Matt]

I know no one wants to hear it, but I personally think this app is dying to be ported. I mean apache and mysql are and they're both huge successes.

Would this be the first open source windows accounting package?

Let's play MadLibs

[autechre]

Let's replace a few words:

"But many people have said [that] Linux is NOT a replacement for a desktop operating system, thus Linux does not satisfy the home user or the business user's needs. And look how many years it's taken already. I say move on and write a new program."

I say eat it. I took accounting in school, I keep track of every last cent that passes through my life, and GNUcash is excellent. It took maybe 30 minutes to get started, and several more to figure out split transactions, but that was definitely worth it. Yes, there are areas that could use improvement, but saying "I don't like it, my friends say it's bad, start over" is idiotic.

[On a side note, it's a major failing of the educational system in the US that NOTHING is taught about budgets, finances, etc. in grade school. At least the importance of keeping records should be impressed. GNUcash, a program that keeps track of things correctly, should be much more popular.]

One thing that scares me....

[plazman30]

Well, we have GnuCash here that is in danger here and it has no way of exporting your data. Now there is a scary thought.

One thing I have to say is that the most important feature for me in a financial app is cross platform use. Because of that, I chose to spend money on Moneydance. It's written in Java and has great support. I run it on my Mac at home on both my Windows and Linux partitions on my laptop.

If you prefer to go the free software route, there is jGnash, whch will also run on various OSes, becuase it's also written in Java.

GnuCash is good product, but it has way too many dependancies and relies way to heavily on Gnome. Because of that, it can't be ported to Windows of MacOS X, even though there are native GTK libraries for both those environments. Perhaps the GnuCash team should focus on making a really good accounting engine and allow others to wrap GUIs of any kind around them.

A personal financial app is very important to the Linux desktop. I think it's far too important for the application to be in jeapordy of disappearing. Perhaps someone like Ximian should add this to their list of software, or the FSF should turn around and get some people coding full time on this with a grant.