Free as used by most modern software monoliths (Oracle, Corel, IBM, Microsoft to name a few) means that the pre-compiled software package is distributed without a charge for a copy of the software package, usually under extremely restrictive licensing conditions as well. With a software package being distributed as machine language (binary) code, it disallows the ability for the general public to look at the source. To avoid confusion, the reference to such programs was left as free. However, the other programs that would be developed, such that its source code is public domain, were renamed to open.
Open software is a seemly increased descriptive term for the software
package developed under the concept of public domain. Furthermore,
an Open Source software package does not necessarily denote a free copy.
A company may create, test, and announce a request for comments for a piece
or version of software that is currently in development. When the software
is fully developed, the company may choose to release the package to certain
individuals, whom have paid a fee for its use.(1)
In the end, however, the final objective is met. The software development
company was able to release a software product that myriad of developers
(affiliated and unaffiliated with the company) was able to look at from
the inside out. A project where external programmers were able to submit
comments or code patches to improve bugs that would normally have not been
picked up by the developers creating the product.
A software project may be developed with six months hiatuses between releases. Good examples of this scheme are the Netscape / Mozilla Project, and the Windows 9x projects. If a user has a particular problem with the current release of the software package he must wait six months until the next time that the software is released(2).
Jamie Zawinski, ex-employee number twenty, at Netscape Communications Corporation, states that one of the major problems with the Mozilla Project was that they had not produced a usable web browser even after one year of development. They had not 'released often', nor released early.
This may be seen with contrast to the Linux operating system (OS) kernel development. A new kernel release is distributed every four weeks on average. Each minor release provides bug fixes that were demonstrated in the previous version. In most cases not all bug fixes are implemented. However, there are just enough differences between the previous minor version and the current version to warrant the release. Even so, the release, needing approval by Linus Torvalds himself, is not released fast enough to a community hungering for the bleeding edge. So the lead developer of the Linux kernel, Alan Cox, posts a pre-release version usually suffixed by his initials (AC).
With each release, the kernel developers get live and current feedback from the users and implement these changes to each subsequent version. In this manner Linus is treating his users as 'co-developers' in the project. In effect: "Release early, release often, and listen to your customers."(3) This is the traditional problem with other methods of development.
Listening to your customers has a "positive" spiral effect on the development of an Open Source project. This is demonstrated by treating each of your users as an integral part in the Open Source development paradigm. Listen to what they have to say and let the users determine the direction of the software package.
By implementing the solutions as rapidly as possible, utilizing the internet as the main distribution medium, and releasing early versions of the project the users are kept satisfied. This kind of environment keeps an upward spiral of positive feedback that ameliorates the growth in the quality of the software product. This, in effect, keeps your users active within the software project.
This is one concept that the developers of Netscape (code named Mozilla) and Windows did not take into account. There is no instant gratification for users, and possibly contributors, of the software package. If there is a bug in the software package the users must wait until the next scheduled release of the software update.
Having open source software, one is able to get instant feedback and
comments regarding the software package. In some cases, this feedback is
accompanied with a patch for the source code that the developer may wish
to incorporate as part of his software package, or implement a tidier set
of code which has the same end result.
The developers of ARPANET created standardized protocols allowing for solid and unrestricted communication possibilities. For each protocol they published a request for comment (RFC) document. These protocols were wide open for the general public and not limited in scope to a particular operating system or computer platform. By publishing the protocol and separating the design from the implementation they allowed for the free sharing of ideas and proliferation of its use.
This may be contrasted with the AT&T Bell Labs closed doors design of the Open Systems Interconnection (OSI) standard in the 1980's. It was a vague and cryptic design at the time of its presentation for use on ARPANET. It is, today, still being designed.(5) And is probably one decade away from being completely finished. Some of the major criticisms against the OSI protocols are, in fact, due to its being closed source.
At the root of all of the following criticisms(6) it seems quite apparent that had it been created as public domain, many of these concerns may have been addressed before standardization of the protocol.
Linus Torvalds is not a genius, although it does take a lot of know how to develop an operating system from scratch, and not many of us have done that. What he did do, however, was take advantage of help from wherever he could muster it. This meant utilizing the Internet as a tool for developers, from all parts of the world, to be able to communicate, share ideas, and work on such a large project.
Torvalds had a simple approach to engineering his project. Open the source for all eyes to see and listen to what the users had to say. Implement as many changes as possible without regard to the additions' stability. The end goal was based on one assumption: if you have enough users and developers, most problems will be detected early and weeded out.(8) This is something that can only be accomplished with the Open Source development model.
The number of developers in the Microsoft Corporation for the Windows operating system is assuredly in the hundreds. However, they are all of one mindset, and physically cultural location; Their schema, is also quite similar, and if not at first, their tied interpersonal relations easily foster a schema altering environment. This is a limiting factor when developing software, because the environment becomes stale. The only solution for this 'staleness' is to have a continuous turnover rate. Hence, by keeping fresh people in the 'Cathedral' development model, the company is always allocated fresh ideas.
There is one flaw with the 'turnover' method used in the 'Cathedral' development process. When you have new people take over a project that was already started, acclimation and familiarization doesn't always occur. Some developers may implement functions that are not fully understood. Comment styles, and coding styles change drastically from person to person. The developers are not exactly familiar with how their portion of code fits into the project at large. This produces buggy and unstable software which winds up on most users' desktop. They take crashes in the OS, or software package, as a 'normal part' of computers, which is certainly not the case with open source software.
Open source software must be usable, and it must work
or it goes by the wayside. The only way to achieve this is by having the
source out in a type of environment that allows for maximum user and developer
access. It must be placed in a public forum, agoria, where all eyes can
evaluate and find bugs that are not so apparent to the developers, but
that are apparent to someone attempting a particular task.
This seems like it can transfer itself beautifully in a controlled closed source environment. However, by pure example (i.e.: Windows 9x/NT) , we see that this form of development in a closed software system detains the release of the software package. Why? As stated above, in a closed system there are some dedicated few developers, looking at the problem attempting to fix it, hacking at the source over and over again. They must be sure that the bug is fixed before the next release. This can and does delay the next release of the software package. If there are any more bugs released after a long hiatus, the user group will be even more disappointed.
With the Open Source model, division of the software package into key components becomes fully manageable. At the head of each division is a module developer; if the users have any problems with a particular module, they may scrutinize and find or fix a piece of code then inform the module owner of the bug and its fix. The module owner then knows how the fix is to be incorporated into the source tree and its local effects.
With Open Source you know exactly who the module owner is, and may communicate directly with him to exchange information regarding a problem or optimization specific to that particular module. This sort of personalized information exchange in the 'Cathedral' model would cause a massive level of confusion and disarray. Imagine FTP'ing a file in Internet Explorer and having it crash on you. Then imagine the number of people experiencing the same problems with Internet Explorer. Two problems would arise:
Intellectual ownership is maintained if all sources are Open,
because then it would be quite apparent when someone has stolen an algorithm,
or design, and not given proper credit where credit was due. While not
all source is open, during the transition phase, the GNU Public License
(GPL) may be attached to the code. This is the legal sword with which to
fight battles should intellectual ownership rights be infringed by commercial
and non-commercial closed source software developers.
I offer this response as a counter argument to the question of reward.(9)
The concept is quite blatant: If there is only one outlet for any particular product, then the consumers of the product are at the discretion of the monopolizing outlet. Hence, the originator of the product has full control as to the direction and monetary value of the product, regardless of the consumers' wants.
A prime example of this Microsoft Windows operating system. I would rather see a more stable OS than a 'prettier' one. Yet, they insist that 'they know what is best for me' as a developer and attempt to charge me US$95 for the distribution. Microsoft controls the market based on scarcity. It is the only outlet with an x86 operating system that has the most hardware and software support, mainly due to their Rockefeller tactics.
The economic principle of abundance is the driving force for Open Source software. This principle is quite simple: The more you use and distribute a product, the more valuable this product becomes. Hence the customers are the actual driving force for the product. They dictate what direction the product should take.
Two prime examples are the Internet, and Linux. If the consumers of the Linux operating systems were not satisfied with the product, they would simply not use it. The product would die; Or the product would be driven toward the direction of excellence because no one source has complete control over the direction or price of an open source product(11) like Linux. Then it is quite apparent that Linux's value comes, not from its sale, but from its use. The more people use it, the more they rely on it, which increases its value. With increased value, people would be more prone to develop software solutions that would in turn ameliorate the upward spiral. Pecuniary interests may then be satiated by its use rather than its manifestation(12).
The same may be said about the Internet. The Internet's abundance (in this case, its omnipresence) for daily tasks such as e-mail, WWW, and general communications, lends itself amicably to the economic principle of abundance. No one source has complete control over the Internet driving its cost and direction. It is, however, its own entity. Lest it be forgotten, the Internet started out as an Open Source venture by an "unprofessional" Internet Engineering Task Force (IETF). The Internet evolves, and takes on its own direction as the users deem it necessary for new protocols and standards to be developed. It adapts or it dies! And once again, pecuniary interests from this 'free' software project are satiated by its use and not by its presence.
So here I offer this explanation of the Open Source paradigm in hopes
that the contents would provoke thought among members of my community.
This thought prodding is necessary at a time like this, while the networked
computing industry is still at its infancy. All of this in hopes that the
industry, of which I am a part, does not 'shoot itself in the foot' from
mistakes past made, repeated.
"Perhaps the central problem we face in all of computer science is how
we are to get to the situation where we build on top of the work of others
rather than redoing so much of it in a trivially different way." -R. W.
Hamming, 1968(13)
2. Zawinski, Jamie. "Resignation and Postmortem." <http://www.jwz.org/gruntle/nomo.html> May 23, 1999
3. Raymond, Eric. "The Cathedral and the Bazaar." <http://www.tuxedo.org/~esr/writings/cathedral-paper.html> May 24, 1999.
4. Berger, Robert. "Microscared: The Challenge of Open Source Software." Linux Magazine Spring 1999:27.
5. "OSI Protocols." <http://ken.slctech.org/miscdatacomm/osi_protocol.htm> May 23, 1999.
7. In reference to the closed source corporate development model as opposed to the 'bazaar' open source Linux development model in Raymond's "The Cathedral and the Bazaar." Section 1.
9. These reasons were offered in the book 'The Mythical Man-Month" as Joys in the Craft page 7. I am speaking as a code hacker and software systems developer for a major hospital in the Philadelphia area. They seem as valid reasons; I have adopted them as valid arguments for this issue in the Open Source movement.
10. He could possibly charge for the use of the tool. However, this creates certain problems within the closed source software industry. Each person or company within the industry must keep reinventing the wheel. This re-invention of the wheel produces a loss of productivity and an overall loss to the industry. See the Agorics papers article listed in the bibliography, particularly, the section on implementation of wide scale Agoric Systems.
11. Linux Magazine, "Microscared: The Challenge of Open Source Software." page 26.
12. For more information on the pay-per-use versus pay-per-copy issue see "The Agoric Papers" section 6.
13. Regarding the reinvention of the wheel each
time the developer wants to impliment something for his particular project.
From "One Man's View of Computer Science." ACM Turing Award Lectures:
The First Twenty Years 1966-1985. p.216. See W.C. for more information.