Survey comments as well

Alan Orndorff dwarf@solarisresources.com
Thu, 12 Jul 2001 22:59:03 -0700


>> (i.e. print address on check) support. So I'm tempted to conclude that
>> respondants have little/no actual experience in using a small-business
>> accounting package. Indeed, we should filter results for those who have
>> actually used peachtree/quickbooks or other business pacakge. 

>I am one of the people mentioned above, I have and use PeachTree
>to run my computer & network consultancy.  I use PeachTree 
>primarily for Address/Contact info and bookkeeping purposes 
>to primarily print pretty invoices and keep track of what 
>people owe me and what I have paid to people.  You are absolutely 
>right about invoicing being useless without addresses and phone 
>numbers and stuff, but I read "Integrated address-book/contact 
>manager/to-do list" as GNUCash has yet another address-book/contact 
>manager/to-do list that is specialized to it and would not be able 
>to easily share data with my email program, my palm pilot, backend 
>web based end user reporting/authentication system, and eventually
>even my phone system (through GNU Bayonne).

>The reason I don't care about the contact manager in GNUCash is 
>I am looking to Evolution (or some other more generic database)
>to keep track of that information and I want to tie several
>different applications into that backend.  There are many places 
>in business where you would like to create automated scripts/programs 
>to pull information from one central contact/informational 
>database but can't because every application implements its own
>contact database and doesn't make it easy to extend and play 
>nicely with other applications that you want to interoperate
>with (I have this problem with PeachTree and QuickBooks).  

I'm not one of the users listed above, but one of those that compiles
this thing on another platform, until recently.  While I agree with the
above comments my mind keeps going back to those that are already
crying about the dependency list, and adding Evolution to it, although
I've heard great things about it, would just add to the stack.  Which
brings up a question I've had in the back of my mind for a while now:
IF, IF it were possible to replace all the dependencies with nothing
but GNUcash code, how much of a set back would that be?  My guess, 
a long time before anything new gets added to the program.  Dependencies
to some might be a pain, but think about how much time it probably saves 
the developers from having to reinvent the wheel.  Besides, isn't code
reuse something your supposed to shoot for?  Is this the type of thing
that the new plugin approach is going to take into account?

>(like an LDAP backend for instance).  I want all my 
>applications to have fields associated to customers so that 
>I can reduce the amount of duplication of effort I have
>to do to keep all the contact information in sync.  Ideally,
>I want to change the contact information in any program and
>then have all other programs be able to reflect that change.

Great approach.  I've done this as well using .dbf files on
some other OS, a long time ago :-)

Anything that can reduce the dependencies I think most of us
would agree is highly desireable.  However, in the overall 
scheme of things it might be more desireable to have a lot
of dependencies, that add a lot of bells and whistles to the
program and gives people the features that they're looking for
without having the Gnucash coders write all the code.  It's
also been stated in the past that the best way to handle this is
to <insert your distro here> include the binaries and developers
packages that Gnucash needs as part of the base system.  At least
on Linux systems that doesn't sound like to far fetched a goal.

Sun will get there soon enough and then things should get real
interesting.  I still can't figure out why you guys have -devel
packages, to me everything should just be in one big .rpm file, but
oh well, guess I don't understand the philosophy of that approach
well enough.

Of course as Dennis Miller would say, those are just my opinions,
I could be wrong :-)

alan


-- 
Solaris Ultra/Intel Resources - http://www.solarisresources.com