Kapitel 5 (c)

5.2 Open Source Softwareentwicklung

Der folgende Abschnitt soll zeigen, wie die Softwareentwicklung in einer offenen, locker organisierten Gemeinschaft (ansatzweise in Abschnitt 1.4 erläutert) funktioniert und warum die produzierte Software nicht in einem heillosen Chaos in verschiedene, inkompatible Bruchstücke zerfällt. Soziale, organisatorische und technische Aspekte des Entwicklungsprozesses werden ebenso betrachtet wie das Software-Projekt, in dem dieser seine Entfaltung findet.

Linus Torvalds machte diese Art der Softwareentwicklung im Basar-Stil populär [36]. Basar deshalb, weil sich häufig ein freies Software-Projekt anderer Softwarekomponenten bedient und weil die Entwickler und Anwender wie Händler auf einem Basar nehmen und geben. Zwar hatten Jahre vor ihm bereits andere ansatzweise mit dieser Methode gearbeitet, aber es war Torvalds, der sie effektiv und praktisch umzusetzen wußte, allerdings ohne sich dessen - zumindest zu Anfang - bewußt zu sein. Eric Raymond war schließlich derjenige, der mit seinem analytischen Gespür als "Hacker-Anthropologe" die freie Softwareentwicklung genau anhand von Fallbeispielen untersuchte. In den drei bekannten Essays The Cathedral and the Bazaar, Homesteading the Noosphere [37] und The Magic Cauldron [38] hielt er seine Gedanken und Entdeckungen schriftlich fest. Sie besprechen jeweils die technischen, sozial-gesellschaftlichen und wirtschaftlichen Aspekte von Open Source.

Freie Software vor Linux wurde meist in kleinen, geschlossenen und eng zusammenarbeitenden Gruppen geschrieben. Es bestand also in der Arbeitsweise selbst gar kein so großer Unterschied zu der Art wie proprietäre Software in Unternehmen entwickelt wurde. Beiträge von unbekannten Außenstehenden wurden selten in die Hauptversion integriert. Aufgrund fehlender Kommunikationskanäle - schließlich war das Internet damals noch schwach entwickelt - waren diese auch äußerst selten. Viele Projekte der FSF, z.B. Emacs und der GNU C Compiler entstanden auf diese Weise.

Heute aber ist das Internet ein globales Netzwerk und fast alle großen, freien Software-Projekte werden nach Linux-Manier oder ähnlich organisiert. GNOME, KDE, Perl und Samba leben von weltweiter, reger Beteiligung. An Größe und Komplexität reichen sie mittlerweile an ihre proprietären Gegenstücke heran.

5.2.1 Die Idee

Am Anfang einer freien Software steht die Idee eines einzelnen Entwicklers. Sie erwächst oft aus einem Problem, das während der täglichen Arbeit mit dem Computer auftritt. Eine Umständlichkeit, eine Inkompatibilität, ein Mangel oder sich ständig wiederholende, monotone Verwaltungsarbeiten sind Grund für den Hacker, ein Programm zu schreiben, das diese Unwägbarkeiten automatisch ausräumt oder übernimmt. Not macht erfinderisch.

"Every good work of software starts by scratching a developer's personal itch." - Eric Raymond

Die zweite Möglichkeit für die Idee einer neuen freien Software bieten ihre proprietären Gegenstücke. Oft entdeckt ein Programmierer eine Software auf einem Windows- oder Mac-System, die er gerne auch auf dem von ihm favorisierten Betriebssystem nutzen möchte. Dort baut er sie in seiner Freizeit einfach nach.

5.2.2 Die erste Version

Beginnt der Entwickler mit einem völlig neuen Programm, so wird ein erstes Design ausgeklügelt, welches die folgende Arbeit massiv beinflussen wird, denn Design hat eine sehr hohe Priorität und muß deshalb genau überdacht werden. Der Programmierer kann aber auch als Basis eine fremde freie Software nehmen, die in etwa oder zum Teil sein Problem löst. Er entscheidet, was er davon benutzt, was herausgenommen und was erweitert oder verändert werden soll. Aber auch hier steht das Design an oberer oder oberster Stelle.

"It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode." - Eric Raymond

Eine solche erste Vorabversion ist immer noch die Entwicklung eines einzelnen oder einer kleinen Gruppe und hat somit noch nicht das Stadium der verteilten, gemeinschaftlichen Arbeit erreicht. Sie ist häufig instabil, unvollständig und schlecht dokumentiert, läßt aber schon eine klare Struktur erkennen, die durch das Design geformt wurde. Die Reife und Komplexität einer ersten Version beeinflußt den Erfolg der Folgeversionen. Ist sie zu mager, könnten sich hinzugewonnene Programmierer, wenn überhaupt, mehr auf das Fehlerbeheben statt auf Erweiterungen konzentrieren. Andererseits kann eine zu komplexe erste Version weniger versierte Entwickler abschrecken.

Hat der Schöpfer sich für einen Mittelweg entschieden, so kann er sein Werk in einer Newsgroup ankündigen und es im Internet zum Herunterladen bereitstellen, so daß jeder ambitionierte Hacker es studieren kann.

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