[ox-de] Alan Cox über Software Engineering
- From: Stefan Meretz <stefan.meretz hbv.org>
- Date: Mon, 31 Jul 2006 14:04:20 +0200
Hi all,
in einem Vortrag hat sich Alan Cox (Linux Kernel-Hacker) mit
Unterschieden bei der Entwicklung freier und proprietärer
Software-Entwicklung beschäftigt.
Hier der Audio-Mitschnitt (54 MB, 1:19h):
http://bigbro.skynet.ie/resources/ogg/AlanCox_UL_20060513.ogg
In der Diskussion äußert er sich auch zum Entwurf der GPL V3, vgl. dazu
http://fsfe.org/en/fellows/ciaran/weblog/alan_cox_5_minutes_on_gplv3_plus_comments
Aber Thema dieser Mail ist eine Zusammenfassung des Vortrages, soweit
ich das verstehen konnte (Alan Cox spricht sehr schnell und nuschelig).
Zentrale Stichworte in seinem Vortrag waren Kommunikation,
Persönlichkeit und Modularisierung bzw. Vereinfachung. Er berichtet aus
seiner Erfahrung, dass es sehr schwer sei, in einem Unternehmen
jenseits der Hierarchien (der "Linie") zu kommunizieren. Wenn ein Stück
Software, auf das man aufbaue, nicht funktioniere, dann ist der normale
Weg, über die Linie eine "Anfrage" zu stellen. Bis die Antwort
eintrifft, kann es lange dauern. Bei Freier Software hingegen gäbe es
diese Kommunikationsbarrieren nicht, hier würde man einfach den
Entwickler auf der anderen Seite der Erde ansprechen und schnell eine
Antwort bekommen. Das sei zwar auch in Unternehmen möglich und
funktioniert auch, aber dann bekäme man schnell Ärger mit den
Vorgesetzten, die sich übergangen fühlen. [Kommentar: Ich bin mir nicht
sicher, ob die hier angesprochene taylorische Arbeitsorganisation noch
vorherrschend ist oder ob nicht inzwischen flache Hierarchien und
direkte Kommunikation das Bild in der Mehrheit der Unternehmen
bestimmen. Hat dazu jemand eine Einschätzung?]
Die Persönlichkeit des Maintainers in einem freien Softwareprojekt ist
ein herausragendes Merkmal. Viele (nicht alle) Projekte haben
charismatische "Projekt-Leader", die das Image des Projektes verkörpern.
Es gibt auch in Freien Softwareprojekten Hierarchien oder besser:
Aufgabenteilungen, die Kommunikation läuft jedoch im Gegensatz zur
proprietären Software immer direkt und nicht vermittelt über
Hierarchien. Zentraler Ort ist die Mailingliste. Das bedeutet jedoch,
dass jeder Entwickler selbst seine Arbeitsbedingungen organisieren muss
(etwa sich Tools zu verschaffen, um der Kommunikation über die Listen
zielgerichtet folgen zu können).
Sozialer Status spielt in proprietärer und Freier Software ein völlig
unterschiediche Rolle. In prop. Software ist der Status an die
betriebliche Funktion gebunden. Manager und ein Zuarbeiter seien nicht
nur unterschiedliche Rollen, sondern dem entsprechen wirklich auch
unterschiedliche Personen. In Freier Software ist es nicht
ungewöhnlich, wenn ein Leiter eines Projektes in einem anderen Projekt
die Rolle eines "Zuarbeiters" hätte - sozialer Status spielt hier keine
abgrenzende Rolle. So etwas gäbe es in proprietärer Software nicht.
Freie Software ist im Gegensatz zur proprietären Software nicht
marketinggetrieben, sondern problem- bzw. bedürfnisgetrieben: Jemand
hat ein Problem und löst es. Bei proprietärer Software steht oft das
Marketing und die Defintion der Leistungen am Anfang, bei Freier
Software entwickeln diese sich schrittweise mit den Anforderungen der
Benutzer und Entwickler. Deswegen gilt generell: "free software is
late". Freie Software erscheint immer zu spät, weil es in Freier
Software auch kein "fertig" gibt - sie entwickelt sich immer
weiter. "Marketing" hat bei Freier Software eine andere Funktion,
nämlich weitere Entwickler zu gewinnen, um die Programmierung
voranzubringen.
Ein großer Teil der Anforderungen kommt aus der globalen Tendenz zur
Modularisierung und Vereinfachung bei Freier Software. Wenn ein Projekt
wächst und weitere Entwickler hinzukommen, entsteht ein hoher Bedarf an
Modularität und Einfachheit der Interfaces. Wachsende Projekte teilen
sich in Unterprojekte auf. Die emprisch am häufigste beobachtete
(angenommene optimale) Größe ist 6 Entwickler. Wenn Schnittstellen zu
komplex werden, dann weigern sich viele Entwickler diese trotz
teilweise genauer Dokumentation (Zitat: "Entwickler lesen keine
Dokumentation") zu benutzen. Stattdessen wird die Funktion neu und
einfacher implementiert. Da proprietäre Software unter einem "Dach" mit
einheitlicher Leitung entstehe, sei der Modularisierungsdruck erstmal
nicht vorhanden, weil Skalierung hier durch weitere Einbeziehung von
Projektmitarbeitern umgesetzt wird (mit allen Problemen: vgl.
http://en.wikipedia.org/wiki/Brooks_Law). In Freier Software ist
Modularisierung hingegen die Voraussetzung für Skalierung und
Kommunikation.
Code-Wiederverwendung in proprietärer Software werde per Definition
gesetzt und entsteht nicht - wie bei Freier Software - aus dem
evolutionären Prozess. Das hat Vor- und Nachteile. Code-Wiederverwendung
in Freier Software ist Copy und Paste. Das sei einerseits ok, aber
andererseits wirft das Probleme auf. Erstens sei es zentral wichtig,
das "Beispielcode" stimmen muss, weil der erfahrungsgemäß häufig
einfach kopiert und modifiert werde. Statt abstrakten Beispielcode
anzugeben ("so verwende ich das Modul x"), sollte der Beispielcode aus
realen Applikationen stammen und sich somit im Einsatz bewährt haben.
Zweites Problem sei die fehlende Nachverfolgbarkeit des per C&P
wiederverwendeten Codes. Wenn ein Bug entdeckt werde, sei es sehr
schwierig, die Orte der weiteren Verwendung zu finden, um zu prüfen, ob
der Bug sich dort auch auswirkt. Auch hier wieder ist breite und
transparente Kommunikation zentral. Ferner gilt, dass schlechter Code
in Freier Software schlicht sichtbar sei, was bei proprietärer Software
nicht der Fall ist. Die Code-Qualität steht unter permanenter
Beobachtung und Kritik bereits während des Entwicklungsprozesses,
während bei proprietärer Software Code-Qualität eine zusätzliche und
nachgelagerte Anforderung sei. Das bedeutet jedoch nicht, dass FS immer
gute Code-Qualität und proprietäre Software immer schlechte
Code-Qualität hätte - es handelt sich nur um in unterschiedlichen
inneren Dynamiken und Prioritäten gründende Tendenzaussagen.
Ergänzungen und Korrekturen willkommen!
Ciao,
Stefan
--
Start here: www.meretz.de
________________________________
Web-Site: http://www.oekonux.de/
Organisation: http://www.oekonux.de/projekt/
Kontakt: projekt oekonux.de