Design Decisions

[tripp+gnucash-devel at perspex.com]

On Thu, 28 Aug 2003, Linas Vepstas wrote:

> Havoc is paid work on Gnome full-time.  I am not.
	[...]
> Gnucash has zero full-time, paid developers.

What would it take to make this otherwise? I mean, just brainstorm
outloud, because maybe someone's out there in a position to make it happen
(individually or collectively).


> I have a house, 2 kids, and need to maintain a web site, do the
> backups, handle the network issues, as well as write code. I manage
> 5-10 hours a week.

If there's no good answer to the question above (which there may not be,
who knows?), then let's move on to this, because this is definitely
something we ought to be able to address.

There are probably plenty of people in the gnucash community who could
take on (or take on the automation of) some of these tasks. For instance,
I work for a firm with lots of in-house site architecture experience, a
nice content management toolset, and mad sysadmin skillz. I know there
must be some small-medium ISP out there using gnucash to manage their
books, and would repay by mirroring, doing live / rsync backups of the
site content, CVS tree, etc.

In other words, there must be some way to distribute some of this load so
that you can focus on code.


> > The GnuCash developers need to put together a vision for future versions
> > of the GnuCash codebase.  I don't see that vision anywhere.  You just
>
> I guess you don't like http://gnucash/en/roadmap.phtml
> (which hasn't changed in 2-3 years, and no one seems to comment on?)

It's a fine document that asks a lot of worthy questions about the road
ahead. It might be stronger if it answered some of those questions, or
assigned priorities to them, or established mechanisms for answering them
(e.g., a "roadmap review").

Perhaps people would find it easier to comment on if it were in a Wiki, or
copied to a Wiki, or had a discussion group attached. Perhaps not.

As for the fact that it hasn't changed in 2-3 years, perhaps it should
have? Has anything changed in 2-3 years that affects the relevance of the
document? Should it have a regular, "formalized" review by the gnucash
core team (developers) and core community (list lurkers, users, etc.) to
validate the path?

A perfectly acceptable answer to some of these hypotheticals, by the way,
is "no. gnucash scratches the core developers' itch, and this is as it
should be." I'm merely throwing out what I hope will be helpful questions
to think about how to get things moving positively.


> There is a difference between 'vision', 'strategy' and 'plan'.

Absolutely.


> "We want this and that in the next release" is a plan.
> Roadmaps are things that the marketing team trots out to keep customers
> appeased while the engineers work on the next version. Engineers
> don't pay attention to roadmaps.  They follow the plan.

Here's where we diverge, or maybe I'm misunderstanding your statements? Do
vision and strategy play a part in gnucash? This paragraph implies they do
not, and that's why I ask if I'm reading it correctly.

The roadmap document referenced above implies that there's a -desire- for
a vision (and strategies to back up that vision), but the document itself
does not establish that vision. The document, instead, asks "what would
such a vision be like?" and "what do we want that vision to be?"

Since I don't like to just throw out problems and not help with solutions
(except when I'm being a troublemaker :) ), I'll try to jump-start this
with a simple question:

	What's the purpose of the GnuCash project?

I've read the main page and the roadmap page and the goals page and the
architecture page, and I already know the answer to this question :) (as
stated by the project's own documents, that is). My purpose in asking the
question is to focus attention on it and its simple answer.

That answer should be the yardstick by which the project judges its work.

Now, with this answer in mind, returning to the "problem" of the roadmap
page, I'd say that the page is not a roadmap so much as a page that asks
the question "now that we're almost there... do we want to alter the
purpose, by extension or even redirection?"

Whether the purpose changes or not, it needs to remain at the center of
all the work, guiding the team's decisions, and being agreed upon by those
responsible for the project's existence and evolution.



> I did. We have *three* client server implementations (RPC, HTTP, SQL).
> No one cared.

For the record, I care quite a lot, I just haven't had time to express
that caring in code. I promise to do so in the future :)


> Client-server is a statement about network technology, and not about
> application design. Client-server is a set of design priniples that
> allows multiple users to access a single database.

I don't mean to be contrary, but this is not strictly true. Client-server
(at least these days) simply implies a separation between (well, this
sounds dumb, but...) a client of some services, and a server of those
services.

In that sense, then, as I understand the gnucash architecture, "engine"
could stand on its own as a server of the six basic object types. The fact
that it does so in-process at present is does not invalidate its
server-ness, it simply changes the transport layer from sockets or pipes
to the stack...


> > so you don't have the GUI migration issues you currently suffer
>
> This has absolutely *zero* do do with client-server.
> First of all, there already is a separation between the gui and the
> engine and if you'd studied http://gnucash/en/architecture.phtml
> you would know this.
>
> Secondly, the separation between engine and GUI is orthogonal to
> client-server.

I'm going to (hopefully respectfully) disagree again, here. The GUI at
present is built as a collection of C modules, is it not? And the entirety
is linked together into an application that in turn links to the Gnome1
libraries.

Is it safe to say that an application trying to link transitionally to
both Gnome1 and Gnome2 would have a "hard time of it" (which is to say,
blow chunks all over the floor and be too sick to clean up its own
godawful mess)?

Bear with me, I have a point :)

