Re: [ox] GPL im Architekturbereich
- From: Stefan Merten <smerten oekonux.de>
- Date: Fri, 22 Jun 2001 00:51:47 +0200
Hi Christoph!
5 days ago Christoph Reuss wrote:
Stefan Merten schrieb gestern:
[Jens Wilke schrieb:]
Sofern es die Honorarordnung für Architekten und Ingenieure, die
für diese Berufsgruppen verbindlich ist, zulässt, könnte ein Entwurf
unter der GPL veröffentlicht werden.
Nur, was hat die Menschheit davon, wenn ein Entwurf, der auf eine
spezifische Situation (Form und Größe des Grundstücks, Bestand,
Nutzungsansprüche, Exposition, Bodenverhältnisse u.a.) unter der
GPL veröffentlicht wird?
Was hat die Menschheit denn davon, daß ein komplexes Programm unter
GPL gestellt wird? Ist ja auch immer eine spezielle Anwendung, bezieht
sich also auch immer auf eine spezifische Situation.
...
Eine zweite Fläche zu finden, auf der dieser Entwurf _sinnvoll_ so
oder ähnlich realisiert werden könnte wäre ziemlich
unwahrscheinlich.
Vermutlich wahrscheinlicher als ein zweites Problem zu finden, das mit
der gleichen Software gelöst werden könnte...
Jens meinte offenbar den Unterschied zwischen Standard-Programmen (à la
StarOffice/M$-Office oder Betriebssysteme) und massgeschneiderten Programmen
(Spezialanwendung für _eine_ Firma).
Da hatte ich es mir wohl mal schnell ein bißchen zu einfach gemacht -
aber ihr seid mein Lieblingskorrektiv ;-) .
Und da gibt's tatsächlich ein Problem,
nicht nur in der Landschaftsarchitektur, sondern auch in der Informatik:
Auch ein Textverarbeitungsprogramm ist zwar "eine spezielle Anwendung,
bezieht sich also auch immer auf eine spezifische Situation", aber eben
doch universell bezüglich seiner AnwenderInnen -- die Omi kann damit an
Tante Hulda schreiben, und der Manager kann mit dem selben Programm
seine Geschäftsbriefe verfassen.
Laß uns das mal aufdröseln.
Zunächst mal ist das zwar heute so wie du schreibst, aber die
Anforderungen an die heute üblichen Monstern von Textverarbeitung sind
immer noch sehr fallabhängig. Zum privaten Briefeschreiben brauchst du
vielleicht 5% der Features eines Ungetüms wie Word oder auch
StarOffice - da tut's letztlich auch der `vi' :-} .
Für die Geschäftskorrespondenz kannst du dagegen schon sehr viel mehr,
letztlich aber doch nur einen kleinen Teil nutzen. Für wieder andere
Anwendungen - den Satz eines Buches - brauchst du wieder andere Teile.
Wenn ich hier jetzt mal einen kleinen Exkurs der Software-Geschichte
einfügen darf: Solche funktionalen Monstern sind auch frühe
Betriebssysteme gewesen. Unix - auf dem GNU/Linux konzeptuell beruht -
war eines der ersten Betriebssysteme, das mit dieser Logik radikal
gebrochen hat. In Unix wurde dagegen auf mehreren Gebieten eine
heftige Vereinfachung und Vereinheitlichung durchgeführt. So sind z.B.
alle Objekte des Systems Files - so in etwa zumindest. Das wurde
kombiniert mit einer orthogonalen Kombinierbarkeit all dieser
einfachen Konzepte. Heraus kommt ein Baukastensystem, das Lego nicht
unähnlich ist: Einige unterschiedliche Bausteine, die fast beliebig
kombiniert werden können und somit komplexe Funktionalitäten erzeugen
können. Das ist BTW auch der zentrale Grund, warum ich Unix und seine
Derivate für strukturell leistungsfähiger und flexibler halte. Wie das
in graphische Oberflächen zu übersetzen ist weiß ich leider nicht.
Vielleicht wäre das aber mal (wieder) einen Gedanken wert.
Vorteil ist, daß du mit wenigen Kopfgriffen dir die Funktionalität
zusammenbauen kannst, die du für deine je konkrete Aufgabe brauchst.
Perl mag da heute übrigens als leuchtenstes Beispiel dienen, das diese
Philosophie aufgegriffen, gebündelt und noch weiter standardisiert
hat. Damit bist du vor allem unabhängig von der Existenz eines
passenden Programms und insofern bedeutet diese Technik einen
konkreten Freiheitsgewinn. Klar - die Kopfgriffe mußt du erst lernen.
Aber du mußt sowieso lernen, wie du mit einem Computer etwas
Sinnvolles tust.
Um wieder zurück zu der Textverarbeitung zu kommen. Ich fände es in
der Software aber auch in der Hardware wünschenswert, wenn wir solche
kleinen, flexiblen und parametrisierbaren Module noch viel stärker
hätten. Die sind übrigens auch programmiertechnisch überschaubarer und
damit einfacher zu warten und damit auch leichter hochqualitativ zu
machen. Dann könnte die private BriefeschreiberIn das nutzen, was sie
braucht und die ManagerIn das, was ihr von Nutzen ist. Die Software an
sich wäre aber in kleine Module zerlegt, die auch wieder anders
zusammengesetzt werden könnten. Mit wenig Aufwand wäre auch noch eine
Vorkonfiguration zu bauen, die den entsprechenden Leuten das
Zuschneiden für exakt ihre Bedürfnisse abnimmt.
Witzigerweise hat M$ höchstselbst eine solche Komponentenarchitektur
gerne gepusht. Leider haben sie m.W. das Konzept aber dadurch
konterkariert, daß Word o.ä. als eine "Komponente" gilt...
Ah, ich ufere aus :-( . Was ist mir wichtig? Die Ideen, die Unix
zugrunde liegen machen Freie Software stark und bringen reale
Freiheitsgewinne. U.a. den, daß sie unabhängig(er) von der Existenz
spezifischer Programme machen. Es wäre ja dann vielleicht denkbar, daß
noch mehr Programme - zusammengenommen - diese Universalität bieten
können.
Bei den massgeschneiderten Programmen
ist das eben nicht so --
Selbst da sieht es heute schon anders aus als vor 30 Jahren. SAP ist
das lebendige Beispiel dafür, daß sie ein (Monster)-Programm bei und
mit den Auftraggebern anpassen. Sie konfigurieren nur noch und
schreiben keine Programm neu - und da ist ein erheblicher Unterschied
im Aufwand.
In dieser Richtung müßte die Entwicklung weitergehen und momentan sehe
ich keine prinzipiellen Gründe, die dagegen sprechen. XML wird da
sicher noch helfen.
die sind nur für die spezielle Aufgabe des
Auftraggebers (sic!) geschrieben.
Entscheidend an der Aussage ist, daß der "Gebrauchswert" der fertigen
Software für den Auftraggeber nicht mit dem "Gebrauchswert" der
ProgrammiererIn / KonfiguriererIn zusammenfällt und gleichzeitig die
beiden Personen nicht in eins fallen. Wichtig, da häufig so.
Und da sind wir bei der Auftragsarbeit,
die sich schwerlich in das Lustprinzip reinzwängen lässt.
Aber klar läßt sich. Der Spaß am Programmieren verschwindet ja nicht
dadurch, daß du nicht dein je eigenes realweltliche Problem mit dem
Programm lösen willst.
Nimm wieder mein Bahn-Beispiel. Ich würde die Bahn ja nicht deswegen
organisieren helfen wollen, weil mal je ich je konkret angenehm durch
die Lande reisen will. Die *Aufgabe an sich* ist das, was mich
interessiert. Das ist m.E. auch der Schlüssel für die ganze Frage zur
Beibehaltung der arbeitsteiligen Produktion.
Es gibt noch einen weiteren Grund, warum die Gesamtplanung
nicht unter der GPL veröffentlicht werden sollte.
Die freie Verfügbarkeit könnte nämlich dazu führen, daß ein
Entwurf unreflektiert an anderer Stelle unter ungeeigneten
Bedingungen realisiert würde und dadurch z.B. Pflanzen eingehen
('ausfallen'). Das fiele dann zunächst auf denjenigen zurück, der die
Planung gemacht hat, möglicherweise mit weitreichenden
Konsequenzen. (Ansehensverlust usw.)
Das ist dann aber eine falsche Zuschreibung. Bei Software sind diese
Sachen gewöhnlich durch Disclaimer geregelt, die solche Zuweisungen
von vornherherein sinnlos machen.
(Genau, nur so wurde es möglich, dass Gates der reichste Unternehmer der
Welt wurde, obwohl er eigentlich mehr Schaden als Nutzen anrichtete! ;-( )
Tja, aber für die Gemeinde mit den eingegangenen Pflanzen dürfte der
Disclaimer im Kleingedruckten dann ein schwacher Trost sein. Unser Ziel
sollte doch die Maximierung des Nutzens für AnwenderInnen sein, und nicht,
sich möglichst raffiniert mit winkeljuristischen Ausflüchten aus der
Verantwortung zu stehlen...
Das zentrale Stichwort im Originalzitat war für mich das
"unreflektiert" bzw. "ungeeignet". Eine möglichst stimmige fachliche
Beurteilung ist m.E. in allen Gesellschaftsformen von Nutzen.
Mit Freien Grüßen
Stefan
________________________________
Web-Site: http://www.oekonux.de/
Organisation: projekt oekonux.de