Critique for the Open Source Development Model

Contents

1 Introduction
1.1 Disambiguation
1.2 History of Open Source Software

2 Strengths of OS
2.1 Open Source Definition OSD

3 Weaknesses of OS
3.1 Problems and Limitations
3.2 Conflicts Among Developers
3.3 Pseudoproblems
3.4 Death of an OS Project

4 Legal Questions
4.1 Warranty
4.2 Announcement of Source Code
4.3 Development and Payment
4.4 Leasing
4.5 Allocation for Download
4.6 Patent Right
4.7 Licenses

5 Examples
5.1 Unix
5.2 GNU
5.3 Linux
5.4 Costs Example

6 Conclusion

1 Introduction

You can hardly find another topic moving the software world more than the dispute between Open Source and Commercial Software [End00]. You can simplified describe the following positions.

First Open Source promotes developing software in non-industrial organizations or during a bureaucratic process but through spontaneous cooperation by interested people who don’t have any business relationships. Second, users are said acquiring software not only in form of object but to insist on the source code. Third, Software should be preferably given away. And Fourth, Software should be given away without any protection of copyright or license [End00].

Glass, an American observer of the software scene, wrote that he didn’t understand two facts about the open source movement: programmers lovely read anybody’s code and people work for others without getting paid. But there are more understanding prob- lems with this new cult. When you look behind the mascots and easygoing sayings then questions about the main assumptions of this field of activity come up [End00]. A very famous paper named ”Cathedral and the Bazaar” from 1999 described open source development model as a bazaar. The author Eric Steven Raymond wrote: ”I be- lieved that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time. Linus Torvalds’s style of development release early and often, delegate everything you can, be open to the point of promiscuity came as a sur- prise. No quiet, reverent cathedral building here rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly sym- bolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles. The fact that this bazaar style seemed to work, and work well, came as a distinct shock.” [Ray99]

He showed OS as a magic solution [Bez99]:

- Open source is a progressive phenomenon (bright future of mankind) with no problems.
- The best open source projects employ the so-called ”bazaar model”.
- Microsoft should be destroyed.
- All software developers are moving towards the ”gift economy” in a ”post scarcity society”.
- The open source movement consist of ideal cooperative people. Conflicts are few and can be resolved within a community.
- Like a primitive society the movement is (successfully) regulated by unwritten norms and taboos.

That sounds so amazing that I wonder why not every software is developed during an open source software process? Later on this paper will show that reality isn’t that simple.

1.1 Disambiguation

Open source wasn’t the whole time the title for what this paper is about. The turn- around from free to open source software took place in the already mentioned paper ”The Cathedral and the bazaar”. In his versions until 1998 Raymond uses the expres- sion ”free software”, after it was replaced by ”open source”. The word free is not only ambiguous (like free beer and free speech) but also a little bit dirty. Free Software was formed by Richard Stallman, the founder of GNU movement. Its devotees still keep this term alive. Officially, Open source became the new name during OSI foundation meeting in February 1998. Reason for this meeting gave Netscape’s decision to lay open the source code of their browser. After this historical step the computer and financial press used the new term ”open source”. Devotees of free software still criticise that ”open sourcers” would only focus on pragmatical aspects, usability, features, reliability and the efficiency of software. They would disregard beliefs like freedom, community and other principles. ”In fact, that’s the genuine difference between these similar terms: free software follows a political philosophy and open source software is a development model.” [Gra02] Stallman says the following sentences when he categorises software: [hSI05]

”The term open source software is used by some people to mean more or less the same thing as free software. However, their criteria are somewhat less strict; they have accepted some kinds of license restrictions that we have rejected as unacceptable. We prefer the term free software”

1.2 History of Open Source Software

Let’s have a short look on the short history of OSS.

Software was delivered as free adjunct with new computers until middle 60’s. Manufactures made exclusively money of hardware. Source Codes were freely available for all enthusiastic programmers in the whole world. First 1965 IBM finished delivering source code together with operation systems of computers. At the beginning of the 70’s several programmers assert making much money out of their own developed software. With the aid of license contracts narrowing or even restricting dissemination of software from one user to another they protected their sources of income. Source Codes became the best kept secrets of young businessmen.

Almost ten years later Software was developed behind closed doors. In this way manufacturers could retain control of their tools. Non-Disclosure-Agreements bared programmers from free enhancements their products.

Richard Stallman from the MIT and the later founder of Free Software Foundation was so unsatisfied with this evolution that he decided in 1984 to reproduce a free software package named GNU. His aim was the recreation of open co-operation among software developers to benefit for all computer users. Moreover Stallman created GNU General Public License (GPL) protecting the freedom of software.

The word ”free” let the economy become quietly sceptic. That gave Eric S. Raymond 1998 reason to propose naming software together with open source code in the future Open-Source-Software. The Open Source Definition says nothing about using open source software among commercial software. [Gra02], [Ber05]

2 Strengths of OS

The strengths of OSS result from its primary aims: developing software in non-industrial processes and so on. In the internet you can read what the official homepage www.opensource.org says about basic ideas of open source: ”The basic idea behind open source is very sim- ple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.”

