FS-Praxis (was: Re: [ox] Zum Begriff der Herrschaft)
- From: Stefan Merten <smerten oekonux.de>
- Date: Mon, 25 Nov 2002 22:00:17 +0100
Hi Stefans (sic! ;-) )!
2 weeks (17 days) ago Stefan Seefeld wrote:
hmm, ich mache mir dar"uber nat"urlich Gedanken, insbesondere da es mich
pers"onlich betrifft (ich bin selbst 'leader' mehrerer Projekte...),
aber eine definitive Antwort habe ich nicht. Deshalb f"allt meine mail
auch ein bischen Stichpunkt-artig aus. Sorry.
Eine meiner älteren Lernerfahrungen ist, dass es oft sinnvoll ist,
erst halbvergorene Gedanken zu präsentieren. Das hat für die anderen
den Vorteil, dass sie sich noch leichter eindenken können, weil sie
nicht sofort mit einem fertigen Gebäude konfrontiert werden. Und
natürlich ist bei einem Rohentwurf auch noch leichter was
grundsätzlich anders zu machen.
Für mich hat es den Vorteil, dass ich noch nicht in meinem fertigen
Gebäude sitze, das ich dann tendenziell verteidigen will.
Allerdings braucht es für solche halbvergorenen Gedanken ein offenes,
akzeptierendes und interessiertes Klima. Halbvergorenes hat ja gerade
als Eigenschaft, dass es noch nicht fertig ist. Deswegen ist es
tendenziell leicht angreifbar. Dass das hemmungslos "ausgenutzt" wird,
ist allerdings ein Effekt, der unter Linken allzuoft zu beobachten ist
:-( . Leider werden mit solchen Angriffen tendenziell neue, gute
Ansätze zerstört.
Jedenfalls finde ich eine der Stärken von Oekonux, dass Halbvergorenes
in aller Regel positiv aufgegriffen wird und mit ein bisschen Glück
ein gemeinsamer Denkprozess entsteht. Das ist in der
Software-Entwicklung nach meiner Erfahrung oftmals ähnlich.
Aber zur"uck zur spezifischen Dynamik offener Projekte. Ich denke,
es ist schon falsch von *einer* Dynamik zu sprechen. Vieles h"angt von
verschiedenen Faktoren ab, die die Projektkultur erheblich beeinflussen.
Es macht einen riesigen Unterschied, ob da zum zigsten Mal ein IRC
client entwickelt wird, oder ob es da um echtes Neuland geht.
Klingt erstmal plausibel. Wenn die Blaupause von woher auch immer
schon vorliegt, dann sind die Grenzen einer Entwicklung durch die
Blaupause ja schon mal erheblich bestimmt. Prominentes Beispiel
dürften die ganzen GNU-Basis-Programme sein, die vor allem
Standard-Unix-Kommandos nachprogrammiert haben (und sie dabei heftig
überflügelt haben :-) ).
Auch
spielen Faktoren wie die Programmiersprache(n) etc. eine Rolle, die ja
ihrerseits schon eine Menge Entwicklungskultur verk"orpern.
Ich sage immer: "Software-Entwicklung ist (vor allem) ein sozialer
Prozess" und "Echte Programmierer schreiben in jeder
Programmiersprache Fortran-Programme". Ich würde von daher dem
sozialen Prozess hier deutlich mehr Gewicht einräumen als der
Programmiersprache.
Was bedeutet es, ein Projekt zu leiten ? Heisst das, alle wichtigen
Entscheidungen zu treffen ? Subprojekte an Leute zu verteilen ?
Wichtiger als die Frage, wie ich den Begriff der Leitung genau
verstehen will, wäre für mich die Frage was da konkret getan wird. Ich
denke es ist darauf zu reduzieren, dass Entscheidungen getroffen
werden. Wie diese Entscheidungen getroffen und umgesetzt werden ist
der Kern der Frage nach der Herrschaftsform (i.S. des systematischen
Soziologen).
ESR hat sicher recht, wenn er meint, ein wichtiger Faktor der zum Erfolg
Offener Software beitr"agt, ist die Transparenz, die Leuten erlaubt (und
sie ermutigt) sich den Quellcode anzuschauen, und auszuprobieren. Das
Stichwort ist 'peer review'.
Das setzt freien Zugriff auf den Quellcode voraus, braucht aber mehr.
Es bedeutet dass ich (der Programmierer) mir besondere M"uhe gebe, den
code lesbar zu gestalten, zu dokumentieren, etc.
Sehr wichtig! Sauberer Programmierstil ist wichtig. Überhaupt ein
gewisser Stil, damit ich nicht in jeder Quellzeile neu über die gerade
verwendete Technik nachdenken muss. Dokumentation. Sprechende
Variablennamen. Etc.
Indem ich das mache, erm"achtige (!) ich meine peers, sich getreu den
Grundprinzipien der GPL zu beteiligen: Teilen, Ver"andern, Verbessern.
Yep.
Aber interessant wird es, wenn es sich eben nicht um 'prior art'
handelt, d.h. wenn man den Fortschritt nicht sich selbst "uberlassen
kann, also wenn ein Entwicklungsprozess bewusst befolgt werden muss. Da
kommt dann auch wieder 'Macht' ins Spiel.
Mir kommt hier das Wort "Vision" in den Sinn. Ich glaube viele
neuartige Software, die gut ist, hat solch eine Vision im Hintergrund.
I.a. wird diese Vision von der MaintainerIn ausgehen. Leider haben
Visionen den Nachteil, dass sie nur begrenzt vermittelbar sind :-( .
Zudem schälen sie sich nach meiner Erfahrung oft erst langsam aus dem
Nebel.
Das geht mit 'write access' los, und h"ort mit code und design review
lange noch nicht auf. Ist es Macht, wenn ich einen patch nicht
akzeptiere ?
Klar ist es Macht. Genauso wie es Macht ist, einen Patch
einzuschicken.
Worin besteht mein Interesse, diese Macht auszu"uben ?
Im Erreichen der Projektziele würde ich meinen. Bei neuen Projekten:
Annäherung an die Vision.
Oft wird das 'right to fork' beschworen, um darauf hinzuweisen, dass
je jeder, dem etwas nicht passt, einen clone des Projektes weiterf"uhren
kann. Das stimmt, ist aber nur oberfl"achlich betrachtet wahr:
ein Projekt ist viel mehr als nur der Quellcode. Ich kann nat"urlich
code kopieren so viel ich will, neue Projekte gr"unden so oft ich will
(und http://www.sf.net liefert daf"ur ein beeindruckendes Beispiel),
aber das Entwicklungsteam mitsamt deren Dynamik und 'man power' kann
ich nicht klonen.
Hier würde ich unterscheiden. Natürlich kann das Projekt nicht geklont
werden wie die Sourcen beliebig oft digital kopiert werden können.
Aber m.E. ist das eine ganz andere Frage. Deine Argumentation läuft
darauf hinaus, dass quasi auch die Erfolgsgrundlage - nämlich der bis
dahin gelaufene soziale Prozess - mit in einen Fork kopiert werden
kann. Das ist aber ein Anspruch, den ich ziemlich überzogen finde.
Aber, wo ich jetzt so drüber nachdenke: In der Tat sind
funktionierende soziale Prozesse zu einem gegebenen Zeitpunkt nur
begrenzt verfügbar. Diese Grenze zu verändern bedarf es eben mehr,
als ein `cp'.
D.h. um erfolgreich meinen eigenen branch eines Projektes
weiterzuentwickeln, muss ich Leute davon "uberzeugen, dass meine
alternativen Vorstellungen besser sind als die originalen.
(da es hier um Macht geht, will ich mal von den Projekt-internen
Diskussionen absehen, die zu L"osungen innerhalb des Projektes, d.h.
ohne einen fork, f"uhren)
Ja. Wann gelingt das? Wenn du vermitteln kannst, dass deine Vorschläge
im Interesse des Projekts liegen, so wie es von wichtigen Leuten
wahrgenommen wird.
Und darin liegt wahrscheinlich auch der Grund, dass es nicht zu mehr
forks kommt.
Somit ist ein Aspekt der 'Macht', Leute um eine Projektidee herum
anzusammeln, und zu vermeiden, dass sie sich verstreuen.
Sch"on dabei ist, dass als Machtinstrument im Wesentlichen nur die
bessere (popul"arere ?) Idee in Frage kommt, bzw. Popularit"at an sich.
Ich finde populär trifft es nicht richtig. "Gut" ist da schon ein
gutes Wort. Dazu kommt die Vermittlungskompetenz und das Erspüren des
"Projektinteresses" - d.h. des Interessenkonglomerats, das die Leute
an das Projekt bindet. Andernmails beschreibe ich das als
Gruppenstandpunktswolke.
Aber zur"uck zu der Frage nach der inneren Entwicklungsdynamik:
w"ahrend ESR auf Selbstorganisation beharrt und schlicht auf Quantit"at
vertraut (das ist zugegebenermassen sehr stark vereinfacht...) streicht
Frederick Brooks heraus, wie wichtig Konsistenz und Klarheit sind -
Dinge, die seiner Meinung nach besser in einer Oligarchie zu finden
sind. (Witzigerweise benutzt er als Beispiel den Bau einer Kathedrale,
der sich "uber mehrere Generationen von Bauarbeitern und Architekten
erstreckt, und doch oft beeindruckend konsistent ist).
Dort wird also explizit einzelnen Personen Entscheidungsgewalt gegeben
("viele K"oche verderben den Brei").
Beide Erfahrungen kann ich best"atigen !
Die Oligarchie - oder genauer: die formale Autorität / Hierarchie -
bewirkt, dass eine Vision durchgesetzt wird. Ich glaube aber, dass es
bei großen Kreativprojekten wichtig ist, dass die Vision zumindest
überwiegend gemeinsam entwickelt wird. Durchsetzung mit formaler
Autorität schneidet Kreativität ab. Was am Fließband "nötig" war ist
bei KreativarbeiterInnen tödlich.
Es gibt allerdings das Problem, dass es StörerInnen geben kann, die
nicht oder nicht immer zu der Vision beitragen, aber sehr lautstark
sind. Meine wiederholte Erfahrung ist, dass ständige Störungen ein
Projekt nachhaltig zer-stören können. Was kann hier helfen?
Ich stosse oft Leute vor den Kopf, wenn ich scheinbar restriktiv bin
mit der Vergabe von 'write permissions', oder wenn ich erwarte, dass
sich potentielle Entwickler erstmal gr"undlich mit der bestehenden
Architektur auseinandersetzen, bevor sie Ver"anderungsvorschl"age
machen.
Mir scheint du deutest das Störungsproblem auch an.
Auf der anderen Seite bekommt das Projekt oft sehr positive Kommentare
bzgl. seiner Architektur, da es sehr klar und 'well designed' ist, ein
Aspekt, der - hoffe ich - so einem Projekt ein langes Leben beschert.
Anzunehmen :-) .
http://synopsis.sf.net
Das muss ich mir direkt mal anschauen. Allerdings ist
Source-Dokumentation für meine Zwecke zu wenig.
2 weeks (14 days) ago Stefan Meretz wrote:
On Friday 08 November 2002 17:01, Stefan Seefeld wrote:
Aber zur"uck zur spezifischen Dynamik offener Projekte. Ich denke,
es ist schon falsch von *einer* Dynamik zu sprechen. Vieles h"angt von
verschiedenen Faktoren ab, die die Projektkultur erheblich
beeinflussen.
Ja, das sehen wir auch hier bei Ox, obwohl es nicht um auf Maschinen,
sondern nur um in Gebäuden (wie der TU Berlin) lauffähigen "Codes"
geht;-)
Kannst du laut sagen...
w"ahrend ESR auf Selbstorganisation beharrt und schlicht auf Quantit"at
vertraut (das ist zugegebenermassen sehr stark vereinfacht...) streicht
Frederick Brooks heraus, wie wichtig Konsistenz und Klarheit sind -
Das sind IMHO keine Gegensätze. Die Frage ist nicht, ob Konsistenz und
Klarheit, sondern _wie_ man da hin kommt! Und da halte ich den Weg der
Selbstorganisation den produktiveren.
Was eigentlich meinst du genau mit Selbstorganisation? Vielleicht ein
paar Gegensatzpaare? Warum ist die Arbeit in einer (formalen)
Hierarchie eigentlich nicht selbstorganisiert? Eine solche Hierarchie
organisiert sich ja schon auch irgendwie selbst - oder?
Ich meine die Frage nicht rhetorisch, sondern bin wirklich mal an
einer Schärfung des Begriffs interessiert - wenn möglich.
StefanS hatte die Frage zur Selbstorganisation auch schon gestellt:
Last week (13 days ago) Stefan Seefeld wrote:
hmm, 'Selbstorganisation' ist vielleicht ein bischen idealisiert "uber
die Jahre. Was heisst es denn in diesem Kontext, sich eine Sache sich
selbst zu "uberlassen ? Also etwa, ist dabei bewusstes Handeln aus- oder
eingeschlossen ? In wiefern kann ich noch von Selbstorganisation sprechen,
wenn ich (selbst :-) ) organisierend eingreife ?
Was ist 'innen' und was 'aussen' ?
Weiter mit StefanMz's Mail.
Dinge, die seiner Meinung nach besser in einer Oligarchie zu finden
sind. (Witzigerweise benutzt er als Beispiel den Bau einer Kathedrale,
der sich "uber mehrere Generationen von Bauarbeitern und Architekten
erstreckt, und doch oft beeindruckend konsistent ist).
Dort wird also explizit einzelnen Personen Entscheidungsgewalt gegeben
("viele K"oche verderben den Brei").
Viele Köche können den Brei verderben, aber ein engstirniger Koch, der die
neuen Rezepte nicht kennt, kann ein ungenießbares Essen produzieren.
Zusammengefasst: Die Anzahl der Köche spielt nicht die entscheidende
Rolle.
Die
Frage ist also: Wie akkumulieren wir Qualität?
Das ist die entscheidende Frage - auch und vor allem im Sinne der
andernmails angedeuteten Produktivkraftentwicklung.
Wie ist dieser
Akkumulationsprozess organisiert, so dass viele sich einbringen können?
Diese Frage ist zunächst mal unabhängig von der Akkumulation von
Qualität. Die Antwort auf die Frage nach der Akkumulation kann -
theoretisch - ja auch lauten, dass alle in ihrem stillen Kämmerlein
und alleine vor sich hin wirken.
Ich bin nicht immer sicher, das die Beteiligung Vieler der
Qualitätsakkumulation hilft.
Ein Keyfaktor scheint mir "Vertrauen" zu sein. Vertrauen ist nun gerade
etwas, was man nicht anordnen oder strukturell einfach festlegen kann,
sondern es ist ein Resultat der Praxis. Und da gibt es keinen
one-best-way.
Vertrauen ist in sozialen Prozessen eine wichtige Größe. Dieses
Vertrauen besteht in verschiedene Gegebenheiten. In Leute, aber auch -
über Leute vermittelt - in die Verlässlichkeit von Prozessen. Wenn ich
permanent darum bangen muss, dass ein bestimmter, mir vertrauter
Prozess mir nichts, dir nichts abgewürgt wird, dann muss ich anfangen
private Sicherungsmaßnahmen zu ergreifen. Und das ist der Beginn von
Entfremdung und das Ende von Gemeinsamkeit und damit auch der
gemeinsamen Qualitätsakkumulation. Kontinuität ist für mich daher
wichtig - was natürlich nicht Stillstand heißt.
Mit Freien Grüßen
Stefan
________________________________
Web-Site: http://www.oekonux.de/
Organisation: projekt oekonux.de