Finding The Uncarved Tree

There are many reasons today that programmers write Free Software. Some may write it because they want a specific tool or program that isn't available otherwise. Others may do it because it's a popular thing to do, and a few may indeed do it to try to topple Microsoft. However, there is a common ideal that all of this must be based on, a thread that entwines itself through Open Source developers, users, and engineers. We might think of all the different licenses, programs and reasons for writing Open Source as being carved from the same tree. We need to look at the uncarved tree, the single thread, the GNU/Zen of Open Source.

This GNU/Zen needs to permeate every part of the Open Source Renaissance. The kernel developer, the thousands of coders who are part of small projects and the commercial corporations who are writing, selling or supporting Open Source, all need to understand and follow the path of GNU/Zen. If they do not, then our Renaissance will be short-lived. Open Source will lose its benefits, and we will be no better off. However, if we do follow the GNU/Zen ideal, then this Renaissance may truly affect the future of computers and computer science, for all time.

At the turn of the century, physicists and mathematicians found it to be of immeasurable benefit to publicly publish their work. This was done so that the theories could be reviewed by their peers, and new development could be based on their work. It also saved others from repeating the work. Einstein, Bohr, Schroedinger and others, all followed this practice. Hence, our understanding of atomic, sub-atomic and quantum physics leapt forward in those first decades of the 20th century. While many of their theories and ideas were incorrect in some details, the fact that others could build off of their work, which in turn, had been built off of the work of earlier scientists, benefits us today. This principle is very similar to the GNU/Zen of Open Source.

Software is written to fill a need. A word processor is designed with a particular function in mind. A piece of accounting software, or a satellite tracking program, all fill a need. They all solve a problem. Code has been written, logical ideas have been used to make the program work. In a sense, the programmer has created a theory about the best way to perform a particular task. Now, once Bohr had discovered his ideas on how the atom worked, could you imagine his locking up, so that no one could review, or change, or modify it? Indeed, if that were the case, we'd all still think atoms looked like tiny solar systems. Instead, other scientists, found that while Bohr's model was close, it wasn't the best description. The developers of software 'theories' do well to follow Bohr's example.

Proprietary software, finds a solution to a problem. We assume that they believe that their solution to the problem is correct. However, they lock up the code, the logic, their solution, and don't allow it to be reviewed or improved. This is a very big problem. This is the problem that GNU was formed to change. Here is the beginning of the GNU/Zen Path. Open Source software, always makes the solution available for others to review, change or improve upon. Open Source developers publish their 'theories' in the form of source code.

We need to realize that Open Source isn't simply a development model. A development model is all about an end result. Once the required features are built into a program, once the code compiles, the development model is finished. Open Source is about, surprise, the source. Open Source 'projects' may end with a stable, feature rich program. However, the source code they release, continues to move forward. Some may use the literal code, while others may use the same logic or architecture for a completely different project. The ideas and the theory, can continue to live on. GNU/Zen and The Art of Open Source is not a path to a goal, the path is the goal.

Of course, this means that the code must be reusable. Einstein's theory on Brownian Motion would have been useless if it had been so poorly written that no one else could understand it. The code must be commented, documented, well written. How can projects, programmers and suppliers of Open Source accomplish this?

This is the first of several articles about GNU/Zen. We will explore the idealistic viewpoint as well as a more pragmatic view. Somewhere between extreme idealism, and opportunistic pragmatism bordering on exploitation, we will find the Path of GNU/Zen.