Design Decisions

[BenoitGrégoire]

On Tuesday 19 August 2003 11:40, Charles Goodwin wrote:
> I've been a distant lurker for some time on the GnuCash project.
>
> Some conversations have cropped up and died down on reasons for
> GnuCash's woes with regards to it's developer base.
>
> They all have a common theme.  They all end with a GnuCash developer
> unequivically stating: "We're not changing project direction."
>
> That's fine, it's *your* project after all.  But you cannot then go and
> complain in the next breath 'we don't have enough developers' when you
> refuse to change your own situe.

Hopefully I won't sound like the attitude you describe, but we already changed 
direction; it looks like you haven't read 
http://www.gnucash.org/en/state_of_the_gnucash_project.phtml.

Half of what you state is part of what we agreed on in the link above:

The other half would require us to re-implement from scratch for all practical 
purposes.  Now THAT will indeed not happen.  At least a dozen project were 
started over the years by various groups, but NONE is even close to having 
caught up with gnucash's feature set.  For all it's faults Gnucash works and 
is features-rich now, it's architecture is quite salvageable.  It should be 
incrementally re-engineered, not scrapped.  

> This is no rant, but I'm going to be blunt.  Few people know
> Scheme/Guile and fewer are prepared to learn it.  Pursuing purely
> Scheme/Guile extensions with GnuCash is tying your own hands behind your
> backs.

Yes, de-emphasise Scheme, see the link.
 
> "But we can't rewrite GnuCash or maintain lots of language bindings!"
>
> No, but you can do what some savvy developer already attempted in
> GnuCash, use SWIG.  Forget the pure Scheme/Guile bindings and use pure
> SWIG instead, which supports Scheme/Guile bindings anyway.

Yes, stop discuraging developers who want alternate bindings.  See the link.

Also, to my knowledge, the perl swig bindings predate scheme in gnucash, were 
implemented by (or at least with support form) the core developers and have 
bitroted from non-use.  But we do hope someone will revive them and 
apparently it wouldn't be hard.  They are also mentioned in the link.

> What you, the lead developers, need to do is to put your heads together
> and decide on what is vital for the future of GnuCash.  What do you need
> to do to attract users and developers.
>
> I'll save you some time.
>
> Lowering the barrier to entry should top of your priority list.

See the link.

> Adopting SWIG (which maintains Scheme/Guile whilst allowing
> Python/Perl/Ruby) would help tremendously.

Agreed, but it can't really replace scheme in the short term, as scheme is 
currently used for more than bindings.  It's still integrated a little too 
deep in the GUI (it currently controls the startup sequence), but we are 
working on it.

> Gnome2/Gtk2 support should be next.  The world is a vain place as well
> as a resource begrudging place.

In progress, has been for several months.  It's a huge job but should be ready 
for the beginning of next year.
  
> Reviewing and reorganising the architecture of the GnuCash codebase is
> something you should not delay any longer.  Whilst I have no real
> perception of how well designed or abstracted the various parts of
> GnuCash are, the way even all you developers talk about it is as if it's
> one giant legacy footprint.  What can be it's own library?  What can be
> used by other applications?  What in GnuCash is done better elsewhere
> and how can that be used?

Well, most of the complaints we receive are the exact opposite.  They find 
that we use to many external libraries instead of rolling our own.  We 
consider it bad software engineering to roll our own and have resisted such 
requests in the past.  I take it that you agree with our stance in this 
matter.

As for re-organizing and fixing the GnuCash core and making parts of it 
accessible to other applications, see the link. 

> Another, more controversial, thing to think about is how the GUI is
> written.  Could rapid progress be made with something like PyGtk/Glade?

Glade is already used extensively, and it's usage is increasing.  Still 
perhaps 70% of the codebase is GUI code (custom widgets) or gui related 
logic.  Re-writing it pretty much means starting over, and despite python or 
whatever other language's benefits, I don't think it would be worth it.  We 
do however hope to achieve better code separation that would make it possible 
to have alternate GUIs for GnuCash, as there once were.

> You need to get a decent perspective on things.  The Gnome team looked
> at 1.4, thought, "we can't easily do what we want with this code base."
>   They identified the major changes needed and gutted the original
> codebase, saving only the savable.  People savaged the initial result
> (Gnome 2.0) but it's becoming evident now (Gnome 2.4 beta1) that they
> did what was best for progress and best for the project.

Yes, but they sure as hell didn't start over.

> Sometimes you have to take a step backwards in order to take one
> forwards.  If you embark on a redesign and adopt the simplest, quickest
> route, it's very possible even with a handful of developers to produce
> something amazing.  Look at AbiWord.  AbiWord2 is a complete redesign of
> AbiWord1 and is far better for it, and they only have a handful of
> active developers.

Yes, but this will happen in an incremental way.

> Plus there's nothing like a rewrite to generate a bit of buzz and
> attract a few lurker developers who can't get in on the act with the
> original codebase.

I never heard of any re-write that generated buzz unless is was already 
released or significantly increased the feature set of the project.


-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/