Mein gestriger Eintrag beschäftigte sich mit verschiedenen Versuchen, ein Lisp zu finden, das sich für systemnahe Entwicklung eignet und endete mit dem Schluß, daß die einzige Lösung ein extrem dünner syntaktischer Layer über C zu sein scheint, wie SC einer ist.

Nachdem ich mit diesem Ergebnis immer noch ein wenig unzufrieden war, startete ich noch einen weiteren, letzten Versuch, etwas anderes zu finden. Und wer hätte es gedacht? Die richtigen Suchbegriffe brachten mich tatsächlich zu einem höchst interessanten Lisp-Dialekt für Systementwicklung: Pre-Scheme.

Pre-Scheme wird verwendet, um die virtuelle Maschine von Scheme48 zu entwickeln. Ein Pre-Scheme-Compiler befindet sich entsprechend in der Distribution von Scheme48.

Der Unterschied zwischen Pre-Scheme und SC ist, daß Pre-Scheme versucht, möglichst viele Features von Scheme zu erhalten, ohne die direkte Übersetzung in C-Code zu gefährden. So bietet Pre-Scheme immer noch anonyme Funktionen, (lokale) Endrekursion und die Standard-Scheme-Datenstrukturen. Dafür ist die Sprache statisch typisiert (mit Hindley-Milner-Typinferenz) und verwaltet Speicher nicht selbständig. Daß außerdem Continuations nicht unterstützt werden, versteht sich von selbst. Die Performance von kompiliertem Pre-Scheme-Code ist laut dem zugehörigen Paper sehr nah an dem von händisch geschriebenen C-Code, und die Kompilierstrategie scheint bis ins Detail ausgesprochen durchdacht zu sein.

An sich sieht Pre-Scheme bereits sehr überzeugend aus. Interessant ist jedoch auch, daß in den Kommentaren zu einem der beiden damit zusammenhängenden Reddit-Einträge (der andere ist der ältere) auf einige verwandte Projekte verwiesen wird, nämlich Schlep (ein weiteres abgespecktes Scheme), ThinLisp (ein abgespecktes Common Lisp), CLiCC (Common Lisp, ähnlich ThinLisp) und BitC (ein ML-inspirierter Ansatz).

Sieht so aus, als gälte es, doch noch einiges auszuprobieren.

Der Wunsch: Systemnahes Programmieren mit Lisp

Nehmen wir an, wir möchten für ein kleines, in seinen technischen Fähigkeiten eingeschränktes Gerät Code schreiben, zum Beispiel für ein Handy. In diesem Fall wird man vor allen Dingen versuchen müssen, den Arbeitsspeicherverbrauch in engen Grenzen zu halten. Nehmen wir weiters an, wir wären ein leidenschaftlicher Lispprogrammierer. Welche Programmiersprachen eignen sich für uns in dieser Situation?

Erster Versuch: Scheme

Auf dem Scheme-Wiki liest man, Scheme habe im Gegensatz zu Common Lisp eine kleine Laufzeitumgebung, die leicht in C-Code einbettbar sei. Machen wir uns also zunächst auf die Suche nach einer passenden Scheme-Implementierung. Das scheint am erfolgversprechendsten.

Am sinnvollsten erscheinen zunächst die Implementierungen, die C-Code erzeugen. Diejenigen darunter, die eine einigermaßen hinreichende Auswahl an Bibliotheken bereitstellen, sind, wie es scheint, Chicken, Gambit und Bigloo. Besonders letztere Implementierung scheint C-nah zu sein, ein gutes Zeichen.

Kompiliert man die Implementierungen aber, so zeigt sich ein ernüchterndes Bild: Die Laufzeitumgebungen sind nicht gerade klein, wenn man von einem eingeschränkten Zielgerät ausgeht. Die Runtime von Chicken schlägt mit fast 4 MB zubuche, die von Bigloo mit über 4,5 MB und die von Gambit sogar mit rund 5,5 MB. Damit ist die Option Scheme wohl erledigt.

Zweiter Versuch: Common Lisp

Der Gedanke, den man an diesem Punkt hegen kann, ist: Wenn die Runtimes der Schemes ohnehin recht groß sind, können wir auch gleich Common Lisp verwenden. Das wird zwar nicht kleiner, aber zumindest komfortabler sein.

