On Gnucash, G2, and Architecture

Christian Stimming stimming at tuhh.de
Tue Jun 7 11:49:19 EDT 2005

Chris Shoemaker schrieb:
>>I agree, but I think it's bad right now that devs aren't concerned
>>about getting g2 out the door.  At least it feels to me that you don't
>>care about getting g2 released.  Please tell me I'm wrong!  But it
>>sounds like you'd rather rebuild working code now than wait until
>>after g2 to re-work it.
> I'm sorry I can't tell you what you want to hear.  IMO, attracting
> devs is more important than releasing g2.  As for cause and effect,
> the former can cause the latter, but the latter will not help the
> former.

We've really seen many different seasons of developers that get 
attracted and leave again. IMHO it really doesn't depend much on the 
internal code quality. Instead, the question should be whether a 
developer can *quickly* start with "scratching his itch" (instead of 
cleaning up other bit-rotted code), and that depends much more on 
up-to-date GUI library dependencies as it does on internal design 
patterns that aren't touched by 90% of the new developers anyway.

Now I can surely understand your priorities here, if scratching _your_ 
personal itch unfortunately means you have to deal with some of the 
worse portions of the gnucash code. However, in the overall project we 
have to remember the respect for each other's working areas, namely not 
to break the other's areas only because you're right into your own 
project. There would need to be a large consensus that these fundamental 
changes would help for the overall project *right now*. It seems this 
consensus is not there for some of your proposed changes -- which, as I 
fully understand, doesn't make you happy.

However, I fully support the priority of getting G2 up and running, 
because that's really becoming more and more vital -- any of those 
hypothetical "more developers" really expect an (almost) up-to-date GUI 
library or they won't come here in the first place. Our competitor 
KMyMoney is catching up quite quickly, and they fully benefit from their 
choice of GUI toolkit. In other words, quite soon a developer with some 
"personal itch" will have the free choice in terms of existing features 
between gnucash and kmymoney, and if gnucash at that time will still be 
stuck in five-year-old GUI dependencies, then most probably a developer 
will just pick the other project and happily use their qt3/kde 
dependencies. It's really not all the internal code, but it's the whole 
context of the internal code *plus* the necessary dependencies.

Go G2 go!

(I'll probably join again on the coding side after my LinuxTag talk end 
of June... or maybe some "more developers" get attracted to the project 
because of the talk... :-)


More information about the gnucash-devel mailing list