Netzwerkprodukte

Es ist zehn Jahre her, seit ich zuletzt versuchte, den Einfluß von Computern auf Gesellschaft zum Thema zu machen. Das ist eine lange Zeit - besonders wenn man die Themen betrachtet, die damals aktuell und drängend schienen, und sie mit denen vergleicht, die heute im Zentrum der Diskussion stehen. Ich hatte schon länger vor, die alten Fragen nochmals aufzugreifen: was ist aus der "computergestützten Gesellschaft" der ausgehenden Neunziger, was aus Begriffen wie "Rekursion" geworden, welche Begriffe und Denkfiguren bestimmen unser heutiges Denken?

Ich starte hier eine Reihe von Überlegungen, von denen ich noch nicht weiß, wohin sie führen werden. Meine Grundannahme ist, daß es - wie in jedem Bereich gesellschaftlicher Entwicklung - eine Dialektik zwischen Produkt und Produzenten gibt, daß, mit anderen Worten, das Internet eine technische Erfindung ist, die ihre Erfinder verändert.



Hardware


Startpunkt: die Entwicklung in der Computerhardware.

Im Verlauf der Neunziger mußte man in regelmäßigen Abständen neue Hardware anschaffen. Was man sich für viel Geld gekauft hatte, war nach zwei Jahren obsolet und mit aktueller Software heillos überfordert. Selbst das letzte Update der Office-Anwendungen lief plötzlich nur noch auf dem neuen Betriebssystem, das derart viel Speicher fraß, daß das Motherboard nicht genug Platz für RAM-Bausteine bot - wenn deren neueste Generation nicht ohnehin ein völlig neues Layout hatte (um ein Beispiel herauszugreifen unter vielen). Man nahm das hin (wenn auch zähneknirschend), weil die neuen Applikationen über Features verfügten, die man immer schon haben wollte, bzw. weil plötzlich Dinge möglich waren, von denen man vorher kaum zu träumen wagte.

Dieses Bild hat sich völlig gewandelt. Die Hardware, mit der ich hier gerade schreibe, besitze ich - von ein, zwei kleineren Basteleien abgesehen - seit acht Jahren. Auf ihr laufen alle Programme, die ich nutzen will - z.T. in veralteten Versionen, aber immer in dem Funktionsumfang, den ich brauche.

Gut, ich bin kein (Hardcore-)Gamer. Wer die allerneuesten Spiele laufen lassen will, braucht etwas mehr, als auf und unter meinem Schreibtisch steht. Aber mein PC ersetzt mir nicht nur die Schreibmaschine und das Fotoalbum, sondern auch den Fernseher und den DVD-Player (und zwar - in Kombination mit einem entsprechenden Receiver - mit qualitativ exzellentem Surround-Sound). Wer mir die Features dieses Setups in meiner Zeit als Computeranfänger (Mitte der Achtziger) beschrieben hatte, wäre von mir als talentierter Autor von Science Fiction weiterempfohlen worden - und wenn ich das Ende der Neunziger gehört hätte, nur wenige Jahre, bevor ich meine aktuelle Hardware kaufte, mit dem Hinweis, daß die die nächsten acht Jahre überdauert: den hätte ich ausgelacht.



Software


Eine ähnlich gegenläufige Bewegung findet man in der Entwicklung der Software, zumindest in jener, die die Industrie hervorbringt.

Bis in die späten Neunziger brachten die Updates der großen Softwarepakete fast immer nicht nur Bugfixes, sondern echte Neuerungen - manchmal sogar solche, die niemand für möglich gehalten hätte. Bildbearbeitungen wie Photoshop, Betriebssysteme wie die von Apple, oder - um mal meinen eigenen Bereich zu nennen - Musiksoftware wie Cubase brachten Filterplugins, coole Benutzeroberflächen, und virtuelle Instrumente.

Heute ist dies weitgehend erstarrt. Die kommerziellen, monolitischen Applikationen halten ihren Benutzerkreis weitgehend durch ihre pure Existenz, z.T. weil es zu ihnen keine echte Alternative gibt (Photoshop), z.T. weil die User die existierenden Alternativen nicht wahrnehmen (Windows), z.T. weil man enorm komplexe Applikationen nicht über Jahre gelernt hat, nur um sie dann abzustreifen wie ein Hemd (Cubase, Photoshop).

Um ein wenig aus dem Nähkästchen zu plaudern: jene Erstarrung verdankt sich dem ins Gargantueske gewachsenen Sourcecode. Bei Steinberg hatten wir Mitte der Neunziger immerhin noch erkannt, daß der alte C-Code nicht mehr lange wartbar sein wird, und hatten ein komplettes Rewrite gestartet. Trotzdem geistert da noch einiges an Legacy-Code herum (legacy = Erbe = Wurstcode; z.B. mein Noteneditor) - und selbst die Wurzeln des neue Codes liegen heute dreizehn(!) Jahre in der Vergangenheit. - Bei anderen Firmen mag das weit dramatischer aussehen. Ich möchte jedenfalls keinen Job bei Adobe oder Microsoft. Bei denen dürfte Programmiererarbeit Ahnenforschung bedeuten.

2 Kommentare

Open Source


Wo sich die Anbieter kommerzieller Software immer schwerer tun, ihre Ware unters Volk zu bringen, gewinnt freie Software mehr und mehr an Bedeutung. Es gibt kaum noch einen Bereich, in dem es zur kommerziellen Lösung keine Antwort von der OpenSource-Gemeinde gibt. Ob Office-Paket, Internetbrowser oder komplettes Betriebssystem, die Alternativen sind nicht bloß kostenlos, sondern auch in Funktionsumfang und Bedienbarkeit dem "Vorbild" gleichwertig, wenn nicht sogar überlegen.

Besonders Linux ist eine Erfolgsstory, die ich hier nicht nochmals nacherzählen muß. Die Enduser mögen sich (noch) schwer damit tun, ihre vertraute Windows-Installation durch eine Linux-Distribution zu ersetzen. Die Abstimmung unter den Administratoren von Servern ist längst zu Gunsten von Linux plus Apache ausgegangen: fast zwei Drittel aller Hostnamen werden von Apache-Servern betrieben.

Erwähnenswert finde ich Mozillas Firefox plus Thunderbird, das OpenOffice-Paket, und die diversen Skriptimplementierungen: besonders hervorzuheben wäre PHP, mit dem das "world wide web" dynamisch wird (es ist mehr als unglaublich: Microsofts .NET-Projekt ist hier keine ernsthafte Konkurrenz).

Ich bin erst bei der Vorstellung der Figuren im Spiel, sie müssen noch in Bewegung gesetzt werden - dennoch ein Vorgriff. "OpenSource" ist nicht "Freie Software" (oder - um Richard Stallman zu zitieren: "Freie Software ist kein Freibier") . Erste ist ein Verfahren zur Softwareentwicklung, letzte ein politischer Begriff, der Copyright, Freiheit der Rede und, in letzter Instanz, eine radikale Kritik am Eigentumsbegriff an Bord hat. - Aber wie gesagt: ich greife vor.

2 Kommentare

User


Der letzte Protagonist betritt die Bühne: das Internetpublikum. Wo sich in der Realität ein heilloses Gedrängel ergäbe, ist es im virtuelle Raum tatsächlich möglich, daß alle Zuschauer gleichzeitig Darsteller sind.

Facebook (als deutsche Kopie StudiVZ[1]), MySpace, Flickr, YouTube, die Welt der Blogger[2] - all dies sind Orte, die zentral sind für das Web 2.0. Sie leben von der "Community", den Beiträgen ihrer User. Aus technischer Perspektive sind diese Webseiten eher uninteressant - um den Code etwa für Wordpress zu schreiben, bedarf es keines Studiums der Informatik: sie leben von einer jeweils eigenen, originellen Idee, den Bedarf nach Kommunikation in noch nicht dagewesene, im Nachhinein zwingend scheinende Bahnen zu lenken.

Ein alter Traum wird wahr: ein Medium tritt in die Wirklichkeit, das von denen gesteuert wird, die es benutzen. Hans Magnus Enzensberger hatte den Traum Anfang der siebziger Jahre:

Der Autor hat als Agent der Massen zu arbeiten. Gänzlich verschwinden kann er erst dann in ihnen, wenn sie selber zu Autoren, den Autoren der Geschichte geworden sind.

(Baukasten zu einer Theorie der Medien, Kursbuch 20, Ff./M, 1970)

Das Internet ist die technische Umsetzung dessen, was das Fernsehen nur als Utopie versprach: die Aufhebung des Unterschieds zwischen Sprecher und "Masse", wie man im Jargon jener Tage sagte.

Nun ist es offensichtlich, daß die Utopie von der Autorenschaft der Gesellschaft an der eigenen Geschichte - mit anderen Worten: der Selbstbestimmung von Gesellschaft über ihr eigenes Schicksal - trotz solcher technischen Möglichkeiten keineswegs gelang.

Jeder kann mitreden: damit beginnen aber völlig neue, unvorhergesehene Probleme. Auf der einen Seite versinkt die Welt in selbstbezüglichem Lärm: was wichtig ist, läßt sich in all dem Datenmüll kaum noch identifizieren. Man kann Google nicht dazu instruieren, die "wichtigsten", "relevanten" oder "schönsten" Beiträge zu einem bestimmten Thema zu finden. Auf der anderen Seite ist das Internet keineswegs ein herrschaftsfreier Raum, in dem jeder Redner und jede Rede gleich viel wert wäre. Nach wie vor gilt: wer über Marktmacht verfügt, verfügt gleichzeitig über eine laute Stimme.

Den Problemen, die der "gläserne User" sich selber bereitet, indem er sich den Instrumenten der Spionage privatester Daten kritiklos ausliefert, habe ich einen eigenen Baukasten gewidmet.

  1. [1] Nein, die verlinke ich nicht.
  2. [2] Die Blogszene hierzulande ist eine Randerscheinung, vergleicht man sie mit jener in den Vereinigten Staaten: wenn dort ein bekannter investigativer Blog über das Fehlverhalten eines Senators berichtet, schlägt das Wellen, hoch genug, diesen zum Rücktritt zu zwingen.


Kommerz und Qualität


Nachdem die Protagonisten vorgestellt wurden, stellt sich die Frage, inwieweit man sie Gruppen zuordnen kann; mit anderen Worten: die Spielfiguren sind bekannt - kann man die weißen von den schwarzen Figuren unterscheiden?

Zunächst sind es natürlich die Unterschiede ihrer Einbindung in die kapitalistische Wirtschaft, die ins Auge fallen: hier die auf Profit ausgerichtete Hard- und Softwareindustrie, dort kostenlose Software und ohne Gewinnabsicht produzierter Content der User. Es wäre relativ einfach, sich auf die Seite letzterer Gruppe zu schlagen, und hier nicht nur eine moralische, sondern auch eine inhaltliche Überlegenheit zu sehen: wenn Software ohne das Ziel ökonomischer Verwertbarkeit entwickelt wird, liegt es nahe, daß diejenigen, die sich auf die Sache selber konzentrieren, bessere und vor allem bugfreie, ausgereifte Ergebnisse vorlegen.

Bis zu einem gewissen Grad ist das auch so. Linux hat einen hervorragenden Ruf, was Stabilität angeht - nicht umsonst findet man es so häufig auf Servern, die ohne zuverlässig laufendes Betriebssystem schlicht unbrauchbar sind. Umgekehrt habe ich irgendwann staunend vor einem Geldautomaten der Hamburger Stadtsparkasse gestanden und dabei zugesehen, wie Window NT nach einem Absturz neu gebootet wurde (es ist wirklich wahr: Windows NT von 1995 steuert dort die Geldautomaten). Es wäre also ein Leichtes, in altbekannte Kerben zu hauen und Linux gegen Windows, freie gegen kapitalistische Software, bloggende User gegen profitorientierte Printmedien zu setzen.

So einfach ist es aber dann doch nicht (und das ist der Grund, warum ich diesen Baukasten überhaupt gestartet habe). Freie Software ist nicht per se besser, und feste Angestellte in den Companies sind nicht zwangsläufig Schlampen, die an ihrem Gehaltscheck, nicht jedoch an vernünftigen Programmen interessiert sind. Ebenso wenig sind Blogger die besseren Journalisten, ebenso wenig - was imho eine bemerkenswerte Pointe ist - sind Microsoft und Google quasi dasselbe, weil ja beide börsennotierte Unternehmen sind, amerikanische zumal, die es mit den Quartalszahlen besonders eng sehen.

Ich bin der Meinung, daß es um mehrere dialektisch verzahnte Ebenen zu tun ist - und die will ich in der Folge beschreiben und untersuchen.

(Bislang habe ich letztlich nur Trivia berichtet. Wenn es Widerspruch geben sollte, würde ich darauf mit verbesserten Formulierungen antworten (das soll heißen: ich bin mir verhältnismäßig sicher, daß ich bislang keinen totalen Schwachsinn erzählt habe). Ab jetzt bewege ich mich auf schwankendem Grund. Allen Positionen, die ich von hier an formuliere, kann es passieren, daß ich sie später wieder verwerfe.)



Angestellte Programmierer


Programmierer im Angestelltenverhältnis müssen sich gegebenenfalls dem Druck von Marketing und Sales beugen, und Features einbauen, die sie inhaltlich für falsch halten, oder die unter Zeitdruck nur fehlerhaft oder unvollständig fertig werden. Umgekehrt stehen freie Programmierer unter dem Druck, irgendwo doch wieder Geld verdienen zu müssen - sie sind zwar frei in der Sache, können sich ihr aber, bedingt durch ihren externen Broterwerb, nicht mit ganzer Kraft widmen.

Ideal wäre eine Situation, in der eine kleine Gruppe von Programmierern (Einzelkämpfertum ist in der Branche verbreitet, aber - meistens - kontraproduktiv) unter abgesicherten materiellen Verhältnissen arbeiten könnte, wo das Management sich darum kümmert, das ausreichend Geld hereinkommt, indem es die neuen Features nimmt wie sie sind, und erst dann, wenn sie fertig sind (ein wenig herummeckern, daß das Release sich schon wieder verzögert, dürfte es auch noch). Ideal wäre es außerdem, wenn die Programmierer nicht nur die Technik beherrschten, sondern zudem Domainexperten wären - wenn sie also im Idealfall Kunden der eigenen Software wären. Dann ließe sich die Mühsal der Erstellung und Vermittlung von Spezifikationen klein halten; die Rolle von Produktspezialisten und die ganze Bürokratie, die diese Rolle mit sich bringt, hielte sich in überschaubaren Grenzen (man kann diese Sätze, wenn man sie um 180 Grad wendet, als Beschreibung des Ist-Zustands lesen).

Der Witz oben stehenden Absatzes ist, daß er einen Zustand beschreibt, der vor knapp zwanzig Jahren Realität war. Als ich Anfang der Neunziger bei Steinberg einstieg, gab es ein Verhältnis von Entwicklern zum Rest der Belegschaft von 1 zu 1 (heute liegt es bei ca. 1 zu 3, obwohl der Entwicklungsabteilung ein starkes Gewicht zugemessen wird). Die Features wurden von Musikern bestimmt - und das waren, mit wenigen Ausnahmen, auch diejenigen, die den Code schrieben. Ich habe keine Ausbildung in der Informatik, sondern in der Musik, und damit bin ich unter der "Urbesetzung" keine Ausnahme. Steinberg wiederum ist in der Softwareindustrie jener Tage keine Ausnahme: wenn man die Artikel von Joel Spolsky liest (der für Microsoft als Chef der Excel-Entwickler gearbeitet hat), wird klar, daß selbst ein Bill Gates keineswegs der geldgierige Beutel war, als der er heute gern dargestellt wird, sondern ein Software-Visionär reinsten Wassers, der es blendet verstand, die richtigen Leute um sich zu versammeln. Und wenn ich, nach all der Zeit, noch einmal in die ersten drei Bände von "Inside Macintosh" schaue, kommen mir die Tränen anbetrachts all dieser unwiderruflich verschwundenen Schönheit. Ja, doch: Code konnte schön sein, war das gelegentlich, wie Sprache, auf ebenso verschlungene Art und Weise.

