Is there anything *enjoyable* about our development process?

[P. Christeas]

> On Fri, Oct 14, 2005 at 08:51:12PM -0400, Josh Sled wrote:
> Yes, I'm saying we would fail, because "simplicity" is not a
> sufficiently motivating goal.
>
> ...
> One way or another, if we don't get more developers, in about 200
> *weeks* we're not even going to have 200 users.  There is *no way* GC
> is even close to mature enough to be thinking in these timeframes.
>
> A year ago I would have said that the key to getting more developers
> was codebase simplification.  Today, I think that codebase
> simplification is one part of a goal that we can only achieve
> indirectly through the goal of development process improvement.
>
> -chris
>

May I summarize (IMHO):
GC has pros and cons

Pros:
p1. Full functionality
p2. Interface is usable, fast
p3. Extension language
p4. Database as storage option

Cons:
c1. Dependencies
c2. Hard to compile
c3. Ext. language is non-common
c4. Code complexity

p1. GnuCash is the best at its kind, it has mature code in the sense that it 
can do all complex transactions etc. It's feature rich.
p2. Data entry is what I love in this program, as a user. This kind of 
software is traditionally based on fast interfaces.
p3. We *need* to have an extension language, if not base most of the 
components on it. Reason is that each user may need to adapt the behaviour of 
the program. That will happen after the application has left the build stage. 
We cannot afford to have layout etc. hard-coded, or even to require the user 
to have a C compiler.
p4. That is a huge potential. Consider using third-party tools for some 
operations.

c1. Even the user will have to fine-tune a set of dependencies to get GnuCash 
running.
c2. The new programmer will have a hard time setting the environment and 
dependencies right, before having a first compile. That is putting me, 
personally, off.
c3. I agree that Scheme is not the best choice. It may fit the functionality 
best (I cannot judge that at the moment), but potential programmers will not 
know it. You have to use what programmers know; it's a matter of making the 
development process attractive.
c4. (You mentioned it. I haven't programmed anything yet, so I assume the 
situation.) When a project gets large, it is important that the code is clear 
and focused to the core functionality (instead of having many interface 
tricks, memory managment etc.). No matter how fast it is, C IMHO cannot end 
up in easy-readable code. Consider that programmers will come and go; they 
need to catch up with the meaning of the code fast.

I'm not suggesting anything particular up to now. I assume that we can have a 
long and fruitful discussion on a course to GnuCash 3. Surely, making the 
development 'fun' will attract more developer manpower to the project.