Message 05632 [Homepage] [Navigation]
Thread: oxdeT05345 Message: 67/91 L8 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

FS-Praxis (was: Re: [ox] Zum Begriff der Herrschaft)



Hi StefanSf,

was mir so einfällt zu deinen Berichten...

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;-)

Es macht einen riesigen Unterschied, ob da zum zigsten Mal ein IRC
client entwickelt wird, oder ob es da um echtes Neuland geht. Auch
spielen Faktoren wie die Programmiersprache(n) etc. eine Rolle, die ja
ihrerseits schon eine Menge Entwicklungskultur verk"orpern.

Was bedeutet es, ein Projekt zu leiten ? Heisst das, alle wichtigen
Entscheidungen zu treffen ? Subprojekte an Leute zu verteilen ?

Leite ich ein Projekt, wenn es maintaine? Also, ist das das gleiche? IMHO 
ist da eine ganze Spanne möglich von "ich entscheide alles und zwar so 
wie ich es für richtig halte" bis "ich entscheide alleine nichts, sondern 
ein Kollektiv von Entscheidern, die wie auch immer bestimmt wurden" bis 
"wir entscheiden erst, wenn keiner mehr widersprechen muss (Konsens)".

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.

Indem ich das mache, erm"achtige (!) ich meine peers, sich getreu den
Grundprinzipien der GPL zu beteiligen: Teilen, Ver"andern, Verbessern.

Ja, das sind alles Voraussetzungen.

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.

Wie sieht ein Prozess aus, der - sozusagen eigenlogisch? - befolgt werden 
_muss_? Das kann doch eigentlich nur etwas sein, was du dir denkst, dass 
in einer systematischen Weise verfolgt werden _sollte_, damit was 
funktionierendes herauskommt. Das sind IMHO vor allem die Pre-Code 
Aktivitäten: Design, Strukturentwurf, Konzepte allgemein.

Leider konnte ich Gregorios Beitrag auf der ox2 nicht hören. Wenn ich es 
richtig gelesen habe, wollte er sich den ganzen SWE-Prozess unter dem 
Blickwinkel Freier Software angucken.

IMHO geht es auch hier um: Transparenz, Transparenz, Transparenz.

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 ? Worin besteht mein Interesse, diese Macht auszu"uben ?

Na, ich nehme an: running code. Wenn du das aber gegen die Dynamik des 
Projektes durchziegelst, dann gräbst du dir das Wasser ab. Diese Spannung 
ist IMHO unaufhebbar! (oder das Projekt ist tot)

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.
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)

Und darin liegt wahrscheinlich auch der Grund, dass es nicht zu mehr
forks kommt.

Ja, das beschreibt ESR auch ganz gut.

Somit ist ein Aspekt der 'Macht', Leute um eine Projektidee herum
anzusammeln, und zu vermeiden, dass sie sich verstreuen.

Das ist das _wechelseitige_ Interesse von Maintainer(n) und 
Projekt-Mitgliedern.

Sch"on dabei ist, dass als Machtinstrument im Wesentlichen nur die
bessere (popul"arere ?) Idee in Frage kommt, bzw. Popularit"at an sich.

Du meinst, wenn ein bekannter Hacker sagt "da lang", dann folgen mehr? 
Oder wie meinst du das?

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.

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. Die 
Frage ist also: Wie akkumulieren wir Qualität? Wie ist dieser 
Akkumulationsprozess organisiert, so dass viele sich einbringen können?

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.

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.
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.

Das sind die beiden Aspekte der "Spannung". IMHO kann man die nur 
"halten", anstatt zu versuchen, sie "aufzulösen".

Nun ja, da habe ich viel "uber Konsistenz und Klarheit geschrieben,
und habe doch das Gef"uhl, selbige Regeln beim Schreiben dieser mail
nicht besonders streng verfolgt zu haben. Man m"oge mich entschuldigen,
das ist eben nur 'laut gedacht', und soll eher als Einladung zur
Diskussion verstanden werden...

Auch nur laut mitgedacht....

Ciao,
Stefan

--
    Vereinte Dienstleistungsgewerkschaft ver.di
    Internetredaktion
    Potsdamer Platz 10, 10785 Berlin
-- 
    stefan.meretz verdi.de
    maintaining: http://www.verdi.de
    private stuff: http://www.meretz.de
-- 



________________________________
Web-Site: http://www.oekonux.de/
Organisation: projekt oekonux.de


[English translation]
Thread: oxdeT05345 Message: 67/91 L8 [In index]
Message 05632 [Homepage] [Navigation]