DER ANDERE WEG VOR UNS

September 2001

(In diesem Artikel wird erläutert, warum ein Großteil der Software der nächsten Generation serverbasiert sein könnte, was das für Programmierer bedeutet und warum diese neue Art von Software eine großartige Chance für Startups darstellt. Er basiert auf einem Vortrag bei BBN Labs.)

Im Sommer 1995 beschlossen mein Freund Robert Morris und ich, ein Startup zu gründen. Die PR-Kampagne im Vorfeld des Börsengangs von Netscape lief damals auf Hochtouren, und in der Presse wurde viel über Online-Handel gesprochen. Damals gab es im Internet vielleicht dreißig echte Geschäfte, die alle von Hand erstellt wurden. Wenn es viele Online-Shops geben sollte, brauchte es Software, um sie zu erstellen, also beschlossen wir, welche zu schreiben.

In der ersten Woche wollten wir daraus eine normale Desktop-Anwendung machen. Dann kamen wir eines Tages auf die Idee, die Software auf unserem Webserver laufen zu lassen und den Browser als Schnittstelle zu verwenden. Wir versuchten, die Software so umzuschreiben, dass sie über das Web funktionierte, und es war klar, dass dies der richtige Weg war. Wenn wir unsere Software so schreiben würden, dass sie auf dem Server läuft, wäre es für die Benutzer und auch für uns viel einfacher.

Dies erwies sich als guter Plan. Heute ist diese Software, Yahoo Store genannt, mit rund 14.000 Benutzern der beliebteste Online-Shop-Builder.

Als wir Viaweb gründeten, verstand kaum jemand, was wir meinten, als wir sagten, dass die Software auf dem Server lief. Erst als Hotmail ein Jahr später auf den Markt kam, begannen die Leute, es zu verstehen. Jetzt weiß jeder, dass dies ein gültiger Ansatz ist. Es gibt jetzt einen Namen für das, was wir waren: ein Application Service Provider oder ASP.

Ich denke, dass ein Großteil der nächsten Softwaregeneration nach diesem Modell geschrieben wird. Sogar Microsoft, das am meisten zu verlieren hat, scheint zu erkennen, dass es unvermeidlich ist, einige Dinge vom Desktop zu verlagern. Wenn Software vom Desktop auf Server verlagert wird, bedeutet das für Entwickler eine ganz andere Welt. Dieser Artikel beschreibt die überraschenden Dinge, die wir als einige der ersten Besucher dieser neuen Welt gesehen haben. Soweit Software tatsächlich auf Server verlagert wird, beschreibe ich hier die Zukunft.

Das Nächste?

Wenn wir auf die Ära der Desktop-Software zurückblicken, werden wir, glaube ich, über die Unannehmlichkeiten staunen, die die Leute in Kauf nahmen, so wie wir uns heute darüber wundern, was die ersten Autobesitzer in Kauf nahmen. In den ersten zwanzig oder dreißig Jahren musste man ein Autoexperte sein, um ein Auto zu besitzen. Aber Autos waren ein so großer Erfolg, dass auch viele Leute, die keine Autoexperten waren, eins haben wollten.

Computer befinden sich jetzt in dieser Phase. Wenn Sie einen Desktop-Computer besitzen, erfahren Sie letztendlich viel mehr über das, was in seinem Inneren vor sich geht, als Sie wissen wollten. Aber mehr als die Hälfte aller Haushalte in den USA besitzt einen. Meine Mutter hat einen Computer, den sie für E-Mails und zur Verwaltung von Konten verwendet. Vor etwa einem Jahr war sie alarmiert, als sie einen Brief von Apple erhielt, in dem ihr ein Rabatt auf eine neue Version des Betriebssystems angeboten wurde. Es stimmt etwas nicht, wenn eine 65-jährige Frau, die einen Computer für E-Mails und Konten verwenden möchte, über die Installation neuer Betriebssysteme nachdenken muss. Normale Benutzer sollten nicht einmal die Wörter „Betriebssystem“ kennen, geschweige denn „Gerätetreiber“ oder „Patch“.

Es gibt jetzt eine andere Möglichkeit, Software bereitzustellen, die es den Benutzern erspart, Systemadministratoren zu werden. Webbasierte Anwendungen sind Programme, die auf Webservern laufen und Webseiten als Benutzeroberfläche verwenden. Für den durchschnittlichen Benutzer ist diese neue Art von Software einfacher, billiger, mobiler, zuverlässiger und oft leistungsfähiger als Desktop-Software.

Bei webbasierter Software müssen sich die meisten Benutzer um nichts anderes als die Anwendungen kümmern, die sie verwenden. All das chaotische, sich ständig ändernde Zeug wird irgendwo auf einem Server liegen und von Leuten gepflegt werden, die sich mit solchen Dingen auskennen. Normalerweise braucht man also nicht unbedingt einen Computer, um Software zu verwenden. Alles, was man braucht, ist etwas mit einer Tastatur, einem Bildschirm und einem Webbrowser. Vielleicht hat es einen drahtlosen Internetzugang. Vielleicht ist es auch Ihr Mobiltelefon. Was auch immer es sein mag, es wird Unterhaltungselektronik sein: etwas, das etwa 200 Dollar kostet und das die Leute hauptsächlich aufgrund des Aussehens auswählen. Man zahlt mehr für Internetdienste als für die Hardware, genau wie heute für Telefone. [1]

Ein Klick braucht etwa eine Zehntelsekunde, um zum Server und zurück zu gelangen. Benutzer stark interaktiver Software wie Photoshop möchten die Berechnungen also weiterhin auf dem Desktop durchführen lassen. Wenn man sich jedoch ansieht, für welche Dinge die meisten Leute Computer verwenden, wäre eine Zehntelsekunde Latenz kein Problem. Meine Mutter braucht eigentlich keinen Desktop-Computer, und es gibt viele Leute wie sie.

Der Gewinn für Benutzer

In der Nähe meines Hauses steht ein Auto mit einem Aufkleber, auf dem steht: „Vor Unannehmlichkeiten den Tod suchen“. Die meisten Menschen werden sich meistens für die Option entscheiden, die am wenigsten Arbeit erfordert. Wenn webbasierte Software gewinnt, dann deshalb, weil sie bequemer ist. Und es sieht ganz danach aus, als ob das der Fall sein wird, sowohl für Benutzer als auch für Entwickler.

Um eine rein webbasierte Anwendung zu verwenden, benötigen Sie lediglich einen mit dem Internet verbundenen Browser. Sie können also eine webbasierte Anwendung überall verwenden. Wenn Sie Software auf Ihrem Desktop-Computer installieren, können Sie sie nur auf diesem Computer verwenden. Schlimmer noch, Ihre Dateien bleiben auf diesem Computer gefangen. Die Unannehmlichkeiten dieses Modells werden immer offensichtlicher, je mehr sich die Menschen an Netzwerke gewöhnen.

Die Spitze des Eisbergs war hier die webbasierte E-Mail. Millionen von Menschen erkennen heute, dass man überall Zugriff auf E-Mail-Nachrichten haben sollte. Und wenn man seine E-Mails sehen kann, warum dann nicht auch seinen Kalender? Wenn man ein Dokument mit seinen Kollegen besprechen kann, warum kann man es dann nicht bearbeiten? Warum sollten irgendwelche Daten auf einem Computer auf einem weit entfernten Schreibtisch gefangen sein?

Die ganze Idee von „Ihrem Computer“ verschwindet und wird durch „Ihre Daten“ ersetzt. Sie sollten von jedem Computer aus auf Ihre Daten zugreifen können. Oder besser gesagt, von jedem Client aus, und ein Client muss kein Computer sein.

Clients sollten keine Daten speichern, sie sollten wie Telefone sein. Tatsächlich könnten sie zu Telefonen werden oder umgekehrt. Und wenn die Zahl der Clients kleiner wird, gibt es einen weiteren Grund, Ihre Daten nicht auf ihnen zu speichern: Dinge, die Sie mit sich herumtragen, können verloren gehen oder gestohlen werden. Wenn Sie Ihren PDA in einem Taxi liegen lassen, ist das wie ein Festplattencrash, nur dass Ihre Daten an jemand anderen weitergegeben werden, anstatt verdampft zu werden.

Bei rein webbasierter Software bleiben weder Ihre Daten noch die Anwendungen auf dem Client gespeichert. Sie müssen also nichts installieren, um sie zu verwenden. Und wenn keine Installation erfolgt, müssen Sie sich auch keine Sorgen machen, dass die Installation schiefgeht. Es kann keine Inkompatibilitäten zwischen der Anwendung und Ihrem Betriebssystem geben, da die Software nicht auf Ihrem Betriebssystem läuft.

Da keine Installation erforderlich ist, ist es einfach und üblich, webbasierte Software vor dem „Kauf“ auszuprobieren. Sie können jede webbasierte Anwendung kostenlos testen, indem Sie einfach die Website aufrufen, auf der sie angeboten wird. Bei Viaweb war unsere gesamte Website wie ein großer Pfeil, der die Benutzer auf die Testversion hinweist.

Nach dem Ausprobieren der Demoversion sollte die Anmeldung für den Dienst nichts weiter erfordern als das Ausfüllen eines kurzen Formulars (je kürzer, desto besser). Und das sollte die letzte Arbeit sein, die der Benutzer erledigen muss. Bei webbasierter Software sollten Sie neue Versionen erhalten, ohne extra zu bezahlen, etwas zu tun oder möglicherweise überhaupt davon zu wissen.

Upgrades werden nicht mehr so große Überraschungen sein wie heute. Mit der Zeit werden Anwendungen immer leistungsfähiger. Dies wird einige Anstrengungen seitens der Entwickler erfordern. Sie müssen Software so gestalten, dass sie aktualisiert werden kann, ohne die Benutzer zu verwirren. Das ist ein neues Problem, aber es gibt Möglichkeiten, es zu lösen.

Bei webbasierten Anwendungen verwendet jeder die gleiche Version und Fehler können behoben werden, sobald sie entdeckt werden. Webbasierte Software sollte also weitaus weniger Fehler aufweisen als Desktop-Software. Ich bezweifle, dass wir bei Viaweb jemals zehn bekannte Fehler gleichzeitig hatten. Das ist um Größenordnungen besser als bei Desktop-Software.

Webbasierte Anwendungen können von mehreren Personen gleichzeitig verwendet werden. Das ist ein klarer Vorteil für kollaborative Anwendungen, aber ich wette, die Benutzer werden dies in den meisten Anwendungen wollen, sobald sie erkennen, dass es möglich ist. Es wird beispielsweise oft nützlich sein, zwei Personen dasselbe Dokument bearbeiten zu lassen. Viaweb ermöglichte es mehreren Benutzern, eine Site gleichzeitig zu bearbeiten, mehr, weil dies die richtige Art war, die Software zu schreiben, als weil wir erwarteten, dass die Benutzer dies wollten, aber es stellte sich heraus, dass viele dies taten.

Wenn Sie eine webbasierte Anwendung verwenden, sind Ihre Daten sicherer. Festplattenabstürze gehören nicht der Vergangenheit an, aber die Benutzer hören nichts mehr davon. Sie passieren in Serverfarmen. Und Unternehmen, die webbasierte Anwendungen anbieten, führen tatsächlich Backups durch – nicht nur, weil sie echte Systemadministratoren haben, die sich um solche Dinge kümmern, sondern weil ein ASP, der tatsächlich Daten von Benutzern verliert, in große Schwierigkeiten gerät. Wenn Benutzer bei einem Festplattenabsturz ihre eigenen Daten verlieren, können sie nicht so wütend werden, weil sie nur auf sich selbst wütend sein können. Wenn ein Unternehmen ihre Daten für sie verliert, werden sie viel wütender.

