On Gnucash, G2, and Architecture

[Chris Shoemaker]

It sounds like we agree there's a problem.  But we disagree somewhat
on the analysis of the problem, and therefore the solution.

On Tue, Jun 07, 2005 at 09:54:48AM -0400, Derek Atkins wrote:
> Chris,
> 
> Chris Shoemaker <c.shoemaker at cox.net> writes:
> 
> >> Which do you think is more beneficial to the project in the next six
> >> months:
> >> 
> >> a) Taking a piece of code that might be architecturally questionable
> >>    but doesn't crash, doesn't corrupt data, and doesn't cause any
> >>    visual problems and spend time to fix the architecture and rototill
> >>    the code to change how it works?
> >> 
> >>  or
> >> 
> >> b) Take some code that causes the program to crash, corrupts data, or
> >>    visually misbehaves and spend the time to fix those issues?
> >
> >         I honestly don't know.  I know the question was rhetorical,
> > but I think the answer really depends on many factors.  IMO, having a
> > g2 port that works as well and 1.x, but is equally (un)maintainable is
> > only of _marginal_ benefit.  (And I'm not sure even 6 months will find
> > us there.)  IMO, 95% of the benefit of the g2 port is the potential
> > for improving maintainability.  ** That benefit is not realized by the
> > quickest fixes, but by the design fixes. **
> 
> See, I don't think it's of marginal benefit to get g2 into the hands
> of the users even if it only works as well as 1.8.  Indeed, currently
> the g2 port does NOT work as well as 1.8!  I think just getting it up
> to 1.8's level is sufficient to make users happy and extend the life
> of the project.

If it only works as well as 1.x, why are users going to be any more
pleased with g2 than 1.x?  Do you think the average user knows and
cares what libraries their acct package uses?

> 
> I don't know if 6 months will find us there.  If we keep rewriting
> working code then it certainly wont.  But if we focus on actual bugs,
> so we CAN bring g2 up to the 1.8 working level, then I think it's
> possible to complete in 6 months.
> 
> We've got GoG working, that was a major issue.  Now we just need to
> make sure all the dialogs work, all the signals are attached, etc.
> Sure, it sounds like busywork, but we're at the _end_ of the dev cycle
> here and that's always busywork.  Once we release we can open up to
> major restructuring.  But now is not the time to do it.
> 
> >         You and I really do have very different interests regarding
> > GC.  I realize that the next 6 months are very important to you.  I'm
> > much more concerned about where GC will be in 36 months than 6.  I
> > figure, in 6 months, 1.x will still be an option.  In 36 months, it
> > won't be, and neither will g2 if it develops at anywhere near the rate
> > it has in the past 24 months.  Call me alarmist if you want, but I
> > think GC is "on the brink."  Its survival is no gaurantee.  IMO, its
> > survival depends on architectural improvements far more than fixing
> > visual misbehavior or program crashes.  Why?  
> 
> Actually, I don't think you're behind alarmist enough!  I'm also
> concerned about where gnucash will be in 36 months, but if we don't
> get the g2 release out SOON I don't think there will even BE a gnucash
> in 36 months.  Gnucash has already started dropping out of distros.
> We've been out of slackware for years (I think 1.6 was packaged, but
> I'm fairly sure 1.8 never was).  We got dropped from RHEL 3.  I think
> we're in FC4 but I suspect we'll get dropped from FC5.  Debian has
> considered dropping it.  Fink has considered dropping it...
> 
> Seriously, if we don't get g2 out the door _THIS YEAR_ I don't think
> there will be a gnucash in 36 months for you to primp and preen.

Ok, I think I'm starting to see where we disagree.  You think that the
survival of GC depends on maintaining *users*.  Therefore, dropping
out of distros is death because it leads to fewer users.  Therefore, a
quick g2 turn-around is #1 priority since it will keep users.  I guess
you'd say that popularity (more users) will lead to higher quality.  I
can see the reasoning, but I disagree with the premise.

I think that the survival of GC depends on maintaining (nay,
*gaining*) *developers*.  A growing user-base is an incidental
consequence of a high-quality program, which is determined by
developer labor quantity and quality, which is a function of the
condition of the code-base.

IMO, dropping out of distros is NoBigDeal.  Packages drop in and out
of distros all the time.  Being in distros is no end in itself; it's
merely an *indicator* of the real problem (which is a BigDeal) -
poorly maintained code.  I'm not so concerned about popularity
(user-base) or which distros we're in.  I think *quality* has to come
first, and if it does, users will come.

> 
> Keep in mind that we also need a good 3 months after "feature freeze"
> in order to stabilize the release.  At least that's how long it took
> to get 1.8 out the door.  There was a good 3 months of bi-weekly
> releases to get alpha tested, build tested, and into user's hands.  So
> even if we think it'll be another 6 months of developer work to
> "finish" g2, that means 9 months until 1.10 actually hits the streets.
> We're already late; that puts us into March 2006!

Which is after FC5, isn't it?

> 
> > ** Because the universe of developers willing and able to fix program
> > crashes is determined by the architecture, but the (very small) universe
> > of developers willing and able to fix the architecture has almost
> > *nothing* to do with the program's usability. **

Did you have any thoughts about this?  This is kind of central to my thesis.

