Wow! That become contentious quick!!!

The primary issue I’m seeing here is one of philosophy. What is GNUCash for? 
What is the purpose? What “should” be included and what “shouldn’t” be?
As has been highlighted, when someone loads up software they have a preset 
notion in their own mind of how it “should” work, and that is usually their own 
very narrow context (e.g. “That’s not how budgets work!”).

My assumption on purpose: Open source software is created out of need and 
altruism. People who know how and want help create and maintain the project 
both because they are interested in software and enjoy the process, but also 
because they like being altruistic and providing something that others find 

Based on that assumption, I have had the attitude “All requests should be 
considered and prioritised by the devs, but of course they will mainly 
implement what they find useful and of course they will only give how much time 
they can afford to”.

The natural flow on from my attitude is that I should indeed throw in what I 
want/need from my financial tools, but not expect anyone to act on it. If I 
want it done, I need to donate my time and implement it because it is 
definitely unreasonable to demand others to do it when it isn’t useful for 
them. (On that note, I’m keen to help out, but don’t yet have knowledge (and 
also struggle for time) in all this).

I have lots of specific comments against what people are saying, but all would 
be unhelpful if my fundamental attitude to the project is wrong.

Thanks and regards,


From: John Ralls<>
Sent: Saturday, 3 February 2018 3:51 AM
Cc: gnucash-devel<>
Subject: Re: Future allocated money, aka Envelope Budgeting

> On Feb 2, 2018, at 7:25 AM, Wm via gnucash-devel < 
> <>> wrote:
> There is, IMO, work to be done on on the underlying db structure, have you 
> seen this monster ?
> ===
> <>
> ===
> It is as ugly as an ugly thing (I'd say what I thought but I'd like more than 
> a  mod to get to read this).

Sure is.

Step 1 in getting to being able to clean it up was converting the backend that 
implements it to C++ with clearly defined objects instead of a rather quirky 
collection of macros. That’s in the current “unstable” and will be released in 

Step 2 is to convert the corresponding objects in libgnucash/engine to C++ 
objects with proper constructors so that creating an object doesn’t involve 
calling a bunch of property setters (one at a time!) that want to commit the 
object and write it back to the database. That will be my focus for the next 
development cycle.

Once that’s in hand we can consider refactoring the schema into something a bit 
more reasonable and get away from sucking the whole DB into memory at load time.

John Ralls

gnucash-devel mailing list

gnucash-devel mailing list

Reply via email to