Schließlich sollte webbasierte Software weniger anfällig für Viren sein. Wenn auf dem Client nichts außer einem Browser läuft, ist die Wahrscheinlichkeit geringer, dass Viren auftreten, und es können keine Daten lokal beschädigt werden. Und ein Programm, das die Server selbst angreift, sollte feststellen, dass diese sehr gut geschützt sind. [2]

Für Benutzer wird webbasierte Software weniger stressig sein. Ich denke, wenn Sie in den durchschnittlichen Windows-Benutzer hineinschauen, werden Sie einen riesigen und weitgehend ungenutzten Wunsch nach Software entdecken, die diese Beschreibung erfüllt. Entfesselt könnte dieser Wunsch eine mächtige Kraft sein.

Stadt des Codes

Für Entwickler ist der auffälligste Unterschied zwischen webbasierter und Desktop-Software, dass eine webbasierte Anwendung kein einzelnes Stück Code ist. Es ist eine Sammlung von Programmen unterschiedlicher Art und nicht eine einzige große Binärdatei. Und so ist das Entwerfen webbasierter Software eher wie das Entwerfen einer Stadt als eines Gebäudes: Neben Gebäuden braucht man Straßen, Straßenschilder, Versorgungseinrichtungen, Polizei- und Feuerwehrstationen und Pläne für Wachstum und verschiedene Arten von Katastrophen.

Bei Viaweb umfasste die Software ziemlich große Anwendungen, mit denen die Benutzer direkt kommunizierten, Programme, die diese Programme verwendeten, Programme, die ständig im Hintergrund liefen und nach Problemen suchten, Programme, die versuchten, Dinge neu zu starten, wenn sie kaputt gingen, Programme, die gelegentlich liefen, um Statistiken zu erstellen oder Indizes für Suchvorgänge zu erstellen, Programme, die wir explizit ausführten, um Ressourcen zu bereinigen oder Daten zu verschieben oder wiederherzustellen, Programme, die vorgaben, Benutzer zu sein (um die Leistung zu messen oder Fehler aufzudecken), Programme zum Diagnostizieren von Netzwerkproblemen, Programme zum Erstellen von Datensicherungen, Schnittstellen zu externen Diensten, Software, die eine beeindruckende Sammlung von Anzeigen steuerte, die Serverstatistiken in Echtzeit anzeigten (ein Hit bei den Besuchern, aber auch für uns unverzichtbar), Modifikationen (einschließlich Fehlerbehebungen) an Open-Source-Software und jede Menge Konfigurationsdateien und -einstellungen. Trevor Blackwell schrieb ein spektakuläres Programm, um Geschäfte auf neue Server im ganzen Land zu verschieben, ohne sie herunterzufahren, nachdem wir von Yahoo gekauft worden waren. Programme riefen uns an, schickten Faxe und E-Mails an Benutzer, führten Transaktionen mit Kreditkartenprozessoren durch und kommunizierten miteinander über Sockets, Pipes, HTTP-Anfragen, SSH, UDP-Pakete, gemeinsam genutzten Speicher und Dateien. Einige Teile von Viaweb bestanden sogar aus der Abwesenheit von Programmen, da einer der Schlüssel zur Unix-Sicherheit darin besteht, keine unnötigen Dienstprogramme auszuführen, mit denen Leute in Ihre Server eindringen könnten.

Es endete nicht mit der Software. Wir verbrachten viel Zeit damit, über Serverkonfigurationen nachzudenken. Wir bauten die Server selbst, aus Komponenten – teilweise, um Geld zu sparen, und teilweise, um genau das zu bekommen, was wir wollten. Wir mussten darüber nachdenken, ob unser Upstream-ISP über ausreichend schnelle Verbindungen zu allen Backbones verfügte. Wir datierten seriell RAID-Anbieter.

Aber Hardware ist nicht nur etwas, worüber man sich Sorgen machen muss. Wenn Sie sie kontrollieren, können Sie mehr für die Benutzer tun. Bei einer Desktop-Anwendung können Sie eine bestimmte Mindesthardware angeben, aber nicht mehr hinzufügen. Wenn Sie die Server verwalten, können Sie in einem Schritt allen Ihren Benutzern ermöglichen, Personen anzurufen, Faxe zu senden, Befehle per Telefon zu übermitteln, Kreditkarten zu verarbeiten usw., indem Sie einfach die entsprechende Hardware installieren. Wir haben immer nach neuen Möglichkeiten gesucht, Funktionen mit Hardware hinzuzufügen, nicht nur, weil es den Benutzern gefiel, sondern auch, um uns von Wettbewerbern abzuheben, die (entweder weil sie Desktop-Software verkauften oder webbasierte Anwendungen über ISPs weiterverkauften) keine direkte Kontrolle über die Hardware hatten.

Da die Software in einer webbasierten Anwendung eine Sammlung von Programmen und nicht eine einzelne Binärdatei ist, kann sie in einer beliebigen Anzahl verschiedener Sprachen geschrieben werden. Wenn Sie Desktop-Software schreiben, sind Sie praktisch gezwungen, die Anwendung in derselben Sprache wie das zugrunde liegende Betriebssystem zu schreiben – also C und C++. Und so wurden diese Sprachen (insbesondere unter nichttechnischen Leuten wie Managern und VCs) als Sprachen für „seriöse“ Softwareentwicklung betrachtet. Aber das war nur ein Artefakt der Art und Weise, wie Desktop-Software bereitgestellt werden musste. Für serverbasierte Software können Sie jede beliebige Sprache verwenden. [3] Heute verwenden viele der Top-Hacker Sprachen, die weit von C und C++ entfernt sind: Perl, Python und sogar Lisp.

Bei serverbasierter Software kann Ihnen niemand vorschreiben, welche Sprache Sie verwenden sollen, denn Sie kontrollieren das gesamte System, bis hin zur Hardware. Verschiedene Sprachen eignen sich für unterschiedliche Aufgaben. Sie können die Sprache verwenden, die für jede Aufgabe am besten geeignet ist. Und wenn Sie Konkurrenten haben, bedeutet „Sie können“ „Sie müssen“ (darauf kommen wir später zurück), denn wenn Sie diese Möglichkeit nicht nutzen, werden es Ihre Konkurrenten tun.

Die meisten unserer Konkurrenten verwendeten C und C++, was ihre Software sichtlich unterlegen machte, weil sie (unter anderem) die Zustandslosigkeit von CGI-Skripten nicht umgehen konnten. Wenn Sie etwas ändern wollten, mussten alle Änderungen auf einer Seite erfolgen, mit einer Schaltfläche „Aktualisieren“ am unteren Rand. Wie ich an anderer Stelle geschrieben habe, konnten wir durch die Verwendung von Lisp , das viele Leute immer noch als Forschungssprache betrachten, dafür sorgen, dass sich der Viaweb-Editor mehr wie eine Desktop-Software verhält.

Veröffentlichungen

Eine der wichtigsten Änderungen in dieser neuen Welt ist die Art und Weise, wie Releases durchgeführt werden. Im Desktop-Software-Geschäft ist das Erstellen eines Releases ein riesiges Trauma, bei dem das ganze Unternehmen schwitzt und sich anstrengt, um ein einziges, riesiges Stück Code herauszubringen. Vergleiche sowohl zum Prozess als auch zum resultierenden Produkt liegen auf der Hand.

Bei serverbasierter Software können Sie Änderungen fast so vornehmen, als ob Sie ein Programm für sich selbst schreiben würden. Sie veröffentlichen Software in einer Reihe von inkrementellen Änderungen, statt gelegentlich in einer großen Explosion. Ein typisches Desktop-Softwareunternehmen veröffentlicht vielleicht ein oder zwei Versionen pro Jahr. Bei Viaweb veröffentlichten wir oft drei bis fünf Versionen pro Tag.

Wenn Sie auf dieses neue Modell umsteigen, erkennen Sie, wie stark die Softwareentwicklung von der Art und Weise der Veröffentlichung beeinflusst wird. Viele der schlimmsten Probleme im Desktop-Softwaregeschäft sind auf die katastrophale Natur der Veröffentlichungen zurückzuführen.

Wenn Sie nur eine neue Version pro Jahr herausbringen, neigen Sie dazu, Fehler pauschal zu beheben. Einige Zeit vor dem Veröffentlichungstermin stellen Sie eine neue Version zusammen, in der die Hälfte des Codes entfernt und ersetzt wurde, was zahllose Fehler mit sich bringt. Dann kommt eine Gruppe von Qualitätssicherungsleuten und beginnt, die Fehler zu zählen, und die Programmierer arbeiten die Liste ab und beheben sie. Sie kommen im Allgemeinen nicht bis zum Ende der Liste, und tatsächlich ist sich niemand sicher, wo das Ende ist. Es ist, als würde man Trümmer aus einem Teich fischen. Sie wissen nie wirklich, was in der Software vor sich geht. Bestenfalls erhalten Sie eine statistische Art von Korrektheit.

Bei serverbasierter Software sind die meisten Änderungen klein und inkrementell. Das allein führt weniger wahrscheinlich zu Fehlern. Es bedeutet auch, dass Sie wissen, was Sie am sorgfältigsten testen müssen, wenn Sie Software veröffentlichen: das, was Sie zuletzt geändert haben. Sie haben den Code dann viel besser im Griff. In der Regel wissen Sie, was darin passiert. Natürlich kennen Sie den Quellcode nicht auswendig, aber wenn Sie den Quellcode lesen, tun Sie das wie ein Pilot, der das Instrumentenbrett absucht, und nicht wie ein Detektiv, der versucht, ein Geheimnis zu lüften.

Desktop-Software weckt einen gewissen Fatalismus in Bezug auf Fehler. Sie wissen, dass Sie etwas mit vielen Fehlern ausliefern, und Sie haben sogar Mechanismen eingerichtet, um dies zu kompensieren (z. B. Patch-Releases). Warum sich also über ein paar weitere Sorgen machen? Bald veröffentlichen Sie ganze Funktionen, von denen Sie wissen, dass sie nicht funktionieren. Apple hat dies Anfang des Jahres getan. Sie fühlten sich unter Druck, ihr neues Betriebssystem zu veröffentlichen, dessen Veröffentlichungstermin bereits viermal verschoben worden war, aber einige der Software (Unterstützung für CDs und DVDs) waren noch nicht fertig. Die Lösung? Sie veröffentlichten das Betriebssystem ohne die unfertigen Teile, und die Benutzer müssen sie später installieren.

Bei webbasierter Software müssen Sie eine Software nie veröffentlichen, bevor sie funktioniert, sondern können sie veröffentlichen, sobald sie funktioniert.

Der Branchenveteran denkt vielleicht, dass es eine gut klingende Idee ist, Software nie veröffentlichen zu müssen, bevor sie funktioniert. Aber was passiert, wenn man versprochen hat, bis zu einem bestimmten Datum eine neue Version der Software auszuliefern? Bei webbasierter Software würde man ein solches Versprechen nicht geben, weil es keine Versionen gibt. Ihre Software ändert sich schrittweise und kontinuierlich. Einige Änderungen sind vielleicht größer als andere, aber das Konzept von Versionen passt einfach nicht von Natur aus zu webbasierter Software.

