Freie Software Projekte - Durchführung/Moti vation

[Christian Selig]

Hi Volker, hi alle,

Volker Dormeyer wrote:

>   In einer Besprechung hat einer meiner Kollegen zum Thema
>   Projektmanagement und Methoden die Frage eingeworfen, aus welchem
>   Grund so viele mit modernsten Projektmethoden aufgesetzte
>   Software- und IT-Projekte in vielen Unternehmen scheitern, "Open
>   Source" Projekte hingegen mit simpelsten Methoden daher kämen, dazu
>   kaotisch abliefen, jedoch einfach funktionierten?


Nun, dazu gibt es tausend mögliche Gründe, die einem dazu einfallen 
können. Ich werde es mit einer Erklärungsmöglichkeit versuchen, die mir 
in den letzten Jahren meiner jungen beruflichen Tätigkeit begegnet ist.

Viele Firmen haben zuviel Geld.

Das klingt jetzt reduktionistisch, ist aber nicht der Fall.

Die meisten IT-Projekte werden mit Methoden durchgezogen, die vielleicht

für die Konstruktion eines Space-Shuttles angebracht sind, aber nicht 
für Software. Ich habe nichts gegen eine umfassende Analyse, meinetwegen 
mit Pflichtenheft und Design. Manche GNU-Subprojekte (z.B. GNU 
Enterprise) gehen einen halb-halb-Weg zwischen überdachtem Design und 
"einfach gutem" Coding.
Wenn jedoch vier Wochen lang die komplette Software in UML von Leuten 
designt wird, die mit dem zu modellierenden Prozess aufgrund fehlender 
fachlicher (z.B. betriebswirtschaftlicher oder technischer) Kentnisse 
nicht vertraut sind und so die Software nach Fertigstellung nochmal 
redesignt werden muss, dann fließen Unmengen Ressourcen in eine 
Entwicklungsmaschinerie, die die gängigen Methoden der 
Softwareentwicklung als Vorwand für verzögerte Releases benutzt. Mit den 
Fachtermini erschlägt man dann den ahnungslosen Kunden, und er zahlt 
auch gerne die 200.000 Euros für Regressionstests, obwohl er nicht weiß, 
was das ist. Schließlich hat man ja bald eine (In-house-Software), die 
die Konkurrenz nicht hat!

Außerdem werden manchmal Leute IT-Projektleiter, die weder Ahnung von 
der Technik haben noch den Mut, ihre Ahnungslosigkeit zuzugeben und 
somit die Fachleute zu befragen.
Dazu eine kleine Geschichte, stark vereinfacht, ohne Namen, weil ich das 
laut Vertrag nicht darf :-)
Ein Kooperationspartner von einer Firma, für die ich gelegentlich 
Kleinigkeiten unternehme, hatte Angst, ein Rechner könne keine 10.000 
Datensätze pro Sekunde (zu etwa 40 Byte) auf eine Festplatte ablegen und 
im Speicher in einen B-Tree sortieren. Desweiteren wurden 
A/D-Wandlerkarten für mehrere Tausend Mark eingekauft (schlecht 
dokumentiert noch dazu!), obwohl ein aufgebohrtes, selbstgelötetes 
Soundkarten-HW-Design nicht nur billiger, sondern auch wesentlich 
einfacher zu programmieren gewesen wäre.

Was will man da noch sagen?

In der Freien Software existiert einfach ein zu starker 
Ressourcenmangel, als das so etwas passieren könnte. Die Zeit mangelt 
einfach zu sehr für Kommittee-Designs. Wenn der Code dann zu fragil oder 
zu avantgarde für den eingesetzten Zweck ist, sortiert ihn die Evolution 
von alleine aus. Solche Projekte sterben entweder an ihrer mangelnden 
Wartbarkeit und/oder an ihrer Unverständlichkeit für potentielle 
Mitentwickler. Beispiele für ersteres sind BIND oder IIRC sendmail, für 
zweiteres so manches Stück GNOME-Software (ORB für simples 
Projektmanagement? Ts, ts ...)

> Ich selbst denke das Punkte wie "persönliche Interessen",
> "Identifizierung der eigenen Person mit der jeweiligen Tätigkeit" und
> evtl. "Selbstverwirklichung" in einem "Freie Software" Projekt 
> eine große Rolle spielen. Zumindest ist das bei mir in etwa so,
> wenn ich das mal hinterfrage. Motivation, Verantwortungs- und
> Wirgefühl für das jeweilige Ding kommen dann von selbst.
> 
> In sehr vielen Unternehmensprojekten hingegen wird das Personal
> unabhängig von deren Interessen für irgendetwas eingesetzt, was die
> jeweiligen Personen vielleicht gar nicht interessiert. Dadurch baut
> sich meiner Meinung nach schnell eine Stimmung auf, die ein solches
> Projekt negativ beeinflussen kann. Evtl. fühlen sich nur wenige für
> irgendetwas verantwortlich und letztendlich scheitert das Ganze.

Ja, das ist sicher ein weiterer ganz wichtiger Faktor. Allerdings ist 
FS-Projektmanagement auch nicht einfach: Große Projekte brauchen eine 
kritische Masse an ähnlich "gepolten" konstruktivisch befähigten 
Entwicklern, sonst wird nichts draus. Eine hilfreiche Statistik hierzu 
wäre auch eine Anzahl der die letzten Jahre gestarteten FS-Projekte, die 
diese kritische Masse nicht erreicht haben und somit eingegangen sind...

Wenn aber eine FS-Projekt mal abhebt, ist es schwer zu stoppen. Bei 
einem FS-Projekt ab einem gewissen Punkt irgend etwas anderes als ein 
exponentielles Wachstum zu prognostizieren, ist idiotisch ... Und wenn 
es zu viele Entwickler für das Hauptprojekt gibt, werden eben Plugins, 
Bindings und Nebenprojekte geschrieben. Siehe z.B. KDE, Gnome, Apache.

Letztenendes hilft ein bisschen "der alte" Raymond (d.h. ausschließlich 
"Cathedral and the Bazaar"), der Abschnitt "Worse is Better" aus einem 
Papier über LISPs Design, ein bisschen angewandte Systemtheorie (Dörner, 
"Die Logik des Mißlingens"), konstruktives anstelle "kritisches" Denken, 
ein guter Überblick und eine kräftige Portion gesunder Menschenverstand 
weiter.

Ciao, Christian