Getting money for Gnucash development [was Re: Newbie migration issues]

[Benjamin Carlyle]

On Sun, 2005-01-30 at 01:16 -0600, TC wrote:
> But maybe all of this is conceding too much ground.  Perhaps the trick 
> here is not to get money to allow the existing developers to go full 
> time.  Instead, perhaps it is to figure out why there aren't more 
> non-full-time developers. I'm basing this on the hypothesis that even if 
> Mozilla didn't have funding, it would still have a lot of developers. 
> Surely the linux kernel shows that serious unfunded development is possible?
> And I would have thought that if a young coder, with spare time on 
> his/her hands, wanted to hack on some worthwhile and valued OSS project, 
> a Quicken-for-Linux would be one of the top three projects (the other 
> two being the kernel itself, and something like Chandler).
> So, how come it doesn't?

As a software engineer myself I would put the main problem down to
Gnucash being a pile of spaghetti and inappropriate technology choices.
I would also say that at least one Gnucash has a terse online presence
and dismissive manner that doesn't encourage newby participation, but
mainly I'd put it down to Gnucash's code base itself. This is the fault
of historical choices, not of the current developers.

Let's look at the main architecture components:
1) QOF
2) C/GTK+v1
3) Scheme

QOF is a reinvention of querying capability used only by gnucash and
gnucash authors. It's an unnecessary abstraction layer that makes
gnucash more difficult to write code for and is a hurdle to learning. No
matter how good it might be technically, I will never believe it to be
superior both to SQL and to all of the RDF and XML query capabilities
developed over the last few years.

C combined with an out of date GLIB and GTK is not easy to work with. It
requires a whole lot of typing to do anything useful. Gnucash needs to
be able to leverage better technology and more widely used technology if
it is to gain popularity with developers.

Scheme is a nice idea and a reasonable language by itself, but it never
got off the ground. Touted at the time it was integrated into Gnucash as
they way to add generic scripting capability to your application, the
promised "perl", "python", and miscellaneous language modules never
appeared. Neither did significant useful support libraries.

My personal view is that the only way to save Gnucash is to treat its
current form as an interesting and significant prototyping activity that
needs to be started from scratch for the next major revision.

I may be biased in saying that, having attempted to do exactly this[1].
I can actually report back that my project is currently a complete
failure, given that I haven't done any HMI programming before and really
need to get some design patterns straight in my head before attempting a
new prototype. I think that my choice of implementation language
(python) will fail to scale into a larger application. I'll probably
start working towards a Java solution in a few months time when I've
gotten my act together again.

-- 
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>
[1] http://sf.net/projects/transactionsafe