[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Freie Software Projekte - Durchführung/Moti vation
From: |
Christian Selig |
Subject: |
Re: Freie Software Projekte - Durchführung/Moti vation |
Date: |
Thu, 09 May 2002 00:51:38 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.7) Gecko/20011221 |
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