Wenn sich jemand an Viaweb erinnert, mag das seltsam klingen, denn wir haben ständig neue Versionen angekündigt. Das geschah ausschließlich aus PR-Gründen. Die Fachpresse, so erfuhren wir, denkt in Versionsnummern. Sie berichten ausführlich über eine Hauptversion, was eine neue erste Ziffer der Versionsnummer bedeutet, und in der Regel höchstens einen Absatz über eine Zwischenversion, was eine neue Ziffer nach dem Komma bedeutet.

Einige unserer Konkurrenten boten Desktop-Software an und hatten tatsächlich Versionsnummern. Und für diese Veröffentlichungen, deren bloße Tatsache uns als Beweis ihrer Rückständigkeit erschien, bekamen sie jede Menge Werbung. Wir wollten nichts verpassen und begannen daher, auch unserer Software Versionsnummern zu geben. Wenn wir Werbung machen wollten, erstellten wir eine Liste aller Funktionen, die wir seit der letzten „Veröffentlichung“ hinzugefügt hatten, klebten eine neue Versionsnummer auf die Software und gaben eine Pressemitteilung heraus, in der wir erklärten, dass die neue Version ab sofort verfügbar sei. Erstaunlicherweise hat uns nie jemand darauf angesprochen.

Als wir aufgekauft wurden, hatten wir das bereits dreimal gemacht, also waren wir bei Version 4. Version 4.1, wenn ich mich recht erinnere. Nachdem Viaweb zu Yahoo Store wurde, war Werbung nicht mehr so dringend nötig, und obwohl die Software sich weiterentwickelte, wurde die ganze Idee mit den Versionsnummern stillschweigend fallengelassen.

Insekten

Der andere große technische Vorteil webbasierter Software ist, dass Sie die meisten Fehler reproduzieren können. Sie haben die Benutzerdaten direkt auf Ihrer Festplatte. Wenn jemand Ihre Software kaputt macht, müssen Sie nicht wie bei Desktop-Software raten, was los ist: Sie sollten den Fehler reproduzieren können, während der Benutzer mit Ihnen telefoniert. Vielleicht wissen Sie sogar schon davon, wenn Sie in Ihrer Anwendung Code zur Fehlererkennung eingebaut haben.

Webbasierte Software wird rund um die Uhr genutzt, sodass alles, was Sie tun, sofort auf die Probe gestellt wird. Fehler treten schnell auf.

Softwareunternehmen wird manchmal vorgeworfen, dass sie die Benutzer ihre Software debuggen lassen. Und genau das befürworte ich. Für webbasierte Software ist das eigentlich ein guter Plan, weil es weniger und nur vorübergehende Fehler gibt. Wenn Sie Software schrittweise veröffentlichen, gibt es von Anfang an viel weniger Fehler. Und wenn Sie Fehler reproduzieren und Änderungen sofort veröffentlichen können, können Sie die meisten Fehler finden und beheben, sobald sie auftreten. Wir hatten nie genug Fehler auf einmal, um uns mit einem formellen Fehlerverfolgungssystem zu beschäftigen.

Sie sollten Änderungen natürlich testen, bevor Sie sie veröffentlichen, damit keine größeren Fehler auftreten. Die wenigen, die unweigerlich durchrutschen, sind Grenzfälle und betreffen nur die wenigen Benutzer, die sie bemerken, bevor sich jemand beschwert. Solange Sie Fehler sofort beheben, ist der Nettoeffekt für den durchschnittlichen Benutzer viel geringer. Ich bezweifle, dass der durchschnittliche Viaweb-Benutzer jemals einen Fehler gesehen hat.

Das Beheben neuer Fehler ist einfacher als das Beheben alter. Normalerweise findet man einen Fehler in Code, den man gerade geschrieben hat, ziemlich schnell. Wenn er auftaucht, weiß man oft, was falsch ist, bevor man sich überhaupt den Quellcode ansieht, weil man sich bereits unbewusst darüber Gedanken gemacht hat. Das Beheben eines Fehlers in etwas, das man vor sechs Monaten geschrieben hat (der durchschnittliche Fall, wenn man einmal im Jahr etwas veröffentlicht), ist viel mehr Arbeit. Und da man den Code nicht so gut versteht, ist es wahrscheinlicher, dass man ihn auf eine hässliche Art behebt oder sogar noch mehr Fehler einführt. [4]

Wenn Sie Fehler frühzeitig erkennen, treten auch weniger zusammengesetzte Fehler auf. Zusammengesetzte Fehler sind zwei separate Fehler, die interagieren: Sie stolpern beim Treppenabstieg und wenn Sie nach dem Handlauf greifen, bleibt dieser in Ihrer Hand hängen. In der Software ist diese Art von Fehler am schwierigsten zu finden und hat auch die schlimmsten Folgen. [5] Der traditionelle Ansatz „alles kaputt machen und dann die Fehler herausfiltern“ führt zwangsläufig zu vielen zusammengesetzten Fehlern. Und bei Software, die in einer Reihe kleiner Änderungen veröffentlicht wird, ist dies zwangsläufig nicht der Fall. Die Böden werden ständig von losen Gegenständen befreit, die später irgendwo hängen bleiben könnten.

Es ist hilfreich, wenn Sie eine Technik namens funktionale Programmierung verwenden. Funktionale Programmierung bedeutet, Nebenwirkungen zu vermeiden. Sie wird eher in Forschungsarbeiten als in kommerzieller Software vorkommen, aber für webbasierte Anwendungen erweist sie sich als wirklich nützlich. Es ist schwierig, ganze Programme als rein funktionalen Code zu schreiben, aber Sie können auf diese Weise große Teile schreiben. Diese Teile Ihrer Software lassen sich leichter testen, weil sie keinen Status haben, und das ist sehr praktisch in einer Situation, in der Sie ständig kleine Änderungen vornehmen und testen. Ich habe einen Großteil des Viaweb-Editors in diesem Stil geschrieben, und wir haben unsere Skriptsprache RTML zu einer rein funktionalen Sprache gemacht.

Leute aus der Desktop-Softwarebranche werden das kaum glauben können, aber bei Viaweb wurden Bugs fast zu einem Spiel. Da es sich bei den meisten veröffentlichten Bugs um Grenzfälle handelte, waren die Benutzer, die sie entdeckten, wahrscheinlich fortgeschrittene Benutzer, die bis an die Grenzen gingen. Fortgeschrittene Benutzer verzeihen Bugs eher, insbesondere, da Sie diese wahrscheinlich im Zuge der Hinzufügung einer von ihnen gewünschten Funktion eingeführt haben. Da Bugs selten waren und man anspruchsvolle Dinge tun musste, um sie zu entdecken, waren fortgeschrittene Benutzer oft sogar stolz, einen zu entdecken. Sie riefen den Support eher triumphierend als wütend an, als hätten sie bei uns Punkte gesammelt.

Unterstützung

Wenn Sie Fehler reproduzieren können, ändert das Ihren Ansatz im Kundensupport. Bei den meisten Softwareunternehmen wird Support angeboten, um den Kunden ein besseres Gefühl zu geben. Entweder rufen sie Sie wegen eines bekannten Fehlers an, oder sie machen einfach etwas falsch und Sie müssen herausfinden, was. In beiden Fällen können Sie nicht viel von ihnen lernen. Und so neigen Sie dazu, Supportanrufe als lästige Angelegenheit zu betrachten, die Sie so weit wie möglich von Ihren Entwicklern isolieren möchten.

So lief es bei Viaweb nicht. Bei Viaweb war der Support kostenlos, weil wir von den Kunden hören wollten. Wenn jemand ein Problem hatte, wollten wir sofort davon erfahren, damit wir den Fehler reproduzieren und eine Lösung veröffentlichen konnten.

Bei Viaweb standen die Entwickler also immer in engem Kontakt mit dem Support. Die Mitarbeiter des Kundensupports waren etwa zehn Meter von den Programmierern entfernt und wussten, dass sie jederzeit mit einem Bericht über einen echten Fehler unterbrechen konnten. Wir verließen sogar eine Vorstandssitzung, um einen schwerwiegenden Fehler zu beheben.

Unser Supportansatz hat alle glücklicher gemacht. Die Kunden waren begeistert. Stellen Sie sich nur vor, wie es sich anfühlen würde, eine Support-Hotline anzurufen und als jemand behandelt zu werden, der wichtige Neuigkeiten mitbringt. Den Mitarbeitern des Kundensupports gefiel es, weil sie den Benutzern so helfen konnten, anstatt ihnen Skripte vorzulesen. Und den Programmierern gefiel es, weil sie Fehler reproduzieren konnten, anstatt nur vage Berichte aus zweiter Hand darüber zu hören.

Unsere Vorgehensweise, Fehler sofort zu beheben, hat die Beziehung zwischen den Mitarbeitern im Kundendienst und den Hackern verändert. Bei den meisten Softwareunternehmen sind die Mitarbeiter im Kundendienst unterbezahlte menschliche Schutzschilde und die Hacker kleine Kopien von Gottvater, den Schöpfern der Welt. Wie auch immer das Verfahren zur Meldung von Fehlern aussieht, es ist wahrscheinlich einseitig: Die Mitarbeiter im Kundendienst, die von Fehlern erfahren, füllen ein Formular aus, das schließlich (möglicherweise über die Qualitätssicherung) an die Programmierer weitergeleitet wird, die es auf ihre To-do-Liste setzen. Bei Viaweb war das ganz anders. Innerhalb einer Minute, nachdem ein Kunde von einem Fehler erfahren hatte, standen die Mitarbeiter im Kundendienst möglicherweise neben einem Programmierer und hörten ihn sagen: „Scheiße, Sie haben Recht, es ist ein Fehler.“ Die Mitarbeiter im Kundendienst freuten sich, dieses „Sie haben Recht“ von den Hackern zu hören. Früher brachten sie uns Fehler mit der gleichen erwartungsvollen Miene, wie eine Katze einem eine Maus bringt, die sie gerade getötet hat. Es machte sie auch vorsichtiger bei der Beurteilung der Schwere eines Fehlers, denn jetzt stand ihre Ehre auf dem Spiel.

Nachdem wir von Yahoo aufgekauft wurden, wurden die Mitarbeiter des Kundensupports weit weg von den Programmierern versetzt. Erst dann wurde uns klar, dass sie tatsächlich für die Qualitätssicherung und in gewissem Maße auch für das Marketing zuständig waren. Sie waren nicht nur für die Fehlersuche zuständig, sondern auch für die Bewahrer des Wissens über vage, fehlerähnliche Dinge, wie Funktionen, die die Benutzer verwirrten. [6] Sie waren auch eine Art stellvertretende Fokusgruppe; wir konnten sie fragen, welche von zwei neuen Funktionen die Benutzer lieber haben wollten, und sie hatten immer recht.

Moral

Software sofort veröffentlichen zu können, ist ein großer Ansporn. Oft fiel mir auf dem Weg zur Arbeit eine Änderung ein, die ich an der Software vornehmen wollte, und ich setzte sie noch am selben Tag um. Das funktionierte auch bei größeren Features. Selbst wenn das Schreiben von etwas zwei Wochen dauern würde (bei einigen Projekten dauerte es länger), wusste ich, dass ich die Auswirkungen in der Software sehen konnte, sobald es fertig war.

