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."
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)
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...
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.
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.
IAAL
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
I have mod points and I am not afraid to use them
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.
Chaos is Divine *
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.
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...
This is my sig.
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 theI 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...
Hacker Public Radio is our Friend
I am one of those super-anal people who records everything financial: cash, checking, investments....everything. I am a long time Quicken user. I've spent a bit of time recently investigating GNUCash, and I feel it has promise. I don't mind the dual accounting method used by GNUCash as long as it does what is needed to get information back out of the program (reporting).
I am in agreement with you that investment reporting is an area where GNUCash lacks functionality. Of particular importance is reporting of capital gain/loss and investment performance (time-weighted rate of return). These are the features that are preventing me from moving from Quicken to GNUCash.
I would hate to see GNUCash lose steam and die. I am hopeful that in the future it will acquire the features I need, permitting me to make the change.
Please don't give up on GNUCash.
Red
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.
/. 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.
Enough of the bitching from the
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.
----
Not to be confused with Col.
"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).
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?
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
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.
Need a Python, C++, Unix, Linux develop
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.