William Totten
Software is very useful; however, dependence on software can be quite destructive. So, we must develop software in such a way as to ensure it is as stable as possible. Software programs enable us to solve complex problems in otherwise unimaginably minute lengths of time. Software even helps us to solve problems which are too large for humans to fully contemplate. So, these are reasons to use software, right? Wrong, these are the reasons not to use software or, at least, be skeptical of its results.
We save time by using computer software. Computers have the ability to carry out mathematical computations much more quickly than humans can. This frees people to engage in less mundane work, which makes their lives happier and helps to produce more, faster. Unfortunately, most of us have become accustomed to this and never want to go back to the way things were before software aided our lives. This is unfortunate because we put too much trust into software. It is not often worth our time to check the results of the computer. It often seems pointless to check those results, since we use the software to save the time it would take to do the work anyway. Yet, by not checking the results, we may be putting too much trust in the software. This can lead to dangerous results.
The problem worsens when we use software to solve problems which are so large that we cannot even conceptualize them. In this case, we have no way of checking the output of the program. The operations involved may take days, even on todays fast digital computers, and the amount of data being interpreted may be so large that it would take someone a day just to write it out. To solve this problem, we need software. So, how are we going to ensure that the software is giving us the correct answer? The answer is that we may not be able to for such a large program; however, this is not a new situation for humans to find themselves in.
Since the time of Socrates, Philosophers have questioned what it is that we actually know. Descartes started by questioning everything. He found himself only able to know that he exists as a thinking being, he could doubt everything else. He was in this position because he could not prove that there was not some kind of evil demon causing him to believe false things. He then took solace in a benevolent God who would not let this happen; however, this is considered to be an unprovable assumption. Theories of knowledge developed after Descartes assume something like a Cartesian Evil Demon does not exist. Even with that assumption, philosophy has yet to anser the question of knowledge.
Karl Popper's theory of knowledge takes an entirely different approach. He proposes a theory of conjectures and refutations.[Pop92] You make a conjecture, provide a proof, and try to refute it. As long as the theory seems plausible it is useful. The theory should be developed in such a way that it can be refuted, and people should try to refute it. Nothing is ever certain in this model. Yet, it works because theories help us to understand the world, even if they are never completely provable. They may be eventually overturned by better theories or modified to fix problems.
Computer software is a program or set of programs working in conjunction. Most software is written in a programming language like ``C'', which is a compiled language. What the user usually gets is the compiled version only. The human readable, uncompiled, version of the program is usually referred to as the source code. The process of compiling is that of turning the human readable program into something which the computer understands. In this form, software is like a black box; the user interacts with it (input) and receives a response (output). If the software has a bug in it, all they can do is report what they did to disrupt the normal operation of the software to the developers.
The open source model[Ray] solves this black box problem. Users have access to the human readable source code to the program. They have the option to consult the source code and fix the problem or at least tell the developers exactly where the problem is. If the developers will not fix the problem, the user has the option of fixing it or hiring someone else to fix it. ``Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes.''[Sta93] Open source software will have more people looking at the program, and this usually means that more bugs will be caught.
Open source software protects the user. Problems in software are often caused by sloppy programming. If the user can look at the source code, they can decide for themselves if the program is written to their standards. One major mistake in a ``C'' program is to use the function gets, which reads characters as input and stores them in an array. ``There is no checking to see if the input characters fit in the array, and is thus very dangerous.''[Lew91] Even though people have been warned against using this function, some still do. When you have access to the source code of the software you use, you can check to make sure such ``dangerous'' functions are not present. Another benefit is that open source software is often coded more cleanly, since people will be looking at it.
Eric S. Raymond wrote a very interesting article called ``The Cathedral and the Bazaar''[Ray97]. It discusses two very different models of software development. The cathedral model is the one used most often during software development. In this model, development and releases are heavily controlled. Developers create the software, then they try to find and fix all the bugs before the software is released. This makes releases very infrequent and full of bugs which the small set of developers did not find.
The bazaar model is very different. It's conception was inspired by the development model of the Linux operating system. Few people in the software development community actually believed a model like this would work on such a large scale project; however, it works very well. In this model, you release often --sometimes even twice a day with the Linux project. Since changes are usually minor, it is hard for bugs to creep into the system. Also, since a large number of users are testing the system, bugs are found very quickly. Routinely, stable versions are released in which new development is brought to a halt and only bug fixes are allowed into the source code for the software. Using this model, new development goes very quickly and is well tested; while slightly older stable versions are available for people with the need.
The bazaar model does not just work. The bazaar model implies some kind of open source distribution method. It requires that a program already exists to work from; this starting point would have to be obtained using the cathedral development style. Users are essential; without a properly sized user base for testing and corrections, the ability to catch bugs is no better than the cathedral model. The bazaar software development model also seems to need a good leader; one who can almost instinctively weed out bad patches, keep up with the users, and communicate well with the users.
Software, as mentioned above, is not inherently reliable. However, if the software is developed carefully and is well tested, we can accept that it probably works. This is a conjectured piece of software. We are not sure that it is correct. Nonetheless, it seems to work well, and it is useful. If I am unsure that this new conjecture is as sound as the last, then I may decide to continue using the last one until this new conjecture is proven to be superior.
Hopefully, many people will test this conjecture. These users act as refuters. They test and try to find mistakes in the program. If they are successful in their refutation, they send a report to the conjecturer. When the bug is worked out, another conjecture is made. As Raymond says, ``...you conjecture often in order to get more refutations.''[Ray97, P.7] Although Raymond used the terms release and corrections respectively for the emphasized text, the meaning does not change.
This still does not guarantee fool-proof software development. Just like new information can provide a new refutation in Popper's theory, it can also provide one with software development. For example, suppose the software requires access to a certain file, yet one day a person runs it concurrently with another piece of software which updates that file, but has to move it first to do so. Our original program may crash. Also, the program is only as good as the machine it is running on. Suppose a power surge cause values in the computer's memory to be corrupted, this may very well destroy the correctness of the program. This situation can be thought of as analogous to Descartes evil demons, and we will have to assume that is not going to happen on a regular basis when developing and using the software.
A study done at the University of Wisconsin found that ``[t]he reliability of the basic utilities from the GNU and Linux were noticeably better than those of the commercial systems [tested].''[fuzz , 1] This This study was based on a program which sent random inputs to various programs and their equivalents across different platforms. From the table on pages 7 through 9, the researchers were able to crash or hang between 15% and 43% of the tested utilities from commercial UNIX style operating systems; however, they were only able to crash 6% and 9% of GNU and Linux utilities, respectively.[fuzz ] Most of these errors were caused by misuse of pointers and failing to check if allocated memory was actually allocated. Both of these problems would be reduced in an open source model, because extra eyes catch these kinds of problems relatively easily.
Careless errors are less likely in the open source model. If you are letting the world see your code, you are probably going to put more time into it to make sure it is perfect. Also, commercial programmers often do not use the software they are writing. If commercial software developers released their source code, then not only would the users catch these careless mistakes, but developers would be under more stress to produce high quality programs.
Netscape Communications Corporation is an excellent example of this.[moz98] Netscape, like most corporations, developed its web browser using the cathedral model. Raymond's paper helped convince Netscape to switch to a model more closely related to the Bazaar.[Ray98] At first glance, the size of the source code for Netscape is daunting. However, if you delve into it, then there are many places where you will find the goal was to get it done and not to get it done right. Nevertheless, we should all give Netscape a pat on the back. They are trying to develop their software in the way which will make it the most reliable for future users.
Software is prone to errors, and we may never know for sure if any large application is completely safe. Yet, we depend on it everyday. Our questions regarding software are not that different than the same questions which we have about ourselves. There are different approaches to software development, and we should choose the model which produces the best results. The Bazaar, or at least an open source model, seems to produce the best results. Therefore, we should use this model and we should encourage others to use it as well.
There is no way to prove or create software which we know as a fact is reliable. So, we should take the next best step, to choose the model of development which produces the closest results to our goal. Presently, the software industry controls much of the market. This goes against everything the American free market economy stands for. If everyone were to stand up and refuse to use programs without the source code, then the industry would have to comply. This may never happen, but the present model of software development can not produce the kind of reliability that we need if we are to be trusting our lives to that software.
Copyleft: (C) 1998 1999, William Totten
This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -no_navigation -link 4 paper.tex.
The translation was initiated by William Totten on 1999-05-11