Wenn ich ein Jahr auf die nächste Version hätte warten müssen, hätte ich die meisten dieser Ideen zumindest für eine Weile auf Eis gelegt. Das Besondere an Ideen ist jedoch, dass sie zu weiteren Ideen führen. Ist Ihnen schon einmal aufgefallen, dass die Hälfte der Ideen, die Sie beim Schreiben eines Artikels erhalten, die sind, die Ihnen beim Schreiben eingefallen sind? Dasselbe passiert mit Software. Wenn Sie an der Umsetzung einer Idee arbeiten, bekommen Sie weitere Ideen. Wenn Sie also eine Idee auf Eis legen, kostet Sie das nicht nur die Verzögerung bei der Umsetzung, sondern auch alle Ideen, die durch die Umsetzung entstanden wären. Tatsächlich verhindert das Auf Eis legen einer Idee wahrscheinlich sogar neue Ideen: Wenn Sie anfangen, über eine neue Funktion nachzudenken, fällt Ihr Blick auf das Regal und Sie denken: „Aber ich habe schon eine Menge neuer Dinge, die ich für die nächste Version tun möchte.“

Große Unternehmen planen Funktionen, anstatt sie zu implementieren. Bei Viaweb hatten wir deswegen manchmal Probleme. Investoren und Analysten fragten uns, was wir für die Zukunft geplant hätten. Die ehrliche Antwort wäre gewesen, dass wir keine Pläne hätten. Wir hatten allgemeine Vorstellungen von Dingen, die wir verbessern wollten, aber wenn wir gewusst hätten, wie, hätten wir es bereits getan. Was würden wir in den nächsten sechs Monaten tun? Was auch immer der größte Erfolg zu sein schien. Ich weiß nicht, ob ich es jemals gewagt habe, diese Antwort zu geben, aber es war die Wahrheit. Pläne sind nur ein anderes Wort für Ideen im Regal. Wenn uns gute Ideen einfielen, haben wir sie umgesetzt.

Bei Viaweb hatte der meiste Code, wie bei vielen Softwareunternehmen, einen eindeutigen Eigentümer. Aber wenn man etwas besaß, gehörte es einem wirklich: niemand außer dem Eigentümer einer Software musste eine Freigabe genehmigen (oder auch nur davon wissen). Es gab keinen Schutz gegen Beschädigungen außer der Angst, vor den Kollegen wie ein Idiot dazustehen, und das war mehr als genug. Ich habe vielleicht den Eindruck erweckt, dass wir einfach unbekümmert mit dem Schreiben von Code weitergemacht haben. Wir waren zwar schnell, aber wir haben sehr sorgfältig nachgedacht, bevor wir Software auf diese Server freigegeben haben. Und Aufmerksamkeit ist für die Zuverlässigkeit wichtiger als langsames Vorankommen. Weil ein Navy-Pilot genau aufpasst, kann er ein 40.000 Pfund schweres Flugzeug mit 140 Meilen pro Stunde nachts sicherer auf einem schwankenden Flugzeugträgerdeck landen, als ein durchschnittlicher Teenager einen Bagel schneiden kann.

Diese Art, Software zu schreiben, ist natürlich ein zweischneidiges Schwert. Sie funktioniert für ein kleines Team guter, vertrauenswürdiger Programmierer viel besser als für ein großes Unternehmen mit mittelmäßigen Programmierern, wo schlechte Ideen von Ausschüssen aufgegriffen werden und nicht von den Leuten, die sie hatten.

Brooks im Rückwärtsgang

Glücklicherweise erfordert webbasierte Software weniger Programmierer. Ich habe einmal für ein mittelgroßes Desktop-Softwareunternehmen gearbeitet, bei dem insgesamt über 100 Mitarbeiter in der Entwicklung tätig waren. Nur 13 davon waren in der Produktentwicklung tätig. Alle anderen arbeiteten an Releases, Ports usw. Bei webbasierter Software braucht man (höchstens) nur diese 13 Leute, da es keine Releases, Ports usw. gibt.

Viaweb wurde von nur drei Leuten geschrieben. [7] Ich stand immer unter Druck, mehr Leute einzustellen, weil wir gekauft werden wollten und wir wussten, dass es den Käufern schwerfallen würde, einen hohen Preis für ein Unternehmen mit nur drei Programmierern zu zahlen. (Lösung: Wir stellten mehr Leute ein, erstellten aber neue Projekte für sie.)

Wenn Sie Software mit weniger Programmierern schreiben können, sparen Sie mehr als nur Geld. Wie Fred Brooks in The Mythical Man-Month betonte, verlangsamt das Hinzufügen von Mitarbeitern ein Projekt tendenziell. Die Anzahl möglicher Verbindungen zwischen Entwicklern wächst exponentiell mit der Größe der Gruppe. Je größer die Gruppe, desto mehr Zeit verbringen sie in Besprechungen, um zu verhandeln, wie ihre Software zusammenarbeiten wird, und desto mehr Fehler treten aufgrund unvorhergesehener Interaktionen auf. Glücklicherweise funktioniert dieser Prozess auch umgekehrt: Je kleiner die Gruppen werden, desto effizienter wird die Softwareentwicklung. Ich kann mich nicht erinnern, dass die Programmierer bei Viaweb jemals eine richtige Besprechung hatten. Wir hatten nie mehr auf einmal zu sagen, als wir auf dem Weg zum Mittagessen sagen konnten.

Wenn es hier einen Nachteil gibt, dann ist es der, dass alle Programmierer bis zu einem gewissen Grad auch Systemadministratoren sein müssen. Wenn Sie Software hosten, muss jemand die Server überwachen, und in der Praxis sind die einzigen Leute, die das richtig machen können, diejenigen, die die Software geschrieben haben. Bei Viaweb hatte unser System so viele Komponenten und änderte sich so häufig, dass es keine klare Grenze zwischen Software und Infrastruktur gab. Die willkürliche Festlegung einer solchen Grenze hätte unsere Designentscheidungen eingeschränkt. Und obwohl wir also ständig hofften, dass eines Tages („in ein paar Monaten“) alles stabil genug sein würde, dass wir jemanden einstellen könnten, dessen Aufgabe es wäre, sich nur um die Server zu kümmern, geschah dies nie.

Ich glaube nicht, dass es anders sein kann, solange Sie das Produkt noch aktiv entwickeln. Webbasierte Software wird nie etwas sein, das Sie schreiben, einchecken und dann nach Hause gehen. Es ist ein Live-Ding, das gerade auf Ihren Servern läuft. Ein schwerer Fehler kann nicht nur den Prozess eines Benutzers zum Absturz bringen, sondern alle. Wenn ein Fehler in Ihrem Code Daten auf der Festplatte beschädigt, müssen Sie ihn beheben. Und so weiter. Wir haben festgestellt, dass Sie die Server nicht jede Minute überwachen müssen (nach etwa einem Jahr), aber Sie sollten auf jeden Fall ein Auge auf Dinge haben, die Sie kürzlich geändert haben. Sie veröffentlichen Code nicht spät in der Nacht und gehen dann nach Hause.

Benutzer beobachten

Mit serverbasierter Software haben Sie mehr Kontakt zu Ihrem Code. Und Sie können auch mehr Kontakt zu Ihren Benutzern haben. Intuit ist dafür bekannt, dass sich Kunden in Einzelhandelsgeschäften vorstellen und sie bitten, sie nach Hause zu begleiten. Wenn Sie schon einmal jemanden beim ersten Verwenden Ihrer Software beobachtet haben, wissen Sie, welche Überraschungen auf ihn gewartet haben müssen.

Software sollte das tun, was die Benutzer von ihr erwarten. Aber glauben Sie mir, Sie können nicht wissen, was Benutzer denken, bis Sie sie beobachten. Und serverbasierte Software liefert Ihnen beispiellose Informationen über ihr Verhalten. Sie sind nicht auf kleine, künstliche Fokusgruppen beschränkt. Sie können jeden Klick jedes Benutzers sehen. Sie müssen sorgfältig überlegen, was Sie sich ansehen, denn Sie möchten die Privatsphäre der Benutzer nicht verletzen, aber selbst die allgemeinsten statistischen Stichproben können sehr nützlich sein.

Wenn Sie die Benutzer auf Ihrem Server haben, müssen Sie sich beispielsweise nicht auf Benchmarks verlassen. Benchmarks sind simulierte Benutzer. Mit serverbasierter Software können Sie echte Benutzer beobachten. Um zu entscheiden, was optimiert werden soll, melden Sie sich einfach bei einem Server an und sehen Sie, was die gesamte CPU verbraucht. Und Sie wissen auch, wann Sie mit der Optimierung aufhören müssen: Wir haben den Viaweb-Editor schließlich so weit gebracht, dass er speicher- und nicht CPU-gebunden war, und da wir nichts tun konnten, um die Größe der Benutzerdaten zu verringern (na ja, nichts Einfaches), wussten wir, dass wir hier genauso gut aufhören konnten.

Bei serverbasierter Software ist Effizienz wichtig, denn Sie zahlen für die Hardware. Die Anzahl der Benutzer, die Sie pro Server unterstützen können, ist der Teiler Ihrer Kapitalkosten. Wenn Sie Ihre Software also sehr effizient machen können, können Sie Ihre Konkurrenz unterbieten und trotzdem noch Gewinn machen. Bei Viaweb haben wir die Kapitalkosten pro Benutzer auf etwa 5 US-Dollar gesenkt. Das wäre jetzt weniger, wahrscheinlich weniger als die Kosten für die Zustellung der ersten Monatsrechnung. Hardware ist jetzt kostenlos, wenn Ihre Software einigermaßen effizient ist.

Das Beobachten von Benutzern kann Ihnen sowohl beim Design als auch bei der Optimierung helfen. Viaweb hatte eine Skriptsprache namens RTML, mit der fortgeschrittene Benutzer ihre eigenen Seitenstile definieren konnten. Wir stellten fest, dass RTML zu einer Art Vorschlagskasten wurde, da Benutzer es nur dann verwendeten, wenn die vordefinierten Seitenstile nicht das gewünschte Ergebnis lieferten. Ursprünglich platzierte der Editor beispielsweise Schaltflächenleisten quer über die Seite, aber nachdem einige Benutzer RTML verwendeten, um Schaltflächen auf der linken Seite zu platzieren, machten wir dies zu einer Option (tatsächlich zur Standardeinstellung) in den vordefinierten Seitenstilen.

Und schließlich kann man durch Beobachtung der Benutzer oft erkennen, wann sie in Schwierigkeiten stecken. Und da der Kunde immer Recht hat, ist das ein Zeichen dafür, dass Sie etwas ändern müssen. Bei Viaweb war der Schlüssel zur Gewinnung von Benutzern der Online-Testlauf. Dabei handelte es sich nicht nur um eine Reihe von Folien, die von Marketingleuten erstellt wurden. Bei unserem Testlauf verwendeten die Benutzer die Software tatsächlich. Er dauerte etwa fünf Minuten und am Ende hatten sie einen echten, funktionierenden Shop aufgebaut.

Durch die Testfahrt haben wir fast alle unsere neuen Benutzer gewonnen. Ich denke, das wird bei den meisten webbasierten Anwendungen genauso sein. Wenn Benutzer eine Testfahrt erfolgreich absolvieren, wird ihnen das Produkt gefallen. Wenn sie verwirrt oder gelangweilt sind, wird ihnen das nicht gefallen. Alles, was wir also tun könnten, um mehr Leute durch die Testfahrt zu bringen, würde unsere Wachstumsrate steigern.