If, instead, the GUI were a federation of components wagging their tails
at each other to accomplish the end result, then (so the theory goes) any
one of those components could be replaced without worrying too much about
any bindings -within- each of the components.

And that, in turn, means that an upgrade / transgrade / customization
could be done incrementally and transitionally to a codebase that
therefore remains "stable" throughout.

Which is not to say I'm suggesting this path for GnuCash specifically, but
that it's something to think about, and something that runs counter to the
orthogonality assertion above.

(and, yes, I'm aware of the relative cost of out-of-process calls vs.
in-process calls; I've written an ORB and many distributed systems in my
day. I maintain that Moore's law makes better architecture possible :) ).



> Alsmot all gnucash users use it in single-user mode, which is why they
> don't care about client-server.

The easiest answer to this is that, according to the "Project Goals" page,
multi-user support was "Partly done" as of 1.6.0, and according to a quick
skim of some list archives (which I confess may have led me to the wrong
conclusion), there are still outstanding "issues" that keep this from
being as stable as the rest of the package.

If this is the case, I know, for instance, that my wife and I are not as
likely to sit down at our respective machines and divide up the data entry
work as we are to divide it up along the lines of one person prepping
everything and handing it off to the other person who's typing.

What was that story about the railway line that refused to add a stop
because they sent out a representative to the station and he didn't see
anyone waiting for a train at that time? :-)


However, there's another, I think, more important answer implied by my
"client/server" GUI postulate above. Users may not care about
client/server, but developers very well may. To say that "no one care[s]"
is to miss the power of a complete implementation. Again, please correct
me if I'm misunderstanding, but the "Project Goals" page says:

	The Engine currently handles only a basic set of data sources:
		[...]
	    * It can read and write its own XML byte stream;
	      This ability has been used to provide a multi-user
	      client-server demo (which is currently broken).
	    * It can use a Postgres SQL database as a datastore,
              thereby enabling multi-user and auditing functions.
	    * It can talk, via RPC, to a gnucash server. (This code
              is 'alpha' and incomplete/broken).
		[...]

Of those mechanisms, two are broken, and one (the SQL approach) is, to me,
a less elegant way of approaching multi-user and client-server systems. As
a developer, I'm going to take more time to "get around to" working with
that code if I know I first have to get it into working condition.

Not that I'm trying to shirk, here... I know that if client/server, RPC,
what have you is important to me and no one else, it's my responsibility
to get on it and stay on it. I'm just trying to make it clear that "no
one care[s]" might actually be "no one has made their care apparent yet
because the startup friction is too high to overcome whatever else they've
got on their plate right now".


> Excuse me, I'm getting irritated. You are making harsh criticisms,

I know I'm not the original poster, but I also know that I'm treading into
some of the same territory. I want to make it clear that I'm not trying to
make "harsh criticisms" in any of this, but rather to give constructive
feedback and try to figure out how I can contribute to the GnuCash I want
to see (which, for the record, is the uber-developer-friendly
whatever-langauge-backend-OS-transport-you-like finance application
development tookit).

I hope this helps, and, if it doesn't, well, there's always /dev/null.

Thanks for listening!

- t.