(Ich will nicht verschweigen, das es bei Steinberg nicht bloß golden glänzte, sondern auch ziemlich stank. Wie in jeder menschlichen Gemeinschaft gab es Auseinandersetzungen, die nur scheinbar der Sache galten, in Wahrheit die Machtverhältnisse betrafen - und da wir alle starke und sture Persönlichkeiten waren, ging es teilweise übel zur Sache. Zum zweiten: ich hatte von Gelddingen zu der Zeit überhaupt keine Ahnung. Hätte ich sie gehabt, wäre ich heute finanziell unabhängig oder - was eher wahrscheinlich ist - mich nicht derart bedingungslos mit der Firma identifiziert.)



Hacker und Informatiker


Die Software-Entwickler in den achtziger und neunziger Jahre waren fast immer Autodidakten, meistens ohne formale Ausbildung. Das ist heute grundlegend anders. Ohne abgeschlossenes Informatikstudium hat man - selbst als Domainexperte, als hervorragender Musiker etwa - auch bei Steinberg kaum eine Chance auf eine Stelle in der Entwicklungsabteilung. Dies hat mehrere Seiten, und ein ganzes Bündel an Konsequenzen.

Ein Neueinsteiger in die Programmierung verfügt heute über ein Wissen, das ich erst nach Jahren praktischer Erfahrung hatte bzw. bei dem ich in bestimmten Bereichen bis heute nicht mithalten kann. Ich bin immer wieder erstaunt, mit welcher Selbstverständlichkeit unsere Neueinstellungen in der wahrhaft nicht gerade schmalen Codebasis klarkommen und selber produktiv werden.

Ein Diplomand der Informatik ist allerdings nicht per se ein guter Programmierer. Er ist ausgebildet, bestimmte Zusammenhänge zu überblicken, von denen seine Professoren der Meinung sind, daß sie für die "Wissenschaft" der Computer wichtig seien. - Ich formuliere das hier bewußt sehr unbestimmt (ich kenne mich im Fachbereich Informatik nicht aus).

Jemand, der sich selber als Hacker bezeichnet, funktioniert anders als ein Absolvent eines mehrjährigen Studienganges, der nach einem Job sucht, in dem sich seine Mühe auszahlt. - Auch diese Behauptung versteht sich letztlich als Frage. Es macht m.E. wenig Sinn, über die Psychologie von Motivation und deren Anteil für die Qualität der durch sie angetriebenen Arbeit holzschnittartige Zuordnungen zu treffen. Das ist ein Thema, für das ich hier nur eine Überschrift aufschreiben kann.

Jemand, der Informatik studiert, studiert nicht Wirtschaftswissenschaften oder Jura. Er studiert allerdings auch nicht Germanistik oder Sozialwissenschaft. - Das ist jetzt nochmal in den freien Raum gesprochen: mir scheint, daß jemand, der sein Interesse für Computer als Beruf leben möchte, nicht primär am großen Geld interessiert ist. Das hätte dann der Diplomand mit dem Autor freier Software gemeinsam.



Bugs


Technisches Verständnis ist nur ein Teilbereich der Fähigkeiten, die es braucht, gute Software zu schreiben. Der andere Bereich dreht sich um "social skills". Moderne Software ist so umfangreich und komplex, daß sie nur im Team gebaut werden kann, und man braucht mehr als ein Minimum an Kommunikation, um die einzelnen Arbeitsergebnisse irgendwann wieder miteinander verknüpft zu können.

Auch innerhalb der technischen Arbeit ist die eigentliche Entwicklung nur eine Untermenge: ein großer Teil der Energie geht drauf für die Fehlersuche, für das Debugging. Wenn das Programm hinlänglich groß (und womöglich noch dazu alt genug) ist, kann es passieren, daß man im Projektverlauf zu 90% im Debugger verbringt.

Ich fixe eigentlich recht gerne Bugs (= suche und beseitige Fehler) - zumindest wenn die klar reproduzierbar sind. Man kennt ein Fehlverhalten, und es ist eine Frage der Zeit, bis man es verstanden und beseitigt hat - zumindest wenn man es mit einem Zusammenhang von begrenzter Komplexität zu tun hat. Zweimal "zumindest" - und diese beiden Einschränkungen verursachen unabsehbare Kosten.

Nicht reproduzierbare Bugs sind deutlich in der Unterzahl, kosten aber auch bei weitem den größten Aufwand. Es gibt Fälle, wo über Monate immer wieder neue Anläufe genommen werden, nur um ein Problem so einzukreisen, daß es zuverlässig auf einer Entwicklermaschine wiederholbar ist - und es gibt Fälle, wo man eine Software mit einem bekannten und schwerwiegenden, aber nicht reproduzierbaren Fehler zähneknirschend zum Release freigibt.

Wenn ein Bug in einem Programmbereich auftaucht, der von vielen anderen Bereichen benutzt wird, kann es leicht passieren, daß man ein Problem beseitigt, und durch den Fix ein völlig neues erst erschafft (mir fallen zu dem Thema eine ganze Serie von Beispielen ein, aber keines, das man in wenigen Worten einem Nicht-Programmierer erklären könnte; ich trage das ggf. noch nach).

Beide Problembereiche (Nicht-Reproduzierbarkeit von Bugs, und Seitenwirkungen von Fixes) haben nichts damit zu tun, wo, für wen, und wie man arbeitet - sie betreffen die Industrie ebenso wie freie Software, Amateure wie Profis. Spannend wird es, sich anzuschauen, wie die unterschiedlichen Gruppen damit klar kommen, daß sie wieder und wieder vor denselben Problemen stehen, gegen die kein Kraut gewachsen ist und die die Frustration des Sisyphos nachvollziehbar machen.



Programmierer-Interessen


Wenn es stimmt, daß fähige Programmierer weniger am Geld, sondern eher an der Sache interessiert sind, erklärt das die Eleganz, mit der viele hochkomplexe Programme funktionieren ebenso wie das Desaster, in dem häufig Brot-und-Butter-Anwendungen versinken. Warum ist Microsofts "Visual-C" ein ziemlich cooles Produkt, "Word" aus demselben Haus hingegen nach wie vor - nun: verbesserungswürdig [1]? Die Antwort ist recht simpel: weil man eher gute Programmierer zur Lösung eines interessanten und komplexen Problems findet, als für ein vielleicht gut bezahltes, ansonsten aber langweiliges Projekt.

Wer einen gut bezahlten Job will, interessiert sich letztlich für jene Situationen, in denen sein Geld eine Rolle spielt - und das ist in den Gehaltsgruppen, um die es hier geht, keinesfalls ein beruflicher und gesellschaftlicher Alltag, in dem es Macht und Geltung verleiht, sondern der Feierabend, wenn man es ausgeben kann. Einen guten Manager kann man mit einem möglichst astronomischen Gehalt kaufen; versucht man dasselbe in der Klasse des sog. Mittelstands, bekommt man Mitarbeiter, die sich in ihrer herbeigesehnten Freizeit etwas kaufen. Da wird kaum jemand mit der Qualität seiner Arbeit auffällig werden.

Geltung (und damit Macht) gewinnt ein Hacker durch die Qualität der eigenen Arbeit. Das Statussymbol ist die Zahl der Fragen, die ihm gestellt werden: dies ist sein Gradmesser von Kompetenz und Ansehen - nicht der Porsche, der Auskunft über den Kontostand seines Besitzers gibt.

Die Trennung zwischen "besser" und "weniger gut" liegt also wieder nicht zwischen kommerzieller vs. freier Software: sie hängt am Thema. Compiler und Betriebssysteme [2] sind Felder, für die man ohne weiteres qualifiziertes und begeisterungsfähiges Personal findet. Anders dürfte es aussehen, wenn man eine Stelle für Datenbankprogrammierung oder die Weiterentwicklung von Office-Software zu vergeben hat.

In der Welt der kommerziellen Software findet man leicht Beispiele. Wenn man Open-Source ansieht, findet man ein cooles Betriebssystem mit ebenso coolem Compiler im coolen, aber nicht eben einfach zu bedienendem Unix-Gewand - und ein Office-Paket, dessen Existenz sich einem Zufall [3] verdankt.

  1. [1] Auch Visual-C hat seine Macken, und Word hat im Lauf der Zeit einige Macken abgelegt.
  2. [2] Das gilt auch für Musiksoftware.
  3. [3] Das ist so nicht ganz richtig - man müßte "dessen Existenz sich einem Zufall" durch folgenden Nebensatz ersetzen (was ich aus Gründen der Handhabbarkeit nicht tue): "dessen Verfügbarkeit für die Open-Source-Bewegung sich einer Verkettung von Umständen, für die weder der Gründer jener später Pleite gegangenen Firma, die die Software ursprünglich entwickelte, noch Sun-Microsystems, die diese Firma später kauften und den Sourcecode - aus einem Mißverständnis heraus, wie ich nach wie vor fest überzeugt bin - noch die Open-Source-Bewegung, die zu dieser Verkettung der Umstände nicht das geringste beigetragen hat, etwas kann" - abschließend Komma + "verdankt".


Softwareentwicklung als soziale Tätigkeit


Software ist immer das Resultat von Gemeinschaftsarbeit. Das klingt trivial, und zwar immer genau dann, wenn man daran erinnert wird. Ansonsten bleibt das in der Praxis gerne ausgeblendet. Kontrollfrage: welcher Leser hat die Überschrift "Netzwerkprodukte" mit "benutzbare, dokumentierte, weitgehend fehlerfreie, vernünftig im Markt plazierte Software" - das Netzwerk nicht mit dem Internet, sondern dem sozialen Netz - assoziiert?

Neben dem Code braucht man eine Installersoftware, ein Handbuch, eine Verpackung, das Design jener Verpackung, und auch jene, die die CDs brennen und diese in eine Verpackung tun und das Paket zur Post bringen. Dummerweise - und da wird der Spaß an der Sache gehörig eingeschränkt - braucht man auch Leute, die all dieses planen und organisieren. Einen Plan braucht man auch, wenn man Software schreiben will; die Aufgabe, die Zusammenarbeit zwischen Menschen zu organisieren, spült aber regelmäßig einen Typus nach oben, der eine typische menschliche Eigenschaft in eher untypischem Maß aufweist: die Lust, sich anderen gegenüber durchzusetzen.

Ich will nicht in Abrede stellen, daß es Personen braucht, die in der Softwareentwicklung als Manager arbeiten. Das ist in Open-Source-Projekten der Fall, wo es darum geht, die Entwicklungsarbeit zu administrieren, erst recht natürlich in Firmen, die im Markt agieren und in denen Sales und Marketing eine entscheidende Rolle für das Überleben spielen.

Es gibt eine Reihe von Beispielen in meiner Industrie, die zeigen, wie die erfolgreiche Zusammenarbeit eines Zweierteams aus Entwickler und Kaufmann einen weltweiten Erfolg initiieren kann: Paul Allen und Bill Gates, Steve Wozniak und Steve Jobs, aber auch Karl Steinberg und Manfred Rürup. An diesen Beispielen läßt sich aber gleichzeitig ablesen, wer am Schluß über die Geschicke der Software bestimmt: es sind stets die Kaufleute und Manager.

Man könnte leicht verdutzt fragen, wieso mich das wundert. Schließlich sind das alles Firmen, die sich am Markt behaupten müssen. Da sei es kein Wunder, wenn jene wichtiger sind, die die wirtschaftlichen Notwendigkeiten im Griff haben als jene, die für den technischen Fortschritt verantwortlich zeichnen.

Tatsächlich sind es die Bewegungen am Markt, die dafür sorgen, daß die Manager die Entscheidungsprozesse immer stärker beeinflussen und am Ende das letzte Wort darüber haben, was technisch umgesetzt wird. Das heißt aber längst nicht, daß das Management ein Konzept davon hat, was sinnvoll für das Produkt ist, wie man die Kunden zufrieden stellt, und - entscheidend - wie man die Entwickler dazu motiviert, ein stetig besser werdendes Programm zu schreiben.



Urheberschutz


Wenn man mit Software Geld verdienen will, steht man vor dem gleichen Problem, das auch die Musikindustrie fast in den Ruin getrieben hat: die User können in beiden Fällen kostenlose Kopien herstellen, die sich in nichts vom Original unterscheiden. Man kann das für moralisch verwerflich halten, beim Gesetzgeber Initiativen zum Schutz des geistigen Eigentums einfordern und versuchen, über Kopierschutzmaßnahmen die Leute zum Kaufen zu zwingen: erfahrungsgemäß ist all dies nutzlos und verhindert nicht die Verbreitung privater Kopien. - Zunächst einmal halte ich es deshalb für extrem unintelligent, wenn man, wie die Musikindustrie, an einem Geschäftsmodell festhält, von dem man gesehen hat, daß es nicht funktioniert.

Dazu stellt sich die Frage, wie man jene Bits und Bytes definiert, aus denen eine CD oder eine Software besteht. Schließlich gehört es zum Wesen digitaler Daten, daß sie verlustfrei kopierbar sind. Darüber hinaus haben sie aber noch einen Inhalt - sie sind das Resultat einer geistigen Leitung, so wie das auch bei einem Buch der Fall ist. Schon seit Gutenberg streitet man über den Begriff des geistigen Eigentums, von einem Moment an also, als es zum ersten Mal möglich wurde, Gedachtes - bzw. dessen materiellen Niederschlag - mechanisch zu reproduzieren. Das Problem ist also satte fünfhundert Jahre alt, so daß man sich wundern muß, warum es bislang nicht gelöst wurde, sondern mit derartiger Leidenschaft auch heute im Zentrum der Debatte steht.

Im Zusammenhang geht es um zwei zentrale Aspekte, die konträre Interessen betreffen. Zum einen beanspruchen die Autoren Urheberschutz[1], weil sie ihre ökonomische Existenz gefährdet sehen, wenn sie nicht an der Verbreitung ihrer Ideen beteiligt werden. Zum anderen berufen sich Kopisten wie ihre Nutznießer auf die Meinungsfreiheit, für die der freie Fluß, die uneingeschränkte Verfügbarkeit von Ideen und Informationen unabdingbar sei.

In der ursprünglichen Variante dieses Konflikts kurz nach der Erfindung des Buchdrucks wird das sehr schön deutlich. Wo es zuvor das Privileg weniger war, durch das Lesen fremder Gedanken den eigenen Horizont zu erweitern, gab es plötzlich einen enormen Sprung beim Wissen über die Welt, verbreitet nicht nur über (immer noch kostbare) Bücher, sondern über massenhaft gedruckte Aushänge und Flugblätter. Ohne jenen technologischen Sprung bei der Reproduktion von Wissen wäre Luthers Reformation ebenso wenig denkbar wie die Rolle der Aufklärung bei der Vorbereitung von Demokratie und Rechtsstaat [2]. Dabei ist es dann ausgerechnet Kant, der eine Abhandlung "von der Unrechtmässigkeit des Büchernachdrucks" schreibt, und damit mutmaßlich die erste moderne Fassung des Urheberrechts anstößt.

  1. [1] Die Zusammenfassung des Goethe-Instituts ist gar nicht schlecht.
  2. [2] Was letztlich aus diesem Experiment wurde, steht auf einem anderen Blatt - und das wurde wiederum in Büchern diskutiert.