Wir laden also ECL herunter, das „einbettbare Common Lisp“, kompilieren es und sind erstaunt: Die Runtime ist gerade einmal 2 MB groß — um die Hälfte kleiner als das kleinste praktikable Scheme also. Wir vermuten, daß die Scheme-Seite bis dato einiges an Optimierungspotential ungenutzt gelassen hat.

Wie auch immer: Wir merken uns ECL vor, suchen aber weiter. Kann es wirklich sein, daß man mindestens 2 MB an Runtime mit sich herumschleppen muß, um ein wenig von C wegzukommen?

Dritter Versuch: Exotische Systemlisps

Wir landen auf unserer Suche nach einem möglichst C-nahen Lisp bei einigen Ansätzen, die versuchen, die Auslieferung fertiger Software zu vereinfachen, indem nicht zu weit von C weggegangen wird. Diese sind STELLA, eine Art Multicompiler für Lisp, der seinen Lispdialekt in Java, C++ und Common Lisp übersetzen kann, und Lush, ein speziell auf effiziente numerische Berechnungen ausgelegtes Lisp.

Auch, wenn sich beides ganz nett anhört, die Details machen uns erneut einen Strich durch die Rechnung: Wieder sind die Laufzeitumgebungen einfach zu groß.

Vierter Versuch: Back to the Roots

Langsam müde von der langen Recherche, widmen wir uns der letzten Idee: Wir suchen nach etwas, das so nah an C bleibt, wie möglich. Das heißt: Wir opfern Lispigkeit, um Systemnähe zu erhalten. Wir halten Ausschau nach etwas, das letztlich nur ein Präprozessor ist, der Code direkt und ohne Laufzeitumgebung in reinen, rohen C-Code übersetzt.

Es gibt mit Sicherheit einige Ansätze dazu. Wir beschränken uns auf die Lisp-nahen und finden zwei: C-amplify und SC.

C-amplify: Ambitioniert, und zwar zu sehr

C-amplify ist das ambitioniertere der beiden Projekte. Es versucht, alle Informationen zu sammeln, die es kriegen kann. Dafür nimmt es an, daß der C-Präprozessor nicht verwendet wird. Stattdessen muß der Benutzer dafür Sorge tragen, daß Deklarationen aller Funktionen und Datenstrukturen, auf die man zugreifen will, in für C-amplify verständlicher Form vorliegen.

Der Ansatz von C-amplify verhindert natürlich, daß C-Code direkt eingebettet werden kann, weil ansonsten die Informationen über Rückgabewerte und ähnliches verloren gehen könnten. Leider unterstützt C-amplify noch nicht alles, was in C möglich ist, weshalb das dazu führt, daß man manche Dinge einfach nicht tun kann. Außerdem ist es schwierig, Bibliotheken von Drittanbietern oder des Betriebssystems zu verwenden, wenn man den C-Präprozessor nicht ausnutzen kann. Was aber ist C ohne Bibliotheken? Richtig. Versuchen wir etwas anderes.

SC: Keep it Simple, Stupid

Wir sehen uns zuletzt also SC an. Auf den ersten Blick erinnert es uns sehr an C-amplify, nur mit einem kleinen, doch wesentlichen Unterschied: Die Ambitionen sind merklich kleiner.

SC versucht nicht, Typinferenz zu betreiben oder sonstige Daten über das zu kompilierende Programm zu sammeln, um Optimierungen durchzuführen. Es verlangt auch nicht, daß irgendwelche Informationen aus Header-Dateien dupliziert oder in das System eingelesen werden. Stattdessen macht es eine sture Übersetzung aus einer Lisp-artigen Syntax in die entsprechende C-Syntax, und expandiert nebenbei (prozedurale, lispige) Makros. Mehr tut es nicht, seinen Zweck erfüllt es dafür aber klaglos.

Wir schreiben Code wie diesen:

;;;; -*- mode: lisp -*-

(c-exp "#include <stdio.h>")
(c-exp "#include <stdlib.h>")

(def (main argc argv) (fn int int (ptr (ptr char)))
  (if (> argc 1)
      (printf "Hallo, %s!~%" (aref argv 1))
      (printf "Hallo, Welt!~%"))
  (return EXIT_SUCCESS))

Er wird übersetzt in das Folgende:

#include <stdio.h>
#include <stdlib.h>

