Have any Online Accounting Software companies closed?

Mike or Penny Novack mpnovack at mtdata.com
Mon Jan 16 11:07:23 EST 2017


On 1/16/2017 4:18 AM, Fred Bone wrote:

> Perhaps you could ask your acountant for a written guarantee that
> KashFlow will not fold ...
>
  Yes, that is a problem. But that recommendation by the accountant 
shows that he or she is not naive about the "safe" issues.

Look, this "argument" over making gnucash "safe" is really a 
misunderstanding based on people using two very different meanings for 
the word "safe" and the reasons why some of us are using one meaning and 
others of us another. Let me describe two different meanings, and for 
that purpose will change the word "safe" into two words, "safe1" and 
"safe2".

"Safe1" means safe in the environment where users of the software cannot 
run arbitrary software on their system. And when I say "cannot" I don't 
mean just in terms of their own ability to create but to enable somebody 
else to do this on their behalf.

"Safe2" means safe even in the environment where the user of the 
software does have full rights and powers over the computer, and if 
their own abilities did not suffice, they could allow somebody else to 
do the hard stuff for them.

Those of you who want something put into gnucash to make it "safe" (from 
alteration) are using the "safe1" meaning for "safe". Those of us who 
are saying "it can't be done" are choosing the "safe2" meaning.

Consider back in they days when I was working (for one of the world's 
largest "financials"). The USERS, the people whose job it was to utilize 
these applications in the course of their responsibilities did NOT have 
access to the programs. They could NOT get a new program installed let 
alone cause it to run if they had. So the system was safe from their 
fiddling. But I was a person who could create software, cause it to be 
installed (I am being cagey here -- not directly, and though I had "sign 
off" rights for use in an emergency, would never have signed off on any 
change I was making myself) and cause a production job to run (that is, 
a job with "production rights") but again I must be cagey about how. So 
while I was not a user, I COULD have changed data << and in fact, make 
it look as if one of the regular users had done it through the system* 
 >> In other words, the data "safe1" from them but not "safe2" from me.

OK, now why would the developers of gnucash understand "safe" by its 
"safe2" definition. Because this is the environment of "open software" 
where it us assumed that the users of the software control what runs on 
their computers. For example, I assume that at least some of the gnucash 
developers are also users of gnucash. What would it mean, what would 
gnucash need, to make it "safe" from a user like that? That's why the 
situation is no different when version control utilities like git are 
proposed. Do you imagine that git came from the gods? That people didn't 
write it, and if a person with the necessary skills had full access to a 
computer where git is maintaining an audit trail of changes could not 
substitute their own git2 which behaved the way they wanted << BTW, 
version control systems like git are intended to prevent accidental 
screw ups over versions; not trying to prevent mischief by those running 
the system >>

The point I am stressing is the world of "open source" assumes that the 
environment is one where the users of the software might be in full 
control of their machines. The developers COULD put in any of a number 
of things that have been asked for (password protection, prevention of 
changes, etc.) but their statement that this made things "safe" would 
need to be qualified by a statement "by which we mean "safe1" and NOT 
"safe2" because it ISN'T SAFE in that sense. Sorry, but I can't see that 
would make any accountant happy, pricking their bubble about software in 
general.

Back to where this started, discussing "KashFlow" --- do you not see 
that whatever other problems with KashFlow, it brings into play the 
"safe1`" definition of "safe". And with the asked for features added, 
gnucash itself would be safe WHEN USED THIS WAY (in an environment out 
of the control of the user). So these asked for features would not be 
useless BUT whether they made things "safe" would depend on OTHER 
factors. To give you an example, imagine a smallish (but not really 
small) business that employs a bookkeeper. The bookkeeper  could have 
"permissions" to log into the computer system as an ordinary user with 
no "permissions" to install or even to run software unless authorized to 
his or her log in << even Windows users; remember the question you had 
to answer when installing new software "can any user on the system run 
this?" >>  But see, it wasn't the software feature itself that made 
things "safe"but the features in the context of the ENVIRONMENT. However 
I am skeptical of users being able to understand "this feature makes 
things "safe" but ONLY in the context of specific environments".

Michael D Novack


* That is one of the things I did on a rather frequent basis, part of my 
job. Let's say that because of a bug, some 20,000 records on the 
database needed to  be corrected. The bug has been fixed, but 20,000 
insurance policies need somebody to fix them. That could be done with 
user X sitting at their terminal and using the system enter one 
correction transaction at time. Let's see, supposing they could manage 
500 per working day, that would take this poor person 40 working days or 
two months. Instead I could be asked to write a "sproj" that would 
create a transaction looking just as if it had come out of the on-line 
system with user X's ID in the "by whom" slot and we could bring all 
20,000 of them in a single night. Perfectly proper audit trail. Of 
course my time got charged at a much higher rate per hour than this 
user's time. But I could do this, write that "special program" in less 
than a day. That's because I had done it before, had a skeleton around 
from the last time this particular "fix" transaction had to be used this 
way, so all that would be changing is what fields are being fixed, the 
data going into them, and whose user ID to use. I had skeleton programs 
in my private library for all of the various fix transactions << getting 
my private library ordered and everything given descriptions of what 
good for in an index is how I spent the last few weeks of my official 
career >>



More information about the gnucash-user mailing list