Monolithische Applikationen


Die neunziger Jahre werden als jenes Jahrzehnt in die Geschichte eingehen, in dem Microsoft das weltweit mächtigste und meist gefürchtete Unternehmen war - nicht nur in der Computerindustrie, sondern über die ganze Breite einer Wirtschaft, die mehr und mehr vom Computer abhängig wurde. Mit dem Verkauf von Betriebssystemen und Officepaketen ließen sich ungeheure Umsätze generieren. Es war die Zeit der monolitischen Applikationen, von Software, die - für einen bestimmten Bereich - alles zu können beanspruchte und Jahr für Jahr derart viele neue Features an Bord holte, bis selbst ein spezialisierter User nur wenige Prozent des Funktionsumfangs verstand und benutzte.

Über die Verfügbarkeit dieser Monsterapplikationen definierte sich die Marktstellung der unterschiedlichen Computersysteme. Weil es fast alles für Büro und Spielzimmer für Windows gab, gewann Microsoft fast jeden Krieg. Aber auch Apple war keineswegs die Livestyleveranstaltung heutiger Tage: man hat überlebt, weil man konkurrenzlose Software für die Designer und Layouter hatte - ohne QuarkXpress und die Sachen von Adobe, die erst sehr spät unter Windows liefen, wäre Apple untergegangen (auch die erste Musiksoftware lief exklusiv auf dem Mac - mit der Folge, daß Computeruser in der Musikerszene immer noch 20-30% Applekunden sind).

Dieses Bild wandelt sich etwa mit der Jahrtausendwende: da zeichnet sich ab, daß Google den Kampf um die beste Suche im Internet gewinnen wird. Plötzlich sind es nicht mehr jene Programme, mit denen man einen Computer in ein hochspezialisiertes Werkzeug zum Erstellen von Dokumenten jeder Art verwandelt, die den Ton angeben. In kurzer Zeit steht ein Unternehmen im Zentrum des Interesses, welches letztlich auf einem einzigen Algorithmus[1] basiert: auf einer einzigen Idee, einer einzigen in Programmform gegossenen Formel, die alle Dokumente der Welt bewertet und zugänglich macht.

  1. [1] Ich hatte das Thema schon zuvor am Wickel.


Google


Google ist heute natürlich mehr als nur als jene spartanische Suchmaske, mit der alles anfing - ein ganzer Zoo versammelt heute zahllose Webanwendungen unter diesem Label, einige davon von ebenso beeindruckender Tiefe und Komplexität (Google-Earth), wie jene Ungetüme des Microsoft-Jahrzehnts (Word, Photoshop, etc.). Dennoch stehen hier weniger die Applikationen im Mittelpunkt, als vielmehr die diesen angelagerten Dienste.

In erster Linie dreht es sich bei diesen Diensten um die Bereitstellung von Platz für Werbung. Google hat es als Erster und nahezu Einziger geschafft, der Werbeindustrie im Internet eine Plattform zu geben. Als alle Versuche mit Bannerwerbung und Popupupwindows gescheitert waren, erschien die Idee, die Suche nach bestimmten Wörtern mit Werbung zu verknüpfen, die mit jenen Wörtern in Zusammenhang steht, wie ein Wunder vom Himmel. Mir scheint dies das Grundkonzept von Googles Geschäftsmodell zu sein, das auch in den anderen Produkten zumindest vorbereitet ist: biete den Usern eine nicht zu schlagende Dienstleistung - und baue darin dann Werbung so ein, daß sie nicht stört, möglichst sogar als hilfreich empfunden wird.

Ohne ein Experte in den Googlewissenschaften [1] zu sein, sehe ich einen Schwenk weg vom Geldverdienen durch den Verkauf von Produkten, hin zu dem durch das Angebot von Diensten. Die in diesem Prozeß benötigte Software nimmt immer mehr jenen Charakter an, der ihr eigentlich immer schon zustand: sie wird zu frei verfügbarer Information [2].

Man könnte jetzt jubeln und zum Schluß kommen, daß endlich die Menschen wieder im Zentrum stünden, denen man einen Service bieten muß, um noch Geld verdienen zu können, und daß endlich Schluß sei mit der Vormacht der ihrer eigenen Logik folgenden Entwicklung von abstrakter Technik. Ich habe eher den Eindruck, daß das Gegenteil passiert: man macht Kasse, indem man ausgenudelte Technologie [3] ins Spiel bringt unter dem Vorwand, sie erstmals für eine breite Masse wirklich nutzbar zu machen. Dahinter versteckt sich letztlich ein Mechanismus, der behauptet, die Masse sei zu dumm, um auch bloß begrenzte Komplexität zu begreifen - um dann die Dinge in einem Maß zu simplifizieren, bis sie bloß noch falsch sind.

  1. [1] Derer gibt es zahlreiche, inklusive ihrer wichtigsten Disziplin namens SEO, auf die noch zurückzukommen wäre.

  2. [2] Bzw. zu einem Tool, mit dem sich Informationen bereitstellen lassen - die Grenzen sind hier fließend, weil Bilder und Texte in exakt demselben Form vorliegen, wie Software: als Bits und Bytes.

  3. [3] MapReduce ist der Name für jenen Algorithmus, den Google benutzt, um gigantische Datenmengen mit der Parallelisierung ebenso gigantischer Computerressourcen zu durchforsten. Erstaunlicherweise gibt es seit dreißig Jahren Besseres.

Nachtrag: Es bietet sich an, an dieser Stelle einen Exkurs über die Datenkraken einzuschieben.



Killerspiele


Wenn man über die Auswirkung von Computern auf unsere Gesellschaft sprechen will, kommt man nicht daran vorbei, in einer Debatte Stellung zu beziehen, die wieder und wieder aufbrandet und nur zwei extrem widersprüchliche Positionen zuzulassen scheint: ich spreche von der Diskussion über die sog. Killerspiele.

Auf der einen Seite findet man jene, die Computerspiele, in denen die virtuelle Ausübung von Gewalt eine Rolle spielt, am liebsten verbieten würden, weil sie meinen, mit ihnen würden Jugendliche so weit für die Auswirkungen von Gewalt abgestumpft, daß sie schließlich faktisch gewalttätig werden. Als Beispiele dienen immer wieder die Massaker in Littleton und Erfurt, in denen Schüler zur Waffe griffen, die zuvor auf ihren Computern mit Counter Strike und vergleichbaren Spielen das Schießen und Töten geübt hätten. [1]

Auf der anderen Seite befinden sich - wen wunderts - die Spieler selber, die auf die sportlichen Aspekte ihres Tuns verweisen und das Abschießen von virtuellen Gegnern eher mit Scheibenschießen als mit virtuellem Mord vergleichen. Das Argument, man trainiere hier Verhaltensweisen ein, um sie schließlich auch in der realen Welt zu gebrauchen, verwerfen sie mit dem Hinweis auf die zahlreichen Spieler, die nie gewalttätig würden und die familiären und sozialen Zustände, denen die Amokläufer entstammten und die allein Ursache derer Taten seien.

Ich kenne, aus persönlicher Erfahrung, beide Bereiche, um die es hier geht: den spielerischen Umgang mit Gewalt im Egoshooter am Bildschirm, und die systematische Ausbildung zum Töten. Ich habe mit wachsender Begeisterung "Tomb Raider" gespielt, als es zum ersten Mal auftauchte, später auch "Half Life" und "Unreal" (wobei ich eher Fan von Adventures bin, die eine Geschichte erzählen). Außerdem war ich fünfzehn Monate bei der Bundeswehr, mit einer Grundausbildung zum Infanteristen, bei der ich mit allen Handfeuerwaffen geschossen habe, die es gibt, inklusive Handgranate und Panzerfaust, und inklusive Nachtgefechtsübungen, bei denen mit scharfer Munition auf - in der Dunkelheit verblüffend realistisch wirkende, in zunehmender Nähe aufklappende - Menschenattrappen gefeuert wurde.

Beide Bereiche sind auf einem abstrakten Niveau tatsächlich miteinander verwandt: sie bewirken ein immenses Verschwinden der Selbstkontrolle und des Selbstbezugs. Die bewußte Person verschwindet hinter dem, was Bernt Spiegel [2] die Tiefenperson nennt, jenen triebhaften und reflexgesteuerten Teil in jedem Menschen, der keine Skrupel und kein Mitleid kennt.

Waffengebrauch enthemmt aber völlig anders, als dies das Spiel am Computer tut. Die physische Gewalt, mit der ein loshämmerndes Maschinengewehr die Schulter grün und blau schlägt, ist eher vergleichbar mit der - ebenfalls physisch erfahrbaren - Kraft, mit der ein beschleunigendes Motorrad auf den Körper einwirkt. Hier wie dort geht es um den Gebrauch von Werkzeug, mit dem sich die eigene Physis verlängern oder verstärken läßt. Letztlich geht es also um das Erlebnis des eigenen Körpers, ähnlich dem, das man auch vom Laufen oder Schwimmen kennt.

Computerspieler hingegen bewegen sich - sofern ich ohne weiteres von mir selber schließen kann - in einem geistigen Rausch, der den Körper vergessen macht, vergleichbar am ehesten mit der Wirkung von Alkohol (oder dem Selbstvergessen, das sich bei mir gelegentlich beim Hören von großer Musik einstellt). Der Körper verschwindet und ist nicht mehr Motor des (temporären) Abschieds von der Selbstkontrolle, sondern - im Gegenteil - ein Hindernis, das mit einschlafenden Gliedern oder Hunger- und Durstgefühl unerwünscht auf sich aufmerksam macht.

Um meine Argumentation überspitzt auf den Punkt zu bringen: wie kann man jemanden, der sich unter Drogen setzt, verdächtigen, daß er Kampfsport trainiert? [3]

  1. [1] Trotz der Gefahr, durch die Wiederholung altbekannter Argumente zu langweilen: der Umstand, daß man bei einem Rennsportfan Formel-1-Spiele findet, verwundert niemanden, und niemand würde auf die Idee kommen, daß man sich für Rennsport begeistert, weil man solche Spiele spielt. In der Debatte um Killerspiele wird aber genau dieser rhetorische Trick verwendet.

  2. [2] Bernt Spiegel. Die obere Hälfte des Motorrads. Stuttgart 2006.

  3. [3] Ich bin der Letzte, der die Wirksamkeit mentalen Übens bestreitet - und etwas anderes ist die Ausbildung am Simulator ja nicht. Meine Argumentation zielt auf die Motivation, etwas zu tun oder zu lassen - und die kann man nicht quer durch die Ebenen ziehen. Oder? - Forschungsbedarf. Nachtrag: Vergleiche auch den Eintrag über Soldat und Buddha


Web 2.0


Unter den Teenagern und Twens ist es heute eine Selbstverständlichkeit, sich des Internets zu bedienen, um miteinander zu kommunizieren. Eine wachsende Bedeutung gewinnen dabei Portale des "social net" wie Facebook oder MySpace, in Deutschland deren Kopien wie StudiVZ und SchülerVZ, die den fast schon "klassischen" Kommunikationsformen wie Foren und Chatrooms den Rang abzunehmen drohen.

Die Profile, die man hier anlegt, sind am ehesten mit einer eigenen Website vergleichbar, bieten darüber hinaus aber umfangreiche Möglichkeiten, sich mit den Seiten anderer Teilnehmer zu vernetzen. Der Sport besteht darin, möglichst viele virtuelle "Freunde" einzusammeln, die das eigene Online-"Leben" privilegiert begleiten, etwa, indem sie exklusiven Zugriff zu Tagebuchnotizen oder Bildern bekommen.

Neu ist das nicht: bei Twitter nennt man das "Followers", in den Blogs gibt es die "Blogroll", im wirklichen Leben ist es die Clique, in der man die Köpfe zusammensteckt und die Fotos von der letzten Party - mehr oder weniger hämisch - kommentiert. Dennoch erscheint es vielen Kolumnisten bedrohlich, was die jugendlichen Nutzer über sich selbst in der Öffentlichkeit preisgeben, bzw. was sie über andere dort äußern.

Tatsächlich bleibt es nicht ohne Folgen, wenn man via Google die Spuren all derer über Jahre und Jahrzehnte verfolgen kann, die sich unbedacht geäußert oder Fotos der letzten Sauftour oder gar ein privates Sexvideo online gestellt hatten. Der Personalchef, der eine Bewerbung abklopft, mag sich über solch freimütige Auskunft bedanken. Und nein: die Tatsache, daß jemand ein Medium zu nutzen versteht, heißt längst nicht, daß er sein Funktionieren begreift - soll sagen: die Teens und Twens verfolgen hier ihre eigenen Zwecke, ohne die Konsequenzen zu bedenken.

Auch der Hohn, den man über Lehrer oder pickelgesichtige Mitschüler ausgießt, ist keine Erscheinung, für die es Computer braucht - Netzwerke, die solchen verbreiten, gab es schon immer. Natürlich macht es aber schon einen Unterschied, ob die Information, daß Mitschüler Maier regelmäßig von seinem Vater verprügelt wird, oder daß Lehrer Müller eine Schülerin vögelt, in einem Schulgebäude zirkuliert, oder ob man sie weltweit ergoogeln kann.

Dennoch sollte man die Kirche im Dorf lassen. Die wirklich extremen Excesse sind schon immer vom Boulevard recherchiert und in die Breite getragen worden - und die Tatsache, daß 90% der SchülerVZ-User dem Lehrer Schmidt ein "Ungenügend" verpassen, regt das Umfeld ebenso sehr auf wie vor hundert Jahren, wie es den Rest der Welt nicht im mindesten interessiert.



Kopierschutz


Als Steinberg im Sommer 2001 die neuen Büros in Hamburg-Rahlstedt bezog - die zu dem Zeitpunkt noch eine größere Baustelle waren, mit fehlenden Jalousien vor den Fenstern und ungepflasterten Parkplätzen -, hatte jemand die Idee, die Konferenzräume nach jenen Produkten zu benennen, die in der Vergangenheit desaströs geendet hatten, und zwar je nach Größe des Raumes in Relation zum dazugehörigen Desaster. So tagt die Entwicklerabteilung, wenn sie eine Vollversammlungen abhält, im „Masterscore” - das war Anfang der 90er das Notationsprogramm im Portefeuille von Steinberg, geschrieben von einem Programmierer, der nicht vor Ort in Hamburg war, und auch mit externer Hilfe beim Marketing. Das Programm hatte aufgrund seiner Instabilität einen extrem schlechten Ruf, und irgendwann sollten Wolfgang Kundrus, Werner Kracht und ich herausbekommen, wie schlimm es denn nun wirklich steht. Ich erinnere mich noch allzu gut an unseren gemeinsamen Test von „Masterscore” auf meinem Atari: das war wie Schiffe-Versenken, ungefähr bei jedem dritten Klick stürzte der Rechner ab. Es brauchte kaum eine halbe Stunde, um zum Schluß zu kommen, daß da nichts mehr zu retten ist.