Ich habe die Klickpfade der Testpersonen untersucht und festgestellt, dass sie bei einem bestimmten Schritt verwirrt waren und auf die Zurück-Schaltfläche des Browsers klickten. (Wenn Sie versuchen, webbasierte Anwendungen zu schreiben, werden Sie feststellen, dass die Zurück-Schaltfläche zu einem Ihrer interessantesten philosophischen Probleme wird.) Also habe ich an dieser Stelle eine Nachricht hinzugefügt, die den Benutzern mitteilte, dass sie fast fertig waren, und sie daran erinnerte, nicht auf die Zurück-Schaltfläche zu klicken. Ein weiterer Vorteil webbasierter Software besteht darin, dass Sie sofortiges Feedback zu Änderungen erhalten: Die Anzahl der Personen, die die Testpersonen abschlossen, stieg sofort von 60 % auf 90 %. Und da die Anzahl neuer Benutzer eine Funktion der Anzahl abgeschlossener Testpersonen war, stieg unser Umsatzwachstum allein durch diese Änderung um 50 %.

Geld

Anfang der 1990er Jahre las ich einen Artikel, in dem jemand sagte, Software sei ein Abonnementgeschäft. Das schien mir zunächst eine sehr zynische Aussage zu sein. Doch später wurde mir klar, dass sie die Realität widerspiegelt: Softwareentwicklung ist ein fortlaufender Prozess. Ich denke, es ist sauberer, wenn man offen Abonnementgebühren verlangt, anstatt die Leute zu zwingen, immer wieder neue Versionen zu kaufen und zu installieren, damit sie weiter bezahlen. Und glücklicherweise sind Abonnements die natürliche Art, für webbasierte Anwendungen zu bezahlen.

Das Hosten von Anwendungen ist ein Bereich, in dem Unternehmen eine Rolle spielen, die Freeware wahrscheinlich nicht ausfüllen kann. Das Hosten von Anwendungen ist sehr aufwändig und verursacht echte Kosten. Niemand wird es kostenlos machen wollen.

Für Unternehmen sind webbasierte Anwendungen eine ideale Einnahmequelle. Anstatt jedes Quartal mit einem leeren Blatt zu beginnen, haben Sie einen wiederkehrenden Einnahmestrom. Da sich Ihre Software schrittweise weiterentwickelt, müssen Sie sich keine Sorgen machen, dass ein neues Modell ein Flop wird; es muss nie per se ein neues Modell geben, und wenn Sie etwas an der Software ändern, was die Benutzer hassen, werden Sie es sofort wissen. Sie haben keine Probleme mit uneinbringlichen Rechnungen; wenn jemand nicht zahlt, können Sie den Dienst einfach abschalten. Und es besteht keine Möglichkeit der Piraterie.

Dieser letzte „Vorteil“ könnte sich als Problem herausstellen. Ein gewisses Maß an Piraterie ist zum Vorteil der Softwareunternehmen. Wenn ein Benutzer Ihre Software wirklich um keinen Preis gekauft hätte, haben Sie nichts verloren, wenn er eine Raubkopie verwendet. Im Gegenteil, Sie gewinnen, denn er ist ein weiterer Benutzer, der dazu beiträgt, Ihre Software zum Standard zu machen – oder der sich später, wenn er die High School abschließt, eine Kopie kauft.

Wenn sie können, praktizieren Unternehmen gerne etwas, das man Preisdiskriminierung nennt, das heißt, sie berechnen jedem Kunden so viel, wie er sich leisten kann. [8] Software eignet sich besonders gut für Preisdiskriminierung, da die Grenzkosten nahe Null liegen. Deshalb kostet es mehr, wenn man manche Software auf Suns-Rechnern laufen lässt, als auf Intel-Rechnern: Ein Unternehmen, das Suns verwendet, ist nicht daran interessiert, Geld zu sparen, und kann getrost mehr verlangen. Piraterie ist praktisch die niedrigste Stufe der Preisdiskriminierung. Ich denke, dass Softwareunternehmen dies verstehen und bei manchen Arten von Piraterie bewusst ein Auge zudrücken. [9] Bei serverbasierter Software werden sie sich eine andere Lösung einfallen lassen müssen.

Webbasierte Software verkauft sich gut, insbesondere im Vergleich zu Desktop-Software, weil sie einfach zu kaufen ist. Man könnte meinen, dass die Entscheidung, etwas zu kaufen, und der anschließende Kauf zwei getrennte Schritte sind. Das dachte ich auch vor Viaweb, sofern ich überhaupt über diese Frage nachgedacht habe. Tatsächlich kann der zweite Schritt auf den ersten zurückwirken: Wenn etwas schwer zu kaufen ist, werden die Leute ihre Meinung darüber ändern, ob sie es wollen. Und umgekehrt: Sie werden mehr von etwas verkaufen, wenn es einfach zu kaufen ist. Ich kaufe mehr Bücher, weil es Amazon gibt. Webbasierte Software ist so ziemlich das Einfachste, was man auf der Welt kaufen kann, insbesondere wenn man gerade eine Online-Demo gemacht hat. Die Benutzer sollten nicht viel mehr tun müssen, als eine Kreditkartennummer einzugeben. (Wenn Sie sie dazu bringen, mehr zu tun, tun Sie dies auf eigene Gefahr.)

Manchmal wird webbasierte Software über ISPs angeboten, die als Wiederverkäufer auftreten. Das ist keine gute Idee. Sie müssen die Server verwalten, da Sie sowohl Hardware als auch Software ständig verbessern müssen. Wenn Sie die direkte Kontrolle über die Server aufgeben, verzichten Sie auf die meisten Vorteile der Entwicklung webbasierter Anwendungen.

Einige unserer Konkurrenten haben sich auf diese Weise selbst ins Bein geschossen - normalerweise, denke ich, weil sie von Anzugträgern überrannt wurden, die von diesem riesigen potenziellen Vertriebskanal begeistert waren und nicht erkannten, dass sie damit das Produkt ruinieren würden, das sie über diesen Kanal verkaufen wollten. Webbasierte Software über ISPs zu verkaufen ist wie Sushi über Automaten zu verkaufen.

Kunden

Wer werden die Kunden sein? Bei Viaweb waren es zunächst Privatpersonen und kleinere Unternehmen, und ich denke, das wird auch bei webbasierten Anwendungen die Regel sein. Das sind die Benutzer, die bereit sind, Neues auszuprobieren, teils weil sie flexibler sind, teils weil sie die niedrigeren Kosten neuer Technologien nutzen wollen.

Auch für große Unternehmen sind webbasierte Anwendungen oft die beste Lösung (auch wenn sie das nur langsam realisieren). Das beste Intranet ist das Internet. Wenn ein Unternehmen wirklich webbasierte Anwendungen verwendet, funktioniert die Software besser, die Server lassen sich besser verwalten und die Mitarbeiter haben von überall aus Zugriff auf das System.

Das Argument gegen diesen Ansatz dreht sich normalerweise um die Sicherheit: Wenn der Zugriff für Mitarbeiter einfacher ist, gilt dies auch für Bösewichte. Einige größere Einzelhändler zögerten, Viaweb zu verwenden, weil sie dachten, die Kreditkarteninformationen der Kunden seien auf ihren eigenen Servern sicherer. Es war nicht leicht, diesen Punkt diplomatisch zu vermitteln, aber tatsächlich waren die Daten in unseren Händen mit ziemlicher Sicherheit sicherer als in ihren. Wer kann bessere Leute für die Verwaltung der Sicherheit einstellen, ein Technologie-Startup, dessen gesamtes Geschäft darin besteht, Server zu betreiben, oder ein Bekleidungshändler? Wir hatten nicht nur bessere Leute, die sich um die Sicherheit kümmerten, wir machten uns sogar mehr Sorgen darüber. Wenn jemand in die Server des Bekleidungshändlers eindrang, würde dies höchstens einen Händler betreffen, könnte wahrscheinlich vertuscht werden und im schlimmsten Fall könnte eine Person gefeuert werden. Wenn jemand in unsere Server eindrang, könnte dies Tausende von Händlern betreffen, würde wahrscheinlich als Nachricht auf CNet enden und könnte uns aus dem Geschäft drängen.

Wenn Sie Ihr Geld sicher aufbewahren möchten, bewahren Sie es zu Hause unter Ihrer Matratze auf oder legen Sie es auf einer Bank an? Dieses Argument gilt für jeden Aspekt der Serververwaltung: nicht nur für die Sicherheit, sondern auch für Betriebszeit, Bandbreite, Lastmanagement, Backups usw. Unsere Existenz hing davon ab, diese Dinge richtig zu machen. Serverprobleme waren für uns ein absolutes No-Go, so wie ein gefährliches Spielzeug für einen Spielzeughersteller oder ein Salmonellenausbruch für einen Küchenmaschinenhersteller.

Ein großes Unternehmen, das webbasierte Anwendungen verwendet, lagert seine IT in diesem Ausmaß aus. So drastisch das klingt, ich halte das im Allgemeinen für eine gute Idee. Die Unternehmen erhalten auf diese Weise wahrscheinlich einen besseren Service als von internen Systemadministratoren. Systemadministratoren können launisch und unempfänglich werden, weil sie nicht direkt dem Wettbewerbsdruck ausgesetzt sind: Ein Verkäufer muss sich mit Kunden auseinandersetzen und ein Entwickler mit der Software der Konkurrenz, aber ein Systemadministrator hat wie ein alter Junggeselle nur wenige externe Kräfte, die ihn bei der Stange halten. [10] Bei Viaweb hatten wir jede Menge externe Kräfte, die uns bei der Stange hielten. Die Leute, die uns anriefen, waren Kunden, nicht nur Mitarbeiter. Wenn ein Server stecken blieb, sprangen wir ein; allein der Gedanke daran löst bei mir Jahre später einen Adrenalinstoß aus.

Daher sind webbasierte Anwendungen normalerweise auch für große Unternehmen die richtige Lösung. Sie werden dies jedoch als letzte erkennen, genau wie bei Desktop-Computern. Und teilweise aus demselben Grund: Es wird viel Geld wert sein, große Unternehmen davon zu überzeugen, dass sie etwas Teureres benötigen.

Reiche Kunden neigen immer dazu, teure Lösungen zu kaufen, selbst wenn billige Lösungen besser sind, weil die Anbieter teurer Lösungen mehr Geld ausgeben können, um sie zu verkaufen. Bei Viaweb waren wir immer wieder mit diesem Problem konfrontiert. Wir haben mehrere hochkarätige Händler an Web-Beratungsfirmen verloren, die ihnen einredeten, sie seien besser dran, wenn sie eine halbe Million Dollar für einen maßgeschneiderten Online-Shop auf ihrem eigenen Server bezahlten. In der Regel waren sie damit nicht besser dran, wie mehr als einer feststellte, als die Weihnachtseinkaufssaison kam und die Auslastung ihres Servers stieg. Viaweb war viel ausgefeilter als das, was die meisten dieser Händler hatten, aber wir konnten es uns nicht leisten, es ihnen zu sagen. Bei 300 Dollar im Monat konnten wir es uns nicht leisten, ein Team gut gekleideter und autoritär wirkender Leute zu schicken, um Präsentationen bei den Kunden abzuhalten.

Ein großer Teil der Extrakosten, die große Unternehmen aufbringen, sind die Kosten, die ihnen durch den Verkauf teurer Produkte entstehen. (Wenn das Verteidigungsministerium tausend Dollar für Toilettensitze zahlt, liegt das zum Teil daran, dass es sehr teuer ist, Toilettensitze für tausend Dollar zu verkaufen.) Und das ist ein Grund, warum Intranet-Software auch weiterhin Erfolg haben wird, obwohl sie wahrscheinlich keine gute Idee ist. Sie ist einfach teurer. An diesem Dilemma lässt sich nichts ändern, also ist der beste Plan, sich zuerst um die kleineren Kunden zu kümmern. Der Rest wird mit der Zeit kommen.