int 
main(int argc, char **argv)
{
  if (argc > 1)
    printf("Hallo, %s!\n", argv[1]);
  else
    printf("Hallo, Welt!\n");
  return EXIT_SUCCESS;
}

Hübsch! Fehlt nur noch, daß man SC von der Befehlszeile aus aufrufen kann anstatt von Lisp aus, und auch das ist hinzubekommen, indem man folgende drei Befehle in die CLISP-Befehlszeile eingibt. Wir erzeugen dadurch ein Befehlszeilentool mit dem Namen „sc2c“:

(load "init.lsp")
(ext:saveinitmem "sc2c"
                 :norc t
                 :executable t
                 :init-function (lambda ()
                                  (let ((sc-main::*indent-options* '("-i2")))
                                    (mapc 'sc-main:sc2c ext:*args*))
                                  (ext:exit)))
(ext:exit)

Die Übersetzung durch SC ist einfach und effektiv. Wenn man ein Konstrukt findet, von dem man nicht weiß, wie man es in der Lispsyntax schreiben soll, oder wenn man es aus irgendwelchen Gründen schlicht lieber direkt in C ausdrückt, dann geht das mit der C-EXP-Form. Man kann SC leicht in seinem Makefile vor den C-Compiler schalten, es ist unintrusiv, es verlangt einem nichts ab, und es erfordert keine Änderungen an bestehendem Code. Kurz: Es ist ein Meisterwerk.

Ich werde mit SC auf jeden Fall herumexperimentieren. Vielleicht gewöhne ich mich daran. Vielleicht verwende ich es sogar bald produktiv. Man wird sehen.

Die Landes-ASten-Konferenz Bayern berichtet:

Während sich die soziale Situation der Studierenden durch die Einführung von Bachelor und Studiengebühren weiter verschärft hat, kürzt die Staatsregierung erneut die Gelder der Studentenwerke ...

„Es ist durchaus denkbar, dass das Kaputtsparen der Studentenwerke den Weg für ihre spätere Privatisierung ebnen soll. Solche Gedankenspiele gibt es unter anderem in den Reihen der FDP“, so Malte Pennekamp.

Nach der erfolgreichen Marodisierung der Post, der Bahn, der gesetzlichen Krankenversicherung, der gesetzlichen Altersvorsorge und vielen weiteren für die Gesellschaft lebensnotwendigen Institutionen soll es nun also auch den Studentenwerken an den Kragen gehen. Es wird hier wahrscheinlich genau wie dort ablaufen: Erst spart man die Einrichtung kaputt, dann erklärt man sie für defizitär (Überraschung!) und folglich nicht mehr finanzierbar, und zum Schluß folgt die Privatisierung. Natürlich wird der Staat die Einrichtung auch nach der Privatisierung noch mit Steuergeldern unterstützen, um sein Gesicht zu wahren, nur werden diese Gelder mehr in die Unternehmensstrukturen fließen, als daß sie wie bislang den Studenten zugutekämen.

Umleiten von Geld aus den Taschen derer, die es brauchen, in die derer, die genug haben, um sich ein ehemaliges Staatsunternehmen zu kaufen: Die rot-grün-schwarz-gelbe Einheitspartei nennt das „Fördern von Eigenverantwortung“.

Was man tun kann: Gegen das Vorhaben der Regierung gibt es eine Petition, in die man sich online eintragen kann. Es ist dafür (wie bei Petitionen üblich) nicht notwendig, betroffen (d.h. Student) zu sein.

Wenn Müßiggang wirklich der Anfang aller Laster ist, so befindet er sich also wenigstens in der nächsten Nähe aller Tugenden; der müssige Mensch ist immer noch ein besserer Mensch als der tätige. — Friedrich Nietzsche: Menschliches, Allzumenschliches I

Wenn man versucht, seinen Mitmenschen die Idee eines Grundeinkommens oder gar einer Schenkungswirtschaft nahezubringen, ist das erste, was einem vorgehalten wird, stets der Einwand, jede solche neuartige Ökonomie, welche nicht auf Arbeitszwang beruhe, könne niemals gerecht sein, weil sie Menschen dazu befähige, „auf Kosten der anderen“ zu leben, d.h. sich von einem Grundeinkommen zu ernähren und von ihm zu profitieren, ohne eine Gegenleistung zu erbringen.

Keine Leistung ohne Gegenleistung? Aber was ist eigentlich eine „Leistung“?

Zunächst einmal finde ich es kurios, daß Gerechtigkeit, hier: die Berechtigung zur Nutzung der gemeinschaftlichen Dienste, zuallererst darüber definiert wird, was ein Mensch an Arbeit leistet. Ist ein Menschenleben denn nicht von sich aus schon wertvoll genug, daß eine würdevolle Behandlung ihm zustünde? Gibt es nicht darüberhinaus wesentlich wichtigere Eigenschaften eines Menschen als die des Fleißes, wie Einfühlsamkeit, Hilfsbereitschaft, Genügsamkeit und Friedlichkeit? Ich für meinen Teil kann die meisten allzu eifrigen Menschen jedenfalls nicht leiden — das freilich nicht aufgrund ihres Eifers, aber doch aufgrund der Eigenschaften, die erfahrungsgemäß mit Eifer einherzugehen pflegen wie Selbstgerechtigkeit, Hochnäsigkeit ob der eigenen errungenen oder angestrebten Erfolge, Engstirnigkeit, unkritischer Konformismus und die Verachtung alles und aller Andersartigen, welches und welche nicht in ihr Weltbild von der Brave New World passen, in der jeder Bettler und jeder Mensch beliebiger geistiger, körperlicher und sozialer Prägung zum Millionär werden kann, wenn er sich nur genug anstrengt. (Darauf, daß ein solches Weltbild völlig an der Realität vorbei geht, will ich heute gar nicht eingehen, ich setze es vielmehr als offensichtlich voraus.)

Doch selbst, wenn wir so täten, als gäbe es ein gottgegebenes Gesetz, das uns vorschreibt, jeder müsse für eine in Anspruch genommene Leistung auch eine entsprechende Gegenleistung erbringen — selbst, wenn wir das Leistungsprinzip also als Axiom unseres Wertesystems festschreiben — kann ich nicht nachvollziehen, inwiefern ein freieres System weniger erstrebenswert wäre als das unsrige. Sehen wir uns die Situation in unserem real existierenden kapitalistischen System doch einmal nüchtern an: Auf der einen Seite schuften Menschen tag und nacht und verdienen gerade mal einen Hungerlohn, und auf der anderen haben welche eine Position, in der sie kaum schwer arbeiten und doch Unmengen an Geld (also der angeblichen Meßgröße für „Leistung“) verdienen. So sieht die Realität aus.

Man mag nun diese schnöde empirische Argumentation damit abtun, daß man dem allen widerspricht und behauptet, sicher, vereinzelt möge das momentan ja stimmen, könne aber durch entsprechende Regulierungen behoben werden. In Wahrheit aber hält das Leistungsprinzip in einer rein marktwirtschaftlich organisierten Gesellschaft nicht nur der Empirie, sondern auch der Theorie nicht stand, und zwar gleich in zweierlei Hinsicht: zum einen nämlich in Hinblick auf die Lohnarbeit als Gegenleistung für in Anspruch genommene Leistungen, sowie zum anderen im Hinblick auf die Ergebnisorientierung des Marktes.

Mit dem ersten Punkt meine ich folgende Problematik: Nehmen wir an, jemand würde die Dienstleistung einer Krankenpflegerin in Anspruch nehmen und diesen dafür aus seinem Lohn bezahlen, welchen er für die Entwicklung von Software für eine Rüstungsfirma erhält. Hier stellt sich die Frage: Was, realwirtschaftlich betrachtet, hat die Krankenpflegerin für einen Nutzen von der Arbeit des Softwareentwicklers? Sie hat nur insofern einen Nutzen davon, als daß sie sagen kann: „dieser Mensch hat für meine Leistung selbst etwas geleistet“. Dieser „Nutzen“ ist aber rein virtuell. Real hat der Softwareentwickler nichts geleistet, was der Krankenpflegerin in irgend einer Weise materiell oder sonstwie etwas gebracht hätte. Insofern hat er gerade keine Gegenleistung erbracht, außer in Form des Geldes — welches in einem System mit Grundeinkommen aber genau im selben Maße von ihm zu ihr geflossen wäre.

Man könnte freilich sagen: Gut, der Softwareentwickler mag der Krankenpflegerin keinen direkten, doch aber einen indirekten Nutzen gebracht haben. Es ist dies allerdings wohl sehr anzuzweifeln, sobald die Arbeit eine ist, die weniger der (realen) Gesellschaft zugutekommt als einer wirtschaftlichen Entität wie dem Staat oder einer Firma; oder wenn sie gar von so einer Natur ist, daß sie nur der Aufrechterhaltung der Arbeitsmaschinerie selbst dient — und machen wir uns jeder neoliberalen Rhetorik zum Trotz nichts vor: Die meiste Arbeit fällt gerade in eine dieser beiden Klassen.

Das führt uns direkt zum zweiten Punkt, der Ergebnisorientierung im freien Markt. Produkte werden vom Kunden in einem funktionierenden Markt für einen Preis gekauft, der ihrem Wert für den Kunden entspricht. Ebenso wird ein Angestellter nach dem Wert des Ergebnisses seiner Arbeit bezahlt. Dieser Wert wird aber einerseits nicht gesamtgesellschaftlich gemessen, sondern stets in Bezug auf den Arbeitgeber; andererseits ist er losgelöst von der Mühe, die in der Arbeit steckt. So kommt es, daß der eine Mensch, der sich vom Morgen bis zum Abend mit aller Kraft unter den widrigsten Umständen abmüht, weniger bezahlt bekommen kann als der, der in einem wohlgeheizten Büro in angenehmer Atmosphäre verhältnismäßig leichte Denk- und Verwaltungsaufgaben übernimmt. Das heißt: Nirgends ist hier das Leistungs-Prinzip realisiert, sondern es handelt sich vielmehr um ein Ergebnis-Prinzip. Deshalb ist auch ein gewisser Slogan einer gewissen politischen Partei so zynisch: Es ist gar nicht die Leistung, die sich nach deren Vorstellungen „wieder“ lohnen soll (wo auch immer das Wörtchen „wieder“ in diesem Kontext herrühren mag), sondern das wirtschaftliche Ergebnis der Leistung.

Insofern ist es also sogar doppelt unangebracht, davon zu sprechen, in unserem System würden Leistungen mit Gegenleistungen erkauft. Die Absurdität geht aber noch wesentlich weiter als nur bis hierhin.

Das absurde Geschrei nach dem Recht auf Arbeit

Aus der neoliberalen Ideologie ersteht unmittelbar die Forderung nach einem Recht auf Arbeit. Der Gedankengang ist einfach: Wenn nur für eigene Leistung eine fremde Leistung genutzt werden darf, dann muß auch jeder die Möglichkeit erhalten, Leistung zu erbringen, weil sonst die Teilnahme an der Gesellschaft nicht mehr für alle ermöglicht werden kann.

Eine direkte Konsequenz des Rechts auf Arbeit ist, daß es stets ein großes Drama geben muß, wenn eine Firma sich im Untergang befindet. Rein marktwirtschaftlich gedacht, ist der Untergang eines Unternehmens nichts per se Schlechtes: Leistet die Firma nichts mehr, wofür die Gesellschaft zu zahlen bereit ist, hat sie ihren Zweck in der Volkswirtschaft und damit ihre Existenzberechtigung verloren. Die Arbeitsverwalter aber betonen wie in nahezu jedem anderen Kontext auch stets nicht das Volks-, sondern das Individualwirtschaftliche: Menschen verlieren durch die Auflösung einer Firma ihre Arbeit — also muß der Steuerzahler einspringen und ihr Gehalt bezahlen.

Das ganze Spiel ist für einen Außenstehenden natürlich vollkommen lächerlich, ja geradezu satirisch. Eine bestimmte Arbeit wird nicht mehr gebraucht — aus realwirtschaftlicher Sicht müßte man sich unheimlich darüber freuen! Schließlich bedeutet ein unnötig gewordener Arbeitsprozeß ja, daß die Gesellschaft jetzt die Möglichkeit hätte, jedem ihrer Mitglieder ein bißchen mehr Freizeit zu spendieren. Was wird aber stattdessen getan? Die, die noch Arbeit haben, müssen im Gegenteil für die Erhaltung der Arbeit bezahlen, das heißt: sie müssen mehr arbeiten, damit andere auch mehr arbeiten dürfen.

In der Dualität zwischen Individual- und Volkswirtschaft liegt die Lösung

Der Grund für das Funktionieren dieses absurden Prozesses, der einer gewissen Komik nicht entbehrt, ist, daß die von der Propaganda des Kapitals indoktrinierten Menschen in unserer Gesellschaft stets nur individualwirtschaftlich denken und die reale Volkswirtschaft außer Acht lassen. Was nämlich durchgehend unter den Tisch fällt, ist die Tatsache, daß jeder von uns vom Funktionieren der ganzen Gesellschaft abhängt. Jedes individuelle Stück Erfolg wird zu einem Teil von allen anderen in der Gesellschaft gespendet. Was wäre der Informatiker, wenn der Computer nicht erfunden worden wäre, was der Automobilhersteller ohne den Straßenbauer, den Tankwart, den Reifenhändler? Es gibt eben de facto keine reine Individualwirtschaft, sondern nur eine in die Gesellschaft eingebettete, individuell scheinende Situationswirtschaft.

Die Fixierung auf die (virtuelle) Individualwirtschaft hat zur Folge, daß ein Anwuchs des Volksreichtums ebensowenig den individuellen Wohlstand verbessert, wie ein Anwuchs der Produktivität durch Automatisierung einen positiven Einfluß auf die Freizeit des einzelnen Menschen hat. Was in beiden Fällen stattdessen passiert, ist, daß das Volk Güter und Dienstleistungen überproduziert, die dann an den Rest der Welt teuer verkauft, oder wie im Falle der Landwirtschaft einfach weggeworfen werden.

Der primäre Effekt ist offenbar, daß die Menschen von dem von ihnen selbst erwirtschafteten allgemeinen Wohlstand nichts haben. Das ist an sich bereits ungerecht. (Wir erinnern uns: Angebliche Gerechtigkeit ist das Hauptargument für die Beibehaltung dieses Systems.)

Es gibt aber noch einen sekundären, global gesehen sogar fataleren Effekt: Ein Volk, das überproduziert, überstrapaziert auch die natürlichen Ressourcen, wobei zusätzlich Müll und Abgase anfallen. Wenn einige sagen: „Die Gesellschaft kann sich keine Müßiggänger leisten“, dann ist darauf zu erwidern: Vielleicht, aber vor allem kann sich die Erde keine Übereifrigen leisten. Wer darauf hinweist, daß jeder Müßiggänger Kosten für die Gesellschaft erzeuge, den sollte man seinerseits darauf hinweisen, daß das auf jeden Arbeitenden genauso zutrifft. Nicht umsonst ist es so schwierig, beim Thema Umweltschutz alle unter einen Hut zu bringen: Schließlich gefährdet jede Umweltschutzmaßnahme, jedes Zurückdrehen industrieller Produktion den heiligen Volkswohlstand.

Das Grundeinkommen als Bindeglied zwischen Gesellschaft und Individuum

Die Idee des Grundeinkommens ist es nun, die Brücke zwischen Individual- und Volkswirtschaft zu schlagen, indem jeder einzelne am Volkswohlstand gleichermaßen beteiligt wird, und zwar bedingungslos. So wird das institutionalisiert, was ohnehin wahr ist, bei uns aber bislang nicht gewürdigt wird: die Abhängigkeit des Einzelnen von der Gesellschaft wie umgekehrt. Wer mit seinem eigenen Wohlstand nicht zufrieden ist, muß eben in entsprechendem Maße arbeiten gehen. Damit macht er (wie heute) zugleich die Gesellschaft reicher, was (im Gegensatz zu heute) wieder positiv im Grundeinkommen auf ihn zurückschlägt. Wer mit einem einfacheren Leben zufrieden ist, zehrt vom Volkseinkommen und schont die Umwelt, indem er minimalen Ressourcenverbrauch verursacht, was ebenfalls einen Dienst für die Gesellschaft darstellt. So soll sich ein sinnvolles, gesundes Gleichgewicht zwischen Wohlstand, Muße und Nachhaltigkeit einstellen.

In der Diskussion um ein Grundeinkommen geht es letztlich nicht darum, jegliche Arbeit abzuschaffen. Das Ziel ist vielmehr, das Wüten des irrationalen Arbeitswahns einzudämmen. Die Arbeit wird nicht auf 0 reduziert, sondern auf ein rationales, für die Welt wie auch für die freie Entfaltung eines jeden Menschen verträgliches Maß gedrosselt — ein Maß, das jeder von uns nur für sich selbst bestimmen kann.

Seit gut einem Monat bin ich nun Besitzer eines Motorola Milestone, eines der bislang meistgehypten Android-Handys (die anderen sind, nehme ich an, das T-Mobile G1, das HTC Hero und das Google Nexus One).

An sich ist es ein sehr nettes Gerät. Die Konzepte, die dem Betriebssystem zugrundeliegen, sind interessant und gut durchdacht, die Präsenz einer Kamera mit LED-Blitzlicht ist eine feine Sache, und die Anzeige auf dem Bildschirm ist wunderschön und klar. Mit Android 2.0 bekommt man eine von Drittanbietersoftware momentan und mit etwas Glück auch mittelfristig gut unterstützte Version des Betriebssystems. Eigentlich könnte man rundum zufrieden sein...

...wäre da nicht die Sache mit den Updates. Motorola scheint das Milestone-Pendant in den USA, dort bekannt als Motorola Droid, schnell mit neuen Softwareversionen zu versorgen. Nachdem 2.0.1 schon seit über einem Monat für das amerikanische Gerät verfügbar ist, sollte man meinen, daß es auch langsam seinen Weg nach Europa finden würde, vor allem, wenn man bedenkt, wie gesegnet die 2.0-Version mit Fehlern ist. Leider dringen aus den Motorola-Firmengebäuden nur vage Versprechungen von einem bald erscheinenden Update heraus. Keine Angaben zum Erscheinungsdatum, nicht einmal die einer Größenordnung von Zeiteinheiten, die man noch warten müssen wird.

Man könnte jetzt aber natürlich fragen: Was ist eigentlich so schlimm daran, daß gerade für den Milestone die Updates mit so geringer Geschwindigkeit eintrudeln? Das Gerät funktioniert schließlich immer noch besser als viele andere Telephone (auch, wenn die Kamera intolerabel langsam ist und das Betriebssystem hin und wieder seltsame Dinge tut oder abstürzt, besonders mitten in Gesprächen). Und überhaupt: Die meisten Handys werden nach dem Erscheinen gar nicht upgedatet. Warum sind Updates fürs Milestone so wichtig?

App-Phones sind nicht „Smartphones“

Früher war die Welt für die Hersteller von mobilen Handfunkgeräten noch einfach: Gerät entwickeln, Software entwickeln, beides zusammenwerfen, ab damit zum Kunden, das Gerät vergessen, ein neues Gerät entwickeln, Software dafür und so weiter. Handys mußten nicht viel leisten, und das, was sie leisten mußten, war nicht allzu aufwendig. Außerdem waren die Geräte nicht ungeheuer teuer. In jedem Handy war ein bestimmtes Featureset fest eingebaut, und man konnte dem Kunden zumuten, für jede Funktion, die neu hinzukam, ein neues Handy zu kaufen.

Dann kam das iPhone, und alles änderte sich. Auf einmal war es nicht mehr das fest eingebaute Featureset, das das Telephon definierte, sondern das, was man dazuinstallieren konnte. Zugleich wurde die Anschaffung so teuer wie die eines einfachen PCs und damit zu einer Investition für mehrere Jahre. Das Handy, das zuvor ein integriertes Gerät gewesen war, wurde zur Plattform.

Nun haben es Plattformen so an sich, daß neue Versionen in der Regel auch neue Funktionen bieten, so daß Anwendungen, die für eine neue Version der Plattform geschrieben wurden, auf älteren Versionen der Plattform nicht mehr laufen. Softwareentwickler müssen sich entscheiden, welche Versionen der Plattform sie unterstützen. Für die Lebendigkeit der Plattform selbst ist es dabei von großer Wichtigkeit, daß neu eingeführte Features auch in den meisten Fällen ohne schlechtes Gewissen verwendet werden können. Nur so kann eine Weiterentwicklung stattfinden.

Apple löst dieses Problem auf die denkbar einfachste Weise: Sie sorgen dafür, daß die neueste Betriebssystemversion stets für die große Mehrheit der iPhone-Besitzer zur Verfügung steht. Selbst auf dem ältesten iPhone, das inzwischen schon zweieinhalb Jahre alt ist, läuft die aktuellste Version des iPhone OS (momentan 3.1.2). Nicht nur das, auch der iPod Touch trägt zur Ausbreitung derselben Plattform bei, indem auch auf ihm stets die aktuelle Version des iPhone OS verfügbar ist.

Natürlich wird ein und dasselbe Gerät nicht unendlich lange unterstützt werden. Aber zweieinhalb Jahre — darauf kann man sich bei Apple eben schon einmal einstellen. Das tut nicht nur der Plattform und den Entwicklern gut, sondern auch den Kunden. Wenn man heute ein iPhone der neuesten Generation kauft, kann man sich darauf verlassen, daß es eben nicht innerhalb eines halben Jahrs schon wieder überholt ist. Es mag dann nicht mehr zur Spitzenklasse gehören, vielleicht ein bißchen langsamer sein als das neueste Modell, aber so gut wie all neue Software wird darauf problemlos laufen. Ein iPhone ist eine sichere Investition.

Warum hat Google ein eigenes Handy herausgebracht?

Ich vermute, daß genau diese Plattform-Problematik es war, die Google dazu bewogen hat, ein eigenes Handy auf den Markt zu bringen. Zuvor hatten sie noch explizit angekündigt, eben dies nicht tun zu wollen. Google gab der Industrie das Werkzeug, um mit dem iPhone zu konkurrieren, und verließ sich darauf, daß diese auch begreifen würde, wie man das macht.

Die Handyhersteller jedoch wollten es nicht verstehen. Sie klammerten sich an ihr überholtes Geschäftsmodell, an ihren gewohnten Aktuelles-Handy-rausbringen-neues-Handy-entwickeln-altes-Handy-vergessen-Zyklus. Das Resultat: Ein Wirrwarr aus nicht upgradebaren Telephonen mit verschiedenen Android-Versionen, Anwendungen, die auf diesen Geräten laufen, aber nicht auf jenen, und frustrierte Käufer, die ewig auf dringend nötige Fehlerbehebungen warten müssen, kurz: eine Katastrophe für Entwickler und Endbenutzer gleichermaßen.

Um die Plattform nach vorne zu treiben, hat Google also notgedrungen das Ruder selbst in die Hand genommen. Wenn Googles Partnern dadurch jetzt Einnahmen verloren gehen und sie von Verrat und Markenmißbrauch zu sprechen anfangen sollten, kann man dem nur entgegenhalten, daß sie die Schuld nur bei sich selbst zu suchen haben. Schließlich hat Google ihnen die Gelegenheit gegeben, sich gegenüber Apple neu aufzustellen. Daß sie zu hochmütig waren, diese zu nutzen, zeigt nur, wie umsatzorientiert und kurzsichtig sie denken. Früher oder später werden sie mit Erschrecken feststellen, daß unmittelbarer Umsatz nicht alles ist. Nur wird es dann für die meisten von ihnen zu spät sein.

Und der Benutzer?

Für den gemeinen Benutzer bedeutet das: Wer ein Motorola-, Sony-Ericsson- oder Samsung-Handy mit Android kauft, wird sich darauf einstellen müssen, stiefmütterlich behandelt zu werden und in ein, zwei Jahren festzustellen, daß das Handy, das man sich gekauft hat, die meisten verfügbaren Programme nicht ausführen kann. Da die Anwendungen aus dem Android Market letztlich fast den ganzen Wert eines Android-basierten Geräts ausmachen, wird der betroffene Kunde enttäuscht sein. Die Plattform wird leiden, die Kunden werden leiden, und, wenn Letztere vernünftig sind, auch die Handyhersteller.

Mein Rat steht also fürs erste fest: Jeder Hersteller von Android-Geräten, bei dem nicht davon auszugehen ist, daß er seine Geräte über längere Zeit (d.h. allermindestens zwei Jahre) mit den neuesten Android-Versionen versorgen wird, ist zu meiden. Man mag hier einem unbeschriebenen Blatt einerseits den Vorzug des Zweifels geben (wie ich das mit Motorola tat); andererseits mag man argumentieren, daß bei Google auch nicht klar ist, wie sie die Updates des Nexus One handhaben werden. Dennoch: Im Moment sieht es danach aus, als wäre, wenn man die Updateproblematik in Betracht zieht (und das sollte man, da bin ich mir sicher), das Nexus One die bessere Wahl als der Motorola Milestone.