KMyMoney vs Gnucash

[John Morris]

Thank you, Michael, for such a good example of a specious argument.

  Given that the set of all possible features is a multidimensional continuum, with no natural dividing lines grouping the "individual" features into sets, no application of any "type" SHOULD have or not have any particular feature. We each as users and developers decide what we want and think we need. When many people agree on a particular set of features, we as a society, or some subgroup of the society, give that set of features a name and people start thinking they "belong" together. That does not change the fact that other people in other situations might group the features differently.

  The fact that the GnuCash developers have not chosen to add quoting or billable hours or some other feature has more to do with tradition and any natural order of the universe. Both of those features fit perfectly well in an ACCOUNTING system (or business or graphic design, for that matter). Another person could equally well claim that invoicing and customer tracking should be in a business system rather than an accounting system, but those components have apparently passed muster.

  More to the point is the clear fact, based on GnuCash's history, that no one has had the time and desire to do the work necessary to include those features (quoting and billable hours) in GnuCash. Given what I have seen so far about the culture of the GnuCash development community, I suspect that the social work of such a project would be as difficult as the programming work.

Best,
John

On Aug 15, 2014, at 9:46 AM, Mike or Penny Novack wrote:

>> Finally, afaict, KMyMoney is not suitable for (smaller) businesses and if GC
>> could, somehow, provide feature to have quotes (besides invoices), it would
>> extend its usage quite far.
>> 
>> 
> But this is precisely the sort of request that indicates confusion (about what an ACCOUNTING application is).
> 
> Please, I am NOT meaning to imply that being to produce quotes wouldn't be a very desirable component of say a "business system for the contractor", a more complete system that might USE gnucash for its accounting component. Just like a "business system for the small retail business" should include a "pint of sales" system feeding an inventory system application and feeding say gnucash handing the accounting. ETC.
> 
> But none of these things SHOULD be part of the accounting package itself (gnucash). The reason all of these things should be separate parts is that which parts needed/useful for the business depends upon what sort of business. Some other examples of pieces would be "billable hours" accounting for professional businesses that do that or "commissions systems" for businesses paying sales persons that way, etc.
> 
> Understand? Coordinating all these parts (and recruiting teams to produce parts) would be the proper task of a "business systems" open source project. Might start out able to support only some sorts of businesses and would be the place to submit requests "add the bit I need for my sort of business) and this project might well USE gnucash for its accounting piece. Business systems involve far more than accounting and backwards to think of them as belonging INSIDE the accounting part.
> 
> Michael D Novack