> >
> > <snip>
> >> In the grand scheme of things (or at least the grand scheme of gnucash
> >> [no pun intended]) I don't think this is a heinous architectural flaw.
> >> I can certainly point out a half dozen or more significantly more
> >> heinous archictectural flaws in gnucash.
> >
> > I would agree.
> 
> Then why spend time on it _now_?  I'm not saying not to spend time on
> it.  I'm just saying that it shouldn't be a priority _now_.  Help us
> get g2 out the door so we can ensure gnucash's survival.  _THEN_ feel
> free to really start ripping away.
> 
> Have you ever worked in a ground-up startup?  I mean REALLY ground up?
> Where it was you and one or two other guys trying to make the business
> happen?  Where you've got $100,000 and you need to make that last
> until you've got a product?  In that environment you can't waste time
> rewriting working code to build something you don't need until
> two-years down the road; you need to work on getting the product
> shipped, which means hacking on the non-working code.  Rewrites can
> wait until you get the product shipped and you get the next round of
> funding.


I think your analogy breaks down at one crucial point.  In that
environment, time-to-market is more important because of its influence
on market-share via mind-share.

The *linux* app. market is not so much like that.  Market-share
follows quality much more closely than time-to-market.  Look at how
quick we are to abandon the tried-and-true when the new program is a
little nicer.

> 
> This is where I feel gnucash is _right now_.  Sure, I am _thinking_
> about where I want gnucash to be in 36 months..  But I'm worrying
> about where gnucash will be in 6-12, because no g2 release in that
> timeframe means no gnucash.

I'm not sure about that last sentence.  Say 1.x was EOL'ed, and g2
wasn't ready yet.  Does that mean no gnucash?  Not necessarily in an
ultimate sense.  You could consider g2 as a "new release" of a new
program.  The fact that there wouldn't be any maintained,
production-ready gnucash in the interim would be regrettable, but I
don't think it would necessarily mean the end for the code-base.

> 
> > I think that should be *somebody's* #1 concern.  But I also think, for
> > the reasons above, that if that's *everybody's* #1 concern, then in 12
> > months, GC will still have the equivalent of < 1 full-time developer,
> > and it will be obsoleted within another 18-24 months.
> 
> Gnucash is a team effort, even if it's only loosely associated.  We
> have to work together to get gnucash out the door.  We have to make
> forward progress, not continually re-working everyone's steps.
> 
> > I think *somebody's* #1 concern should be making the architectural
> > changes that will attract more developers.  I know you're said that
> > you don't really care about attracting new developers, and that we
> > have a few really good devs now.  Nevertheless, IMO, attracting more
> > devs is essential to GC's survival.
> 
> I care about attracting developers who can work within the gnucash
> framework.  I don't care about major gnucash restructuring just to
> attract new developers.  Restructuring and rearchitecting because it's
> the right thing to do is certainly warranted... When the time is
> right.

Hypothetically, if in 3 months, g2 was stable, feature equal to 1.x,
but had no major code-restructure, do you think that new developers
would suddenly be attracted to GC?  I don't think so.  

> 
> Right now is not that time.  I've even given up on my qif-importer
> re-write because I think it's more important to finish the g2 port
> than the finish the re-write.  Why?  What's there _works_.  Yes, there
> are some bugs.  Yes, it's hard to maintain.  Yes, it NEEDS to be
> re-written...  But it's more important to COMPLETE THE TASK and get g2
> out the door.
> 
> Gnucash's survival is not hinged on whether the qif importer is
> re-written, or if the gtk/cm interaction is architecturally "pure".
> It's purely hinged on getting g2 released.

Ok, yes, you clearly believe that GC's survival depends on releasing
g2.  But why?  It gets more users?

> 
> We _ARE_ that small startup, trying to get that product out the door
> in order to get more funding.  (Well, there's no funding here, but the
> analogy still holds if you equate time with money ;)

Releasing g2 gets us more time?  We don't need time -- we need
developers.

> 
> After 1.8 was released we had a lot of time on our hands to ponder
> major changes.  QOF, for example, was a major rearchitecting of the
> engine, and IMHO a fairly decent step forward.  But _now_ is not the
> time to create a new QOF.  Now is the time to get g2 out the door.
> Once g2 is released, once we have 1.10.0 in the hands of the people...
> THEN will it be time for you to go off and create your masterpiece,
> create the next QOF.
> 
> I applaud your effort to fix that.  I even encourage it, but not right
> now.  I ask that you hold that energy until we get g2 out the door.  I
> implore upon you to help us get g2 out the door; after g2 is released
> I encourage you to run free and wild rebuilding whatever floats your
> boat!
> 
> > I also recognize that my prioritization is a minority view, but I
> > don't think it's necessarily bad that different devs have different
> > priorities.
> 
> 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.

> 
> >> Assuming you answer "yes" to my final question (and I really hope you
> >> DO answer "yes")...  
> >
> > Was that a qualified "yes"?  :)
> >
> >> what do you feel are the steps necessary to get
> >> the g2 port "finished" and out the door?  What do YOU think is missing
> >> or still needs to be done before it's ready to package up and pass on
> >> to users?
> >
> > I don't know.  As a user, the register misbehavior really bothers me.
> > As a dev, the register code insanity bothers me even more.  :)

Just a clarification about *why* the code bothers me more than the
GUI: When I see the register misbehave, I think "Well, I guess I can't
use this for data-entry *right*now*."  When I see the code, I think
"Yikes!  There's a very real possibility this code will *never* be
fixed.  Its complexity may already exceed its value."

> 
> Oh, I agree..  I'd LOVE to see the register re-written, and lots of
> other code fixed, cleaned up, or rearchitected.  But again, I think
> that's an "after the first g2 release" task.  It's better to spend a
> couple days to get what's there now working and get g2 out sooner,
> than spend a month rewriting and push out the release.  If we do that
> for every bug in the database we'll never finish.
> 
> The more we push out the release, the closer we are to being
> irrelevant.
> 
> > -chris
> 
> -derek
> 
-chris