Sohn des Servers

Software auf dem Server laufen zu lassen ist nichts Neues. Tatsächlich ist es das alte Modell: Mainframe-Anwendungen sind alle serverbasiert. Wenn serverbasierte Software eine so gute Idee ist, warum hat sie dann beim letzten Mal verloren? Warum haben Desktop-Computer Mainframes in den Schatten gestellt?

Anfangs schienen Desktop-Computer keine große Bedrohung darzustellen. Die ersten Benutzer waren allesamt Hacker – oder Bastler, wie man sie damals nannte. Sie mochten Mikrocomputer, weil sie billig waren. Zum ersten Mal konnte man einen eigenen Computer haben. Der Ausdruck „Personal Computer“ ist heute Teil der Sprache, aber als er zum ersten Mal verwendet wurde, klang er bewusst gewagt, so wie der Ausdruck „Personal Satellite“ heute.

Warum haben sich Desktop-Computer durchgesetzt? Ich glaube, es lag daran, dass sie bessere Software hatten. Und ich glaube, der Grund, warum Mikrocomputer-Software besser war, lag darin, dass sie von kleinen Unternehmen geschrieben werden konnte.

Ich glaube, viele Leute wissen nicht, wie fragil und unsicher Startups in ihrer Anfangsphase sind. Viele Startups entstehen fast zufällig – als ein paar Jungs, entweder mit Tagesjobs oder in der Schule, die einen Prototyp von etwas schreiben, aus dem sich, wenn es vielversprechend aussieht, ein Unternehmen entwickeln könnte. In diesem Larvenstadium wird das Startup durch jedes größere Hindernis aufgehalten. Das Schreiben von Mainframe-Software erforderte von Anfang an zu viel Engagement. Entwicklungsmaschinen waren teuer, und da die Kunden große Unternehmen waren, brauchte man eine beeindruckende Vertriebsmannschaft, um ihnen die Software zu verkaufen. Ein Startup zu gründen, um Mainframe-Software zu schreiben, wäre ein viel ernsthafteres Unterfangen, als abends einfach etwas auf dem Apple II zusammenzubasteln. Und so gab es nicht viele Startups, die Mainframe-Anwendungen schrieben.

Das Aufkommen von Desktop-Computern inspirierte eine Menge neuer Software, da das Schreiben von Anwendungen für diese Computer für kleine Startups ein erreichbares Ziel zu sein schien. Die Entwicklung war billig und die Kunden waren Einzelpersonen, die man über Computerläden oder sogar per Versandhandel erreichen konnte.

Die Anwendung, die Desktop-Computern den Durchbruch in der breiten Masse verschaffte, war VisiCalc , die erste Tabellenkalkulation. Sie wurde von zwei Typen geschrieben, die auf einem Dachboden arbeiteten, und konnte dennoch Dinge, die keine Mainframe-Software konnte. [11] VisiCalc war zu seiner Zeit ein solcher Fortschritt, dass die Leute Apple IIs kauften, nur um es auszuführen. Und das war der Beginn eines Trends: Desktop-Computer gewannen, weil Startups Software für sie schrieben.

Es sieht so aus, als ob serverbasierte Software dieses Mal gut ankommen wird, weil sie von Startups geschrieben wird. Computer sind heute so billig, dass man, wie wir, mit einem Desktop-Computer als Server anfangen kann. Preiswerte Prozessoren haben den Workstation-Markt aufgefressen (heute hört man das Wort kaum noch) und sind auf dem Server-Markt fast durch. Yahoos Server, die mit so hohen Lasten wie alle anderen im Internet zurechtkommen, haben alle die gleichen preiswerten Intel-Prozessoren wie Sie in Ihrem Desktop-Rechner haben. Und wenn Sie die Software erst einmal geschrieben haben, brauchen Sie nur noch eine Website, um sie zu verkaufen. Fast alle unsere Benutzer kamen direkt durch Mundpropaganda und Erwähnungen in der Presse auf unsere Site. [12]

Viaweb war ein typisches Start-up-Unternehmen. Wir hatten furchtbare Angst davor, ein Unternehmen zu gründen, und trösteten uns in den ersten Monaten damit, dass wir das Ganze als Experiment betrachteten, das wir jederzeit abbrechen könnten. Glücklicherweise gab es außer technischen kaum Hindernisse. Während wir die Software schrieben, war unser Webserver derselbe Desktop-Rechner, den wir für die Entwicklung verwendeten, und über eine DFÜ-Leitung mit der Außenwelt verbunden. Unsere einzigen Ausgaben in dieser Phase waren Lebensmittel und Miete.

Für Startups gibt es heute umso mehr Gründe, webbasierte Software zu schreiben, da das Schreiben von Desktop-Software viel weniger Spaß macht. Wer heute Desktop-Software schreiben will, tut dies zu Microsofts Bedingungen, ruft deren APIs auf und arbeitet um deren fehlerhaftes Betriebssystem herum. Und wenn es einem gelingt, etwas zu schreiben, das durchstartet, stellt man möglicherweise fest, dass man lediglich Marktforschung für Microsoft betrieben hat.

Wenn ein Unternehmen eine Plattform entwickeln will, auf der Startups aufbauen können, muss es sie so gestalten, dass Hacker sie selbst nutzen wollen. Das heißt, sie muss preiswert und gut gestaltet sein. Der Mac war bei Hackern beliebt, als er herauskam, und viele von ihnen schrieben Software dafür. [13] Bei Windows sieht man das weniger, weil Hacker es nicht verwenden. Die Leute, die gut darin sind, Software zu schreiben, verwenden heute eher Linux oder FreeBSD.

Ich glaube nicht, dass wir ein Startup gegründet hätten, um Desktop-Software zu schreiben, denn Desktop-Software muss unter Windows laufen und bevor wir Software für Windows schreiben könnten, müssten wir es verwenden. Das Web ermöglicht es uns, Windows zu umgehen und Software, die unter Unix läuft, direkt über den Browser an die Benutzer zu liefern. Das ist eine befreiende Aussicht, ganz ähnlich wie die Einführung von PCs vor 25 Jahren.

Microsoft

Damals, als Desktop-Computer auf den Markt kamen, war IBM der Riese, vor dem alle Angst hatten. Heute kann man sich das kaum vorstellen, aber ich erinnere mich noch sehr gut an dieses Gefühl. Heute ist Microsoft der furchteinflößende Riese, und ich glaube nicht, dass Microsoft der Bedrohung gegenüber so blind ist wie IBM. Schließlich hat Microsoft sein Geschäft bewusst im blinden Fleck von IBM aufgebaut.

Ich habe bereits erwähnt, dass meine Mutter eigentlich keinen Desktop-Computer braucht. Die meisten Benutzer brauchen das wahrscheinlich auch nicht. Das ist ein Problem für Microsoft, und das Unternehmen weiß es. Wenn Anwendungen auf Remote-Servern laufen, braucht niemand Windows. Was wird Microsoft tun? Wird es in der Lage sein, seine Kontrolle über den Desktop zu nutzen, um diese neue Software-Generation zu verhindern oder einzuschränken?

Ich vermute, dass Microsoft eine Art Server/Desktop-Hybrid entwickeln wird, bei dem das Betriebssystem mit den von Microsoft kontrollierten Servern zusammenarbeitet. Zumindest werden Dateien für Benutzer, die dies wünschen, zentral verfügbar sein. Ich erwarte nicht, dass Microsoft, wenn möglich, so weit geht, die Berechnungen auf dem Server durchzuführen und nur einen Browser für den Client bereitzustellen. Wenn Sie nur einen Browser für einen Client benötigen, brauchen Sie Microsoft nicht auf dem Client, und wenn Microsoft den Client nicht kontrolliert, kann das Unternehmen die Benutzer nicht zu seinen serverbasierten Anwendungen drängen.

Ich glaube, Microsoft wird es schwer haben, den Geist in der Flasche zu halten. Es wird zu viele verschiedene Arten von Clients geben, als dass sie sie alle kontrollieren könnten. Und wenn Microsofts Anwendungen nur mit einigen Clients funktionieren, werden die Konkurrenten ihnen den Rang ablaufen können, indem sie Anwendungen anbieten, die mit jedem Client funktionieren. [14]

In einer Welt webbasierter Anwendungen gibt es für Microsoft keinen automatischen Platz. Es kann sein, dass es ihnen gelingt, sich einen Platz zu erobern, aber ich glaube nicht, dass sie diese neue Welt so dominieren werden wie die Welt der Desktop-Anwendungen.

Es ist nicht so sehr so, dass ein Konkurrent sie zu Fall bringen wird, sondern dass sie über sich selbst stolpern werden. Mit dem Aufkommen webbasierter Software werden sie nicht nur mit technischen Problemen konfrontiert, sondern auch mit ihrem eigenen Wunschdenken. Sie müssen ihr bestehendes Geschäft kannibalisieren, und ich kann mir nicht vorstellen, dass sie das tun. Dieselbe Zielstrebigkeit, die sie so weit gebracht hat, wird jetzt gegen sie arbeiten. IBM war in genau derselben Situation und konnte sie nicht meistern. IBM ist spät und halbherzig in das Mikrocomputergeschäft eingestiegen, weil sie ambivalent waren, was die Bedrohung ihrer Cash Cow, des Mainframe-Computing, angeht. Microsoft wird ebenfalls durch den Wunsch, den Desktop zu retten, behindert werden. Eine Cash Cow kann einem eine verdammt schwere Last auf dem Rücken sein.

Ich sage nicht, dass niemand serverbasierte Anwendungen dominieren wird. Irgendjemand wird das wahrscheinlich irgendwann tun. Aber ich glaube, dass es eine lange, schöne Zeit fröhlichen Chaos geben wird, so wie es sie in den frühen Tagen der Mikrocomputer gab. Das war eine gute Zeit für Startups. Viele kleine Unternehmen florierten, und zwar, indem sie coole Dinge herstellten.

Startups, aber mehr

Das klassische Startup ist schnell und informell, mit wenigen Leuten und wenig Geld. Diese wenigen Leute arbeiten sehr hart und die Technologie verstärkt die Wirkung der Entscheidungen, die sie treffen. Wenn sie gewinnen, gewinnen sie groß.

In einem Startup, das webbasierte Anwendungen entwickelt, wird alles, was man mit Startups verbindet, auf die Spitze getrieben. Man kann ein Produkt mit noch weniger Leuten und noch weniger Geld entwickeln und auf den Markt bringen. Man muss noch schneller sein und kann sich mehr Ungezwungenheit erlauben. Man kann sein Produkt buchstäblich als drei Leute auf den Markt bringen, die im Wohnzimmer einer Wohnung sitzen und einen Server bei einem ISP betreiben. Das haben wir getan.

Im Laufe der Zeit wurden die Teams kleiner, schneller und informeller. 1960 bestand Softwareentwicklung aus einem Raum voller Männer mit Hornbrillen und schmalen schwarzen Krawatten, die fleißig zehn Zeilen Code pro Tag auf IBM-Codierungsformulare schrieben. 1980 war es ein Team von acht bis zehn Leuten, die Jeans im Büro trugen und in VT100s tippten. Heute sind es ein paar Typen, die mit Laptops in einem Wohnzimmer sitzen. (Und Jeans sind nicht gerade das Nonplusultra in Sachen Informalität.)