Der größte Raum, der auch für die mittlerweile mehr als hundert Mitarbeiter bei einer Betriebsversammlung reicht, trägt den Namen „Topaz”. Die mit dem Projekt dieses Namens verknüpfte Geschichte spielt Mitte der 80er (also noch vor meiner Zeit), und handelt von dem überaus ambitionierten Versuch, den Apple-Rechnern jener Tage das Aufnehmen, Abspielen und Bearbeiten von Audiodateien beizubringen. Das ging damals nur mit höllisch teurer spezialisierter Hardware, und der Anlauf, dies zumindest mit der Benutzeroberfläche eines Macintosh zu verbinden, scheiterte grandios. Nachdem endlos Geld in das Projekt geflossen war, gab es zum Schluß gerade zwei(?) Installationen - und selbst die waren letztlich unbenutzbar. Wenn ich das richtig weiß, ist Steinberg damals knapp an der Insolvenz vorbeigerutscht - mit den Folgen dieses Experiments waren wir jedenfalls noch Jahre später beschäftigt.

Es gab noch mehrere andere kritische Momente in der Firmengeschichte, wovon einige sich der Fehleinschätzungen in der Verkäuflichkeit bestimmter Produkte verdankten. Die zwei oder drei wohl schlimmsten Beinah-Katastrophen entstanden jedoch durch jeweils monatelangen Verzug bei der Fertigstellung einer neuen Cubase-Version. Interessanterweise - und deshalb erzähle ich dies hier - waren hingegen all die Situationen eher unkritisch, in denen unser Kopierschutz geknackt wurde (das zeigt allein die Tatsache, daß kein Meetingraum nach jener Firma benannt ist, die seit jeher unsere Kopierschutz-Dongles konzipiert, Syncrosoft).

Der MI-Markt ist verhältnismäßig klein, und da ist jede Kopie, die illegal genutzt wird, wesentlich schmerzhafter als etwa in einem Massenmarkt, für den Office-Software geschrieben wird. Steinberg hat bereits sehr früh, längst vor den Tagen von Cubase, seine Software mit Hardware-Dongles zu schützen versucht. Dabei hat das eigentlich nur in einer einzigen Periode wirklich funktioniert (zwischen dem initialen Cubase von 1989, bis zum Crack der Version 3.0 für den Atari Mitte der 90er). Sonst standen immer sehr rasch Cracks zur Verfügung, ob für »TwentyFour« Mitte der 80er, oder »Cubase SX« nach 2001. Es war ein ständiges Kräftemessen zwischen den Hackern, die den Wert ihrer Arbeit zu schützen versuchten, und den Crackern, die das allein aus sportlichen Gründen nicht respektieren wollten. Gewonnen haben letztlich immer letztere, und zwar einfach deshalb, weil jedes Stück Software zwangsläufig Fehler (Bugs) hat, und ein einziger Fehler in der Implementierung eines Kopierschutzes diesen kompromittiert.

Trotzdem - und darauf will ich hinaus - hat Steinberg auch in Zeiten, als ein funktionierender Crack vorlag, immer Umsätze gemacht. Unser Marketing ist zwar der Meinung, daß Kopierschutz unabdingbar ist - sonst würde man kaum die Manpower für dessen Entwicklung aufwenden und die teuren Syncrosoft-Lizenzen bezahlen (und würde erst recht nicht Syncrosoft kaufen, wenn sich, wie kürzlich, dazu die Gelegenheit ergibt). Tatsächlich gibt es sogar ein wichtiges Argument, das ich nicht vom Tisch bekomme: je weiter östlich man sich auf der Landkarte bewegt, desto stärkter nimmt die Produktpiraterie zu (nicht nur in Bezug auf Software), und desto unwilliger werden Händler oder Vertriebe, ungeschützte Software in den Bestand zu nehmen: es gibt in Osteuropa oder Fernost niemanden, der sie kauft, will er sich nicht im Kreis von Familie und Bekannten der Lächerlichkeit preisgeben.



Ich will gar nicht grundsätzlich[1] gegen Kopierschutz argumentieren - m.E. ist es das unbestrittene Recht jeder Software-Firma, sich gegen Klau und unentgeltliche Verbreitung ihres Know-How zu wehren; Open-Source vertritt hier keineswegs ein moralisch überlegenes Konzept. Es ist aber allein aus technischen Gründen eher ungeschickt, einen wirtschaftlichen Plan zu verfolgen, der auf der Voraussetzung basiert, daß ein Kopierschutz auch hält. Man kann hohe Summen darauf wetten, daß die Community der Cracker ihr Ziel auch erreicht, wenn sie nur ausreichend motiviert ist - und sie ist dies ausgerechnet immer dann, wenn eine Software erfolgreich ist[2]. Letztlich hatte Steinberg Glück, daß trotz der Cracks, und obwohl man sich auf den Kopierschutz verlassen hatte, das Geschäft weiterging - ob dennoch Schaden entstand, wird seit Jahren in der Firma ebenso begeistert wie kontrovers diskutiert.

Dabei habe ich sogar den Verdacht, daß der Crack von Cubase für den Atari Mitte der 90er Steinberg letztlich sogar genutzt hat: auf einmal war es jedem möglich, das Programm zu verwenden - und zwar auch solchen Usern, die nie das Geld in eine doch recht teure Originalversion investiert hätten[3]. Der Begriff „Cubase” wurde gerade in dieser Zeit zu einem Synonym für den „Sequenzer”, etwa so, wie der Name „Word” sofort mit „Textverarbeitung” assoziiert ist - wofür die freie Verfügbarkeit zumindest einen Anteil hatte. Als später der ganze Rummel um „VST” (Virtual Studio Technologie) losging, brauchte das Marketing sich über mangelnde Resonanz keine Sorge zu machen: nicht zuletzt aufgrund der weiten Verbreitung durch Raubkopien machte das Thema rasch die Runde, und brachte reichlich Verkäufe. Manch einer, der mit einem Crack auf dem Atari gestartet war, mag erst über diese Schiene begriffen haben, was da auf einmal an neuen Möglichkeiten geboten wird - und wurde am Ende zum zahlenden Kunden.[4]

Richtig eklig wird es, wenn eine gecrackte Version besser funktioniert als die legale Variante - das ist uns gelegentlich tatsächlich unterlaufen, und hat, wie man sich denken kann, unserer Reputation nicht gerade gut getan. Gerade die 3er-Versionen der letzten Jahre waren zeitweilig derart mit Aufrufen des USB-Kopierschutzdongels durchsetzt, daß die Performance bei bestimmten Operationen deutlich in den Keller ging - nicht in der Audio- und MIDI-Engine, aber - schlimm genug - bei bestimmten Tasks in der Benutzeroberfläche. Spätestens in dieser Phase habe ich über die Treue unserer User nur gestaunt.[5]

Man kann am Beispiel der Plattenlabels sehr gut ablesen, was passiert, wenn man sich beim Vertrieb von digitalen Medien darin verbeißt, den physikalischen Datenträger zu verkaufen - das muß am Ende grandios scheitern, weil in der heutigen Realität so etwas wie das Internet existiert, dem auch mit schärfster Gesetzgebung und einer noch so großen Zahl Anwälte nicht beizukommen ist. Das Wesen von digitalen Daten ist ihre Kopierbarkeit, ob man das gut findet oder nicht (Musikdateien und Programme unterscheiden sich auf dieser Ebene nicht im mindesten).

Die Geschäftsmodelle liegen m.E. woanders, und im Bereich von Open-Source wird momentan erfolgreich vorgeführt, wo sie liegen: man kann angemessen Geld verdienen, indem man individuellen Service rund um die Daten anbietet. Dabei ist es egal, ob man Linux so aufbereitet, daß es in Form von Distributionen für den Handel taugt, oder ob man seine Musik frei im Netz verteilt und parallel 300-Dollar-Fanpakte verkauft.

Aber ich will dem Marketing nicht erklären, wie sich mit Konzepten von Open-Source Geld verdienen läßt - mir geht es darum, klar zu machen, daß es sich auch dort um ein Modell handelt, welches in stetig zunehmendem Maß versucht, am Markt erfolgreich zu sein. Das ist ein zentraler Punkt, den man m.E. in der Debatte gründlich übersieht: freie Software ist keine Vision einer freien Gesellschaft, sondern ein Geschäftsmodell innerhalb der bestehenden Wirtschaftsordnung, das überraschend gut funktioniert[6]. Dabei bestreite ich gar nicht, daß viele Forderungen der Open-Source-Bewegung letztlich emanzipatorischen Charakter haben - der Kampf gegen Patente auf Software und die Erweiterung des Begriffs der „Redefreiheit” auf den Austausch digitaler Daten geht natürlich in genau die richtige Richtung. - Meine Kritik geht einen - prinzipiellen - Schritt weiter.

  1. [1] Jedenfalls nicht, solange man die Arena der Debatte auf die real existierende Welt begrenzt.
  2. [2] Guter Kopierschutz scheint sie sogar erst recht herauszufordern - der Schutz in Cubase SX war eine richtig harte Nuß, und ich kann nur staunen, wie der regelmäßig geknackt wurde.
  3. [3] Das Argument ist nicht neu, wird aber gerne beiseite gedrängt: wer einen Crack nutzt, ist nicht zwangsläufig ein verlorener Kunde, sondern hätte das Programm möglicherweise auch sonst nicht gekauft - sei es, weil er nicht über das Geld verfügt, oder weil ihm das Preis-Leistungs-Verhältnis nicht angemessen erscheint.
  4. [4] Interessanterweise war übrigens der Schutz der ersten VST-Versionen für den Mac relativ rasch ausgehebelt - und trotzdem haben wir einen unverhältnismäßig hohen Anteil an Versionen für diese Plattform ausgeliefert, wenn man dies am damaligen Marktanteil von knapp 10% von Apple mißt.
  5. [5] Zu diesem Thema wäre noch einiges zu sagen: Cubase-User - oder auch solche von Produkten der Konkurrenz - sind weniger Kunden als vielmehr Fans. Richtig gerecht wird man dem man das m.E. noch immer nicht.
  6. [6] Dies tut es aus einem einfachen Grund: es akzeptiert die Gegebenheiten, statt sie sich zurecht zu biegen.
5 Kommentare

Ideen


Wenn eine Debatte Musik, Texte, oder Software verhandelt, dreht sie sich zunächst einmal um Information. Das ist natürlich nur die übergeordnete, sehr abstrakte Kategorie: Text oder Musik z.B. können zu Kunst werden, Menschen können über Informationen zu Wissen gelangen, und Software kann dazu dienen, Informationen zu bearbeiten, statt unmittelbar von menschlicher Wahrnehmung interpretierbar zu sein. So interessant diese Übergänge auch sind, im Moment schiebe ich sie als unerheblich fürs Thema beseite.

Informationen müssen zusammengetragen und vermittelt werden, von Komponisten und Interpreten, Autoren und Verlegern, Softwareentwicklern und den unterschiedlichen Strukturen, die für die Verbreitung von Software sorgen. Auf der anderen Seite stehen ihre Rezipienten, die Hörer, Leser, und User. Die einen wollen von ihrer Tätigkeit leben können; die anderen wollen die Informationen zu einem möglichst günstigen Preis nutzen. Soweit ist das ein Interessenkonflikt, der immer auftritt, wenn knappe Resourcen über Marktmechanismen verteilt werden sollen. - An dieser Stelle habe ich drei Fragen: (1) Sind diese Resourcen denn wirklich knapp? (2) Sind Informationen - Ideen - tatsächlich vergleichbar mit materiellen Resourcen? (3) Kann jemandem eine Idee gehören, wie etwa ein Stück Land, oder eine industrielle Produktionsanlage?

(1) Es gab schon immer eine kleine Minderheit, die vor Ideen und Kreativität sprudelte, und damit Gesellschaften - ja ganze Epochen - bereicherte, vorantrieb, und prägte. Die Tatsache, daß es sich um eine Minderheit handelt, hat nichts damit zu tun, daß die Ressource knapp wäre. Auf diese Idee kommen vielleicht Verleger und Vertreter der Musikindustrie, schwerlich aber Schriftsteller oder Komponisten [1].

(2) Ideen sind die Grundlage der menschlichen Existenz. Das zeigt sich an der amerikanischen Verfassung oder Napoleons Code Civil ebenso, wie am Bauplan für eine Brücke oder der Navigationssoftware der Mondlandefähre. Sie sind das in weit grundlegendem Maße als materielle Dinge wie Nahrung oder Häuser, weil menschliches Überleben darauf beruht, daß es geplant wird. Die ökologische Nische des Menschen ist sein Vermögen des planerischen Blicks in die Zukunft.

(3) Ideen sind per se gesellschaftliches Eigentum, weil sie nur im gesellschaftlichen Zusammenhang entstehen können [2]. Das gilt aber auch für den (landwirtschaftlichen) Boden, der nur von einer Gemeinschaft bearbeiten werden kann, und - mehr noch - für die Fabrik, deren Aufbau und Produktion sich den zahllosen Händen und Köpfen einer kaum überschaubaren Vielzahl von Arbeitern und Speziallisten verdankt. Insofern würde ich die Frage nach der Legitimität des Besitzes von Ideen bejahen - wenn man mich denn vom Recht auf privaten Besitz von im gesellschaftlichen Zusammenhang geschaffenen Ressourcen überzeugen könnte.

  1. [1] Das klingt wohl doch ein wenig kryptisch...
  2. [2] Das Konzept des "Genies", das aus sich selber heraus nie zuvor Gedachtes erschafft, ist eine Erfindung der Romantik, mit dem eine herausragende Begabung ins Übernatürliche verklärt wird - i.d.R. zum wirtschaftlichen Nutzen des zum Genie verklärten (oder jener, die sein Werk vermarkteten).
2 Kommentare

Patente


Mit den Restriktionen des Urheberrechts sind die meisten schon in Berührung gekommen, einfach, weil es so dicht mit unserem Alltag verwoben ist. Anders sieht dies bei seinen beiden Geschwistern aus, dem häßlichen Schwesterlein mit Namen Markenschutz, und dem martialischen Bruder, der gerade dabei ist, sich zum Präsidenten der Welt zu putschen, dem Patentrecht.

Der Markenschutz bringt die bekannten Merkwürdigkeiten hervor, wie eine Farbe, die plötzlich Eigentum eines Konzerns sein soll (das Magneta der Telekom), und einen als Marke eingetragenen Buchstaben (das "i" vor Begriffen wie iPod etc. durch Apple). Da fallen all die Versuche kaum noch auf, Begriffe des täglichen Lebens zu schützen. Im Großen und Ganzen ist das eine Geschichte, über die man eher amüsiert grinst - wenn man nicht das Pech hat, z.B. in einem Blog solch ein Markenzeichen unberechtigt zu benutzen, und plötzlich eine Abmahnung ihres Inhabers im Briefkasten hat.

Die Ursachen sind dieselben, die Folgen ungleich dramatischer: das Patentrecht hat sich dahin entwickelt, daß man ziemlich jede Entdeckung anmelden und schützen lassen kann, wodurch man sie mehr oder weniger in seinen Besitz bringt. Das betrifft nicht nur Verfahren in der Software wie Copy&Paste, an dem IBM die Rechte hält (und glücklicherweise darauf verzichtet, sie durch seine Rechtsabteilung durchzusetzen). Viel verheerender sind die Folgen der Anwendung des Patentrechts auf biologische und medizinische Funde. Jene Medikamente etwa, mit denen man die Folgen von AIDS entscheidend mildern kann, sind für jene Länder der Dritten und Vierten Welt, in denen die Seuche besonders heftig wütet, unbezahlbar - und die Herstellung von billigen Generika wird von der Pharmaindustrie erbittert bekämpft.

