I tried using gnucash the last 3 months, trying to reduce my dependence on commercial software. I am a proponent of open source, so I figured I should be using it where it is available. I really tried. I got used to using expense accounts for categories, even though it means I have to jump through hoops to see how much I have spent in the last month, or in the last year, or this year so far. I actually liked the way it handled my real accounts, credit cards, checking, so on.
I gave up on it though, for two reasons.
1)Its budgeting tools are vastly inferior to Quicken's. This is actually very important to me. My primary reason for using either program is to create a budget, see how well I am following it, and seeing where that budget has room to give, so that I can get a firmer idea on how much money I have available. I still have not figured out how in the world it is generating its numbers when I tell it to estimate amounts for various categories. Its "budget report" is utterly horrid. It gives you a list of each month, how much is budgeted that month, and how much you have actually spent. If there is a way to get the columns to be colored, so that it is easier to figure out which two columns go to gether, I cannot find it. If you could get the rows colored, so that you can follow a row across the year, that would be even better. As it stands, I have now reached July, and cannot see both the row names and the month's values in the same screen. This makes it very hard to use. Moreover, it handles each category separately. The developers consider this a feature, because the different categories might be different currencies. Well and good, but when I charge something to Auto:fuel I expect to see that I have less money available for the rest of the month in Auto, not just Auto:fuel, and it is totally bogus that I can budget more in Auto:fuel than exists in all of Auto. Which brings me back to setting up that budget. Once I estimate the values, get some sensible values and some off the wall ones, I try to go through and make sense of it. I have to update all sorts of cells manually, on a per-month basis, keeping track of things like "I just added \$10 to Auto:fuel, make sure I add it to Auto also." The month by month thing is not so bad. It can make havoc of a budget report when your tax return arrives in a different month than last year's, but that's fine. It lets me have more fine grained control for things like birthdays and Christmas, and other once a year events like car registration and inspection. But again, I need it to handle more for me, and I would really like it to estimate reliably.
2)It is not stable. This is not so much a problem on linux, though sometimes I have to wait longer for an update on my debian unstable install, but I am primarily using it from OSX right now. And when it starts to crash, and the responce I get from the macports people is "report this upstream, because though clearly an error in the macports library stuff, I do not hit this and maybe some random user who cares enough about gnucash to be on its user list has," I realize that this product is not ready for normal people. I get a massive amount of mail every day. I do not need or want to be on a "user list" for every program I use. Open source programs should Just Work. While its acceptable to have someone read the man page, or its help file, or even its online docs and FAQ, it is not reasonable to expect them to subscribe to a mailing list because the next upgrade might break all over the place.
When we in pidgin have a broken release, I sometimes get frustrated that people do not even check the most recently submitted 10 bugs to realize there are 5 duplicate tickets already. But I do not blame them for coming and submitting bugs in the first place. This is why we have been known to release updates in very short order when a release breaks for significant numbers of users. A program should at very least still run after the upgrade.
When I submit bugs to debian and redhat, and as I am reading bugs from those distributions and ubuntu, I do not ask those users to submit bugs directly to us. They are going to their distribution's bug trackers because that is where they obtained pidgin. This is a good thing, because the distribution has a real role to play, making sure that the programs it packages actually work with the other packages they distribute. So when gtk2 does not compile against cairo if I enable quartz, I do not like it when the macports people say "well, upstream changed cairo, and we can't be bothered to make gtk2 match it until they do, so it will just be broken for a while." Similarly, when gnucash cannot launch because of an error in the jpeg library, I do not want to have to find and subscribe to the gnucash mailing list because the macports maintainer cannot be bothered to help me figure out what is wrong.
This, I think, is what is wrong with the various source based distributions, be it macports, fink, gentoo, or whatever. They allow so much flexibility on what ends up on the system, that the maintainer has no clue what your system actually looks like, and so no basis from which to help you track down why things break. While debian does not allow you the flexibility to compile vim with our without multibyte support, or gnucash with or without quotes (whatever it means to compile it without quotes), at least when there is a problem, the maintainer knows where to look.