Startups sind stressig, und das wird leider auch bei webbasierten Anwendungen auf die Spitze getrieben. Viele Softwareunternehmen haben, besonders am Anfang, Phasen, in denen die Entwickler unter ihren Schreibtischen schliefen und so weiter. Das Beunruhigende an webbasierter Software ist, dass nichts dagegen spricht, dass dies zur Normalität wird. Die Geschichten über das Schlafen unter Schreibtischen enden normalerweise damit, dass wir es endlich ausgeliefert haben und alle nach Hause gingen und eine Woche lang schliefen. Webbasierte Software wird nie ausgeliefert. Sie können 16 Stunden am Tag arbeiten, so lange Sie wollen. Und weil Sie es können und Ihre Konkurrenten es können, werden Sie dazu gezwungen. Sie können, also müssen Sie. Es ist Parkinsons Gesetz in umgekehrter Reihenfolge.

Das Schlimmste sind nicht die Arbeitszeiten, sondern die Verantwortung. Programmierer und Systemadministratoren haben traditionell jeweils ihre eigenen Sorgen. Programmierer müssen sich um Fehler kümmern und Systemadministratoren um die Infrastruktur. Programmierer verbringen vielleicht einen langen Tag bis zu den Ellenbogen im Quellcode, aber irgendwann können sie nach Hause gehen und alles vergessen. Systemadministratoren lassen ihren Job nie ganz hinter sich, aber wenn sie um 4:00 Uhr morgens angepiept werden, müssen sie normalerweise nichts sehr Kompliziertes tun. Bei webbasierten Anwendungen werden diese beiden Arten von Stress kombiniert. Die Programmierer werden zu Systemadministratoren, aber ohne die klar definierten Grenzen, die den Job normalerweise erträglich machen.

Bei Viaweb haben wir die ersten sechs Monate damit verbracht, Software zu schreiben. Wir haben die üblichen langen Stunden eines jungen Startups gearbeitet. In einem Desktop-Software-Unternehmen wäre dies der Teil gewesen, in dem wir hart gearbeitet hätten, aber im Vergleich zur nächsten Phase, als wir Benutzer auf unseren Server brachten, fühlte es sich wie Urlaub an. Der zweitgrößte Vorteil des Verkaufs von Viaweb an Yahoo (nach dem Geld) war, dass wir die letztendliche Verantwortung für das Ganze auf die Schultern eines großen Unternehmens abwälzen konnten.

Desktop-Software zwingt Benutzer, Systemadministratoren zu werden. Webbasierte Software zwingt Programmierer dazu. Insgesamt ist der Stress geringer, aber für die Programmierer ist er höher. Das sind nicht unbedingt schlechte Nachrichten. Wenn Sie ein Startup sind, das mit einem großen Unternehmen konkurriert, sind das gute Nachrichten. [15] Webbasierte Anwendungen bieten eine direkte Möglichkeit, Ihre Konkurrenten zu übertreffen. Kein Startup verlangt mehr.

Gerade gut genug

Ein Grund, der Sie möglicherweise davon abhält, webbasierte Anwendungen zu schreiben, ist die Lahmheit von Webseiten als Benutzeroberfläche. Das ist ein Problem, das gebe ich zu. Es gab ein paar Dinge, die wir wirklich gerne zu HTML und HTTP hinzugefügt hätten. Was jedoch zählt, ist, dass Webseiten gerade gut genug sind.

Hier gibt es eine Parallele zu den ersten Mikrocomputern. Die Prozessoren in diesen Maschinen waren eigentlich nicht als CPUs von Computern gedacht. Sie wurden für den Einsatz in Dingen wie Ampeln entwickelt. Aber Leute wie Ed Roberts, der den Altair entwickelte, erkannten, dass sie gerade gut genug waren. Man konnte einen dieser Chips mit etwas Speicher (256 Bytes im ersten Altair) und Schaltern auf der Vorderseite kombinieren, und schon hatte man einen funktionierenden Computer. Einen eigenen Computer zu haben, war so aufregend, dass es viele Leute gab, die einen kaufen wollten, wenn auch nur in begrenztem Umfang.

Webseiten wurden nicht als Benutzeroberfläche für Anwendungen konzipiert, aber sie sind gerade gut genug. Und für eine beträchtliche Anzahl von Benutzern ist Software, die von jedem Browser aus verwendet werden kann, ein Vorteil, der die Unbequemlichkeit der Benutzeroberfläche aufwiegt. Vielleicht können Sie mit HTML nicht die am besten aussehende Tabelle schreiben, aber Sie können eine Tabelle schreiben, die mehrere Personen gleichzeitig von verschiedenen Standorten aus ohne spezielle Client-Software verwenden können, oder die Live-Datenfeeds enthalten kann, oder die Sie bei Auslösen bestimmter Bedingungen per Pager benachrichtigen kann. Und was noch wichtiger ist: Sie können neue Arten von Anwendungen schreiben, die noch nicht einmal Namen haben. VisiCalc war schließlich nicht nur eine Mikrocomputerversion einer Mainframe-Anwendung – es war ein neuer Anwendungstyp.

Natürlich müssen serverbasierte Anwendungen nicht webbasiert sein. Sie könnten auch einen anderen Clienttyp verwenden. Aber ich bin ziemlich sicher, dass das keine gute Idee ist. Es wäre sehr praktisch, wenn Sie davon ausgehen könnten, dass jeder Ihren Client installieren würde – so praktisch, dass Sie sich leicht einreden könnten, dass alle es tun würden – aber wenn das nicht der Fall ist, sind Sie aufgeschmissen. Da webbasierte Software keine Annahmen über den Client macht, funktioniert sie überall, wo das Web funktioniert. Das ist schon jetzt ein großer Vorteil, und der Vorteil wird mit der Verbreitung neuer Web-Geräte noch größer werden. Die Benutzer werden Sie mögen, weil Ihre Software einfach funktioniert, und Ihr Leben wird einfacher, weil Sie sie nicht für jeden neuen Client anpassen müssen. [16]

Ich habe das Gefühl, dass ich die Entwicklung des Webs so genau verfolgt habe wie kein anderer und ich kann nicht vorhersagen, was mit den Clients passieren wird. Konvergenz wird wahrscheinlich kommen, aber wohin? Ich kann keinen Gewinner ausmachen. Eines kann ich jedoch vorhersagen: einen Konflikt zwischen AOL und Microsoft. Was auch immer Microsofts .NET sein wird, es wird wahrscheinlich darum gehen, den Desktop mit Servern zu verbinden. Wenn AOL sich nicht wehrt, werden sie entweder beiseite geschoben oder zu einer Verbindung zwischen Microsoft-Client- und Server-Software gemacht. Wenn Microsoft und AOL in einen Client-Krieg geraten, wird das einzige, was auf beiden sicher funktionieren wird, das Surfen im Internet sein, was bedeutet, dass webbasierte Anwendungen die einzigen sein werden, die überall funktionieren.

Wie sich das Ganze entwickeln wird? Ich weiß es nicht. Und Sie müssen es auch gar nicht wissen, wenn Sie auf webbasierte Anwendungen setzen. Niemand kann das zerstören, ohne das Surfen zu zerstören. Das Web ist vielleicht nicht die einzige Möglichkeit, Software bereitzustellen, aber es ist eine, die jetzt funktioniert und noch lange funktionieren wird. Webbasierte Anwendungen sind billig zu entwickeln und selbst für das kleinste Startup einfach bereitzustellen. Sie machen viel Arbeit und sind besonders stressig, aber das verbessert die Chancen für Startups nur.

Warum nicht?

EB White war amüsiert, als er von einem befreundeten Bauern erfuhr, dass viele elektrische Zäune keinen Strom führen. Die Kühe lernen anscheinend, sich von ihnen fernzuhalten, und danach brauchen sie den Strom nicht mehr. „Steht auf, Kühe!“, schrieb er, „Nehmt euch eure Freiheit, während die Despoten schnarchen!“

Wenn Sie ein Hacker sind, der daran denkt, eines Tages ein Startup zu gründen, gibt es wahrscheinlich zwei Dinge, die Sie davon abhalten. Das eine ist, dass Sie keine Ahnung vom Geschäft haben. Das andere ist, dass Sie Angst vor der Konkurrenz haben. Keiner dieser beiden Punkte ist spannungsgeladen.

Es gibt nur zwei Dinge, die Sie über das Geschäft wissen müssen: etwas bauen, das die Benutzer lieben, und mehr verdienen, als Sie ausgeben. Wenn Sie diese beiden Dinge richtig machen, sind Sie den meisten Startups voraus. Den Rest können Sie im Laufe der Zeit herausfinden.

Vielleicht verdienen Sie am Anfang nicht mehr, als Sie ausgeben, aber solange sich die Lücke schnell genug schließt, ist alles in Ordnung. Wenn Sie mit zu wenig Geld anfangen, wird das zumindest eine Gewohnheit der Genügsamkeit fördern. Je weniger Sie ausgeben, desto einfacher ist es, mehr zu verdienen, als Sie ausgeben. Glücklicherweise kann es sehr billig sein, eine webbasierte Anwendung auf den Markt zu bringen. Wir haben mit weniger als 10.000 Dollar angefangen, und heute wäre es sogar noch billiger. Wir mussten Tausende für einen Server ausgeben und noch mehr Tausende, um SSL zu bekommen. (Das einzige Unternehmen, das damals SSL-Software verkaufte, war Netscape.) Heute können Sie einen viel leistungsfähigeren Server, SSL inbegriffen, für weniger mieten, als wir allein für die Bandbreite bezahlt haben. Sie könnten heute eine webbasierte Anwendung für weniger als den Preis eines schicken Bürostuhls auf den Markt bringen.

Hier sind einige allgemeine Tipps, wie Sie etwas erstellen können, das die Benutzer lieben. Beginnen Sie damit, etwas Sauberes und Einfaches zu erstellen, das Sie selbst gerne verwenden würden. Bringen Sie schnell Version 1.0 heraus und verbessern Sie die Software weiter, wobei Sie den Benutzern genau zuhören. Der Kunde hat immer Recht, aber verschiedene Kunden haben in verschiedenen Dingen Recht. Die am wenigsten versierten Benutzer zeigen Ihnen, was Sie vereinfachen und klarstellen müssen, und die versiertesten sagen Ihnen, welche Funktionen Sie hinzufügen müssen. Das Beste, was Software sein kann, ist einfach, aber der Weg dorthin besteht darin, die Standardeinstellungen richtig zu machen und nicht darin, die Auswahlmöglichkeiten der Benutzer einzuschränken. Geben Sie sich nicht zufrieden, wenn die Software Ihrer Konkurrenten lahm ist. Der Maßstab, mit dem Sie Ihre Software vergleichen, ist das, was sie sein könnte, und nicht das, was Ihre aktuellen Konkurrenten zufällig haben. Verwenden Sie Ihre Software immer selbst. Viaweb sollte ein Online-Shop-Builder sein, aber wir haben es auch verwendet, um unsere eigene Site zu erstellen. Hören Sie nicht auf Marketingleute, Designer oder Produktmanager nur wegen ihrer Berufsbezeichnungen. Wenn sie gute Ideen haben, verwenden Sie sie, aber die Entscheidung liegt bei Ihnen. Software muss von Hackern entwickelt werden, die etwas von Design verstehen, und nicht von Designern, die sich ein bisschen mit Software auskennen. Wenn Sie Software nicht entwickeln und implementieren können, gründen Sie kein Startup.

