Giving up on Gnucash

[Neil Williams]

On Sunday 24 April 2005 2:08 am, Rod Engelsman wrote:
> Neil Williams wrote:
> > And points that are being addressed in the G2 port.
> >
> > The developers are not unaware of the failings of Gnome1.4.
>
> What exactly does the G2 port accomplish? I'm asking because I honestly
> know absolutely nothing about that and I'm interested in whether this
> addresses primarily appearance, functionality, or some combination.

It replaces an old UI with the code to use the new Gnome interface that you 
find in other Gnome applications. There are a wide range of improvements 
because this is a big step - I'm not a GUI programmer and I'm not aware of 
the details of them all. 

I'll have to let someone else answer the online banking Q, I don't use it, 
don't work on it and haven't looked at the code.

Other parts of G2 are graphs/charts, internal engine stuff that makes import 
and export much simpler from other applications and between GnuCash and other 
programs. 

This could help you directly. I'm working on code that will allow all the 
essential data to be exported in XML (calling it QSF) that is 
program-neutral. It's just the data. Originally designed to allow invoices to 
be created on-the-fly from pilot-link data it will also be usable by all 
manner of XML capable scripts and programs to convert into other forms. 
That's a beginning, it's not a complete solution to your problem, but it 
doesn't exist in the 1.8 tree, it has taken over a year so far to produce and 
it is desperately needed.

> 2. The arrangements of the checks and deposits columns is exactly
> opposite of other programs, as well as the paper checkbook register
> supplied by banks. After thirty years of seeing it one way, why should I
> force myself to see it the other? Small thing? Maybe, but it's caused me
> to make mistakes, particularly when entering split transactions.
>
> Comment: Would you take seriously a suggestion for a View setting that
> would allow those columns to be swapped? GC is billed as a personal
> finance program. I would think users trying to migrate from Quicken or
> Money would appreciate a more familiar interface. I would.

Now we did explore that, in amongst the rest. There appears to be no standard 
way of doing it, some banks do it left right, some (like mine) right left. 
Plus there are the issues of credit card statements that are single column, 
customer statements that can be anything and the perspective issue. The bank 
does it their way because they see a credit to your account as a debit of 
their accounts.

If someone created the option to do that in the register window, I dare say 
that would be accepted. Unfortunately, I don't know if any of the current 
developers have time to put that into the first release of G2.

> I don't mind submitting reports and having to wait; I understand that
> part. I feel much less motivated to do so when they don't seem to be
> taken seriously.

They are taken seriously. However, if problems in something like the loan 
druid are unreproducible, it makes it impossible to fix. Simply moving to G2 
could fix those problems as it may well be related to old code in old 
libraries that will be replaced.

> > It is useful to hear why someone doesn't get on with the current version
> > but it is not generally helpful to be emotive, political or to start
> > ranting. I believe that most of Rod's points HAVE been addressed already
> > in the G2 port but it is understandable that he may not be able to wait
> > for the release.
>
> I would be genuinely interested to know which, if any, of the above will
> be addressed by G2. That would make a really big difference in how I
> proceed. I'm feeling somewhat frustrated because I really *want* to
> stick with the program. But this isn't like a project for something like
> a web browser, for instance, where you can try it out and beta test
> things while you use something else for your "production" environment.
> It's too much of a PITA to keep two sets of books, so there is a real
> threshold of usability that you need to cross first.

As above, G2 will help with that. It won't be so much of a problem to get the 
data out of GnuCash in a usable form. It may still require some work to get 
other programs to read that data but this is because only so much can be done 
as a volunteer effort.

> On the other hand, I've been using it since Mid-January and moving to
> another app will be a significant investment in time and energy. The
> longer I wait the worse that gets. It's not a matter of impatience so
> much as practical reality.

G2 won't be ready in that timeframe. End of the year is planned but it may 
take a little longer for it to permeate out into the distributions.

However, I do hope that my work is going to make it easier for people to 
handle their account data in other applications. Naturally, I would like 
those people to continue using GnuCash but it does have a side-effect that 
moving data out of GnuCash more easily may help in allowing users to move 
away from GnuCash more easily. That's no bad thing - nobody wants lock-in 
within free software - and we all want users to remain with GnuCash for the 
right reasons. If it isn't right for you, why shouldn't GnuCash make it 
easier to change your mind? That's what my code should help achieve and that 
code is G2 only.

> I had the exact *opposite* impression! I see things like Accounts
> Payable, Accounts Receivable, and most of the reports being aimed
> squarely at small business. For a PF app, the account register UI seems
> to me to be "wrong" or at least unfamiliar

