Message 05637 [Homepage] [Navigation]
Thread: oxdeT05345 Message: 68/91 L9 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

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



Stefan Meretz wrote:

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.

auch, aber das disqualifiziert sie ja nicht. Entwickeln ist weit mehr als
'coden', also wozu "uberhaupt der Begriff 'Pre-Code' ?
Aber auch beim coden: Es gibt einfach bestimmte Dinge, die machen mehr
Spass, sind eine gr"ossere Herausforderung, sind mehr 'sexy', etc.

Wenn's dann um Kleinigkeiten geht, schaut man gern nach neuen Aufgaben.
Aber f"ur einen release m"ussen auch die Kleinigkeiten getan werden.
Da muss dann also irgendwann mal ein 'code freeze' her, ein 'formales'
Verbot irgendwelche Ver"anderungen am code vorzunehmen, es sei denn
sie qualifizieren als 'bug fixes' etc, oder sind vom 'release manager'
abgesegnet. Und die Notwendigkeit f"ur solcherlei formale Eingriffe
steigt mit der Projektgr"osse...

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?

ich meine dass gl"ucklicherweise *nur* Popularit"at als Machtmittel
in Frage kommt. D.h. da ich meiner Arbeit nicht entfremdet werde,
werde ich mich also nur von meinen Interessen tragen lassen. Und die
sind Ergebnis-orientiert: entweder meine Erkenntnis (der Lern-Effekt)
oder (und) funktionierende software. Und dabei spielt dann, wie wir
gesehen haben, die Popularit"at einer Idee (eine kritische Masse von
Entwicklern sind bereit, in dieselbe Richtung zu gehen) die gr"osste Rolle.

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.

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' ?

Viele Köche können den Brei verderben, aber ein engstirniger Koch, der die neuen Rezepte nicht kennt, kann ein ungenießbares Essen produzieren.

stimmt. Daraus dass ein Essen das von 100 K"ochen gekocht wurde oft nicht
besonders gut schmeckt, l"asst sich gewiss nicht schliessen, das ein Mahl
gut sein muss, nur weil's ein Einzelner zubereitet hat.


Die Frage ist also: Wie akkumulieren wir Qualität? Wie ist dieser Akkumulationsprozess organisiert, so dass viele sich einbringen können?

Genau, das ist eine sehr unteressante Frage (die ja auf so ziemlich alles
anwendbar ist, nicht nur software Projekte)...

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

ein durchaus dialektischer Konflikt. Das team ist auf den Einzelnen
angewiesen, der wiederum sich optimal einbringt, wenn er mehr als
Teil des teams agiert, nicht als unabh"angiges Individuum.

beste Gr"usse,
		Stefan

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


[English translation]
Thread: oxdeT05345 Message: 68/91 L9 [In index]
Message 05637 [Homepage] [Navigation]