Non-POM and Open-Source

The people who write the programs that maintain accounting systems are just ordinary people. They have the same temptations and moral weaknesses as the rest of us. From time to time in the past, the huge amounts of money that their accounting systems keep track of have lured some programmers into putting in various program tricks or hacks that have allowed those who knew about them to divert some of the money for their own uses. In other words, some of the accounting software not only has the accidental bugs which all software suffers, it also has some "features" which should not be there and which allow some people to steal money. This is an inevitable feature of any POM (physical object money) accounting system because very intelligent and driven people will use their ingenuity to find ways to steal that money.

Wouldn't the same thing be true of a non-POM accounting system? In fact, wouldn't it be even more likely given that money comes into existence in the accounts and ceases to exist when spent? If there are no transactions as money is shifted from one account to another, who's to know whether someone has received more money than they should have or has changed the numbers in their accounts?

These are exactly the questions one should ask about a non-POM system of accounts. So let's see if we can give a good answer to them.

To begin, let's assume that the computer system can uniquely identify those persons that interact with it. Today we use passwords, a most imperfect system, to identify ourselves to the computers. Some of us have more advanced computers that can recognize fingerprints. This is only the beginning. The technology currently exists to provide any number of ways of identifying who is communicating with the computer. Therefore, one can be confident that for the computers of any non-POM accounting system, the persons who provide code to execute will be known.

Next, let's assume that those who establish the computer system during the POM economy for use right after the transition have attempted to build into the programs ways to cheat in their own favor. To me this seems almost inevitable. The habits of mind and the temptations of the present would guarantee such attempts and it is only reasonable to assume that some will succeed at hiding bad code in the many thousands of lines of code necessary to operate such a system.

Finally, let's assume that the persons who pay (we'll call them Payers, for now) want the system to work properly because unless it does they will suffer. People will be angry with the Payers and the Payers cannot escape the consumers' wrath. Therefore the Payers will pay well for anyone who improves or debugs the accounting software. They will also pay for anyone who helps those who debug the software.

There are two basic ways to prevent hackers from exploiting bugs in programs. One way is to keep the programs as much a mystery as possible. Keep the source code of the programs a secret so that no one can examine it to find the flaws. The other way is to give everybody access to the code and have as many as possible looking for flaws so that they can be corrected before harm can be done.

If the code is kept secret, people will rightly suspect that there is cheating going on. They will suppose that the programs unfairly benefit some people and harm others or that the programs are under the control of some group conspiracy. This suspicion is bad for the Payers because they are the natural people to blame when things go wrong. This is one reason that the accounting programs would be made public.

Imagine that you are a skilled programmer. You have access to a copy of the accounting program code and you want a lot of money. You search and find a bug in the code. You now have two choices. You can keep your discovery secret and exploit it to get more money. Or you can expose the bug along with improved code that does not have the bug. If you take the first path, you risk other programmers finding the bug. If they do, your exploitation of the bug will be discovered and you are caught. Remember that the computer recognizes those who deal with it and for you to get money your account must be modified. Therefore, exploiting the bug would be risky. Your other choice, to expose the bug, guarantees a significant reward, improves your reputation, and gets people to help you find more bugs.

Now some people will follow each option, of course. But those who decide to steal using the flaw will be removed from the exercise and those who improve the code will be retained. Over time, the proportion of those who choose to publicize bugs will become very high.

The above situation is the simplest, most primitive, one at a time approach. But programmers don't think that way. Rather than searching for one bug at time, programmers like to have searches automated (because really good programmers are all lazy) so they would write programs that sought out bugs. That way the successful programmers don't just find a bug or two, they find numerous bugs at a time and they provide tools to search for bugs in proposed improvements to the basic accounting code. In short, the improvements build on themselves because that's where the rewards are. One gets paid for making things better and the rewards for improving the accounting programs are high because this software is, to the Payers, one of the most important parts of the economy.

Will there be some people who manage to cheat the system? Of course there will. Will some people get away with giving themselves extra money? It is almost inevitable. But with a non-POM system there are records of the benefits that were realized to justify each payment. To get a large payment there must be some large benefit. Such large benefits are obvious and noticed. Therefore, if a person suddenly has a lot more money than before, there must be some corresponding benefit that "accounts" for that increase in money. So to get away with cheating, one must "cheat small" or make oneself obvious. Thus even successful cheating in a non-POM system is minimized.