Kommen wir nun zur Konkurrenz. Sie fürchten sich vermutlich nicht vor Hackergruppen wie Ihnen, sondern vor echten Unternehmen mit Büros, Geschäftsplänen, Verkäufern und so weiter, richtig? Nun, sie haben mehr Angst vor Ihnen als Sie vor ihnen, und sie haben recht. Für ein paar Hacker ist es viel einfacher, herauszufinden, wie sie Büroräume mieten oder Verkäufer einstellen können, als für ein Unternehmen jeder Größe, Software zu schreiben. Ich habe beide Seiten erlebt und weiß Bescheid. Als Viaweb von Yahoo aufgekauft wurde, arbeitete ich plötzlich für ein großes Unternehmen, und es war, als würde ich versuchen, durch hüfttiefes Wasser zu laufen.

Ich möchte Yahoo nicht herabwürdigen. Sie hatten einige gute Hacker und die Führungsspitze war ein echter Arschtritt. Für ein großes Unternehmen waren sie außergewöhnlich. Aber sie waren trotzdem nur etwa ein Zehntel so produktiv wie ein kleines Startup. Kein großes Unternehmen kann das viel besser. Was an Microsoft beängstigend ist, ist, dass ein so großes Unternehmen überhaupt Software entwickeln kann. Sie sind wie ein Berg, den man besteigen kann.

Lassen Sie sich nicht einschüchtern. Sie können so viel tun, was Microsoft nicht kann, wie Microsoft tun kann, was Sie nicht können. Und niemand kann Sie aufhalten. Sie müssen niemanden um Erlaubnis bitten, um webbasierte Anwendungen zu entwickeln. Sie müssen keine Lizenzverträge abschließen, sich Regalfläche in Einzelhandelsgeschäften sichern oder sich darum quälen, dass Ihre Anwendung mit dem Betriebssystem gebündelt wird. Sie können Software direkt an den Browser liefern, und niemand kann sich zwischen Sie und potenzielle Benutzer stellen, ohne sie am Surfen im Internet zu hindern.

Sie werden es vielleicht nicht glauben, aber ich versichere Ihnen, Microsoft hat Angst vor Ihnen. Die selbstgefälligen mittleren Manager haben vielleicht keine Angst vor Ihnen, aber Bill hat sie, denn er war einmal Sie, damals im Jahr 1975, als zum letzten Mal eine neue Art der Softwarebereitstellung aufkam.

Hinweise

[1] Da Unternehmen, die leichte Clients bauen, erkannten, dass ein Großteil des Geldes in den Diensten steckt, haben sie normalerweise versucht, die Hardware mit einem Onlinedienst zu kombinieren. Dieser Ansatz hat nicht gut funktioniert, zum Teil, weil man zwei verschiedene Arten von Unternehmen braucht, um Unterhaltungselektronik zu bauen und einen Onlinedienst zu betreiben, und zum Teil, weil die Benutzer die Idee hassen. Rasierer zu verschenken und mit den Klingen Geld zu verdienen, mag für Gillette funktionieren, aber ein Rasierer ist eine viel geringere Verpflichtung als ein Webterminal. Hersteller von Mobiltelefonen geben sich damit zufrieden, Hardware zu verkaufen, ohne zu versuchen, auch die Serviceeinnahmen zu erzielen. Das sollte wahrscheinlich auch das Modell für Internetclients sein. Wenn jemand einfach eine hübsche kleine Box mit einem Webbrowser verkaufen würde, mit dem man sich über jeden ISP verbinden könnte, würde jeder Technikfeind im Land eine kaufen.

[2] Sicherheit hängt immer mehr davon ab, dass man nichts vermasselt, als von Designentscheidungen. Die Natur serverbasierter Software zwingt Entwickler jedoch dazu, mehr darauf zu achten, dass sie nichts vermasseln. Die Kompromittierung eines Servers könnte einen solchen Schaden anrichten, dass ASPs (die im Geschäft bleiben wollen) bei der Sicherheit wahrscheinlich vorsichtiger sein werden.

[3] Als wir 1995 Viaweb gründeten, galten Java-Applets als die Technologie, die jeder zur Entwicklung serverbasierter Anwendungen verwenden würde. Applets schienen uns eine altmodische Idee zu sein. Programme herunterladen, um sie auf dem Client auszuführen? Einfacher war es, den ganzen Weg zu gehen und die Programme auf dem Server auszuführen. Wir haben wenig Zeit mit Applets verschwendet, aber zahllose andere Startups müssen in diese Teergrube gelockt worden sein. Nur wenige dürften lebend davongekommen sein, sonst wäre Microsoft nicht damit durchgekommen, Java in der neuesten Version des Explorers wegzulassen.

[4] Dieser Punkt geht auf Trevor Blackwell zurück, der hinzufügt: "Die Kosten für das Schreiben von Software steigen mehr als linear mit ihrer Größe. Vielleicht liegt das hauptsächlich daran, dass alte Fehler behoben werden müssen, und die Kosten können linearer sein, wenn alle Fehler schnell gefunden werden."

[5] Am schwierigsten zu finden sind möglicherweise Varianten zusammengesetzter Fehler, bei denen ein Fehler zufällig einen anderen kompensiert. Wenn Sie einen Fehler beheben, wird der andere sichtbar. Es wird jedoch so aussehen, als ob die Behebung des Fehlers der Grund ist, da dies das letzte war, was Sie geändert haben.

[6] Bei Viaweb haben wir einmal einen Wettbewerb veranstaltet, bei dem es darum ging, das Schlimmste an unserer Software zu beschreiben. Zwei Mitarbeiter des Kundensupports haben sich den ersten Preis geteilt, und zwar mit Beiträgen, bei deren Erinnerung ich noch immer schaudere. Wir haben beide Probleme sofort behoben.

[7] Robert Morris schrieb das Bestellsystem, mit dem die Käufer Bestellungen aufgeben konnten. Trevor Blackwell schrieb den Bildgenerator und den Manager, mit dem die Händler Bestellungen abrufen, Statistiken anzeigen und Domänennamen usw. konfigurieren konnten. Ich schrieb den Editor, mit dem die Händler ihre Websites erstellten. Das Bestellsystem und der Bildgenerator wurden in C und C++ geschrieben, der Manager größtenteils in Perl und der Editor in Lisp .

[8] Preisdiskriminierung ist so weit verbreitet (wie oft haben Sie schon einen Einzelhändler behaupten hören, seine Kaufkraft bedeute niedrigere Preise für Sie?), dass ich überrascht war, als ich herausfand, dass sie in den USA durch den Robinson-Patman Act von 1936 verboten wurde. Dieses Gesetz scheint nicht energisch durchgesetzt zu werden.

[9] In No Logo sagt Naomi Klein, dass Bekleidungsmarken, die bei der „urbanen Jugend“ beliebt sind, sich nicht allzu sehr anstrengen, Ladendiebstahl zu verhindern, weil in ihrem Zielmarkt die Ladendiebe zugleich die Modeführer seien.

[10] Unternehmen stellen sich oft die Frage, was sie auslagern sollten und was nicht. Eine mögliche Antwort: Alle Tätigkeiten, die nicht direkt dem Wettbewerbsdruck ausgesetzt sind, werden ausgelagert, da sie durch die Auslagerung dem Wettbewerbsdruck ausgesetzt werden.

[11] Die beiden waren Dan Bricklin und Bob Frankston. Dan schrieb in ein paar Tagen einen Prototyp in Basic, dann arbeiteten sie im Laufe des nächsten Jahres (meistens nachts) zusammen, um eine leistungsfähigere Version in der Maschinensprache 6502 zu erstellen. Dan war zu dieser Zeit an der Harvard Business School und Bob hatte nominell einen Tagesjob als Softwareentwickler. „Es gab kein großes Risiko bei der Führung eines Unternehmens“, schrieb Bob, „wenn es scheiterte, dann scheiterte es. Keine große Sache.“

[12] Es ist nicht ganz so einfach, wie ich es darstelle. Es dauerte quälend lange, bis die Mundpropaganda in Gang kam, und wir bekamen erst viel Presseberichterstattung, als wir eine PR-Firma (zugegebenermaßen die beste in der Branche) für 16.000 Dollar pro Monat engagierten. Es stimmte jedoch, dass der einzige bedeutende Kanal unsere eigene Website war.

[13] Wenn der Mac so toll war, warum war er dann so schlecht? Wieder einmal waren es die Kosten. Microsoft konzentrierte sich auf das Softwaregeschäft und ließ eine Schar billiger Komponentenlieferanten auf Apple-Hardware los. Es half auch nicht, dass in einer kritischen Phase die Anzugträger die Oberhand gewannen.

[14] Eine Sache, die webbasierten Anwendungen helfen und dazu beitragen würde, dass die nächste Software-Generation nicht von Microsoft in den Schatten gestellt wird, wäre ein guter Open-Source-Browser. Mozilla ist zwar Open-Source, scheint aber darunter zu leiden, dass es so lange Unternehmenssoftware war. Ein kleiner, schneller Browser, der aktiv gepflegt wird, wäre an sich schon eine tolle Sache und würde wahrscheinlich auch Unternehmen ermutigen, kleine Web-Appliances zu entwickeln.

Unter anderem würde ein richtiger Open-Source-Browser dazu führen, dass sich HTTP und HTML weiterentwickeln (wie es beispielsweise bei Perl der Fall ist). Webbasierten Anwendungen würde es sehr helfen, zwischen der Auswahl eines Links und dem Folgen desselben unterscheiden zu können. Alles, was Sie dazu brauchen, wäre eine triviale Erweiterung von HTTP, um mehrere URLs in einer Anfrage zuzulassen. Kaskadierende Menüs wären ebenfalls gut.

Wenn Sie die Welt verändern möchten, schreiben Sie ein neues Mosaic. Sie denken, es ist zu spät? 1998 dachten viele Leute, es sei zu spät, eine neue Suchmaschine zu starten, aber Google hat ihnen das Gegenteil bewiesen. Es gibt immer Platz für etwas Neues, wenn die aktuellen Optionen nicht mehr so gut sind. Stellen Sie zunächst sicher, dass es auf allen kostenlosen Betriebssystemen funktioniert – neue Dinge beginnen bei ihren Benutzern.

[15] Trevor Blackwell, der hierüber aus eigener Erfahrung wahrscheinlich mehr weiß als jeder andere, schreibt:

"Ich würde sogar noch weiter gehen und sagen, dass serverbasierte Software, weil sie so hart für die Programmierer ist, eine grundlegende wirtschaftliche Abkehr von großen Unternehmen bewirkt. Sie erfordert von den Programmierern eine Intensität und Hingabe, die sie nur dann aufbringen werden, wenn es ihr eigenes Unternehmen ist. Softwareunternehmen können qualifizierte Mitarbeiter einstellen, die in einer nicht allzu anspruchsvollen Umgebung arbeiten, und sie können ungelernte Mitarbeiter einstellen, die Härten ertragen, aber sie können keine hochqualifizierten Mitarbeiter einstellen, die ihnen den Arsch aufreißen. Da kein Kapital mehr benötigt wird, haben große Unternehmen wenig beizutragen."

[16] In der Originalversion dieses Essays riet ich dazu, Javascript zu vermeiden. Das war 2001 ein guter Plan, aber Javascript funktioniert heute.

Mein Dank geht an Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson und Dan Giffin für das Lesen der Entwürfe dieses Dokuments, an Dan Bricklin und Bob Frankston für Informationen zu VisiCalc und nochmals an Ken Anderson für die Einladung, beim BBN einen Vortrag zu halten.

Diesen und 14 weitere Aufsätze finden Sie in Hackers & Painters .