Open Source - Alles umsonst?

vorgesehen, produktiv eingesetzt zu werden. Die so genannte Entwicklungsvariante dient demgegenüber dazu, neue Beiträge zu testen. Auf diese Weise wird ein Umfeld für ‚Trial and Error‘ geschaffen, ohne die Zuverlässigkeit der Software im Produktiveinsatz zu gefährden. Die Ergebnisse der Entwicklungsversion werden nach und nach in die stabile Version integriert. Darüber hinaus werden auch ganze Aufgaben von Entwicklern parallel ausgeführt. Insbesondere ist hierbei der Test- und Fehlerkorrektur-Prozess angesprochen, der von den Entwicklern kein großes Maß an Kommunikation und Koordination verlangt. Diese massenhafte Code peer review durch sachverständige Programmierer, denen außerdem der grundlegende Quellcode vorliegt, trägt im entscheidenden Maße zur Qualität von Open Source Projekten bei. Berühmt geworden ist was Eric S. Raymond Linus’s Law nennt: „Given enough eyeballs, all bugs are shallow.“191 [...]

Das Prinzip von Versuch und Irrtum gehört zu den dominanten, wenn auch manchmal unbeachteten Regeln, nach denen Open Source funktioniert. Linus Torvalds nennt es “Evolution” oder „survival of the fittest.“183 Projekte profitieren von diesem Wettbewerb der Ideen insbesondere wenn sie ihren Entwicklern einen Rahmen bieten, innerhalb dessen sie eigene Vorstellungen ausprobieren können. So ist es beispielsweise zu erklären, dass sich der Internet Browser Konquerer unter dem Dach des Metaprojekts KDE entwickeln konnte, in unmittelbarer Konkurrenz zum straffer organisierten und fokussierten Mozilla Projekt.184 Eric S. Raymond geht so weit, in Anlehnung an Frederick Brooks zu behaupten: „Plan to throw one away; you will, anyhow.“185 Dies soll nichts anderes bedeuten, als dass sich die Entwickler darauf gefasst machen sollten, einen ganzen Entwurf zu verschleißen, um das Problem vollständig zu verstehen und folglich kompetent umsetzen zu können. Open Source Projekte müssen, um den Prozess von Versuch und Irrtum langfristig zu garantieren, dafür Sorge tragen, dass der jeweilige Entwickler nicht zu viel Energie und Zeit in einen Irrtum investiert. Aus diesem Grund wird der Zyklus, in dem neue Versionen veröffentlicht werden, so kurz wir möglich gehalten; oder als Empfehlung an den Owner: „Release early, release often.“186 In den [...]

Es existiert eine ganze Reihe von Versuchen, Open Source in kurzen, griffigen Formulierungen zu umschreiben. Kaum einer dieser Slogan trifft so ins Schwarze wie Michael J. Hammel’s „Open Source Software wurde nicht zum Verkauf entwickelt, sondern zum Gebrauch.“181 Dieser Punkt ist eng verbunden mit dem zuvor dargestellten Prinzip des Users als Entwickler. Open Source Projekte beginnen gerne in Nischen, die von kommerziellen Produkten nicht oder unzureichend abgedeckt werden (z.B. Linux, Perl, Apache). Es liegt nahe, dass Entwickler Projekte starten bzw. an ihnen mitwirken, von denen sie direkt profitieren. Die Entwickler stellen dabei oft fest, dass sie vor Problemen stehen, die auch andere teilen und identifizieren so nahezu unbewusst interessante Projektumfelder, in denen ihrer Projekte aufblühen können. Eric S. Raymond fasst diese Beobachtung in die knappe Formel zusammen: „Ein erfolgreiches Projekt, kratzt ein großes Jucken.“182 [...]