Natürlich sind das - und ich deute hier nur einiges an, weil es über das Thema hinausschießt - nicht etwa Auswüchse eines ansonsten vernünftigen Systems. Es sind Symptome einer Gesellschaft, die alle Werte verliert, weil ihr alles zum Wert wurde. Jeder Lebensbereich wird darauf abgeklopft, ob er Dinge enthält, die man zur Ware machen und handeln kann; all das, wo dies nicht gelingt, wird marginalisiert und aus dem gesellschaftlichen Kontext verstoßen. Die absurde Pointe dieser Veranstaltung kommt zutage, wenn die Produktion sich monopolisiert: der Markt schafft sich selber ab, Waren werden nicht mehr gehandelt, sondern zu diktierten Preisen verkauft.

In der industriellen Produktion hat es Jahrzehnte der Akkumulation des Kapitals gebraucht, um die heutigen weltweiten Oligopole und Monopole zu schaffen. Bei der Aneignung der intellektuellen Resourcen durch die Weltwirtschaft ist man einen Schritt weiter: man nutzt von Beginn an die Formen des Rechts, um den Markt zu verteilen. Man setzt kein Kapital mehr ein für Maschinen, um materielle Güter immer rationeller erzeugen zu können; man bezahlt die Köpfe der Rechtsanwälte, um den Anspruch an der Verfügung über jene der Erfinder durchzusetzen.

Ich bin weniger weit vom Ursprungsthema weg, als ich noch zu Beginn der Arbeit an diesem Eintrag dachte.



Wissen als Ware


Wissen ist immateriell - und damit letztlich dagegen immun, als Produkt auf den Markt gebracht und verkauft zu werden.

Handelbare Waren sind immer Gegenstände, die man tauschen kann. Dies setzt voraus, daß sie sich von einem Ort an einen anderen versetzen lassen. Wissen kann man zwar auch bewegen - es bleibt aber immer gleichzeitig bei seinem ursprünglichen Besitzer: es wird transferiert[1], nicht aber versetzt. Dadurch ist es seinem Wesen nach nicht tauschbar: wenn ich jemandem etwas gebe, damit ich dafür etwas anderes erhalte, setzt dies voraus, daß der ursprüngliche Besitzer hinterher im Besitz des Tauschgegenstandes ist, und seinen eigenen dafür hergegeben hat. Wenn ich jemandem einen Gegenstand gebe, damit er mir sein Wissen mitteilt, hat der andere hinterher meinen Tauschgegenstand sowie das ursprüngliche Wissen in seinem Besitz - für mich wäre dies ein denkbar schlechtes Geschäft.

Das Schreiben von Software ist Wissensproduktion[2].

Der Verkauf von Software funktioniert letztlich nur über eine Reihe von Tricks[3], mit denen versucht wird, den Austausch von Wissen dem Austausch materieller Dinge gleichzusetzen. Dabei ist Software in ihrem Wesen eben kein Ding, das sich bewegen läßt, sondern Information, die man praktisch kostenlos transferieren kann.

Wo der Arbeiter bei VW am Fließband physische Gegenstände produziert, die bei ihrer Nutzung irgendwann unbrauchbar - abgenutzt - werden, erzeugt ein Softwareentwickler eine immaterielle Struktur, die sich beliebig kopieren und endlos oft nutzen läßt. Wenn man bei der Produktion von materiellen Gütern ständig Arbeit investieren muß, um vernutzte Gegenstände zu ersetzen, wird Software nicht obsolet, weil sie kaputt geht, sondern weil sie beständiger Innovation unterliegt. (Eine gewisse Parallele zur materiellen Welt findet sich im vermögenden Autoliebhaber, dem schon die vorletzte Variante eines Modells wertlos vorkommt, so daß er sie gegen das letzte Facelift tauschen muß. Hier würden all jene jubeln, die solchen Zwängen nicht unterliegen und den gebrauchten Jahreswagen bis in alle Ewigkeit und ohne jegliche Reparatur weiterfahren könnten. Solcher Jubel wäre im Softwarebereich ohne weiteres angebracht).

Die Produzenten digitaler Informationsgüter können etwas, was noch kein seriöser Warenproduzent je gekonnt hat und je können wird, etwas, was mit Tauschbeziehungen strikt unvereinbar ist: Sie sind in der Lage dasselbe Produkt, denselben Klingelton oder dieselbe Software, beliebig oft an den Mann oder die Frau zu bringen, und das, ohne wegen Betrugs vor Gericht zu landen!

(Ernst Lohoff: Der Wert des Wissens. Kurzfassung.)

  1. [1] Ich suche noch nach einem Begriff - "Transfer" ist im Sprachgebrauch ja ein Synonym für "Überführung", also als Antithese eigentlich nicht brauchbar. Gesucht ist ein Wort für "Transfer durch (ungegenständliche!) Kopie", im Gegensatz zum "Transfer durch Bewegen".
  2. [2] Diese These liegt eigentlich auf der Hand; ich habe dazu aber noch eine Reihe von Fragen, und verschiebe eine ausführlichere Debatte auf später.
  3. [3] Diese "Tricks" sollte ich bei Gelegenheit näher beleuchten - Stichworte: Anbindung von Soft- an Hardware auf der einen, Maßgaben des Gesetzgebers auf der anderen Seite.


Agile Softwareentwicklung


Wenn eine Firma ihr Geld mit der Entwicklung von Software verdienen will, gibt es eigentlich genau ein zentrales Problem: den Release-Termin. Es ist dabei relativ unwichtig, welche Features implementiert wurden, oder ob die Version stabil läuft: entscheidend ist der Zeitpunkt, an dem das Produkt auf dem Markt erscheint. Nur so lassen sich Geschäftspläne aufstellen, Marketing-Kampagnen planen, die Belieferung der Händler und Vertriebe koordinieren etc.pp.

So sehen das jedenfalls Sales und Marketing - und ich überspitze da nur sehr wenig.

In der Entwicklung hat man mit ganz anderen Problemen zu tun. Das beginnt in der Produktplanung: welche Features müssen implementiert werden und sind unverzichtbar, weil a) man ein Alleinstellungsmerkmal für das Release braucht, b) die Konkurrenz die auch hat, oder c) sie den Kunden längst versprochen waren? Mit den Auflistungen, die aus diesen Fragen resultieren, gerät man unvermeidlich in einen Konflikt mit der Entwicklung. Dort sieht man sich die Anforderungen an - und erstarrt. Eigentlich braucht man die Feature-Listen dort auch gar nicht erst zu analysieren. Es ist von vornherein klar, daß da Sachen draufstehen, die in der vorgegebenen Zeit nicht ansatzweise zu schaffen sind - schon gar nicht, wenn man das „Pflichtenheft” (wie das in Zeiten hieß, in denen man noch von „EDV” sprach) handwerklich sauber, ohne allzu viele Bugs, und mit einer gewissen Tiefe implementieren will.

Es ist fast schon ein eingespieltes Ritual, an dem kaum zu rütteln ist: die Sales-Leute legen einen Abgabetermin fest, die Produktplaner planen das ultimative Release mit Features, auf die die User gleichsam ein Recht zu haben scheinen - und die Entwickler regen sich darüber auf, daß hier Leute am Werk sind, denen sie jeglichen technischen Verstand abzusprechen bereit sind. Die Planung zieht sich schon im Vorfeld endlos hin, weil jedes Detail darauf abgeklappert wird, wie dringend es benötigt wird, und wie viel Zeit seine Implementierung fressen wird, wobei natürlich beide Parteien maßlos übertreiben, und - sofern der Release-Termin noch verhandelbar ist - sogar drei Parteien damit beschäftigt sind, die Brisanz ihrer jeweiligen Nöte zu betonen.

In diesem Spiel kommt man regelmäßig an einen Punkt, wo etwas grundlegend schief geht. Entweder, es wird gnadenlos Geld verbrannt, weil die Marketingmaschine loslief, obwohl man kein Produkt hat, das man verkaufen könnte - oder man wirft ein Produkt auf den Markt, das von den Usern nicht akzeptiert wird und der Firma eine massive Beule im Image verpaßt. Um sich vor Schuldzuweisungen zu schützen, geht man bei den nächsten Releases Schritt für Schritt immer weiter in der Verschriftlichung von Verhandlungsergebnissen - man ist auch firmenintern plötzlich dabei, letztlich Verträge zwischen den Abteilungen auszuhandeln. Richtig schwierig wird das dann, wenn die unterschiedlichen Aspekte - Sales, Produktdesign, Entwicklung - über mehrere Firmen verteilt sind - Steinberg arbeitet streckenweise auch mit Third-Party-Unternehmen zusammen, und ich bin heilfroh, daß ich damit nie zu tun hatte.

Dies ist gewissermaßen die Ausgangslage, auf die „agile” Methoden eine Antwort suchen. Ich beschreibe das so drastisch (obwohl man das noch wesentlich schärfer zuspitzen könnte, und sich haufenweise Geschichten erzählen ließen, die teilweise bizarrer sind, als ein Außenstehender sich das vorstellen kann), weil man öfters der Meinung zu sein scheint, daß „Agile” ein Triumph der Bedürfnisse der Entwickler sei. Das ist eine stark verengte Wahrnehmung (auch wenn die Entwickler tatsächlich produktiver werden können und definitiv mit mehr Spaß an solchen Projekten beteiligt sind), die darüber hinweg sieht, daß man hier versucht, kreative Prozesse steuerbar zu machen - und zwar für eine Kapitalisierung ihrer Ergebnisse.

(Um möglichen beleidigten Reaktionen zuvor zu kommen: ich bin keineswegs der Meinung, daß irgend eine der beteiligten Parteien hier das Recht auf ihrer Seite hätte (ich verweise hier auf meine Notizen über Vernunft und Interesse). Ich habe natürlich weniger Probleme, die Argumente der Entwicklung zu verstehen - insofern sind die hier vielleicht ein wenig pointierter formuliert. Dennoch kann ich nachvollziehen, daß Planbarkeit völlig unverzichtbar ist, wenn man ein Produkt im Markt platzieren will - und vom Verkauf des Endprodukts leben dann alle Beteiligten, auch und gerade die so wenig geschäftstüchtigen Hacker.)



Das „Manifesto for Agile Software Development” sagt:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Quelle

Eric S. Raymond wundert sich, warum man diese Punkte so hervorhebt, obwohl sie bloß all jene Grundsätze zusammenfassen, denen die Community der Hacker schon seit jeher folgt (wobei er hervorhebt, daß „Agile” diese Grundsätze besser formuliert, als dies je zuvor geschah[1]). Damit liegt er zunächst natürlich völlig richtig - übersieht dabei aber eine ganze Reihe von Werkzeugen, die eine zentrale Rolle für Scrum und Co. spielen.

Die agilen Methoden versuchen keineswegs, den Entwicklern ein schönes Leben zu verschaffen; sie stellen lediglich in Rechnung, daß Softwareentwicklung ein kreativer Prozeß ist, den man nach anderen Regeln organisieren muß als z.B. die Arbeit einer Sekretärin, wenn man erreichen will, daß für Sales und Marketing Planbarkeit entsteht. - Auf den letzten Halbsatz kommt es an: man versucht hier, Kreativität Regeln der Verwertung zu unterwerfen.

Softwareentwicklung funktioniert letztlich nicht anders als z.B. das Schreiben eines Buchs. Es passiert regelmäßig, daß irgendein Einfall wie aus dem Nichts auftaucht, ausprobiert wird, um verworfen oder weiter gesponnen zu werden. Dabei gehört es zur gängigen Praxis, daß ein vielversprechender Ansatz, der ausgiebig diskutiert und spezifiziert wurde, sich nach längerer Zeit als Sackgasse herausstellt. Umgekehrt kann ein zunächst viel zu kompliziert (oder auch zu blauäugig) erscheinendes Design dazu führen, daß sich bei der Betrachtung eines Prototypen überraschende Perspektiven ergeben, an die - in der Phase der Spezifikation - niemand gedacht hatte.

Kreativität ist nicht plan- oder berechenbar. Man kommt nicht weiter, wenn man versucht, sie gewaltsam zu erzwingen. Es ist also eine elementare Anforderung, daß man auf Änderungen - möglicherweise sogar in Bezug auf die strategischen Ziele - vorbereitet ist und ihr Auftauchen als notwendigen Teil des Prozesses begreift.

Der erste Schritt besteht darin, daß man in iterativen Zyklen vorgeht. Das ist nicht neu - eine These in ESR's Buch „The Cathedral and the Bazaar” lautet: „Release early. Release often. And listen to your customers”. Bei den „Agilen Methoden” geht es natürlich - wie bei Open Source - zunächst darum, möglichst rasch Feedback vom User zu bekommen, um die Qualität der Features zu sichern. Daneben aber will man zwei Dinge erreichen, die den politischen Ideen von Open Source[2] letztlich entgegen stehen: man will die Vertragsverhandlungen mit dem User (der hier der zahlende „Customer” ist) vereinfachen - zumal ein zufriedener Kunde es nicht nötig hat, die Gerichte zu bemühen. Zum zweiten - und das ist in meiner Sicht der zentrale Punkt - bezieht man in die Iterationen auch die Aufwandsabschätzungen ein.

  1. [1] Den Begriff „Refactoring” biegt er in dem Artikel allerdings in einer Weise, daß sich mir die Fußnägel zusammenrollen.
  2. [2] Nachtrag: Es gibt einen feinen, aber entscheidenden Unterschied zwischen „Open Source” und „Free Software”, den ich nicht recht auf dem Zettel hatte, als ich Open Source (wie oben im Text) politische Qualitäten unterstellte.



Handwerkszeug


Noch in den sechziger Jahren war es unabdingbar, daß ein Autofahrer sich zumindest grundlegend mit der Technik seines Fahrzeugs auskennen mußte, wollte er nicht riskieren, unvermittelt mit rauchendem Motor mitten in der Landschaft liegen zu bleiben. Knapp zwanzig Jahre später (als ich meinen Führerschein machte) brauchte man Kenntnisse der Verkehrsregeln; ansonsten setze man sich auf den Fahrersitz und fuhr - im Zweifel sogar mit automatischer Kupplung - einfach los.

Zu dieser Situation finden sich eine Reihe Analogien, wenn man den Gebrauch von Computern Mitte der achtziger Jahre mit jenem von heute vergleicht. Als ich anfing, mich mit dieser Technik auseinander zu setzen, ging die Zeit gerade erst zu Ende, in der man BASIC-Programme schrieb, um Kontakt mit dem Betriebssystem zu nehmen. Schon damals begann bereits die Ära von Maus und Desktop, Fenstern und Menus - trotzdem war es längst noch nicht möglich, den technischen Hintergrund komplett auszublenden: spätestens, wenn man einen Drucker anschließen wollte, mußte man in Schichten des Betriebssystems einsteigen, die nicht mit der Maus, sondern mit einem Texteditor zwecks Bearbeitung von Konfigurationsdateien bedient wurden.

