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 [EMAIL PROTECTED] ========================================================================
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
