Where to discuss the development of gnucash (Re: KMyMoney vs Gnucash)

[Michael Hendry]

On 22 Aug 2014, at 17:06, Geert Janssens <janssens-geert at telenet.be> wrote:

> Michael,
> 
> You're still hijacking the thread. A good hint for that should be the 
> title: it's called "KMyMoney vs GnuCash", not "how should an accounting 
> program be developed".
> 
> But since the original thread is now dead anyway, I will continue on 
> this one but change the subject so people can more easily decide if they 
> want to follow this twist in the subject or not. I didn't do so before 
> because I presumed the discussion would end. I was wrong.
> 
> And I'll repeat my original stance: the *user* mailing list is *not* the 
> place to discuss *how* gnucash should be designed. Here's the 
> description of the mailing list [1]:

<Big Snip>

Phew! It’s getting a bit hot around here!

As a user of GnuCash since 2010, using it for my own personal finances - no invoicing, no inventory, no uploading of bank statements or stock prices - I get all I need from the program itself, and have had a lot of help from the users list over the years.

I think there _is_ a place for discussing the overall direction of development in the users list, so that users like me can understand why development hasn’t taken place in a given direction - most of us would be completely lost in the development list.

Granted, the user list is not the place for discussing the nitty-gritty details, but it’s helpful to know the constraints that govern what can reasonably be included in a volunteer-developed program, in general terms.

I’m very much a fan of the Unix-etc idea of having simple tools which once developed do the same job consistently over the years, and can be chained together with others to do more sophisticated work. I’m getting out of my depth here, but I believe that the “plugins” which are used as add-ins to a lot of software provide a model for extras that might be added to GnuCash to deal with inventory, quotations and bizarre tax regimes. The feasibility and desirability of this would properly be discussed on the devel list.

Michael