Wo man selbst als "normaler" User gelegentlich unter die Motorhaube schauen mußte, blieb jemandem, der auch noch eigene Programme laufen lassen wollte, nichts übrig, als die Basisprinzipien zu lernen, die einen Computer zum Leben erwecken, sprich: man mußte - früher oder später - Maschinensprache lernen. Ich kenne aus meiner Entwickler-Generation niemanden, der nicht zumindest rudimentäre Kenntnisse in Assembler hat - sei es, um wenigstens gelegentlich einige Zeilen Inline-Assembler einzustreuen, oder nur zur Kontrolle des Outputs des C-Compilers auf der Suche nach Optimierungen in Geschwindigkeit oder Speicherverbrauch.

Meine jüngeren Kollegen starteten bereits mit einem völlig anderen Handwerkszeug: wo ich - als Anfänger - nur mit Mühe begriffen hatte, wie "Pointer" funktionieren, konnten sie schon in Büchern nachlesen, wie man z.B. polymorphe Listen verwaltet. Wo ich noch gelernt habe, welche Bedeutung der Programcounter hat [1], wird heute objektorientiertes Programmieren im ersten Semester Informatik vermittelt [2]. Mit anderen Worten: wo ich noch wissen mußte, wie man einen Motor zerlegt, sitzt die heutige Generation bereits im Rennauto und trainiert die schnellste Linie durch die Kurven [3].

Wesentlich radikaler sieht man diesen Umbruch natürlich, wenn man sich die heutigen User anschaut. Was vor zwanzig Jahren der Spielplatz einer technisch begeisterten "Elite" war, ist heute definitiv jedem zugänglich: man kauft sich ein Notebook mit vorinstallierter Software, steckt einen Stecker ein, und surft im Internet [4].

  1. [1] ..z.B. um Module "zu Fuß" nach dem Laden im Speicher relozieren...
  2. [2] Als ich vor kanpp fünfzehn Jahren C++ gelernt habe, war es für mich ein Kulturschock, mit völlig neuen Paradigmen konfrontiert zu werden, die sich nur schwer in meine bisherige Erfahrung einordnen ließen. Ich habe bis heute gewisse Vorurteile gegen die (unnötige) Verschwendung von Resourcen, über die die Jüngeren wahrscheinlich heimlich lächeln.
  3. [3] Das hat nicht nur, aber weit überwiegende Vorteile.
  4. [4] Das bringt nicht nur, aber weit überwiegend Probleme - vor allem, wenn man es mit einer Welt zu tun hat, in der die Rechner immer wichtiger werden.



Abstraktionen und Planung


In der Softwareentwicklung hat man mit dem Problem zu kämpfen, daß man am Anfang eines Projekts allenfalls in eine (inhaltlich) grobe Richtung sehen kann, ohne jede Chance, die (technischen) Details zu überblicken.

Wenn man z.B. den Auftrag bekäme, eine Software zu schreiben, mit der die Bürger Online-Petitionen beim Bundestag abgeben können, ist allenfalls klar, daß man mindestens zwei Features implementieren muß: neue Petitionen einzureichen, und bereits eingereichte Petitionen zu unterschreiben. Halbwegs erfahrene Softwareentwickler assoziieren sofort eine ganze Reihe anderer Anforderungen - das Resultat muß zuverlässig funktionieren, Datensicherheit ist zu gewährleisten, es muß für sehbehinderte User bedienbar sein, etc. pp. Dennoch wären auch solche Spezialisten völlig überfordert, selbst nach einigem Nachdenken zu sagen, wie viele „Manntage” die Realisierung solch einer Aufgabe erfordern wird.

Das ist schlecht - hat doch der Auftraggeber nur ein gewisses Budget und muß in einem mehr oder weniger striktem Zeitrahmen die Software am Laufen haben.

Man kann sich jetzt hinsetzen, und die Dinge im voraus planen. Dann erstellt man ein Pflichtenheft, in dem zunächst nur drinsteht, was konkret an Funktionalität zu realisieren ist - und das wächst langsam, indem zu jedem Punkt noch ergänzt wird, was technisch zu realisieren ist, um am Ende die geforderten Funktionen in der Hand zu halten. Mit dieser Liste geht man zu einem Anbieter von Softwareerstellung, dessen Management in der Entwicklung nachfragt, wie lange es dauert, die Punkte auf dieser Liste abzuarbeiten, und dann ein Angebot kalkuliert.

Tatsächlich ist man lange Jahre in der Industrie genau so vorgegangen - es gibt sogar irgendeine ISO-Norm, die diesen Prozeß ausgiebig und in jedem Detail definiert. Allein: so hat das noch nie funktioniert. Ich schreibe sehr bewußt „nie”, und nicht z.B. „selten” (wofür das Scheitern der Entwicklung für die Software der Online-Petitionen ein anschauliches Beispiel bietet).

Das grundlegende Problem besteht darin, daß man am Anfang allenfalls ein Grundgerüst vor Augen hat, das aber aus sich selbst heraus immer wieder neue Voraussetzungen neu erzeugt, je weiter man ins Detail geht. Dummerweise sieht man diese Details erst in dem Moment, in denen man vor ihnen steht.

Ein Plan ist die Abstraktion einer zukünftigen Realität.

Eine nicht-triviale Software hat selbst dann einen überaus hohen Grad an Komplexität, wenn sie bereits existiert - selbst Abstraktionen von ihrem konkretem Bestehen sind nicht ganz einfach (z.B. wenn man sie verändern, dokumentieren, oder einfach nur benutzt will). Wenn sie dann noch für die Zukunft erst geplant wird, erweisen sich die anfänglichen Abstraktionen immer als falsch („immer”, und nicht z.B. „meistens”).

Das ist auf einer bestimmten Ebene vergleichbar mit dem Architekten, der ein Gebäude plant: auf dem Papier sieht das alles ganz logisch aus. Es läßt sich im Vorfeld leicht ausrechnen, welche Materialien in welchen Quantitäten benötigt werden, und wieviel das kostet. Auch die Zahl der Stunden, den die einzelnen Schritte bei den konkreten Bauarbeiten in Anspruch nehmen werden, läßt sich zumindest näherungsweise im Vorfeld abschätzen. Spätestens, wenn es um die Kalkulation der Verzahnung der einzelnen Komponenten und Arbeitsschritte geht, wird jede Planung früher oder später von der Realität überholt. Die Verzögerung von nur wenigen Stunden bei der Lieferung einer bestimmten Komponente bewirkt womöglich am Ende, daß die Planung eines Prozesses, in dem ein Arbeitsschritt den nächsten vorbereit, völlig aus dem Ruder läuft.

In der Softwareentwicklung sind es nicht nur die Abläufe, die letztlich unkalkulierbar sind. Hinzu kommt, daß sich in den Abläufen überhaupt erst etwas realisiert, von dessen Existenz man vorher keine Ahnung hatte. Ein Haus ist - mit minimalen Abweichungen - am Ende ein Haus von vielen. Im Bereich von Software sind die Abweichungen hingegen die Regel. Eine Software, die es bereits gibt, muß man kein zweites Mal schreiben, weil man sie kopieren kann. Den Plan eines Hauses muß man immer noch jedesmal neu realisieren - mit den Problemen, die sich auf den Ablauf der Bauarbeiten beschränken. Ein neuer Plan, den man zum ersten Mal realisiert, hat hingegen die Tücke, daß er immer wieder revidiert werden muß, weil er nur begrenzt auf bereits gemachte Erfahrung zurückgreifen kann. Je konkreter solch ein Plan wird, desto komplexer wird die Realität, die er erzeugt, und desto weniger bilden die ihm zugrunde liegenden Abstraktionen ein zutreffendes Bild der Wirklichkeit. (Dies dürfte übrigens auch in der Architektur zutreffen: die Kosten für den Bau eines Reihenhauses sind wahrscheinlich wesentlich besser kalkulierbar als jene z.B. eines Theaters, das es so zuvor noch nicht gegeben hat.)



Man könnte sagen: wenn es nicht möglich ist, ein (endgültiges) Design noch vor jeder Arbeit am konkreten Code zu erstellen, dann kann man ja wenigstens das Userinterface (GUI) im Vorhinein festklopfen (GUI jetzt nicht so verstanden, wie das mittlerweile fast schon gängig ist - als graphisches Design -, sondern in der ursprünglichen Bedeutung: als Summe aller Aktionen und Abläufe, mit denen es der User zuletzt zu tun bekommt).

Auch hier stößt man aber auf im ersten Moment überraschende Probleme. Zum einen sind die Auftraggeber einer Software normalerweise Experten in der jeweiligen Problemdomain (z.B. Sachbearbeiter von Petitionen an den Deutschen Bundestag), so daß man eigentlich erwarten könnte, sie wären in der Lage, eine adäquate Beschreibung der eigenen Tätigkeit abzuliefern. Das ist jedoch höchst selten der Fall. Zum zweitem - und das ist dann der springende Punkt - ist selbst ein vernünfig im Vorhinein abgestimmtes Interface in der praktischen Anwendung nie auf Anhieb brauchbar, einfach weil ein GUI auf dem Papier etwas völlig anders ist als eines, das man mit Maus und Tastatur wirklich bedienen kann. Ersteres ist eine Abstraktion, die zwangsläufig bestimmte Aspekte ausläßt - was erst in der konkreten Realisierung spürbar wird.

Zum ersten Punkt wäre anzumerken, daß gute Fachleute in einem beliebigen Bereich nur dann gut sind, wenn sie nicht mehr über das „Wie” ihrer Tätigkeit nachdenken (müssen). Sie haben ihren Job gelernt, und dieses Gelernte verinnerlicht - sie denken nicht über jeden Handgriff nach, sondern tun ihn einfach. Wenn man jetzt verlangt, daß sie sich selber bei der Arbeit beobachten und die Abläufe dokumentieren sollen, tun sie plötzlich nicht mehr ihren Job, sondern etwas ganz anderes - und zwar dann noch etwas, das sie nie gelernt oder geübt haben. Selbstanalyse ist eine Disziplin, die ganz eigene Anforderungen stellt.

Hinzu kommt, daß Fachleute, wenn sie an einer Software für den eigenen Bereich mitarbeiten sollen, schnell dazu tendieren, konkrete Funktionen, ja sogar einzelne Buttons oder Menupunkte vorzuschlagen, statt nur zu erklären, was sie mit Hilfe der neu zu entwickelnden Software eigentlich erreichen wollen (dasselbe Problem hat man, wenn User Verbesserungsvorschläge machen). In der Regel kommt dann die Frage nach einem weiteren Button für eine bestimmte Spezialfunktion, oder der Wunsch nach einem Modifier bei einer Mausoperation, um ein verändertes Verhalten zu bekommen. Dabei wäre es wünschenswert, zu erfahren, was denn mit dieser Spezialfunktion bezweckt werden soll - es wäre die Aufgabe der Software-Architekten, sich zu überlegen, wie man solch eine neue Anforderung dann im GUI implementiert.

Der zweite Punkt ist aber - wie gesagt - entscheidend: einen Entwurf auf dem Papier kann man nicht anklicken. Man kann das Verhalten des Programms und den „Workflow” für den User nur abstrakt beschreiben, aber nicht „am lebenden Objekt” testen, ob die Abstraktionen wirklich korrekt sind. In der Praxis stößt man immer (wieder ein „immer”, kein oft) beim ersten Testlauf eines auch noch so sorgfältig vorbereiteten Features auf Dinge im GUI, die sich falsch anfühlen, und die man definitiv ändern muß, wenn man die Erwartungen der User nicht enttäuschen will. Das können Kleinigkeiten sein, wie zwei Buttons, die man besser vertauscht, weil man den Button links oben intuitiv „lieber” drückt als den direkt daneben, so daß man die eher „ungefährliche” Auswahl eben besser ganz links unterbringt.[1] Das kann aber auch ein kompletter Um- bzw. Rückbau sein, wenn sich etwa herausstellt, daß man in typischen Arbeitssituationen derart viele Pannels (Fenster, die immer „oben” bleiben, auch „Floating Windows” genannt) geöffnet haben müßte, daß der komplette Arbeitsbereich im Hauptfenster von ihnen verdeckt wäre. Dann wird man vielleicht die Funktionen aus den Panels in einen festen Fensterbereich verlagern. - Usf.

Nochmal: Ein Plan ist die Abstraktion einer zukünftigen Realität. Wenn man den Begriff „Abstraktion” so definiert, wie ich das tue - als Vereinfachung eines komplexen Konkreten - hat man eine nur schwer wiederlegbare Begründung für die Beobachtung, daß letztlich jeder Plan scheitern muß, der auf etwas hinlänglich Komplexes abzielt.

  1. [1] Das konkrete Beispiel, vor dem ich gerade auch sitze, ist der „Editor”, mit dem ich diesen Eintrag bearbeite. Links oben sind zwei Buttons direkt nebeneinander - einer, der den Eintrag tatsächlich veröffentlicht, und ein zweiter, um den Eintrag temporär zu speichern. Nachdem ich einst zum dritten Mal versehentlich den „Publish”-Button gedrückt und ein unfertiges Textsegment ins Netz gestellt hatte, habe ich den Platz der beiden Buttons vertauscht, und die „Save”-Option ganz nach links gerückt. Seitdem ist mir dieses Versehen nicht wieder passiert.



Userinterfaces


Am Anfang war die Lochkarte. Für jede Berechnung, die man auf einem jener Zimmerfüllenden Mainframes noch Anfang der 80er Jahre durchführen wollte, mußte man ein eigenes Programm schreiben, und zwar in binärem Code. Damit konnte man natürlich keiner Sekretärin kommen, und die Idee eines echten PC - eines Einzelplatz-Rechners für die alltägliche Arbeit oder gar das heimische Wohnzimmer - war aus dieser Perspektive völlig absurd.

Daran änderte auch die erste echte Schnittstelle zum Benutzer wenig, die Kommandozeile. Mit ihr kann man immerhin textbasiert arbeiten, und man bedient sich komplexer Befehle, die im Betriebssystem integriert und durchaus mächtig sind - auch heute noch lassen sich diverse Arbeiten mittels Kommandozeile und dem damit verbundenen Skripting besser erledigen als mit Maus und Menu. Auch dies ist aber letztlich eine Umgebung nur für Spezialisten, die ein grundlegendes technisches Verständnis vom Computer haben.

Der echte Durchbruch, der aus dem Computer ein Werkzeug für den massenhaften Gebrauch machte, brachte erst die Erfindung des grafischen Userinterface (GUI) - wobei man es hier nicht mit nur einer einzigen Neuerung zu tun hat, sondern einem ganzen Set von neuen Konzepten und Werkzeugen.

MacOS

An zentraler Stelle steht das virtuelle Desktop. Der Computerbildschirm ist hier eine Metapher für einen Schreibtisch, auf dem unterschiedlichste Dokumente liegen - Texte, Grafiken, Tabellen, usf.. Dieser Wust aus virtuellen „Papieren” wird abgebildet und lebt in „Fenstern”, die sich überlappen können, die man in ihrer Größe verändern und gegeneinander verschieben kann. Andere, ergänzende Konzepte sind Menus, die bei Bedarf aufklappen und in deren Textlisten sich die Kommandos finden, die im jeweiligen Kontext zur Verfügung stehen, und - ganz prominent - die Einführung eines neuen Eingabegeräts neben der Tastatur, der Maus, mit der sich Fenster und Menus „anfassen” und „anklicken” lassen.

