Kapitel 5 (g)

5.2.3.4 Technische Entwicklung

Der Organisation der menschlichen Ressourcen steht technische Entwicklung und deren Koordination gegenüber. Tausende Dateien müssen geprüft und in die vorhandene Code-Basis integriert werden. Es kann sich dabei um eine einzelne Basis handeln, deren Äste verschiedene Architekturen repräsentieren (Linux) oder um mehrere Code-Basen (BSD-Varianten), für die dann zwar die Programmierung leichter fällt, aber das Management erschweren. Hin und wieder passiert es, daß eine Code-Basis aufgespalten wird (forking) und sich ihre Teilbäume unabhängig voneinander - meist in verschiedende Richtungen, auf bestimmte Einsatzgebiete spezialisiert - weiterentwickeln. Im allgemeinen wird dieser Akt in der Open-Source-Gemeinde nicht gerne gesehen und muß wohl begründet sein.

Häufig werden zwei Linien der Code-Basis gepflegt. Eine stabile, produktionsreife Version und eine Entwicklerlinie, die neueste Features beinhaltet und somit relativ instabil ausfällt. Linux und die freien BSD-Varianten arbeiten mit diesem Verfahren. Zusätzlich können Termine für den Code- und den Feature-Freeze vereinbart werden. Mit dem Code-Freeze geht die Software en in die "Fertigung". Für die aktuelle Version werden bis zur Veröffentlichung keine Änderungen mehr vorgenommen. Beim Feature-Freeze werden keine neuen Beiträge mehr integriert; lediglich Fehlerbehebung und Integration finden noch statt.

Die weitaus wichtigste technische Eigenschaft eines freien Software-Projekts ist ihre Modularität. Sie ist die Voraussetzung für eine verteilte und unabhängige Entwicklung. Je modularer eine Software aufgebaut ist, umso besser können Aufgaben an Gruppen verteilt werden, und umso einfacher wird die Organisation und Koordination. Im Falle einer einzelnen Anwendung kann Modularität durch ein Plug-In-Konzept sichergestellt werden, wie es das Bildverarbeitungsprogramm GIMP eindrucksvoll zeigt. Grafische Funktionen oder Konvertierungen können leicht über ein Plug-In in die Applikation integriert werden. Modulares Design steht über der Benutzerfreundlichkeit und über Performanz. Sie läßt sich aber nur dann realisieren, wenn offene Standards und dokumentierte Schnittstellen zur Verfügung stehen.

Die hochgepriesene Stabilität freier Software resultiert aus der ungeheuren Masse der Anwender und Entwickler in Bezug auf Tests und Fehlerbehebung. Da der Quellcode verfügbar ist, kann jeder gefundene Fehler selbständig beheben. Oft werden Fehler von Benutzern gefunden und gemeldet, die aber dann von anderen Anwendern oder Entwicklern verstanden und womöglich wiederum von anderen behoben werden. Dieses Vorgehen ist parallelisierbar und läßt sich so ideal auf eine große, verteile Gemeinde anwenden. Ein ganz entscheidender Vorteil gegenüber der traditionellen Softwareentwicklung.

"One of the core practices used in open-source software is peer review: because everyone can see the code, everyone can see your work. One obvious benefit of peer review is that mistakes get caught sooner. I call this Linus's Law, after Linus Torvalds: 'With enough eyeballs, all bugs are shallow.'" - Eric Raymond

Stetige Verbesserungen, Ergänzungen und Fehlerbereinigungen verlangen nach ebenso stetigen Veröffentlichungen. Ein Motto von Open Source ist deshalb "release early, release often". Die schnelle Behebung schwerwiegender Fehler mündet daher sofort in einer neuen Version. Für den Teardrop-Bug oder den "Ping of Death" vor wenigen Jahren standen 24 Stunden nach ihrer Entdeckung Patches für Linux bereit. Bleibende kurze Veröffentlichungsintervalle deuten auf das große Entwicklungspotential einer freien Software hin.

Kommentare, Anregungen, Berichtigungen, Verbesserungsvorschläge oder anderes Feedback an info@dbus.de