Von Meistern und Sklaven? (was: Re: [ox] Zum Begriff der Herrschaft)
- From: Stefan Merten <smerten oekonux.de>
- Date: Mon, 25 Nov 2002 00:23:03 +0100
Hi Max und Liste!
2 weeks (17 days) ago Max J Werner wrote:
Hallo Stefan (mn) und alle anderen die vor grauen Urzeiten (im September
wars) sich hier mal mit dem Herrschaftsbegriff in Freier Software
Produktion herumgeplagt haben!
Dazu muss ich natürlich auch meinen Senf geben:
Welcome :-) .
Unter http://linuxwiki.de/MaxWerner/MyWritings/VonMeisternUndSklaven
findet sich eine Abhandlung des Themas (da der Text etwas länglich ist,
weiß ich nicht, ob es gut wäre, ihn hier zu posten. Ihr könnt mich bitte
eines Besseren belehren :-).
Ich zitiere mal und schreibe gleich meine Kommentare dazwischen.
Von Meistern und Sklaven
Die Gegenüberstellung finde ich nicht ganz passend. MeisterInnen haben
keine SklavInnen sondern Lehrlinge. SklavInnen haben keine
MeisterInnen sondern HerrInnen. Während ich den ersten Begriff noch
relativ passend finde, finde ich SklavInnen doch ziemlich daneben. Der
Begriff der MeisterIn deutet in der Tat auf den Begriff der Elite hin.
Ich bin jetzt bereits seit einigen Jahren ein sehr großer Anhänger der
Open-Source-Programmierung und versuche oft, den Gedanken, den diese
Arbeitsweise mit sich bringt, zu verbreiten und zu unterstützen.
Na, dann bist du hier richtig :-) .
Die
Open-Source-Programmierer propagieren diese Arbeitsweise mit Phrasen
wie "Freiheit der Entwickler", "Freiheit der Anwender" und
"Patentfreies Programmieren".
Ich denke, dass es mehr als Phrasen sind. Die Freiheit der
EntwicklerInnen besteht - zumindest bei Doppelt Freier Software -
gerade darin, dass kein Markt, keinE KundIn, keinE AuftraggeberIn den
EntwicklerInnen reinredet. Diese Freiheit ist bei proprietärer
Software und kommerzieller Freier Software nicht gegeben. Diesen
Faktor der Doppelt Freien Software finden wir hier dabei ziemlich
erheblich, da er auf die Selbstentfaltung der EntwicklerInnen
hindeutet, die nach einer hier verbreiteten Meinung das zentrale
Element des nächsten paradigmatischen Schritts der
Produktivkraftentwicklung ist.
Die Freiheit der AnwenderInnen sehe ich nicht so gefährdet, aber das
ist ja auch nicht dein Thema.
Genau das ist auch ganz meiner Meinung, jedoch haben mich einige
Artikel im Internet und in Zeitungen stutzig und nachdenklich gemacht.
Ich musste mir Gedanken darüber machen, inwieweit diese Freiheiten
nicht selten durch die Entwickler selber beschnitten werden.
D.h. es geht um das Innenverhältnis in Freie-Software-Projekten. Ok.
Wenn ein Projekt gestartet wird, ist das meistens das Ergebnis der
Arbeit von einigen wenigen Leuten (oft auch nur einer Person).
Ja. Wichtig hier: Diese InitiatorInnen eines Projekts haben so viel
Interesse an dem Projekt, dass sie es implementieren. Ich kann's nicht
theoretisch fassen, aber für mich besteht da gefühlsmäßig schon
irgendwie ein Unterschied zu denen, die später irgendwann mal einen
schlampigen Patch oder einen absurden Wunsch einsenden - um mal den
anderen Extrempunkt zu skizzieren.
Diese
Leute stellen das Projekt dann ins Internet und lassen andere
Entwickler an dem Projekt teilhaben. Es entsteht ein Entwickler-Team,
das sich, meistens über eine Mailing-Liste, organisiert, Vorschläge
für Verbesserungen berät und Fehler im Programm bespricht und
entfernt.
Ich bin nicht sicher, dass sich immer ein Entwickler-Team ausbildet.
Widerspricht meiner persönlichen Erfahrung. Aber das wäre eine
interessante Untersuchung, inwieweit das wirklich passiert.
Diese Gemeinde organisiert sich frei von konventionellen
Entwickler-Teams, denen meistens ein Chef-Programmierer übersteht, der
die Leitung übernimmt.
Nun bin ich ja auch beruflich ziemlich heftig mit Software-Entwicklung
befasst und von meiner Aufgabenstellung her habe ich mir auch in einem
wichtigen Teilbereich des Projekts so etwas wie eine leitende Stellung
erarbeitet - wenn auch nicht formal. Meine Erfahrung hier ist die,
dass es für maximal viel Running Code keinen großen Unterschied macht,
ob ein Software-Projekt Frei oder proprietär ist was die Form der
Leitung betrifft: In beiden Fällen geht es darum, maximale Zustimmung
zu konzeptionellen Vorschlägen zu bekommen. Ist diese Zustimmung nicht
gegeben, so verlassen die Leute Freie-Software-Projekte während sie
bei proprietärer Entwicklung anfangen, sich auf alle möglichen Arten
zu verweigern. Letzteres ist oft schlimmer, als wenn sie einfach gehen
könnten :-( ... Bei manchen "Features" kann ich den Namen nennen, um
die es ein Workaround ist...
Diese Zustimmung beruht in beiden Varianten m.E. auf ganz ähnlichen
Gegebenheiten. Eine davon ist, dass das Interesse an einer positiven
Entwicklung des Gesamtprojekts bei jedem Vorschlag erkennbar sein
muss. Logisch: Was erkennbar dem Gesamtprojekt schadet, kann nicht mit
Zustimmung rechnen - höchstens bei denen, die sich sowieso schon
verweigern. Dies wäre die technische Seite und hat auch ein bisschen
was mit dem Meister zu tun, den du oben erwähntest.
Die soziale Seite besteht m.E. u.a. darin, möglichst gerecht zu
handeln. Es ist klar, dass in einem Software-Projekt immer Konflikte
auftreten. In der bei mir vorliegenden Variante geht das oft so: "Ich
habe meinen Code aber jetzt so und ich kann [d.h. oft: will] ihn nicht
mehr ändern. Deswegen muss dies und jenes so und so gemacht werden /
alles bleiben wie es ist." Solche Haltung endet natürlich schnell im
Konflikt. Wie jetzt verhalten, um dennoch eine möglichst gute Lösung
möglichst zu erreichen (d.h. manchmal leider auch: durchzusetzen)?
Machtmittel habe ich in meiner Position fast keine, also bleibt nur
das Argument, zuweilen gutes Zureden und eben: Gerechtigkeit. Wenn ich
anfange ungerecht zu werden, dann habe ich sofort einen Teil des
Projekts gegen mich aufgebracht und die Lösung des Problems ist damit
in weite Ferne gerückt...
Nach meiner Wahrnehmung hängt diese Ähnlichkeit damit zusammen, dass
die Produktivkraftentwicklung allgemein zu dieser Form von Leitung
drängt. Das simple, rückkopplungsfreie Kommando hat auf dem heutigen
Stand der Produktivkräfte schlicht und ergreifend ausgedient, weil du
KreativarbeiterInnen aller Art eben vernünftigerweise keine Kommandos
erteilen kannst, sondern letztlich mit ihnen zusammen eine möglichst
gute Lösung von Sachproblemen erarbeiten musst. Allerdings stößt
dieses Vorgehen bei proprietärer, aber auch kommerzieller Freier
Entwicklung an die dewm Projekt äußerliche, nichtdestoweniger aber
harte Grenze des Verwertungszwangs.
*Dies* ist m.E. auch der tiefste Grund dafür, dass die Freie Software
keimförmig erstmals auf hohem Niveau aus der alten Produktivkraftlogik
ausbricht und das Tor zu einer Produktivkraftlogik aufstößt, die -
beim heutigen Stand der Produktivkräfte - die Leistungsfähigere ist
(d.h. bessere Produkte liefert), während sie gleichzeitig sich im
Widerspruch zu den alten Produktivkraftverhältnissen befindet (aka
Verwertungszwang). Dieser Widerspruch drängt nach Auflösung und diese
Auflösung zu verstehen, denkend zu begleiten und - wenn uns das
vergönnt ist - ein bisschen zu befördern, ist für mich eines der
tiefsten Anliegen von Oekonux.
Oh, ich schwiff ab ;-) .
Doch diese "freie" Gemeinde ist nicht so frei,
wie es auf den ersten Blick scheint und es kommen wieder die
konventionellen Methoden zum Vorschein, wie sie schon seit Jahrzehnten
in der Software-Branche bekannt sind. Die sogenannten Maintainer des
Projekts (die die es initiiert haben und leiten) sind Götter, sie
bestimmen darüber, welcher Patch in das Programm aufgenommen wird und
wie die Entwicklung weiter verläuft.
Götter kommunizieren nicht mit Menschen - oder zumindest höchst
einseitig. Die Aufgabe einer MaintainerIn ist aber m.E. gerade die der
Kommunikation. EinE MaintainerIn, die nicht zuhört, wird bald ohne
Gemeinde dastehen - meinst du nicht? Also Götter trifft es m.E. nicht
wirklich.
Sie haben die Macht darüber, was
mit dem Programm später geschieht. Im schlimmsten Fall können sie das
Programm sogar unter eine proprietäre Lizenz stellen und es als
Closed-Source-Projekt weiterführen, und die jetzt doch nicht so freien
Entwickler haben das Nachsehen.
Das ist spätestens dann nicht mehr der Fall, wenn sich Patches von
anderen in dem Programm befinden - zumindest geht das dann nicht so
ohne weiteres.
Aber ich glaube auch nicht, dass das dein Hauptproblem ist.
Der schlimmste Auswuchs dieses Meister-Sklaven-Modells ist die
Entwicklung des Linux-Kernels, deren Richtung zu hundert Prozent in
der Hand des Initiators liegt, Linus Torvalds.
Das ist nicht ganz richtig. Es gab (gibt?) von Alan Cox z.B. parallele
Kernel und die Entwicklung der Anwender-Kernel liegt inzwischen nicht
mehr bei Linus.
Tagtäglich werden ihm
dutzende von Patches, Fehlermeldungen und Vorschläge zur Verbesserung
des Programms zugesandt, von denen (vor allem den Patches) nicht mal
die Hälfte von ihm gelesen wird.
Dieses Problem ist unter "Linus skaliert nicht" bekannt. Abhilfe, die
es ja teilweise schon gibt, bestünde darin, hier mehr Arbeitsteilung
einzuführen. Dadurch wäre das MaintainerInnen-Prinzip nicht
grundssätzlich in Frage gestellt, aber der Überlastungsfaktor wäre
gemindert.
Aber mal andersherum gefragt: Wäre einE MaintainerIn, die alle Patches
lesen *muss* nicht auch eine (Patch-)SklavIn?
Selbstentfaltung muss auf beiden / allen Seiten da sein. Dazwischen
kann es eine Spannung geben. Dein Unbehagen drängt tendenziell dazu,
diese Spannung zu Gunsten einer Seite bzw. auf Kosten der anderen
Seite aufzulösen. Das kann's m.E. nicht sein.
In einer FAQ zur
Linux-Kernel-Mailingliste wird geraten, Patches mehrmals an Linus zu
senden, weil viele von ihnen einfach ohne Worte in den Tiefen von
/dev/null verschwinden.
Was irgendwie ein blöder Tipp ist, weil es die Last noch mehr erhöht.
Man erhält nicht einmal eine Antwort von
Linus, dass der zugesandte Vorschlag von ihm nicht akzeptiert wurde,
Hier kommt der Aspekt, den ich andernmails als das Gefühl Einfluss zu
haben beschrieben habe. Mein Eindruck ist, dass dies die tiefere
Quelle deines Unbehagens ist: Der Einfluss der Patch-EinsenderInnen
ist nicht spürbar. Wie andernmails angedeutet ist das m.E. in der Tat
ein Hinweis auf Entfremdung.
womit wir zur Gefahr dieses Modells kommen: Wer am Projekt mitarbeiten
will, der muss sich anpassen, der muss so handeln, wie der Meister es
will. Wenn man Pech hat, hat man absolut keinen Einfluss darauf, was
mit dem Projekt passiert.
Ah, du sagst es selbst :-) .
Siehst du aber auch, dass es hier auch ein praktisches Problem gibt?
Nicht jedeR kann Einfluss auf ein solches Projekt haben in dem Sinne
dass jeder Patch einfach integriert wird. Wäre das so, dann wäre der
Running Code bald im Eimer und die MaintainerIn kann auch einpacken.
Hier kommt zur Spannung zwischen zwei Selbstentfaltungen auch noch die
Spannung zwischen der menschlichen Selbstentfaltung und der Sachebene
dazu.
Die Freiheit der Entwickler hört da auf, wo
der Master es will.
Das finde ich ein bisschen steil. Mal abgesehen von der mangelnden
Kommunikation - die ich auch problematisch finde - wird hier lediglich
die Freiheit beschnitten, dass ein bestimmter Patch auch garantiert
berücksichtigt wird oder gar ins Endprodukt kommt. Wenn du so willst,
wird hier Willkür beschnitten. Dies halte ich nicht nur für legitim,
sondern im sachlichen Interesse des Gesamtprojekts sogar für
notwendig. EinE Patch-SklavIn, die einfach alle Patches integriert
stünde ebenfalls bald ohne HerrInnen da - weil niemensch an ein
kaputtes Projekt Patches sendet.
Ich will keinesfalls gegen die Open-Source-Programmierung sprechen,
aber das, was bei vielen Projekten abläuft, macht mir Sorgen.
Da bleibe ich aufgrund meiner Oekonux-geschwängerten Argumentation
gelassen. Solche Projekte, wo das Innenverhältnis dauerhaft erheblich
gestört ist, werden auf Dauer nicht überleben bzw. von parallelen
Projekten verdrängt werden. Das Produktivkraftmodell basiert nunmal
auf Selbstentfaltung und die ist hier eben nicht mehr gegeben.
BTW: Ein interessantes Beispiel in diesem Zusammenhang scheint mir
immer mehr bei den Distributionen zu erwachsen. Vor Jahren riet ich
wegen der (nicht-Freien) SuSE hier zur Gelassenheit, weil sich nach
der obigen Produktivkraftmodellthese die Freie Variante letztlich
durchsetzen wird. Dies findet nach meiner Wahrnehmung bei SuSE vs.
Debian momentan immer stärker statt. SuSE hat einfach immer mehr das
Problem, dass sie Kapital verwerten müssen, was immer spürbarer auf
Kosten der Qualität geht. Debian hat das Problem nicht - und wird m.E.
auf lange Sicht weiter zulegen.
Ist das wirklich die Freiheit, wie wir sie uns vorstellen?
Gegenfrage: Wie stellst du sie dir denn vor?
Mit Freien Grüßen
Stefan
________________________________
Web-Site: http://www.oekonux.de/
Organisation: projekt oekonux.de