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