Strategy

[Jeff Warnica]

As with Donald, I haven't contributed any code, but I would tend to agree
that there is a problem.

A rewrite from scratch is a drastic solution to that not quite as drastic
problem.

The roadmap on the Wiki is more like a wishlist, and the schedule is, well,
non existent. Sorry, I see that there is a documented and very wide
guideline, but the history doesn't show that being hit. And maybe bug fix
releases should be an as-needed basis; regardless, its indication of a
problem.

There is a big difference between a collection of (mostly/largely... trying
to be apolitical) people working on a shared chunk of code, and a project
producing a specific product. That is a bit of a false dichotomy, but on
that spectrum, where as something like Gnome seems to have a project wide
vision, schedule, plans; something like the Linux kernel has at least a
pretty regular cycle of integrating random factions.

Questions about the use of library versions (and major versions Gnome/GTK 3
being the obvious white elephant here) seem to flair up and die out, but no
real resolution I can see. Carrying on as normal, not targeting new base
libraries, isn't an answer, it is just not doing anything.

I don't see a project goal/vision saying that it (we) target long-term
platforms (which, while I would disagree with, at least is
something tangible to measure against). Of course, compounding
this unsolvable question is that there is no release schedule for 2.6 (or
3.0).

Maybe all the devs implicitly agree on most everything. I think that that
is great. The open source mantra of devs scratching an itch is a bit
simplistic... Sure, fixing bug #whatever might be doable; others want, for
lack of a better word, belonging, as much as any technical problem solved.
I doubt that many potential developers are aware of this; but getting
contributions more then just bug #x being squashed... getting new project
contributions... really requires a solid project to latch on to.

To that end, before  you (we?) move to GTK 3, or port Guile to Python, or
whatever:

Capture and document high level technical and feature goals; prioritize
them; mapped to versions, and dates. Time box that (features will slip),
but try to get out major feature versions (or versions with major technical
changes), say, every 6 months.



On Sun, Dec 4, 2011 at 12:35 PM, Graham Leggett <minfrin at sharp.fm> wrote:

> On 03 Dec 2011, at 11:40 PM, Donald Allen wrote:
>
> > Gnucash has been around
> > for a long time, and its life-span covers the development of a lot of
> > tools. If you were going to start with a blank sheet of paper today, I
> > doubt very much whether you would do a lot of the system as it is
> > today. The big question is, when is it worth it to cut your losses and
> > start over?
>
> I use gnucash because a) it's been around a long time, and b) because
> gnucash is likely to be around a long time still.
>
> Anyone can start over at any time - that's called a new product - but when
> people decide to abandon what they have and start over, that's when you
> lose faith in the project and start to look somewhere else.
>
> Sure, new fandangled languages are shiny, but will they still be popular
> in 5 years? No idea. I am happy to bet that C will be around in 5 years, so
> investing in the language as unsexy as it might be for me is a good
> investment.
>
> I think gnucash needs a heavy set of refactoring. I'd like to see a proper
> libgnucash split out as a separate library that I can depend on in other
> software. I'd like to use a libgnucash library as a basis for a restful
> service that will allow me to share gnucash with others, like my
> accountant. But I don't think gnucash needs to be started over.
>
> Regards,
> Graham
> --
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>