Slashdot Mirror
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."
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)
Still hoping for Gentle Treatment...
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
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
...in brinance a command-line driven ledger app. I like it. Have a look.
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.
"Life is tough but we're tougher. You only get what you give, so give all that you've got." --Tony LaRussa
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.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
I agree it's a great package, and I love it- but there are several things which REALLY irk me.
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:
Please help metamoderate.
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.
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, 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.
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.
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!
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.
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)
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.
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.
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.
I read the internet for the articles.
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.
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?
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
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.
"I'm not impatient. I just hate waiting." - My Dad
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? :)
Like what I said? You might like my music