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

[Derek Atkins]

Hi,

I suspect this thread should probably move over to the -devel list, but
I'll leave it here for now.

Benjamin Carlyle <benjamincarlyle at optusnet.com.au> writes:

> 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.

I think the source code layout isn't as consise as it could be, but
each individual source file is fairly well modularlized.  For _MOST_
functions you can easily divine which source file to look at based on
the function name.  Part of the problem you see is that there was an
historic goal to clearly separate the engine and gui-agnostic parts
from the GUI-specific parts.  This wound up complicating the source
hierarchy and giving the code an appearance of spaghetti.

Seriously, the more you look at the code the easier it is to
understand.  Especially with some judicious use of:

  find | xargs grep ___

> 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.

Hey, everything starts somewhere.  Keep in mind that the gnucash
project is almost ten years old!  The original interface was in Motif!
There was no RDF or XML at the time.  The only usable SQL engine
around was postgres, and that's STILL way too heavyweight for the
average gnucash user.

QOF as it stands now is just a refactoring of the query engine gnucash
has been using for almost a decade.  Nobody else is using it yet
because it was only recently refactored.  It takes time for people to
see and start using a "new" package.

> 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.

Again, keep in mind historical context.  The port to Glib/GTK happened
around 1998 or 1999.  At the time there were two interfaces, the motif
interface and the gtk interface.  There was a very active set of
developers who were working nearly full time (as far as I could tell)
on progressing the code.

Unfortunately the forward progress made by the developers has slowed
significantly, and the hurdle to port the gtk code over to gtk2 is
SIGNIFICANT.  See the FAQ for this one.  It's not a one-man-week
project.  It's a several man-month project, and right now we've got
maybe a total of half-a-developer to do all the work (porting plus 1.8
maintenence).

Go take a look at the g2 port.  The UI is mostly complete now.  The
problem right now is that a number of feature dependencies no longer
exist in g2 (e.g. Guppi for the report graphics) so we need to spend a
lot of time finding a replacement and then hooking it in.  This takes
a lot of time and effort that we just haven't been able to sustain.

> 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.

Here we agree totally.  We've been working to reduce the dependence of
Scheme.  It was over 20% of the codebase.  Now it's down to about
15-17%.  Also, I still curse the names of the ancient developers to
half-modularized gnucash into the pile of steaming bits you see and
then left without completing the job.

Do I feel Scheme was the WRONG language for the job?  Maybe..  Maybe
not.  But the way it was intregrated is certainly bad.

> 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.

Unfortunately while I've had similar thoughts, that just isn't
reasonable.  Gnucash has had several man-decades of effort put into
it.  Yes, man-decades.  Throwing that away is like telling Microsoft
"ok, windows was a good experiment.  Now go start over.  Oh, but you
still need to be compatible with all your users' applications".  It's
just not a reasonable approach.

Future releases of gnucash need to leverage the work done so far.  We
need to make incremental changes to make forward progress, otherwise
you have a nearly-insurmountable problem to overcome.  On the other
hand we DO need to make forward progress.  It's happening.. Slowly.
For example, Josh has successfully built gnome-office-graphing into
GnuCash, and is trying to finish the integration process.

However we do need more development resources to put at the problem so
we can actually complete it.

> 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.

I would again urge you to help with the G2 port.  Ignore the scheme;
it's such a small portion of the code that few features are left in
it.  The only major pieces left in scheme are the reports and the
'options' (oh, and the qif importer, at least until I finish the new
one).  Everything else of note is in C.

If you need help, most of the developers are on the #gnucash irc
channel on irc.gnome.org and we're usually able and always willing to
help new developers with questions.

I look forward to you helping.  :)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available