Man ist an diese Features heutzutage derart gewöhnt, daß man sie für völlig selbstverständlich hält. Als sie Ende der 70er von Rank Xerox erfunden und wenige Jahre später zum ersten Mal in den Computern von Apple für einen breiteren Markt praktisch zur Verfügung standen, wirkten sie allerdings sensationell - erstmals konnten Menschen Computer bedienen, die von der dahinter liegenden Technik wenig oder gar nichts wußten, und lediglich auf ihre Alltagserfahrungen zurückgreifen mußten, um das Bedienungskonzept zu verstehen.

Dabei hat dieses intuitive Verständnis für die Bedienung von Computerprogrammen durchaus Seiteneffekte, die auf der Seite der User gelegentlich Stirnrunzeln und Unverständnis hervorrufen, auf der Seite des Marketings von Softwarefirmen dafür verantwortlich sind, wenn die Manager angesichts wiederholt verschobener Releasetermine und davonlaufender Kosten die Hände über dem Kopf zusammenschlagen, und auf der Seite der Entwickler für rauchende Köpfe und verzweifelte Blicke sorgen. Ein gutes GUI, das in sich konsistent und intuitiv bedienbar ist, testet regelmäßig die Grenzen des technisch Machbaren und fordert die kompletten intellektuellen Ressourcen selbst von überdurchschnittlich begabten Designern und Entwicklern.

Anders formuliert: verschachteltes Skripting für Unix kann jeder, sofern er sich genug bemüht. Das Design eines in sich schlüssigen GUI für eine halbwegs komplexe Anwendung, das auch noch technisch umsetzbar ist, ist eine Kunst, in der es zwar eine Reihe begabter Handwerker, aber nur wenige Genies gibt.



Wenn man sich dafür entscheidet, ein Programm mit einem grafischen Userinterface zu schreiben, muß man deutlich mehr Zeilen Code schreiben, als für dessen Version für die Kommandozeile.

Ein ganz gutes Gefühl für das Ausmaß dieses „Mehr” bekommt man, wenn man das grundlegende Skelett einer Applikation schreibt - das klassische „Hello World”, das eben diese beiden Wörter auf den Bildschirm bringt. In reinem „C” mit einer Textausgabe auf die Konsole sind das keine zehn Zeilen Code. Wenn man die gleiche Ausgabe in ein Fenster z.B. unter Windows machen will, sind es plötzlich mehrere hundert Zeilen, in denen u.a. ein ohne das Studium umfangreicher Dokumentationen kaum nachvollziehbares Zwiegespräch mit dem Betriebssystem geführt werden muß.

Um ein wenig besser nachvollziehbar zu machen, über was für Schwierigkeiten man stolpert, wenn man ein GUI implementieren will, schildere ich kurz, wie die Verwaltung von Fenstern auf dem Desktop geschieht. Dreh- und Angelpunkt ist die sog. „Eventloop”. Die eigene Applikation übermittelt dem Betriebssystem ein Stück Code, das immer dann aufgerufen wird, wenn der User eine Aktion ausführt - wenn er die Maus bewegt, mit der rechten oder linken Maustaste klickt, Eingaben auf der Tastatur macht, aber auch, wenn ein Fenster verschoben oder geschlossen wird, so daß der Inhalt anderer, dahinter verborgener Fenster restauriert werden muß.

Das Problem ist ja, daß die gegenseitig sich verdeckenden Fenster denselben Bildschirm teilen - die Hierarchie übereinander liegender Dokumente ist lediglich eine Illusion für den User, die aufrecht erhalten wird, indem ein hinten liegendes Fenster stets auf Überlappungen Rücksicht nimmt und Ausgaben in scheinbar „verdeckte” Bereiche unterdrückt.

Jedes Betriebssystem löst dabei die Aufgabe anders, zu verhindern, daß vermeidlich verdeckte Bereiche versehentlich übermalt werden, wobei in unterschiedlichem Ausmaß die Programme an dieser Aufgabe beteiligt sind. Auf dem Atari ST war es beispielsweise den Programmierern überlassen, Überlappungen bei der Restauration von Fensterinhalten zu berücksichtigen, wobei das Betriebssystem lediglich eine Rechteckliste der neu zu zeichnenden Bereiche lieferte. Das Design des MacOS war immerhin schon ganz zu Beginn elegant genug, den Applikationen Grafikausgaben auch in eigentlich unsichtbare Bereiche zu erlauben, wobei das Betriebssystem dann verhinderte, daß solche „unzulässige” Grafik auf dem Bildschirm erschien. Usf.[1]

Das ist nur ein kleiner Teil der Aufgaben, die man lösen muß, wenn Programmausgaben nicht direkt auf dem Bildschirm, sondern in einem virtuellen Fenster erscheinen sollen. Es dürfte aber einleuchten, daß die Komplexität eines Programms, das ein GUI implementiert, erheblich größer ist als dessen Version für die Kommandozeile, obwohl es letztlich - die einfachere Bedienbarkeit außer acht gelassen - nicht mehr leistet als dieses.

Das bedeutet zunächst Dreierlei. Das Programm wird teurer, und zwar drastisch teurer, weil es schlicht länger - drastisch länger - dauert, es zu entwickeln. Zum zweiten frißt es mehr Ressourcen in Form von Rechenleistung und Speicherplatz. Außerdem ist es - drittes - deutlich anfälliger für Programmfehler, Bugs.

Viertens aber - und das ist m.E. der eigentliche Schlüssel - sind die Metaphern eines GUI oft nur begrenzt belastbar - entweder, weil das Vorbild aus der realen Welt Dinge erlaubt, die für sein virtuelles Gegenstück technisch schlicht nicht umsetzbar sind, oder aber, weil in der Realität Konzepte praktisch sind, die, auf den Computer übertragen, nur teilweise oder überhaupt nicht funktionieren.

Die Fenster auf dem Computerbildschirm lassen sich nicht - wie ein Stück Papier - falten oder zusammenrollen, und Knöpfe lassen sich an einem Radio wunderbar mit Daumen und Zeigefinger anfassen und verstellen, sind an seinem virtuellen Gegenstück mit der Maus jedoch schlicht unbedienbar.

  1. [1] Heute sieht das auf den ersten Blick sehr viel entspannter aus, weil - zumindest unter Windows und OS X - jedes Fenster einen eigenen Speicherbereich zur Verfügung hat, der bei Bedarf ohne Zutun durch die Applikation vom Betriebssystem auf den Bildschirm kopiert wird. Dabei handelt man sich andere Probleme ein - z.B. unter Windows das außerordentlich unangenehme Phänomen, daß sich urplötzlich Task-Prioritäten zugunsten des GUI verschieben, weil Windows die Restauration von Fensterinhalten wichtiger findet, als die ungestörte Wiedergabe einer Audiodatei (um nur ein beliebiges Beispiel zu nennen).
2 Kommentare

Bei der Entwicklung eines GUI konkurrieren drei Herausforderung miteinander, und beim Design geht es darum, eine gewisse Balance zwischen ihnen zu finden. Zunächst ist dies die Anforderung, daß das Interface einfach zu verstehen sein soll. Zum zweiten soll es einfach bedienbar sein. Nicht zuletzt muß es sich mit den gegebenen Mitteln auch technisch umsetzen lassen.

Die beiden ersten Punkte - einfaches Verstehen wie Bedienbarkeit - scheinen einander zu bedingen, stehen aber in Konkurrenz zueinander. Ein User, der ein Programm gut beherrscht und auswendig kennt, wird i.d.R. völlig anders operieren, als jemand, der zum ersten Mal vor ihm sitzt. „Poweruser” wollen für jede Funktion einen Tastaturbefehl, während Neulinge auf vernünftig benannte Einträge in den Menus angewiesen sind. Wenn man mit einem Programm vertraut ist, kommt es darauf an, daß einzelne Arbeitsschritte optimal ineinander übergehen - eine Forderung, die darauf hinausläuft, die Werkzeuge für unterschiedliche Schritte dicht nebeneinander zu legen, was auf den ersten Blick für Verwirrung sorgt. Usf.

Amp Simulator

Ein recht schönes Beispiel für ein GUI, das anfangs überaus einleuchtend erscheint, nach einiger Gewöhnung jedoch hochgradig nervt, findet sich in der ursprünglichen Konzeption der Plug-in für Cubase VST. Man hat Mitte der 90er damit begonnen, Audio-Hardware (Effektgräte, Mischpulte, Synthesizer, usw.) im Computer zu simulieren. Um den Usern das Konzept verständlich zu machen, hat man auch die Benutzerführung der Hardware kopiert. Auf dem Computermonitor erscheinen Knöpfe und Schiebregler, blinkende LEDs und sogar Klaviertastaturen. Tatsächlich leuchtet das Konzept unmittelbar ein, und man kann die Software bedienen, ohne zuvor das Handbuch gelesen zu haben. Ohne diese Strategie wäre VST möglicherweise nicht derart populär geworden, wie es dies heute ist.

Dabei läßt die Begeisterung für die ebenso bunte wie vertraute Oberfläche jedoch nach, wenn man ernsthaft mit den virtuellen „Geräten” arbeiten will. Da stellt sich dann plötzlich heraus, daß der Text, mit dem bestimmte Werte dargestellt werden - wie auf der Hardware auch - nur eine Anzeige ist. Man kann ihn nicht doppelklicken und als Text editieren, sondern ist gezwungen, die Werte z.B. mit einem Drehregler einzustellen. Überhaupt die Knöpfe: man muß sie anklicken und mit der Maus einen Kreisbogen entlang fahren - ein Verfahren, das nicht nur ungenau ist, sondern irgendwann in den Gelenken und Sehen der Hände physische Schmerzen verursacht.

Irgendwann werden die Texte editierbar, und um einen Regler auf z.B. 0db (oder eine andere Default-Einstellung) zu bringen, muß man ihn nur noch mit gehaltener Command-Taste kurz anklicken. Auch die Drehregler verlieren ihren Schrecken, als man den Usern erlaubt, in den Präferenzen zwischen drei unterschiedlichen Modi zu wählen (u.a. einen Modus, bei dem man die Maus nicht kreisförmig, sondern auf und ab bewegt). Usf. Die Plug-in werden immer besser bedienbar, dabei aber gleichzeitig immer komplexer und schwerer zu verstehen - und zwar auch dort, wo sich an der die eigentlichen Funktionalität (der Klangerzeugung etwa) überhaupt nicht ändert. Ein Neuling hat derart viel über die Bedienkonzepte zu lernen, daß er anfangs nur verloren dasteht und nicht weiß, wo er beginnen soll.

Man kann letztlich in sämtlichen Programmen, die über ein gewisses Maß an Komplexität verfügen und schon einige Updates hinter sich haben, das Phänomen betrachten, wie ein ursprünglich logisches und stimmiges Konzept nach und nach „in die Breite geht”. Dabei rede ich gar nicht von „Bloatware” - wenn also ein Programm immer mehr aufgeblasen wird und nach Jahren über Funktionen verfügt, die allenfalls ein kleiner Teil der User nutzt, und die in erster Linie womöglich eingebaut wurden, um die Schlacht um neue Features nicht gegen die Konkurrenz zu verlieren. Schon beim Versuch, alltägliche Abläufe - den berühmten „Workflow” - so zu optimieren, daß sie mit möglichst wenigen Aktionen ausführbar sind, passiert es regelmäßig, daß eine Apllikation sich nach und nach in ein Monster verwandelt, das ein Anfänger nicht mehr durchschaut. - Interessanterweise sind an solchen Entwicklungen i.d.R. die User selber schuld.



Man hat in den letzten Dekaden wiederholt darüber gestritten, wie ein ideales GUI auszusehen habe, und diese Diskussionen waren nicht nur kontrovers, sondern häufig außerordentlich emotional besetzt. Eigentlich sollte man meinen, daß man es hier mit einem technischen Thema zu tun hat, bei dem sich allenfalls unbedarfte User vehement in die Haare geraten, die Fachleute hingegen eine sachliche Debatte führen. Auch unter letzteren toben aber Auseinandersetzungen, die manchmal an Glaubenskriege erinnern, und deren Ende nicht absehbar ist, auch wenn in bestimmten Teilbereichen mittlerweile stillschweigende Übereinstimmung herrscht. Die Antwort auf die Frage, warum es hier so bewegt zugeht, ist dabei wohl ein Schlüssel, um zum Thema selbst relevantes zu sagen.

Ich bin der Meinung, daß es keine allgemeingültige Theorie darüber geben kann, wie ein optimales GUI auszusehen hat. Man hat öfters versucht, allgemeine Regeln aufzustellen, was man zu tun bzw. zu lassen habe - gerade Apple hat schon früh versucht, den Macintosh-Entwicklern klare Richtlinien auf den Weg zu geben. Dabei hat man sich aber wiederholt in Widersprüche verwickelt, bzw. immer mal wieder Entwicklungen auf den Weg gebracht, die den eigenen Regeln widersprachen. Das ist eigentlich auch kein Wunder - die Anforderungen an ein GUI widersprechen einander selbst.

Ich sehe zwei zentrale Anforderungen an ein GUI, die jeweils durch andere, widersprüchliche Ansprüche in die Zange genommen werden:

  • Ein GUI soll intuitiv verständlich, gleichzeitig aber einfach bedienbar sein. Der Widerspruch zwischen diesen Anforderungen wird immer dort deutlich, wo ein Power-User mit einem GUI zurande kommen soll, das auf einen Anfänger zugeschnitten wurde. Der Profi braucht Abkürzungen jeder Art[1], wo der Einsteiger ausführlich an die Hand genommen werden will, und vice versa[2].

  • Ein GUI soll konsistent sein - d.h., eine einmal eingeübte Metapher oder Folge von Befehlen soll sich überall gleich verhalten. Copy&Paste z.B. soll sich auf alle Daten anwenden lassen, egal, wie diese konkret aussehen.

Dem Wunsch nach Konsistenz stehen andere Anforderungen entgegen:

  • Ein GUI muß an vielen Stellen redundant sein - d.h., es muß mehr als nur einen Weg bieten, ein bestimmtes Ziel zu erreichen (z.B. einen Befehl durch ein Menu, oder aber ein Icon in einer Toolbar verfügbar machen). Konsistenz und Redundanz sind zwei einander widersprechende Prinzipien.

  • Jede Präferenz, jede konfigurierbare Toolbar und jedes vom User individuell zuweisbare Tastaturkommando widerspricht der Forderung nach Konsistenz, und bedeutet zusätzlich zunehmende Komplexität, die dem intuitiven Verständnis entgegen läuft. Ohne solche Konfigurierbarkeit läßt sich aber keine halbwegs komplexe Applikation realisieren, die den Ansprüchen einer größeren Gruppe von Usern gerecht wird.

  • Weiterhin steht der Versuch, ein Interface so konsistent wie nur möglich zu implementieren, dem Unterschied in der Beschaffenheit der Daten entgegen, wodurch gelegentlich Lösungen entstehen, die aufgesetzt wirken und für den User nicht wirklich produktiv sind. Ein Beispiel hierfür ist Drag&Drop von Textblöcken in „Word” & Co. Ein Feature, das für Dateioperationen im Betriebssystem perfekten Sinn ergibt, ist nicht ohne Grund in den meisten Texteditoren in den Präferenzen abschaltbar.

    In diese Rubrik gehört sogar das „universelle” Prinzip von Selection&Action - man selektiert Daten, und führt auf dieser Selektion eine Aktion aus, die man z.B. in einem Menu anwählt. Es gibt durchaus Situationen, in denen dieses - allgemein fraglos akzeptierte - Schema sich nur gewaltsam durchziehen läßt - der „Selected”-Status von farbigen Objekten in einem Grafikprogramm etwa läßt sich nur mühsam und unter Verrenkungen konsistent auf dem Bildschirm darstellen.

