KMyMoney vs Gnucash

[Mike or Penny Novack]

> Actually no you didn't need to be clearer. Technically you are very 
> much hijacking a list thread which is considered bad mailing list 
> practice.
>
> In addition you are trying to evangelize the wrong crowd. This is the 
> *user* mailing list. When I'm engaged as a *user* in a community I 
> couldn't care less how exactly the internals of the program work. How 
> the program *should* work is even further away. At best I'd ignore 
> such a reply, at worst I would be so annoyed as to leave the list. 
>
> If you want to share your systems analyst's experience you're most 
> welcome. However I invite you to do so on the gnucash-devel mailing list.
>
Sorry if you don't agree that THIS is the place (the user level) to be 
discussing what a system SHOULD do as opposed to the development list 
where the discussion should be about HOW to make the system do that. I 
was not talking about "internals" but "externals".

Look, when I was doing this in the "real world" (large financial 
systems) at least 20%, sometimes more of the project time was spent with 
users, with the help of analysts, deciding on the formal system 
requirements (what the system must DO, from the point of view of the 
user) and only after that was defined going to the more technical types 
plus analysts to decide how that was to be implemented. When  you say 
this (level) is for the developers to decide you guarantee dissatisfied 
users. If there is no formal set of requirements for what a system is 
supposed to do then whatever it does is correct (as long as it doesn't 
loop or hang).

It is here (at this level) we need to decide whether the accounting 
system gnucash should expand to a monolithic all encompassing system for 
the needs of businesses (inventory, point of sales, commissions, 
approvals, billable hours, etc, etc.) or whether those (including the 
accounting package) should be separate components of an overall 
"business system" in which case need only the parts your type of 
business needs and add then as become available.

It isn't with the developers that my analyst experience would be most 
needed though I often/usually wore that hat too. Our greatest weakness 
with many of these free source projects is inadequate USER commitment to 
the development process, the "system requirements" phase (and later 
commitment to the "testing" phase). Developers know the programming but 
it users that know the needs of the business.

Michael D Novack, FLMI

PS: Feel free to add to that "needs of business list. I intentionally 
included things like "commissions" and "approvals" because I hadn't so 
far seen any requests for the things needed to support those but that 
reflects the types of businesses users on this list represent. For 
example, there aren't many businesses that normally sell "on approval" 
(and so need to be able to account for goods in the possession of 
potential buyers but not yet sold to them). It would be a USER decision 
whether an "inventory system" (assuming one already existed) could be 
stretched to handle "approvals" or not.