GnuCash observations

[Ian Pilcher]

I've been following all the activity spurred by Benoit's article with a
great deal of interest.  I'm a huge fan (and devoted user) of GnuCash,
so I certainly consider myself a stakeholder in its success.

In "real life", I work as a pre-sale IT architect.  This gives me the
opportunity to do a lot of high-level application design, but I am not
actively involved in the actual implementation of my ideas.  (Anyone
remember that UPS commercial?)  That being said, the people who are
responsible for the implementations know where to find me, and I haven't
received any death threats yet.

I also do a little bit of C coding from time to time.  I'd like to think
that I can help out a bit in that regard, but I'm not sure that my
skills are up to the task; we'll see.  (BTW, I've been poking around
some of the design documents in the source tree, and if you all think
that GnuCash's internals are undocumented, check out rpmlib sometime!)

I offer the following thoughts/observations/opinions in the hope that
they may spur some useful discussion.  I don't expect anything I say to
be accepted carte blanche.

A couple of my ideas are fairly radical architectural changes.  Please
don't interpret these as criticisms of current or previous developers.
These suggestions are based on a "starting from scratch" scenario, and
one of my reasons for writing this note is to determine if they are in
any way doable given the current codebase.  (Look at it this way; at
least it's not a 20 year old COBOL application.)

So here we go, in no particular order...

1.  PROJECT MANAGEMENT

     The difficulties that Benoit describes could be seen as the "dark
     side" of the Open Source development model.  "Given enough eyes, all
     bugs are shallow," but what happens when the number of eyes begins
     to shrink?

     I submit that the core GnuCash developers are faced with a choice --
     either (1) attract a sufficient number of developers to continue
     with a "Darwinian" development model, or (2) adopt a more
     "corporate" model.  I also submit that option #1 must be
     accomplished in a relatively short period of time to be successful.

     If option #2 is chosen (which I think may be unavoidable), the first
     priority must be to get a core set of features fully functional.
     Actually, that would be the second step.  The first step would be to
     decide what those core features are.

     Patches which do not serve this end should not be accepted into the
     main tree.  (Ideally, however, a mechanism should exist to encourage
     the development of new features which can later be "promoted" into
     the main tree.)  Additionally, any non-functional modules should be
     removed immediately.  (I believe that the RPC backend, for example,
     fits this description.)

2.  ENGINE/INTERFACE SEPARATION

     From what I can tell, it appears that separation of the GnuCash
     engine and interface exists only at the source level.  If the Qt
     interface were "resurrected", for example, it could only be a
     compile-time option.  There is no way for an interface program to
     connect to a running engine.

     In an ideal world, the engine would run as a separate process from
     the client, communicating via a network-transparent method such as
     RPC.  If a stable, well documented interface can be created, it may
     be possible to actually split off the GUI into a separate project;
     this would make both the GUI and the engine smaller and more
     approachable for new developers.  It would also, of course, enable
     the creation of third-party interfaces.

3.  MULTI-USER ENGINE?

     The current tight coupling of the interface and the engine forces
     any multi-user capability to be implemented at the data store level.
     This is something that I can't recall ever seeing in this type of
     (read/write) application.  There may be a good argument for doing
     things this way, but it "feels" like its forcing the DBMS to do
     something for which it wasn't really designed, particularly in
     "Multi-User Events" mode.

     (How does PostgreSQL deliver events in "Multi-User Events" mode?)

4.  BACKENDS

     At present course and speed, it looks like there will be continual
     struggle to keep the capabilities of the XML and PostgreSQL backends
     in sync.  I would like to suggest that the best way to address this
     is to support only SQL-based backends.  The XML backend would be
     supplanted by an embedded SQL DBMS such as SQLite.  (SQLite just
     happens to be the first such "product" that I found on Freshmeat;
     I've never heard of it before tonight.)

Well, that's all the controversy I can stir up right now.  I'll be
interested to see what people think.

-- 
========================================================================
Ian Pilcher                                           pilchman at attbi.com
========================================================================