Unfamiliarity coming from Quicken is not unexpected but is unavoidable. There 
is no way GnuCash is going to become more like Quicken by dumping 
double-entry or other "dumbing down". I'm afraid you are going to have to get 
used to the accountants way of doing things within GnuCash. Lots of users 
require this functionality, it is good practice, good sense and strongly 
recommended.

Equally, I personally don't see GnuCash becoming more like QuickBooks either. 
More on that below.

> and it lacks a household 
> budgeting tool, which is a fairly standard feature in those kinds of
> programs.

Now, budgeting - OK. Budgets are part of G2. That is a significant lump of 
code that is much appreciated by all concerned. Again, it's a combined budget 
tool, capable of working with any GnuCash accounts, personal or business.

> So maybe what you have is a kind of identity crisis.

Not at all. What we have is an application in the midst of a comprehensive 
overhaul of the user interface and adding large amounts of new code behind 
the UI as well. 

> What is this?

a way to manage your personal or business finances using Free Software

Note that GnuCash has always been both. It has personal features and it has 
business features. Neither are complete or bug-free but both are supported.

> Where  
> is it going?

To Gnome2.4

> What do you envision it being in five years?

(I haven't run all of this passed Derek yet, so here goes!)

Personally? OK, I'm looking to provide code to achieve:
1. Direct interfaces with multiple applications for data exchange via an 
external library (QOF). Pilot-link is the first example.
2. Running GnuCash on notebook and handheld devices to enhance 1.
3. Support for data mining and extrapolation (DWI).
4. One off-shoot of all this - a forecasting tool that will give users a 
calendar of their known and expected expenses and income to estimate future 
balances of relevant accounts.
5. Linking into third-party applications that can handle inventory, maybe 
payroll, even an EPOS system.

(I should be fairly safe with those, 1 to 3 have already been discussed on the 
devel list at one time or another. 4 is a natural follow-on and has been 
requested by users, 5 is new ground - but again, some users have requested 
something of this type.) 

This is where it could become more controversial:

I'd like to see GnuCash being able to interface with an EPOS system - such as 
those that already run on GNU/Linux - doing the business accounts direct from 
data exported from the tills (or more likely from an administrative program 
running behind the tills that does the till balances and aggregates the till 
readings into daily cashing up figures that GnuCash could use). That would be 
a job for the external library - QOF - that would receive data from the admin 
program and provide that data as QSF that GnuCash would simply import and 
merge with existing books.

I'd like to see GnuCash with an inventory capability that is not core to 
GnuCash itself but is linked via simple and robust data exchange protocols - 
again QOF and QSF could be the base of the protocol. Inventory is a 
long-awaited addition to GnuCash but to me at least, GnuCash does not ever 
need to know that you have 6 packs of soap on the shelf at $1.15 each with 
another box of 12 on order. That is best done by a bespoke application but 
there is every reason (at least to me) for GnuCash to be able to handle the 
accounts that pay for that order, handle the payment of the invoices, etc.

(Yes, I know, I should have put that on devel first, but it's only partially 
related to GnuCash, it's mainly to do with QOF.)

Now that's my 5 year plan and I don't think I'm going to be able to get it all 
done. So maybe it's a 10 year plan.
:-(

My influences may appear very business-centric but there's a simple reason:

Businesses understand standards. It's easier to get businesses to export and 
import data in a predictable manner than it is to get users to do the same. 
Put another way, it is easier for a business to *specify* that data is 
exported in a specific manner than it is for a user to *request* such a 
format from another user or a business. This also reflects on online banking 
which is geared towards providing data to users, not other businesses. I can 
hope that banks would consider exporting in a format that can be converted to 
QSF XML - that may well be achievable - but it's more likely that a business 
creating software to run a business is going to be using such an interface 
and the interface itself is subsequently inherited by programs in userspace.

B2B is easier than B2U or U2U. Once that is working, the effects do permeate 
down to B2U and thereby to U2U.

Users are not ignored though - the format is open and simple and inherently 
suitable for scripting. So users with a little experience of XML, Perl, PHP 
or other tools can provide userspace tools that will let the whole thing take 
off.

> Are you aiming  
> to provide a replacement for Quicken et al, or is it Quickbooks,
> Peachtree, and Simply Accounting?

It's not a copy of anything, it is it's own program and has it's own 
direction. 

> It will probably be too much for you 
> to do both, given the resources. Inquiring minds want to know.  :)

and the developers need time, contributions, support, appreciation, 
understanding, motivation, help and more people to become developers!


-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20050424/4db983c5/attachment.bin