Um diese Widersprüche aufzulösen, hat man gelegentlich die Forderung erhoben, Monster wie „Word” oder auch „Cubase” in eine Gruppe von Modulen aufzuteilen, die jeweils auf einen bestimmten Task spezialisiert sind und die Komplexität einer Applikation, die für alles eine Lösung hat, aufteilt, und für den User beherrschbar machen. Dabei übersieht man, daß die Komplexität auf diese Weise lediglich verteilt, nicht aber reduziert wird - um den zusätzlichen Preis, daß die Userinterfaces nur locker miteinander verkoppelter Module große Probleme mit kohärentem Verhalten im GUI haben[3].

  1. [1] Tastaturkommandos sind nur eines von vielen Beispielen.
  2. [2] Im Extrem mag der Profi das grafische „Design” eines Interfaces als äußerliche „Tapete” empfinden, wo ein Einsteiger es als hilfreich „cool” bewertet.
  3. [3] Stichwort: OpenDoc.


Wenn man vom grafischen Userinterface oder dem GUI-„Design” spricht, läuft man in Gefahr, das Userinterface mit dessen grafischer Gestaltung zu verwechseln. Ein GUI besteht zwar aus grafischen Objekten, die z.B. eine bestimmte Farbe haben und über ein mehr oder weniger gelungenes optisches Design verfügen - ein GUI ist dies aber noch lange nicht, auch wenn einem dies das Marketing in den Software-Companies gelegentlich einreden möchte. Es spielt zwar schon eine Rolle für den Anwender, ob er vor einer Applikation sitzt, deren Optik ihn anspricht, oder nicht. In manchen Fällen gibt es sogar funktionelle Auswirkungen der Gestaltung der Grafik, etwa wenn man in einem abgedunkelten Tonstudio vor einer grell leuchtenden Musiksoftware sitzt, oder womöglich grünen Text auf rotem Grund präsentiert bekommt. GUI-Design meint aber letztlich etwas anderes, nämlich die Gestaltung der Funktionalität durch aufeinander abgestimmte grafische Elemente. Dabei spielt ihre Optik eine eher untergeordnete Rolle.

Trotzdem finden sich im GUI-Design - selbst wenn man es rein funktionell betrachtet - Moden. Dabei bestehen all jene Debatten, die sich um den vermeintlich „besten Computer” drehen, letztlich aus Statements über die modischen Qualitäten des GUI im betreffenden Betriebssystem. Gleiches gilt für den Streit um das beste Programm zur Bearbeitung von Text, Grafik, oder Musik, oder um den besten Internet-Browser.

Bevor ich diese - zugegeben stark zugespitzte - These näher begründe, muß ich einschieben, daß es natürlich durchaus auch rationale Gründe gibt, sich für oder gegen ein bestimmtes Betriebssystem oder eine Applikation zu entscheiden. Ich behaupte aber, daß diese Gründe deutlich in der Unterzahl sind - wenn das anders wäre, würde man die Debatten erheblich sachlicher führen, ohne sie regelmäßig in emotional aufgeheizte Flame-Wars zu eskalieren. Es geht in erster Linie um subjektive Vorlieben, und zwar auch und gerade dann, wenn man nur über die funktionale Seite von Userinterfaces streitet.

Zunächst läßt sich leicht belegen, daß bestimmte Moden im GUI kommen und gehen. Ich erinnere mich z.B. noch ganz gut an meinen Versuch, auf dem Atari ST sog. „Floating Windows” zu implementieren, Fenster also, die über den „Hauptfenstern” der Applikation schweben, und in denen man beispielsweise verschiedene Modi für Operationen mit der Maus - Tools - auswählen kann. Das war auf dem Macintosh selbstverständlich, ließ sich aber auf dem Atari nur unter hohem Aufwand implementieren[1] - der Coolness-Faktor war entsprechend hoch, und sämtliche Applikationen auf dem Mac haben dieses Konzept u.a deshalb realisiert, weil es anderswo nicht zu haben war.

Irgendwann kam Microsoft mit einem anderen Modell, bei dem sämtliche Fenster nebeneinander untergebracht werden, um Überlappungen komplett zu vermeiden. Die Tools liegen stets neben den Hauptfenstern, und verdecken nicht länger Teile der zu bearbeitenden Daten (Text, Grafik, Noten, etc.). Plötzlich empfand man die Floating Windows generell als lästig, weil man der Meinung war, daß man nur noch damit beschäftigt ist, sie hin- und her zu schieben, um den Überblick über die - eigentlich im Fokus stehenden - Daten nicht zu verlieren (das Konzept der „Dockable Windows” hat definitiv seine Meriten).

Mittlerweile schlägt das Pendel wieder in die andere Richtung. In Cubase kann man eine Reihe von Fenster optional „always on top” setzen, ihnen also den Charakter von Floating Windows geben. Dabei läßt sich diese Option in den Präferenzen voreinstellen, und ist seit kurzem per Default aktiviert. Das hat durchaus Gründe - man muß keine weiten Wege mit der Maus machen, um zwischen den editierten Daten in der Mitte des Bildschirms und den Tools an dessen Rand zu wechseln.

  1. [1] Ich habe es damals nicht geschafft, das fehlerfrei und Release-fähig hinzubekommen.



Ein Sequenzer, der MIDI wie auch Audio behandeln und gemeinsam abspielen will, steht vor dem Problem, daß es sich um sehr unterschiedliche Medien handelt, die immer wieder nach Sonderbehandlung vernehmlich rufen: MIDI basiert auf PPQ (und ist damit unabhängig vom Tempo); Audiodateien sind „timebased“ und laufen zunächst unabhängig vom eingestellten Tempo; etc., ich hatte das Thema schon ausführlicher behandelt.

Auch in der „Philosophie“ bei der Wiedergabe gibt es einen gewichtigen Unterschied: ein Audio-Track im Sequenzer entspricht idR. einem Kanalzug auf dem virtuellen Mischpult, während MIDI dort zunächst überhaupt nicht auftaucht. „Lautstärke“ ist ein Attribut, das man Audio nachträglich hinzufügt (indem man den „Stream“ gewissermaßen filtert, und jedes Sample, abhängig von der Stellung des Volume-Reglers auf dem Mischpult, skaliert). In der MIDI-Welt ist Lautstärke hingegen zunächst ein Attribut der einzelnen Noten (Velocity) – auch MIDI-Volume (Controller 7 und 11) kommt nicht „von außen hinzu“, sondern ist Teil des Datenstroms selbst.

Das ist historisch begründet, und nicht per se „gutes Design”. Man kann die Welten aus MIDI und Audio jedoch zumindest auf dieser Ebene nachträglich einigermaßen gut miteinander „verheiraten”: MIDI-Tracks bekommen z.B. einen Kanal im Mixer, der MIDI-Volume ausspuckt (wobei er dann regelmäßig in Kollision mit dem MIDI-Volume gerät, das der User im Track selbst abgelegt hat).

Diese unterschiedlichen Ansätze führen zu weiteren Konsequenzen. In der MIDI-Welt ist es z.B. kein Problem, mehrere Datenströme (z.B. in Form von „Parts“ in Cubase) auf demselben Track übereinander zu stapeln und gemeinsam abzuspielen. Bei Audio-Daten geht das nicht: hier geht genau eine Datei zur selben Zeit an den Ausgang. Wenn man mehrere Audio-Dateien auf demselben Track übereinanderstapelt, „gewinnt“ immer die, die „oben“ liegt; der Rest bleibt stumm. - Das hat wieder historische Ursachen; vergl. oben.

Die Tatsache, daß es eine „Hierarchie“ von Audio-Dateien auf demselben Track gibt, kann man fruchtbar machen, wenn es darum geht, aus mehreren Aufnahmen desselben Takes – aus mehreren, unmittelbar aufeinander folgenden Aufnahmen derselben Passage – die „beste“ Version zusammenzuschneiden. Der Sänger hat im ersten Take die Töne in Takt eins und zwei richtig, im nächsten sind die in Takt drei und vier besser: man schneidet innerhalb der „Lanes“ desselben Tracks, aktiviert jene Lanes, die am besten gefallen, und verläßt sich darauf, daß der Rest des Materials automatisch stumm ist. Wie gesagt: auf einem Audiotrack kann immer nur eine Audiodatei gleichzeitig spielen. Wenn man eine Datei (oder einen Ausschnitt davon) „nach vorne holt“, kommt der Rest automatisch zum Schweigen.

Dieses Konzept von „Lane-Editing“ (oder „Comping“) hat auf den ersten Blick eine Reihe von Vorteilen, die von den Usern auch erkannt und ausgiebig genutzt werden. Sie rasseln dann aber in Probleme, wenn sie das Feature für Aufgaben benutzen, für die es anfangs gar nicht konzipiert war. So gibt es regelmäßig Situationen, wo man nicht einfach zwischen den Versionen mehrerer Takes hin- und herschalten kann, ohne daß die Takes überlappen. Im Beispiel oben sind die ersten beiden Takte des Sängers vielleicht perfekt, haben aber am Ende einen langen Ton, den man nicht einfach abschneiden kann, wenn man in die beiden nächsten Takte auf dem anderen Take wechseln will. - Ich deute das nur an; wenn es um Take-basiertes Editing von Sprachaufnahmen (die keinem Taktmaß folgen) geht, landet man in noch ganz anderen Problemen.

Worauf ich hinaus will: es gibt in den meisten Programmen Features, die nur historisch begründet sind, und mit den Problemen, die ihre User lösen wollen, gar nichts zu tun haben. Das Konzept der „Lanes“ z.B. kommt vom Versuch, die ursprünglichen Limitierungen bei der Wiedergabe von Audiomaterial im Userinterface fruchtbar zu machen. Die User sehen das ganz anders: sie haben ein Problem, das man in der ursprünglichen Version des Features nicht recht lösen kann, und verlangen Nachbesserungen, selbst wenn die regelmäßig deutlich über die technischen Limitationen des ursprünglichen Designs hinaus weisen. Dann wird von den Entwicklern oft genug nachgebessert, bis ein Grad an Komplexität im Code (aber auch im Userinterface) entsteht, den keiner mehr recht versteht bzw. beherrscht.

(Wer übrigens der Meinung ist, dies sei ein Cubase- bzw. Steinberg-spezifisches Problem, sollte mal versuchen, Adobe Photoshop zu lernen.)

2 Kommentare

Jede technische Innovation geht erst dann in die Breite, wenn sie nicht nur problemlos funktioniert, sondern auch einfach zu bedienen ist. Das ist bei Autos nicht anders als im Bereich von Computersoftware. Noch in den 60ern mußte man sich richtig mit seinem Fahrzeug auskennen, um nicht unvermittelt mit ihm liegen zu bleiben; auf das Internet Anfang/Mitte der 90er hatten nur Spezialisten Zugriff; etc.

Lenkrad F!

Man sollte aber einen zweiten Punkt nicht übersehen. Wenn ich ein Familienauto verkaufen will, muß es einfach zu bedienen sein. Wenn ich jedoch einen Rennwagen baue, ist einfache Bedienbarkeit nur eine Anforderung. In erster Linie muß dieses Auto dem Fahrer alle Option geben, das Limit aus ihm herauszuholen. Das geht nicht ohne ein gewisses Maß an Komplexität im Userinterface – man muß sich nur einmal das Lenkrad eines Formel-1-Autos ansehen, um dafür ein Gefühl zu bekommen. Auch hier geht es natürlich nicht ohne erheblichen Aufwand beim Design der Bedienelemente – schließlich muß der Fahrer auf die Strecke schauen, und nicht auf die Knöpfe am Lenkrad. Es geht hier also nicht in erster Linie um Einfachheit, sondern Ergonomie bei der Bedienung, wobei man in Kauf nimmt, daß es eines gewissen Trainings bedarf, diese Bedienung zu erlernen. – Aber das ist jetzt genug mit Autometaphern.

Was ich sagen will: wenn man neue Sachen in der Software-Entwicklung ausprobiert, hat man nicht automatisch die richtigen Abstraktionen zur Hand, die dem User (und auch dem Programmierer) das Handwerk einfach machen. Wenn man dann noch die Kosten in der Entwicklung berücksichtigen muß (und nicht etwa mit einem Release Jahre warten will, weil man noch zahllose Iterationen bräuchte, um ein Feature „richtig” zu bekommen), hat man öfters nur zwei Möglichkeiten: man nimmt eine gewisse Komplexität hin, weil man dem User bestimmte Möglichkeiten nicht nehmen will; oder man streicht gewisse Optionen (indem man z.B. eine Auswahl durch einen Defaultwert ersetzt). Ich bin dann (nur dann, unter den oben genannten Restriktionen) eher geneigt, ein Menu mehr anzubieten, als es für ein sauberes Interface „richtig” wäre.

Ich bin überzeugt, die Mehrheit der User teilt meinen Standpunkt.



Wenn man es mit einem über Jahrzehnte gewachsenen, durch zahlreiche Hände gegangenen Sourcecode zu tun hat, gibt es wohl nur zwei Möglichkeiten, an ihm etwas zu verändern:

  • Man geht den „richtigen Weg”: die Probleme werden analysiert; die Aufwände abgeschätzt; und das Management bewilligt die benötigten Ressourcen in der Entwicklungsabteilung (eine fromme Utopie).

  • Der zuständige Entwickler „hackt“ eine Lösung – hoffentlich dann im Bewußtsein, daß dies Konsequenzen hat, weil man sich hier „technische Schulden“ aufhalst (in Form von mittel- oder langfristig unwartbarem Code, den niemand anderer – nicht einmal er selbst – in der Zukunft noch verstehen wird).

  • Dazwischen gibt es, soweit ich das sehe, keine Lösung. Kompromisse sind immer der Weg der Hacker.

    Dabei ist der „richtige Weg“ nur in den allerwenigsten Situationen gangbar. In der Forschung an den Universitäten ist dies vielleicht eine Option – selbst dort wohl nur ausnahmsweise. Spätestens bei proprietärer Software, in der sog. „freien Wirtschaft“, funktioniert das zu keiner Sekunde. Die Entwickler dort sind – zumindest in meiner eigenen Erfahrung – letztlich permanent am Hacken, so wenig sie das mit ihrem eigenen Ethos auch vereinbaren können. Der „Markt“ verlangt, daß sie mit ihren Features zu einem bestimmten Zeitpunkt fertig werden.

    Glücklicherweise bin ich mit Musiksoftware beschäftigt. Dennoch: wenn ich nur eine Zeile Code falsch schreibe, hat dies durchaus Konsequenzen für alle User von Cubase (im Zweifelsfall bringt das das Programm zum Absturz, und beerdigt zahlreiche Stunden Arbeit Anderer mit ihm). Zumindest hat mein Fehler dann nicht zur Folge, daß man Leichen zählt.

    Woanders sieht das ganz anders aus.

    Die Mechanismen, in die meine Arbeit eingebettet ist, dürften sich wiederfinden bei jenen, die mit der Entwicklung der Software für Autopiloten in Flugzeugen oder die Steuerung von Abschußanlagen für nukleare Raketen (oder – prominent gerade – der Entwicklung von Algotrading) beschäftigt sind.

    Das ist jetzt keine Verschwörungstheorie, sondern eine Beschreibung dessen, womit ich in meinem Alltag zu tun habe.



    Kommentieren [Drucken]