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

Hans-Gert Gr�be (2007-01-15 09:40 +0100):
> Holger Baxmann wrote:
>> Das führt zu einer stärkeren Abhängigkeit des Konsumenten, da heute  die
>> Verfügbarkeit der Sourcen allein ganix bedeutet. 
> 
> 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?

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?

Mal ein Beispiel aus anderer Sphäre: es gibt Anwälte, die zwei
verschieden komplexe Rechtssysteme kennen -- DDR- und BRD-Recht,
und die der Meinung sind, ersteres sei a) gerechter und b)
zugänglicher gewesen als zweiteres (in der DDR brauchte man keinen
Anwalt, um gesetzliche Vorschriften verstehen zu können, in der
BRD braucht man ihn schon wegen der wesentlich höheren
"Komplexität" der ganzen Angelegenheit).

Ein anderer Gedanke, aus meiner eigenen "Praxis": mein Ansteller
scheut vor der Komplexität seiner eigenen Anwendung zurück und
bewirkt dadurch, daß der zugrundeliegende Code immer verworrener
wird.  Das hat seinen Grund in der Kombination von 1) dem Zwang
neue Features zu präsentieren und 2) der Ressourcenknappheit
(Zeit & Hirn).  Hier wird "Komplexität" quasi "künstlich"
produziert, obwohl sie gar nicht sein müßte.

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.

Es scheint mir nicht fernliegend, hier einen Zusammenhang zwischen
dem Charakter der Produktion und dem Charakter des Produkts zu
vermuten -- spontan fällt mir hierzu der Beitrag von Alan Cox ein,
auf den Stefan Mz seinerzeit mal hingewiesen hat:

  Hier der Audio-Mitschnitt (54 MB, 1:19h):
  http://bigbro.skynet.ie/resources/ogg/AlanCox_UL_20060513.ogg

Aber mir scheint ebenso einleuchtend zu sein, daß es eben nicht
umgekehrt funktioniert:  durch quasi nachträgliche Offenlegung des
Codes wird dieser nicht automatisch den Prinzipien der
Komplexitätsbewältigung gerecht, die Alan Cox aus seinen
Beobachtungen der Freie-Software-Entwicklung ableitet.

Komplexität kann also so oder so aussehen, je nachdem, wie man
sich ihr (bzw. ihrer Abbildung) nähert.

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

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?


Gruß,
El Casi.
________________________________
Web-Site: http://www.oekonux.de/
Organisation: http://www.oekonux.de/projekt/
Kontakt: [email protected]