LWN.net Logo

Missing functionality holding them back: Budgeting and Export

Missing functionality holding them back: Budgeting and Export

Posted Aug 11, 2003 18:48 UTC (Mon) by dwheeler (guest, #1216)
Parent article: State of the GnuCash project

GnuCash is an important project, and I wish them the very best. However, speaking as a potential home user, there are two major weaknesses with the current GnuCash. Basically, it lacks support for:

  1. budgeting (input budget, compare/graph vs. actuals), and
  2. data export (as so-called "Quicken" files).
They might also consider a Microsoft Windows port, which I'll explain in a moment.

This is not an indictment on the project. Indeed, it's impressive that they've come this far, and the list of "critical missing features" has steadily shortened. For example, they once couldn't handle repeated transactions... and now they can! In fact, perhaps they can export data now... but I just checked their website briefly and didn't see it (can anyone tell me otherwise?).

In fact, given all the the infrastructure they've put together, I think the "critical missing features" list is getting rather short. I think they WILL get more developers once they get those missing features fleshed out.

I think they're right to focus on development to get more developers, and that they're almost over the hump... just a little more to go. Look at other successful open source projects with many developers. In general, they only got a lot of developers once the program had enough functions to be useful to some target audience. For example, the Linux kernel project really grew once there were market niches it was already well suited for (e.g., special-purpose low-cost servers on x86 machines).

What seems to happen is a very small percentage of users become developers, so if you want more developers in an open source project, you want to create a very large user base.

The GnuCash folks have an ambitious project to support both home users and small business users. Ambition is fine! But GnuCash developers need to find some subgroup of users and create a product that's "good enough" for the basic needs of that group. I suggest home users, for their needs are easier: most just need to keep track of just a few accounts and compare them to a budget. Some home users will be more willing to experiment with a "new" product, too. But I suspect few home users will be able to use GnuCash without budgeting. And, with an export capability, they can use other projects and not fear getting "stuck" with GnuCash (giving them the confidence needed to try GnuCash). A Windows port would also add a large number of potential users, eventually resulting in more developers. It would also make it easier for users to transition... first switch to the open source applications (Open Office, Mozilla, GnuCash), and once they've done that they can then switch operating systems.

So, my advice: focus on the home user. Add budgeting and QIF export, enough for their needs. Then work to get lots of users (maybe even with a Windows port). Some of those users will become developers, and your life will get easier. Well, at least, you'll have a different set of problems ;-).


(Log in to post comments)

Missing functionality holding them back: Budgeting and Export

Posted Aug 11, 2003 19:12 UTC (Mon) by smoogen (subscriber, #97) [Link]

Well are there programmers who are familiar with how a budget is done?

Missing functionality holding them back: Budgeting and Export

Posted Aug 11, 2003 19:56 UTC (Mon) by benoitg (guest, #13928) [Link]

Well, QIF export should happen thru LibOfx before the end of the year.

As for budgeting, there have been discussions about an implementation model in the past, but we never settled on an architecture, especially since we were waiting for Lots to be completed. But now that active work on Lots is in progress, people are most definitely welcome to start discussing it again.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds