Message 12537 [Homepage] [Navigation]
Thread: oxdeT12531 Message: 7/7 L4 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

Re: [ox-de] Dossier "Open Source"



Hi El Casi

El Casi wrote:
Sourcen sind eben nur der trivialisierte Teil des Know-How. Aber für ein
Buch gilt auch: du musst es nicht nur beschaffen, sondern auch aneignen
(also wenigstens lesen). Warum soll das ausgerechnet bei Software - noch
dazu komplexer - anders sein?

Hm, gibt es eigentlich verschiedene Arten von Komplexität?

Nun ja, im Open-Source-Bereich gibt es offensichtlich einen Trade-off
zwischen Größe der potenziellen Nutzergemeinde und Schwierigkeit, die
entsprechende Software zu bauen. Das klassische Beispiel ist das
Kernel-Projekt Hurd, was seinerzeit offensichtlich zu ambitioniert war,
während Torvalds mit einem letztlich "schlechteren" Konzept eines
monolithischen Kernels die nötigen "Ressourcen" allokieren konnte. Noch
deutlicher ist das Phänomen im Bereich der Computeralgebrasysteme zu
beobachten, wo (trotz Maxima und Axiom) noch gar keine wirklich ernst zu
nehmenden Alternativen zu den "Großen" existieren.

Womit du auch schon zwei Arten von Komplexität auf dem Teller hast - im
ersten Fall die konzeptionelle Tiefe und im zweiten Fall die fachliche
Tiefe. Während du die erstere durch entsprechende
Komplexitätsreduktionstechniken - Abstraktionen, Modularisierung,
Architekturkonzepte - in den Griff bekommen kannst (und die Linux-Leute
sie ja im weiteren Verlauf der Entwicklung auch so in den Griff
bekamen), ist sie im ersteren Fall inhärent. Du kannst einen guten
Algorithmus für eine mathematische Problemklasse nur entwerfen und
implementieren, wenn du von der dabei auftretenden Mathematik auch was
verstehst.

Komplexität kann man zugänglich oder weniger zugänglich gestalten,
man kann sie auch einfach übertreiben... Gibt es Studien zum
Zusammenhang zwischen Komplexität und Funktionalität?

Komplexität muss immer so weit reduziert werden, dass sie letztlich in
(d)einen Kopf passt. Dafür gibt es viele Techniken. Heute wird zunehmend
wichtig, darüber hinausgehende Komplexität in kollaborativen Strukturen
aufzufangen. Bzw. eigentlich *ist* Kapitalismus eine bereits 300 Jahre
währende Antwort auf diese Frage, wie ich mit dem "Korngrößendilemma"
thematisiert habe. Eben die "pubertäre Form einer Freien Gesellschaft",
in welcher dann auch diese Art der "Verkehrsformen" einer bewussten
zielgerichteten Gestaltung zugänglich werden.

Ein anderer Gedanke, aus meiner eigenen "Praxis": mein Ansteller
scheut vor der Komplexität seiner eigenen Anwendung zurück und
bewirkt dadurch ...

Typisches Opfer des Korngrößendilemmas.

Ich will damit folgendes sagen: der "trivialisierte Teil des
Know-How", also der Source Code, kann einerseits so abgefaßt sein,
daß sich jemand über ihn dem fachlichen Know-How nähern kann, oder
aber so, daß er sich erst des fachlichen Know-Hows bemächtigen
muß, bevor er überhaupt eine Chance hat, sich halbwegs die
Trivialisierung aneignen zu können.

"trivialisiert" bedeutet ja gerade, dass das Tool als black box genutzt
werden kann, wie ein Auto. Du musst nur wissen, wo der Zündschlüssel
reinzustecken ist (und ggf. die Wegfahrsperre zu deaktivieren). Du
redest hier davon, das "tote" (in SW vergegenständlichte) Wissen wieder
zum Leben zu erwecken - aka in einen Kopf reinzukriegen. Was du, nehme
ich mal an, nur so weit treibst, wie für deine praktischen Zwecke
erforderlich. Du wirst sicher nicht jede Feinheit des Codes bis zum
bitteren Ende studieren und verstehen wollen. Insofern ist der
Unterschied zum Wissen um das "Schlüssel reinstecken" nur ein
gradueller. Komplexitätsreduktion ist eben allgegenwärtig.

Insofern scheint es mir durchaus wert zu überlegen, ob nicht ein
Open-Source-Projekt unter der Ägie von, sagen wir mal, IBM ein
anderes Produkt hervorbringt, als ein OSS-Projekt mit demselben
Gegenstand, das aber keinen einzelnen ressourcen-sprudelnden, in
sich geschlossenen Motor hat...

Davon wird man wohl ausgehen müssen. IBM will ja trotz OS-Engagement
Technologieführer bleiben und demzufolge einen Teufel tun und der
Konkurrenz auch noch beim Verstehen seiner Entwicklungen über das
funktional erforderliche Maß hinaus behilflich sein.

Auch in der schnöden Marktwirtschaftstheorie ist die sogenannte
"entry barrier" ein wesentliches Kriterium für die Planung von
Monopol-Extra-Profiten, die Investoren dazu anhält, den
entsprechenden Markt entsprechend zu gestalten.  Es scheint
durchaus naheliegend, ähnliche Gestaltungsansprüche auch
kommerziellen Open-Source- oder Free-Software-Produzenten und
-Dienstleistern zu unterstellen -- und genauso naheliegend
scheint es, nicht-kommerziellen FLOSS-Produzenten entgegengesetzte
Gestaltungsinteressen zu unterstellen...

Oder sehe ich das übertrieben?

Nö, jeder verhält sich halt artgerecht. Es ist die alte Frage von
Adorno, ob es ein richtiges Leben im falschen gibt.
Transformationszeiten wie die heutigen sind besonders komplex und mit
vielfältigen Perspektiven aufgeladen, die einseitige Antworten
verbieten. Insofern noch einmal Stallman at
http://www.gnu.org/philosophy/free-software-for-freedom.html

Radical groups in the 1960s developed a reputation for factionalism:
organizations split because of disagreements on details of strategy, and
then treated each other as enemies. ... 
The relationship between the Free Software movement and the Open Source
movement is just the opposite of that picture. We disagree on the basic
principles, but agree more or less on the practical recommendations. So
we can and do work together on many specific projects. We don't think of
the Open Source movement as an enemy. ...
Spreading the idea of freedom is a big job--it needs your help. That's
why we stick to the term “free software” in the GNU Project, so we can
help do that job. If you feel that freedom and community are important
for their own sake--not just for the convenience they bring--please join
us in using the term “free software”.

Viele Grüße, hgg

-- 

  Prof. Dr. Hans-Gert Graebe, Inst. Informatik, Univ. Leipzig
  Johannisgasse 26, D-04109 Leipzig, Raum 5-18	
  tel. : +49 341 97 32248
  email: graebe informatik.uni-leipzig.de
  Home Page: http://www.informatik.uni-leipzig.de/~graebe

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



[English translation]
Thread: oxdeT12531 Message: 7/7 L4 [In index]
Message 12537 [Homepage] [Navigation]