Design Decisions

[Charles Goodwin]

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.

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.

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

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. 
Adopting SWIG (which maintains Scheme/Guile whilst allowing 
Python/Perl/Ruby) would help tremendously.

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

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?

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

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.

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.

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.

Nobody will do this for you with a fork of GnuCash because there is not 
a group of dedicated developers disatisfied with the project direction - 
other than the lack of abundant help.  So it's up to you to do it, to 
help yourselves so that others may help you in the future.  The AbiWord 
team took a year out to do their redesign and rewrite.  That's the kind 
of sacrifice you'll have to make.

Of course, you could keep moaning about people not being willing to 
learn Scheme or run a legacy Gtk1 application, but if you do then don't 
expect anybody to feel sorry for you or the fate of GnuCash.

That's the cold, hard truth.

- Charlie