The main advantages of open source are the following [Ber05]:

- Source Code is optionally extendable, improvable and individually adaptable.
- Bugs and security holes can be fastly detected.
- Permanent quality improvement of software.
- Independent development and continuity of software.
- Less expensive than commercial products.
- Usage of open standards guarantees compatibility and portability

2.1 Open Source Definition OSD

Bruce Perens wrote the first version of OSD with the name ”The Debian Free Software Guidelines” and improved it adding messages from a lasting for months email confer- ence. Open source developers should follow the 10 criteria of the Open Source Defini- tion [htt05]

1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

4. Integrity of The Author’s Source Code

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of ”patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly per- mit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the orig- inal software.

5. No Discrimination Against Persons or Groups

The license must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those par- ties.

8. License Must Not Be Specific to a Product

The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

10. License Must Be Technology-Neutral

No provision of the license may be predicated on any individual technology or style of interface.

If any software follow these 10 criteria, then you can call it open source. These criteria create the strengths of open source software.

3 Weaknesses of OS

”Experiences is a wonderful thing, it enables you to recognize a mistake when you make it again.”

Because Open Source Software is a development model, it has its own set of prob- lems. Application qualification has to be verified in every different field of application. There are several questions needed to be answered: technical questions like ”Does the chosen periphery support open source software?”; and economical questions like ”Can you really save money using Open Source Software privately or commercially?”. Just until a few years, Open Source was only popular to insiders. And today someone has to ask if there exists a open source solution for its application area. In Germany the project ”BerliOS” by the Federal Ministry of Economy and Technology shall produce relief . BerliOS has to act like a neutral arbitrator between users, developers and sup- port companies with main task of showing which open source solutions are available or should be developed.

For each open source software package we have one developer or a group of developers committed to making that package the best it can be. If a project has a bug, the developers responsible for it wants it not have bugs. But the reality is not that simple. There are popular papers revealing that weaknesses of OSS projects fall into three primary buckets: management costs, process issues and organizational credibility [Bez99]. This section will present different problems which could surprise the reader.

3.1 Problems and Limitations

DOES OPEN SOURCE REALLY PROVIDE A RAPID DEVELOPMENT ENVIRONMENT?

”Open Source does work, but it is most definitely not a panacea...Software is hard. The issues aren’t that simple.” Jamie Zawinski

Jamie Zawinski developed the Netscape Navigator and took part in many other OS projects.

OSS is made by developers being widespread all around the world. Ordinary projects have the advantage of meetings and face-to-face communication. But these meetings are impossible for OSS programmers. The only way to communicate is provided by the Internet. But Internet has one big error: missing development advantage. When programming work requires everyone to develop on a single and fixed task, the pace of OS development became slow or even slower than traditional projects. For Example, TeX was fully created without the medium Internet.

At the same time there are counterexamples that grandiose projects are created by small groups of developers. They are more productive than a large community, this inhibits innovation. The more developers involved the worse their cooperation is and projects even may stagnate. If there exists developer A who is interested in finishing the project quickly than he may have the problem of missing authority. Developers work for fun and they don’t like being commanded around. A has to wait until every important developer worked at his part. Speed in a project can only be reached through authority. People have to do their task persistent. But authoritarian methods kill any given project and they militate against each OS principles. So, when speed is important you need authority. In history of Open Source Software the best example for authority or even ”cult of personality” is the Linux project with its ”guru” Linus Torvalds. One developer has a tremendous amount of authority and this centralization dissatisfied developers which frequently lead to several splitting competing projects.

To answer the question if OS really provide a rapid development environment, you can loudly say no. It provides no speed but quality and simplicity.

WHICH IMPACT DOES THE TOWN COUNCIL EFFECT CAUSE? ”Show me the source” (Linus Torvalds)

Alan Cox, developer of Linux kernel, also named Town Council effect ”The committee for the administration of the structural planning of the Linux kernel”. So what does the Town Council effect really mean? You can say, that is a particular bureaucratic super- structure of developers. Programs aren’t produced in isolation. Many users with email play an important role, they want to take part in the project and change its directory of development. But often majority of users have more dangerous smattering and opin- ions than helpful ideas for the code. Therefor a core team like a clique is created. Now every code changing must nodded through this core team. This of course seems unde- mocratically, but for the project it is en essential fended position that only a small group effectively work for the project.

The Town Council effect contradicts the OS principle that everybody can change the source code non-restrictively.

IS THERE A SIGNAL-TO-NOISE-RATIO OF E-MAIL CONFERENCES AND SUPERSIZED EGO PROBLEMS?

”To succeed in the world, it is not enough to be stupid, you must also be wellmannered.” (Voltaire)

Although this quote is much older than the Internet, it describes Internet communica- tion very well. You can find a lack of cooperation, decorum and useless things. It’s much easier to express hostility, selfishness and simple nonsense in emails than in a face-to-face communication. As already said, OS doesn’t own the ability of these (nat- ural) things. Internet just isn’t the ideal way to communicate although it connect so many developers. But often they rather use Internet for fanatic diatribes against ”The Others” than for solving operations system errors or similar problems.

[...]