DER ANDERE WEG NACH VORNE

September 2001

(Dieser Artikel erklärt, warum ein großer Teil der nächsten Generation von Software serverbasiert sein könnte, was das für Programmierer bedeutet und warum diese neue Art von Software eine großartige Gelegenheit für Startups ist. 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, die auf den Börsengang von Netscape hinarbeitete, lief damals auf Hochtouren, und in der Presse wurde viel über Online-Handel gesprochen. Zu dieser Zeit gab es vielleicht dreißig tatsächliche Geschäfte im Web, alle von Hand gemacht. Wenn es viele Online-Shops geben sollte, müsste es Software geben, um sie zu erstellen, also beschlossen wir, etwas zu schreiben.

In der ersten Woche oder so hatten wir vor, dies zu einer gewöhnlichen Desktop-Anwendung zu machen. Dann hatten wir eines Tages 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 schrieben, dass sie auf dem Server lief, wäre es für die Benutzer und auch für uns viel einfacher.

Das stellte sich als guter Plan heraus. Jetzt, als Yahoo Store, ist diese Software der beliebteste Online-Shop-Baukasten mit etwa 14.000 Benutzern.

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 gestartet wurde, 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ßer Teil der nächsten Generation von Software nach diesem Modell geschrieben wird. Selbst Microsoft, die am meisten zu verlieren haben, scheinen die Unvermeidlichkeit zu erkennen, einige Dinge vom Desktop zu verlagern. Wenn Software vom Desktop auf Server verlagert wird, wird das eine ganz andere Welt für Entwickler bedeuten. Dieser Artikel beschreibt die überraschenden Dinge, die wir sahen, als einige der ersten Besucher dieser neuen Welt. Soweit Software auf Server verlagert wird, ist das, was ich hier beschreibe, die Zukunft.

Das Nächste?

Wenn wir auf die Ära der Desktop-Software zurückblicken, denke ich, werden wir über die Unannehmlichkeiten staunen, mit denen die Menschen sich abfanden, genau wie wir jetzt darüber staunen, was frühe Autobesitzer ertragen mussten. In den ersten zwanzig oder dreißig Jahren musste man ein Auto-Experte sein, um ein Auto zu besitzen. Aber Autos waren so ein großer Gewinn, dass viele Menschen, die keine Auto-Experten waren, sie ebenfalls haben wollten.

Computer befinden sich jetzt in dieser Phase. Wenn man einen Desktop-Computer besitzt, lernt man viel mehr, als man wissen wollte, über das, was darin passiert. Aber mehr als die Hälfte der Haushalte in den USA besitzt einen. Meine Mutter hat einen Computer, den sie für E-Mails und zur Buchführung 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 ist etwas falsch, wenn eine fünfundsechzigjährige Frau, die einen Computer für E-Mails und Buchhaltung nutzen möchte, darüber nachdenken muss, neue Betriebssysteme zu installieren. Gewöhnliche Benutzer sollten nicht einmal die Worte "Betriebssystem" kennen, geschweige denn "Gerätetreiber" oder "Patch".

Es gibt jetzt einen anderen Weg, Software bereitzustellen, der die Benutzer davor bewahrt, Systemadministratoren zu werden. Webbasierte Anwendungen sind Programme, die auf Webservern laufen und Webseiten als Benutzeroberfläche verwenden. Für den durchschnittlichen Benutzer wird diese neue Art von Software einfacher, günstiger, mobiler, zuverlässiger und oft leistungsfähiger sein als Desktop-Software.

Mit webbasierter Software müssen die meisten Benutzer an nichts anderes denken als an die Anwendungen, die sie verwenden. All die unordentlichen, sich ändernden Dinge werden irgendwo auf einem Server sitzen, gewartet von denjenigen, die gut in solchen Dingen sind. Und so wird man normalerweise keinen Computer im eigentlichen Sinne benötigen, um Software zu verwenden. Alles, was man braucht, ist etwas mit einer Tastatur, einem Bildschirm und einem Webbrowser. Vielleicht hat es drahtlosen Internetzugang. Vielleicht ist es auch dein Handy. Was auch immer es ist, es wird Unterhaltungselektronik sein: etwas, das etwa 200 Dollar kostet und das die Leute hauptsächlich danach auswählen, wie das Gehäuse aussieht. Du wirst mehr für Internetdienste bezahlen als für die Hardware, genau wie du es jetzt mit Telefonen tust. [1]

Es wird etwa ein Zehntel einer Sekunde dauern, bis ein Klick den Server erreicht und zurückkommt, sodass Benutzer von stark interaktiver Software wie Photoshop immer noch möchten, dass die Berechnungen auf dem Desktop stattfinden. Aber wenn man sich die Art von Dingen ansieht, für die die meisten Menschen Computer verwenden, wäre eine Verzögerung von einem Zehntel einer Sekunde kein Problem. Meine Mutter braucht wirklich keinen Desktop-Computer, und es gibt viele Menschen wie sie.

Der Gewinn für die Benutzer

In der Nähe meines Hauses gibt es ein Auto mit einem Aufkleber, auf dem steht: "Tod vor Unannehmlichkeit." Die meisten Menschen werden die Wahl treffen, die am wenigsten Arbeit erfordert. Wenn webbasierte Software gewinnt, wird es daran liegen, dass sie bequemer ist. Und es sieht so aus, als ob sie es sein wird, sowohl für Benutzer als auch für Entwickler.

Um eine rein webbasierte Anwendung zu verwenden, benötigt man nur einen Browser, der mit dem Internet verbunden ist. So kann man eine webbasierte Anwendung überall verwenden. Wenn man Software auf seinem Desktop-Computer installiert, kann man sie nur auf diesem Computer verwenden. Noch schlimmer ist, dass deine Dateien auf diesem Computer gefangen sind. Die Unannehmlichkeit dieses Modells wird immer offensichtlicher, je mehr die Menschen sich an Netzwerke gewöhnen.

Der dünne Anfang des Keils hier war webbasierte E-Mails. Millionen von Menschen erkennen jetzt, dass man Zugang zu E-Mail-Nachrichten haben sollte, egal wo man ist. Und wenn man seine E-Mails sehen kann, warum nicht auch seinen Kalender? Wenn man ein Dokument mit seinen Kollegen besprechen kann, warum kann man es dann nicht bearbeiten? Warum sollte irgendeine deiner Daten auf einem Computer gefangen sein, der auf einem weit entfernten Schreibtisch steht?

Die ganze Idee von "deinem Computer" verschwindet und wird ersetzt durch "deine Daten." Du solltest in der Lage sein, auf deine Daten von jedem Computer zuzugreifen. Oder besser gesagt, von jedem Client, und ein Client muss kein Computer sein.

Clients sollten keine Daten speichern; sie sollten wie Telefone sein. Tatsächlich könnten sie Telefone werden oder umgekehrt. Und je kleiner die Clients werden, hast du einen weiteren Grund, deine Daten nicht auf ihnen zu speichern: Etwas, das du mit dir herumträgst, kann verloren gehen oder gestohlen werden. Dein PDA in einem Taxi zu vergessen, ist wie ein Festplattenschaden, nur dass deine Daten jemand anderem übergeben werden, anstatt vaporisiert zu werden.

Mit rein webbasierter Software werden weder deine Daten noch die Anwendungen auf dem Client gespeichert. Du musst also nichts installieren, um sie zu verwenden. Und wenn es keine Installation gibt, musst du dir keine Sorgen machen, dass die Installation schiefgeht. Es kann keine Inkompatibilitäten zwischen der Anwendung und deinem Betriebssystem geben, weil die Software nicht auf deinem Betriebssystem läuft.

Da es keine Installation benötigt, wird es einfach und üblich sein, webbasierte Software auszuprobieren, bevor du sie "kaufst". Du solltest erwarten können, jede webbasierte Anwendung kostenlos testen zu können, einfach indem du die Seite besuchst, auf der sie angeboten wird. Bei Viaweb war unsere gesamte Seite wie ein großer Pfeil, der die Benutzer zur Testfahrt führte.

Nach dem Ausprobieren der Demo sollte die Anmeldung für den Dienst nichts mehr erfordern als das Ausfüllen eines kurzen Formulars (je kürzer, desto besser). Und das sollte die letzte Arbeit sein, die der Benutzer leisten muss. Mit webbasierter Software solltest du neue Versionen erhalten, ohne extra zu bezahlen, ohne Arbeit zu leisten oder möglicherweise sogar davon zu erfahren.

Updates werden nicht die großen Schocks sein, die sie jetzt sind. Im Laufe der Zeit werden Anwendungen leise leistungsfähiger werden. Das wird einige Anstrengungen von den Entwicklern erfordern. Sie müssen die Software so gestalten, dass sie aktualisiert werden kann, ohne die Benutzer zu verwirren. Das ist ein neues Problem, aber es gibt Wege, es zu lösen.

Mit webbasierten Anwendungen verwenden alle dieselbe Version, und Fehler können behoben werden, sobald sie entdeckt werden. Daher sollte webbasierte Software weit weniger Fehler haben als Desktop-Software. Bei Viaweb bezweifle ich, dass wir jemals zehn bekannte Fehler gleichzeitig hatten. Das ist um Größenordnungen besser als Desktop-Software.

Webbasierte Anwendungen können von mehreren Personen gleichzeitig verwendet werden. Das ist ein offensichtlicher Gewinn für kollaborative Anwendungen, aber ich wette, die Benutzer werden anfangen, dies in den meisten Anwendungen zu wollen, sobald sie erkennen, dass es möglich ist. Es wird oft nützlich sein, zwei Personen zu erlauben, dasselbe Dokument zu bearbeiten, zum Beispiel. Viaweb erlaubte mehreren Benutzern, eine Seite gleichzeitig zu bearbeiten, mehr, weil das der richtige Weg war, die Software zu schreiben, als weil wir erwarteten, dass die Benutzer es wollen würden, aber es stellte sich heraus, dass viele es taten.

Wenn du eine webbasierte Anwendung verwendest, werden deine Daten sicherer sein. Festplattenschäden werden nicht der Vergangenheit angehören, aber die Benutzer werden nicht mehr davon hören. Sie werden innerhalb von Serverfarmen passieren. Und Unternehmen, die webbasierte Anwendungen anbieten, werden tatsächlich Backups machen – nicht nur, weil sie echte Systemadministratoren haben, die sich um solche Dinge kümmern, sondern weil ein ASP, der die Daten der Benutzer verliert, in großen, großen Schwierigkeiten sein wird. Wenn Menschen ihre eigenen Daten bei einem Festplattenschaden verlieren, können sie nicht so wütend werden, weil sie nur sich selbst dafür verantwortlich machen 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 der Client nichts außer einem Browser ausführt, gibt es weniger Chancen, Viren auszuführen, und keine Daten lokal, die beschädigt werden könnten. Und ein Programm, das die Server selbst angreift, sollte sie sehr gut verteidigt finden. [2]

Für die Benutzer wird webbasierte Software weniger stressig sein. Ich denke, wenn du in den durchschnittlichen Windows-Benutzer hineinblicken würdest, würdest du ein riesiges und weitgehend ungenutztes Verlangen nach Software finden, die dieser Beschreibung entspricht. Ungezügelt könnte es 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 wird eine Sammlung von Programmen unterschiedlicher Art sein, anstatt ein einzelnes großes Binary. Und so ist das Entwerfen von webbasierter Software wie das Entwerfen einer Stadt anstatt eines Gebäudes: Neben Gebäuden benötigt man Straßen, Straßenschilder, Versorgungsunternehmen, Polizei- und Feuerwehrabteilungen sowie 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 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 Suchen 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 zur Diagnose von Netzwerkproblemen, Programme zur Durchführung von Backups, Schnittstellen zu externen Diensten, Software, die eine beeindruckende Sammlung von Anzeigen zur Anzeige von Echtzeit-Serverstatistiken steuerte (ein Hit bei den Besuchern, aber auch für uns unverzichtbar), Modifikationen (einschließlich Fehlerbehebungen) an Open-Source-Software und eine große Anzahl von Konfigurationsdateien und -einstellungen. Trevor Blackwell schrieb ein spektakuläres Programm, um Geschäfte ohne Abschaltung auf neue Server im ganzen Land zu verschieben, nachdem wir von Yahoo gekauft wurden. Programme alarmierten uns, sendeten Faxe und E-Mails an Benutzer, führten Transaktionen mit Kreditkartenverarbeitern durch und kommunizierten über Sockets, Pipes, http-Anfragen, ssh, udp-Pakete, gemeinsamen Speicher und Dateien. Ein Teil von Viaweb bestand sogar aus der Abwesenheit von Programmen, da einer der Schlüssel zur Unix-Sicherheit darin besteht, unnötige Dienstprogramme, die Menschen verwenden könnten, um in deine Server einzudringen, nicht auszuführen.

Es endete nicht mit 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 schnelle genug Verbindungen zu allen Backbone-Netzen hatte. Wir hatten eine Reihe von RAID-Anbietern.

Aber Hardware ist nicht nur etwas, worüber man sich Sorgen machen muss. Wenn du sie kontrollierst, kannst du mehr für die Benutzer tun. Mit einer Desktop-Anwendung kannst du bestimmte Mindesthardware angeben, aber du kannst nicht mehr hinzufügen. Wenn du die Server verwaltest, kannst du in einem Schritt allen deinen Benutzern ermöglichen, Personen zu alarmieren, Faxe zu senden, Befehle per Telefon zu senden oder Kreditkarten zu verarbeiten, usw., einfach indem du die entsprechende Hardware installierst. Wir suchten immer nach neuen Wegen, Funktionen mit Hardware hinzuzufügen, nicht nur, weil es die Benutzer erfreute, sondern auch als Möglichkeit, 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 kein einzelnes Binary ist, kann sie in einer beliebigen Anzahl von verschiedenen Sprachen geschrieben werden. Wenn Sie Desktop-Software schreiben, sind Sie praktisch gezwungen, die Anwendung in derselben Sprache wie das zugrunde liegende Betriebssystem zu schreiben – das bedeutet C und C++. Und so wurden diese Sprachen (insbesondere unter nicht-technischen Personen wie Managern und VCs) als die Sprachen für "ernsthafte" Softwareentwicklung angesehen. Aber das war nur ein Artefakt der Art und Weise, wie Desktop-Software geliefert werden musste. Für serverbasierte Software können Sie jede Sprache verwenden, die Sie möchten. [3] Heute verwenden viele der besten Hacker Sprachen, die weit von C und C++ entfernt sind: Perl, Python und sogar Lisp.

Bei serverbasierter Software kann Ihnen niemand sagen, welche Sprache Sie verwenden sollen, denn Sie kontrollieren das gesamte System, bis hin zur Hardware. Verschiedene Sprachen sind für verschiedene Aufgaben gut. Sie können diejenige verwenden, die für jede am besten geeignet ist. Und wenn Sie Wettbewerber haben, bedeutet "Sie können", dass "Sie müssen" (darauf werden wir später zurückkommen), denn wenn Sie diese Möglichkeit nicht nutzen, werden es Ihre Wettbewerber tun.

Die meisten unserer Wettbewerber verwendeten C und C++, und das machte ihre Software sichtbar unterlegen, weil (unter anderem) sie keinen Ausweg aus der Zustandslosigkeit von CGI-Skripten hatten. Wenn Sie etwas ändern wollten, mussten alle Änderungen auf einer Seite erfolgen, mit einem Aktualisierungsbutton am Ende. Wie ich anderswo geschrieben habe, konnten wir durch die Verwendung von Lisp, das viele Menschen immer noch als Forschungssprache betrachten, den Viaweb-Editor dazu bringen, sich mehr wie Desktop-Software zu verhalten.

Veröffentlichungen

Eine der wichtigsten Änderungen in dieser neuen Welt ist die Art und Weise, wie Sie Veröffentlichungen durchführen. Im Desktop-Softwaregeschäft ist eine Veröffentlichung ein riesiges Trauma, bei dem das gesamte Unternehmen schwitzt und sich anstrengt, um ein einziges, riesiges Stück Code herauszupressen. Offensichtliche Vergleiche drängen sich sowohl für den Prozess als auch für das resultierende Produkt auf.

Bei serverbasierter Software können Sie Änderungen fast so vornehmen, wie Sie es bei einem Programm tun würden, das Sie für sich selbst schreiben. Sie veröffentlichen Software als eine Reihe von inkrementellen Änderungen anstelle einer gelegentlichen großen Explosion. Ein typisches Desktop-Softwareunternehmen könnte ein oder zwei Veröffentlichungen pro Jahr durchführen. Bei Viaweb haben wir oft drei bis fünf Veröffentlichungen pro Tag durchgeführt.

Wenn Sie zu diesem neuen Modell wechseln, erkennen Sie, wie sehr die Softwareentwicklung von der Art und Weise beeinflusst wird, wie sie veröffentlicht wird. Viele der schlimmsten Probleme, die Sie im Desktop-Softwaregeschäft sehen, sind auf die katastrophale Natur von Veröffentlichungen zurückzuführen.

Wenn Sie nur einmal im Jahr eine neue Version veröffentlichen, neigen Sie dazu, Bugs im Großhandel zu behandeln. Einige Zeit vor dem Veröffentlichungstermin stellen Sie eine neue Version zusammen, in der die Hälfte des Codes herausgerissen und ersetzt wurde, was unzählige Bugs einführt. Dann tritt eine Gruppe von QA-Mitarbeitern ein und beginnt, sie zu zählen, und die Programmierer arbeiten die Liste ab und beheben sie. Sie kommen in der Regel nicht bis zum Ende der Liste, und tatsächlich ist niemand sicher, wo das Ende ist. Es ist wie das Fischen von Schutt aus einem Teich. Sie wissen nie wirklich, was in der Software passiert. Im besten Fall haben Sie eine statistische Art von Richtigkeit.

Bei serverbasierter Software sind die meisten Änderungen klein und inkrementell. Das ist an sich weniger wahrscheinlich, Bugs einzuführen. Es bedeutet auch, dass Sie wissen, was Sie am sorgfältigsten testen sollten, wenn Sie kurz davor sind, Software zu veröffentlichen: das Letzte, was Sie geändert haben. Sie haben einen viel festeren Griff auf den Code. Als allgemeine Regel wissen Sie, was darin passiert. Sie haben den Quellcode natürlich nicht auswendig gelernt, aber wenn Sie den Quellcode lesen, tun Sie es wie ein Pilot, der das Instrumentenpanel scannt, nicht wie ein Detektiv, der versucht, ein Rätsel zu lösen.

Desktop-Software fördert eine gewisse Fatalismus gegenüber Bugs. Sie wissen, dass Sie etwas versenden, das voller Bugs ist, und Sie haben sogar Mechanismen eingerichtet, um dies auszugleichen (z. B. Patch-Veröffentlichungen). Warum sich also um ein paar mehr kümmern? Bald veröffentlichen Sie ganze Funktionen, von denen Sie wissen, dass sie kaputt sind. Apple hat dies Anfang dieses 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) war nicht bereit. Die Lösung? Sie veröffentlichten das Betriebssystem ohne die unfertigen Teile, und die Benutzer müssen sie später installieren.

Bei webbasierten Software müssen Sie Software niemals veröffentlichen, bevor sie funktioniert, und Sie können sie veröffentlichen, sobald sie funktioniert.

Der Branchenveteran mag denken, es ist eine gut klingende Idee zu sagen, dass Sie Software niemals veröffentlichen müssen, bevor sie funktioniert, aber was passiert, wenn Sie versprochen haben, eine neue Version Ihrer Software bis zu einem bestimmten Datum zu liefern? Bei webbasierten Software würden Sie ein solches Versprechen nicht abgeben, denn es gibt keine Versionen. Ihre Software ändert sich allmählich und kontinuierlich. Einige Änderungen könnten größer sein als andere, aber die Idee von Versionen passt einfach nicht natürlich zu webbasierten Software.

Wenn sich jemand an Viaweb erinnert, mag das seltsam klingen, denn wir haben immer neue Versionen angekündigt. Dies geschah ausschließlich aus PR-Gründen. Die Fachpresse, haben wir gelernt, denkt in Versionsnummern. Sie geben Ihnen eine große Berichterstattung für eine große Veröffentlichung, was bedeutet, dass eine neue erste Ziffer in der Versionsnummer und im Allgemeinen ein Absatz höchstens für eine Punktveröffentlichung, was bedeutet, dass eine neue Ziffer nach dem Dezimalpunkt.

Einige unserer Wettbewerber boten Desktop-Software an und hatten tatsächlich Versionsnummern. Und für diese Veröffentlichungen, deren bloße Tatsache uns als Beweis für ihre Rückständigkeit erschien, erhielten sie alle möglichen Publicity. Wir wollten nicht zurückbleiben, also begannen wir auch, unseren Software Versionsnummern zu geben. Wenn wir etwas Publicity wollten, machten 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 sagten, dass die neue Version sofort verfügbar sei. Erstaunlicherweise hat uns nie jemand darauf angesprochen.

Als wir gekauft wurden, hatten wir dies dreimal getan, also waren wir bei Version 4. Version 4.1, wenn ich mich recht erinnere. Nachdem Viaweb Yahoo Store wurde, gab es nicht mehr so einen verzweifelten Bedarf an Publicity, also wurde die gesamte Idee von Versionsnummern stillschweigend fallen gelassen, obwohl die Software weiterhin weiterentwickelt wurde.

Bugs

Der andere große technische Vorteil von webbasierten Software ist, dass Sie die meisten Bugs reproduzieren können. Sie haben die Daten der Benutzer direkt auf Ihrer Festplatte. Wenn jemand Ihre Software kaputt macht, müssen Sie nicht raten, was vor sich geht, wie Sie es bei Desktop-Software tun würden: Sie sollten in der Lage sein, den Fehler zu reproduzieren, während sie am Telefon mit Ihnen sind. Möglicherweise wissen Sie sogar bereits davon, wenn Sie Code zur Fehlererkennung in Ihre Anwendung eingebaut haben.

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

Softwareunternehmen werden manchmal beschuldigt, die Benutzer ihre Software debuggen zu lassen. Und genau das plädiere ich. Für webbasierte Software ist es tatsächlich ein guter Plan, denn die Bugs sind weniger und vorübergehend. Wenn Sie Software schrittweise veröffentlichen, erhalten Sie von Anfang an viel weniger Bugs. Und wenn Sie Fehler reproduzieren und Änderungen sofort veröffentlichen können, können Sie die meisten Bugs beheben, sobald sie auftreten. Wir hatten nie genug Bugs zu einem bestimmten Zeitpunkt, um uns mit einem formalen Bug-Tracking-System zu beschäftigen.

Sie sollten Änderungen testen, bevor Sie sie veröffentlichen, sodass keine größeren Bugs veröffentlicht werden sollten. Die wenigen, die unvermeidlich durchrutschen, betreffen Grenzfälle und betreffen nur die wenigen Benutzer, die ihnen begegnen, bevor jemand anruft, um sich zu beschweren. Solange Sie Bugs sofort beheben, ist der Nettoeffekt für den durchschnittlichen Benutzer viel weniger Bugs. Ich bezweifle, dass der durchschnittliche Viaweb-Benutzer jemals einen Bug gesehen hat.

Frische Bugs zu beheben ist einfacher als alte. Es ist normalerweise ziemlich schnell, einen Bug im Code zu finden, den Sie gerade geschrieben haben. Wenn er auftaucht, wissen Sie oft, was falsch ist, bevor Sie überhaupt den Quellcode ansehen, weil Sie sich bereits unbewusst darüber Sorgen gemacht haben. Einen Bug in etwas zu beheben, das Sie vor sechs Monaten geschrieben haben (der durchschnittliche Fall, wenn Sie einmal im Jahr veröffentlichen), ist viel mehr Arbeit. Und da Sie den Code nicht so gut verstehen, ist es wahrscheinlicher, dass Sie ihn auf eine hässliche Weise beheben oder sogar mehr Bugs einführen. [4]

Wenn Sie Bugs frühzeitig erfassen, erhalten Sie auch weniger zusammengesetzte Bugs. Zusammengesetzte Bugs sind zwei separate Bugs, die interagieren: Sie stolpern die Treppe hinunter, und wenn Sie nach dem Handlauf greifen, kommt er in Ihrer Hand ab. In der Software ist diese Art von Bug am schwersten zu finden und hat auch tendenziell die schlimmsten Folgen. [5] Der traditionelle Ansatz "alles kaputt machen und dann die Bugs herausfiltern" führt von Natur aus zu vielen zusammengesetzten Bugs. Und Software, die in einer Reihe von kleinen Änderungen veröffentlicht wird, neigt von Natur aus nicht dazu. Die Böden werden ständig von losen Objekten befreit, die später in etwas stecken bleiben könnten.

Es hilft, wenn Sie eine Technik namens funktionale Programmierung verwenden. Funktionale Programmierung bedeutet, Nebenwirkungen zu vermeiden. Es ist etwas, das Sie eher in Forschungsarbeiten als in kommerzieller Software sehen, aber für webbasierte Anwendungen erweist es sich als wirklich nützlich. Es ist schwierig, ganze Programme als rein funktionalen Code zu schreiben, aber Sie können erhebliche Teile auf diese Weise schreiben. Es macht diese Teile Ihrer Software einfacher zu testen, weil sie keinen Zustand haben, und das ist sehr praktisch in einer Situation, in der Sie ständig kleine Modifikationen 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.

Menschen aus der Desktop-Softwarebranche werden dies schwer glauben können, aber bei Viaweb wurden Bugs fast zu einem Spiel. Da die meisten veröffentlichten Bugs Grenzfälle betrafen, waren die Benutzer, die ihnen begegneten, wahrscheinlich fortgeschrittene Benutzer, die die Grenzen austesteten. Fortgeschrittene Benutzer sind nachsichtiger gegenüber Bugs, insbesondere da Sie sie wahrscheinlich im Laufe der Hinzufügung einer Funktion, nach der sie gefragt haben, eingeführt haben. Tatsächlich, weil Bugs selten waren und Sie etwas Sophistiziertes tun mussten, um sie zu sehen, waren fortgeschrittene Benutzer oft stolz darauf, einen zu fangen. Sie riefen den Support in einem Geist mehr des Triumphes als des Zorns an, als ob sie Punkte gegen uns erzielt hätten.

Support

Wenn Sie Fehler reproduzieren können, ändert sich Ihr Ansatz für den Kundensupport. In den meisten Softwareunternehmen wird Support als Möglichkeit angeboten, die Kunden besser fühlen zu lassen. Sie rufen entweder wegen eines bekannten Bugs an, oder sie machen einfach etwas falsch und Sie müssen herausfinden, was. In beiden Fällen gibt es nicht viel, was Sie von ihnen lernen können. Und so neigen Sie dazu, Supportanrufe als eine lästige Pflicht zu betrachten, die Sie so weit wie möglich von Ihren Entwicklern isolieren möchten.

So lief es nicht bei Viaweb. 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.

So standen die Entwickler bei Viaweb immer in engem Kontakt mit dem Support. Die Kundenservicemitarbeiter waren etwa dreißig Fuß von den Programmierern entfernt und wussten, dass sie jederzeit alles unterbrechen konnten, um einen echten Bug zu melden. Wir würden eine Vorstandssitzung verlassen, um einen schwerwiegenden Bug zu beheben.

Unser Ansatz für den Support machte alle glücklicher. 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 bringt. Die Kundenservicemitarbeiter mochten es, weil es bedeutete, dass sie den Benutzern helfen konnten, anstatt ihnen Skripte vorzulesen. Und die Programmierer mochten es, weil sie Bugs reproduzieren konnten, anstatt nur vage Berichte darüber zu hören.

Unsere Politik, Bugs im laufenden Betrieb zu beheben, änderte die Beziehung zwischen den Kundenservicemitarbeitern und den Hackern. In den meisten Softwareunternehmen sind Supportmitarbeiter unterbezahlte menschliche Schutzschilde, und Hacker sind kleine Kopien von Gott dem Vater, Schöpfer der Welt. Egal, wie das Verfahren zur Meldung von Bugs aussieht, es ist wahrscheinlich einseitig: Supportmitarbeiter, die von Bugs hören, füllen ein Formular aus, das schließlich (möglicherweise über QA) an Programmierer weitergeleitet wird, die es auf ihre To-Do-Liste setzen. Bei Viaweb war es ganz anders. Innerhalb einer Minute, nachdem sie von einem Kunden von einem Bug gehört hatten, konnten die Supportmitarbeiter neben einem Programmierer stehen und hören, wie er sagt: "Verdammtes Mist, du hast recht, es ist ein Bug." Es erfreute die Supportmitarbeiter zu hören, dass "du recht hast" von den Hackern. Sie brachten uns Bugs mit der gleichen erwartungsvollen Haltung, wie eine Katze, die Ihnen eine Maus bringt, die sie gerade getötet hat. Es machte sie auch vorsichtiger bei der Beurteilung der Schwere eines Bugs, denn jetzt stand ihre Ehre auf dem Spiel.

Nachdem wir von Yahoo gekauft wurden, wurden die Kundenservicemitarbeiter weit weg von den Programmierern versetzt. Erst dann erkannten wir, dass sie effektiv QA und bis zu einem gewissen Grad auch Marketing waren. Neben der Erfassung von Bugs waren sie die Hüter des Wissens über vage, bugähnliche Dinge, wie Funktionen, die Benutzer verwirrten. [6] Sie waren auch eine Art Proxy-Fokusgruppe; wir konnten sie fragen, welche von zwei neuen Funktionen die Benutzer mehr wollten, und sie lagen immer richtig.

Moral

Die Möglichkeit, Software sofort zu veröffentlichen, ist ein großer Motivator. Oft dachte ich, während ich zur Arbeit ging, an eine Änderung, die ich an der Software vornehmen wollte, und machte es an diesem Tag. Das funktionierte auch für größere Funktionen. Selbst wenn etwas zwei Wochen in Anspruch nehmen würde (wenige Projekte dauerten länger), wusste ich, dass ich die Auswirkungen in der Software sehen konnte, sobald es fertig war.

Hätte ich ein Jahr auf die nächste Veröffentlichung warten müssen, hätte ich die meisten dieser Ideen für eine Weile auf Eis gelegt. Das Problem mit Ideen ist jedoch, dass sie zu weiteren Ideen führen. Ist dir schon einmal aufgefallen, dass, wenn du dich hinsetzt, um etwas zu schreiben, die Hälfte der Ideen, die darin enden, solche sind, die dir beim Schreiben eingefallen sind? Dasselbe passiert mit Software. An einer Idee zu arbeiten, gibt dir mehr Ideen. Das Aufschieben einer Idee kostet dich also nicht nur die Verzögerung bei der Umsetzung, sondern auch all die Ideen, die die Umsetzung hervorgebracht hätte. Tatsächlich hemmt das Aufschieben einer Idee wahrscheinlich sogar neue Ideen: Wenn du anfängst, über eine neue Funktion nachzudenken, siehst du das Regal und denkst: "Aber ich habe bereits viele neue Dinge, die ich für die nächste Veröffentlichung tun möchte."

Was große Unternehmen stattdessen tun, ist, Funktionen zu planen. Bei Viaweb hatten wir manchmal Probleme damit. Investoren und Analysten fragten uns, was wir für die Zukunft geplant hatten. Die ehrliche Antwort wäre gewesen, dass wir keine Pläne hatten. Wir hatten allgemeine Ideen darüber, was 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 wie der größte Gewinn aussah. Ich weiß nicht, ob ich jemals gewagt habe, diese Antwort zu geben, aber das war die Wahrheit. Pläne sind nur ein anderes Wort für Ideen auf dem Regal. Wenn wir gute Ideen hatten, setzten wir sie um.

Bei Viaweb, wie in vielen Softwareunternehmen, hatte der Großteil des Codes einen bestimmten Besitzer. Aber wenn du etwas besessen hast, hast du es wirklich besessen: Niemand außer dem Besitzer eines Softwareteils musste eine Veröffentlichung genehmigen (oder sogar davon wissen). Es gab keinen Schutz gegen Fehler außer der Angst, wie ein Idiot vor seinen Kollegen auszusehen, und das war mehr als genug. Ich habe vielleicht den Eindruck erweckt, dass wir einfach unbeschwert voranschritten und Code schrieben. Wir gingen schnell voran, aber wir dachten sehr sorgfältig nach, bevor wir Software auf diese Server veröffentlichten. Und aufmerksam zu sein, ist wichtiger für die Zuverlässigkeit als langsam zu arbeiten. Weil er genau aufpasst, kann ein Marinepilot ein 40.000 Pfund schweres Flugzeug mit 140 Meilen pro Stunde auf einem wackelnden Flugdeck bei Nacht sicherer landen als der durchschnittliche Teenager einen Bagel schneiden kann.

Diese Art, Software zu schreiben, ist natürlich ein zweischneidiges Schwert. Sie funktioniert viel besser für ein kleines Team von guten, vertrauenswürdigen Programmierern als für ein großes Unternehmen von mittelmäßigen, wo schlechte Ideen von Komitees anstatt von denjenigen, die sie hatten, aufgefangen werden.

Brooks in umgekehrter Reihenfolge

Glücklicherweise erfordert webbasierte Software weniger Programmierer. Ich arbeitete einmal für ein mittelgroßes Desktop-Softwareunternehmen, das über 100 Personen in der gesamten Technik hatte. Nur 13 davon waren in der Produktentwicklung. Alle anderen arbeiteten an Veröffentlichungen, Ports usw. Bei webbasierter Software benötigst du (höchstens) diese 13 Personen, weil es keine Veröffentlichungen, Ports usw. gibt.

Viaweb wurde von nur drei Personen geschrieben. [7] Ich stand immer unter Druck, mehr einzustellen, weil wir gekauft werden wollten, und wir wussten, dass Käufer Schwierigkeiten haben würden, einen hohen Preis für ein Unternehmen mit nur drei Programmierern zu zahlen. (Lösung: Wir stellten mehr ein, schufen aber neue Projekte für sie.)

Wenn du Software mit weniger Programmierern schreiben kannst, sparst du mehr als nur Geld. Wie Fred Brooks in The Mythical Man-Month feststellte, führt das Hinzufügen von Personen zu einem Projekt dazu, dass es langsamer wird. Die Anzahl der möglichen 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 entstehen durch unvorhergesehene Interaktionen. Glücklicherweise funktioniert dieser Prozess auch umgekehrt: Wenn Gruppen kleiner werden, wird die Softwareentwicklung exponentiell effizienter. Ich kann mich nicht erinnern, dass die Programmierer bei Viaweb jemals ein tatsächliches Meeting hatten. Wir hatten nie mehr zu sagen, als wir beim Gehen zum Mittagessen sagen konnten.

Wenn es hier einen Nachteil gibt, dann, dass alle Programmierer bis zu einem gewissen Grad auch Systemadministratoren sein müssen. Wenn du Software hostest, muss jemand die Server überwachen, und in der Praxis sind die einzigen, die dies richtig tun können, die, 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. Eine willkürliche Erklärung einer solchen Grenze hätte unsere Designentscheidungen eingeschränkt. Und so hofften wir ständig, dass eines Tages ("in ein paar Monaten") alles stabil genug sein würde, dass wir jemanden einstellen könnten, dessen Aufgabe es war, sich nur um die Server zu kümmern, aber das geschah nie.

Ich glaube nicht, dass es anders sein könnte, solange du das Produkt noch aktiv entwickelst. Webbasierte Software wird niemals etwas sein, das du schreibst, eincheckst und nach Hause gehst. Es ist ein lebendiges Ding, das gerade jetzt auf deinen Servern läuft. Ein schwerwiegender Fehler könnte nicht nur den Prozess eines Benutzers zum Absturz bringen; er könnte sie alle zum Absturz bringen. Wenn ein Fehler in deinem Code einige Daten auf der Festplatte beschädigt, musst du ihn beheben. Und so weiter. Wir fanden heraus, dass du die Server nicht jede Minute überwachen musst (nach dem ersten Jahr oder so), aber du möchtest definitiv ein Auge auf Dinge haben, die du kürzlich geändert hast. Du veröffentlichst keinen Code spät in der Nacht und gehst dann nach Hause.

Benutzer beobachten

Mit serverbasierter Software bist du näher an deinem Code. Du kannst auch näher an deinen Benutzern sein. Intuit ist berühmt dafür, sich den Kunden in Einzelhandelsgeschäften vorzustellen und zu fragen, ob sie sie nach Hause begleiten dürfen. Wenn du jemals jemanden beobachtet hast, der deine Software zum ersten Mal verwendet, weißt du, welche Überraschungen auf sie gewartet haben müssen.

Software sollte das tun, was die Benutzer denken, dass sie es tun wird. Aber du kannst keine Ahnung haben, was die Benutzer denken werden, glaub mir, bis du sie beobachtest. Und serverbasierte Software gibt dir beispiellose Informationen über ihr Verhalten. Du bist nicht auf kleine, künstliche Fokusgruppen beschränkt. Du kannst jeden Klick jedes Benutzers sehen. Du musst sorgfältig überlegen, was du dir ansehen möchtest, denn du willst die Privatsphäre der Benutzer nicht verletzen, aber selbst die allgemeinsten statistischen Stichproben können sehr nützlich sein.

Wenn du die Benutzer auf deinem Server hast, musst du dich zum Beispiel nicht auf Benchmarks verlassen. Benchmarks sind simulierte Benutzer. Mit serverbasierter Software kannst du echte Benutzer beobachten. Um zu entscheiden, was du optimieren möchtest, logge dich einfach auf einen Server ein und sieh dir an, was die gesamte CPU verbraucht. Und du weißt auch, wann du mit der Optimierung aufhören solltest: Wir haben den Viaweb-Editor schließlich so weit gebracht, dass er speichergebunden war, anstatt CPU-gebunden, und da es nichts gab, was wir tun konnten, um die Größe der Benutzerdaten zu verringern (nun, nichts Einfaches), wussten wir, dass wir dort aufhören konnten.

Effizienz ist wichtig für serverbasierte Software, weil du für die Hardware bezahlst. Die Anzahl der Benutzer, die du pro Server unterstützen kannst, ist der Divisor deiner Kapitalkosten, also wenn du deine Software sehr effizient machen kannst, kannst du Wettbewerber unterbieten und trotzdem einen Gewinn erzielen. Bei Viaweb haben wir die Kapitalkosten pro Benutzer auf etwa 5 $ gesenkt. Es wäre jetzt weniger, wahrscheinlich weniger als die Kosten, um ihnen die Rechnung für den ersten Monat zu senden. Hardware ist jetzt kostenlos, wenn deine Software einigermaßen effizient ist.

Benutzer zu beobachten kann dir sowohl bei der Gestaltung als auch bei der Optimierung helfen. Viaweb hatte eine Skriptsprache namens RTML, die es fortgeschrittenen Benutzern ermöglichte, ihre eigenen Seitenstile zu definieren. Wir fanden heraus, dass RTML zu einer Art Vorschlagsbox wurde, weil Benutzer es nur verwendeten, wenn die vordefinierten Seitenstile nicht das tun konnten, was sie wollten. Ursprünglich platzierte der Editor beispielsweise Schaltflächenleisten über die Seite, aber nachdem eine Reihe von Benutzern RTML verwendet hatte, um Schaltflächen an die linke Seite zu setzen, machten wir das zu einer Option (tatsächlich der Standard) in den vordefinierten Seitenstilen.

Schließlich kannst du oft erkennen, wenn Benutzer in Schwierigkeiten sind, indem du sie beobachtest. Und da der Kunde immer recht hat, ist das ein Zeichen für etwas, das du beheben musst. Bei Viaweb war der Schlüssel, um Benutzer zu gewinnen, die Online-Testfahrt. Es war nicht nur eine Reihe von Folien, die von Marketingmitarbeitern erstellt wurden. In unserer Testfahrt verwendeten die Benutzer tatsächlich die Software. Es dauerte etwa fünf Minuten, und am Ende hatten sie einen echten, funktionierenden Laden aufgebaut.

Die Testfahrt war der Weg, wie wir fast alle unsere neuen Benutzer gewonnen haben. Ich denke, es wird für die meisten webbasierten Anwendungen dasselbe sein. Wenn Benutzer eine Testfahrt erfolgreich durchlaufen können, werden sie das Produkt mögen. Wenn sie verwirrt oder gelangweilt sind, werden sie es nicht. Alles, was wir tun konnten, um mehr Menschen durch die Testfahrt zu bringen, würde unsere Wachstumsrate erhöhen.

Ich studierte die Klickpfade von Personen, die die Testfahrt machten, und stellte fest, dass sie an einem bestimmten Schritt verwirrt wurden und auf die Zurück-Taste des Browsers klickten. (Wenn du versuchst, webbasierte Anwendungen zu schreiben, wirst du feststellen, dass die Zurück-Taste eines deiner interessantesten philosophischen Probleme wird.) Also fügte ich an diesem Punkt eine Nachricht hinzu, die den Benutzern sagte, dass sie fast fertig seien, und erinnerte sie daran, nicht auf die Zurück-Taste zu klicken. Eine weitere großartige Sache an webbasierter Software ist, dass du sofortiges Feedback von Änderungen erhältst: Die Anzahl der Personen, die die Testfahrt abschlossen, stieg sofort von 60 % auf 90 %. Und da die Anzahl neuer Benutzer eine Funktion der Anzahl abgeschlossener Testfahrten war, stieg unser Umsatzwachstum um 50 %, nur durch diese Änderung.

Geld

In den frühen 1990er Jahren las ich einen Artikel, in dem jemand sagte, dass Software ein Abonnementgeschäft sei. Zunächst schien dies eine sehr zynische Aussage zu sein. Aber später erkannte ich, dass es die Realität widerspiegelt: Softwareentwicklung ist ein fortlaufender Prozess. Ich denke, es ist sauberer, wenn du offen Abonnementgebühren erhebst, anstatt die Leute zu zwingen, ständig neue Versionen zu kaufen und zu installieren, damit sie dir weiterhin Geld zahlen. Und glücklicherweise sind Abonnements der natürliche Weg, um für webbasierte Anwendungen abzurechnen.

Das Hosting von Anwendungen ist ein Bereich, in dem Unternehmen eine Rolle spielen werden, die wahrscheinlich nicht von Freeware übernommen wird. Das Hosting von Anwendungen ist eine Menge Stress und hat echte Kosten. Niemand wird es kostenlos tun wollen.

Für Unternehmen sind webbasierte Anwendungen eine ideale Einnahmequelle. Anstatt jedes Quartal mit einem leeren Blatt zu beginnen, hast du einen wiederkehrenden Einnahmenstrom. Da sich deine Software allmählich weiterentwickelt, musst du dir keine Sorgen machen, dass ein neues Modell floppt; es muss nie ein neues Modell im engeren Sinne geben, und wenn du etwas an der Software tust, das die Benutzer hassen, wirst du es sofort wissen. Du hast keine Probleme mit uneinbringlichen Rechnungen; wenn jemand nicht zahlt, kannst du einfach den Dienst abschalten. Und es gibt keine Möglichkeit der Piraterie.

Dieser letzte "Vorteil" könnte sich als Problem herausstellen. Ein gewisser Grad an Piraterie ist zum Vorteil von Softwareunternehmen. Wenn ein Benutzer deine Software zu keinem Preis gekauft hätte, hast du nichts verloren, wenn er eine raubkopierte Kopie verwendet. Tatsächlich gewinnst du, weil er ein weiterer Benutzer ist, der dazu beiträgt, deine Software zum Standard zu machen – oder der später eine Kopie kaufen könnte, wenn er die High School abschließt.

Wenn sie können, machen Unternehmen gerne etwas, das Preisdiscrimination genannt wird, was bedeutet, dass sie jedem Kunden so viel berechnen, wie er sich leisten kann. [8] Software eignet sich besonders gut für Preisdiscrimination, weil die Grenzkosten nahe null liegen. Das ist der Grund, warum einige Software mehr kostet, um auf Suns als auf Intel-Boxen zu laufen: Ein Unternehmen, das Suns verwendet, ist nicht daran interessiert, Geld zu sparen, und kann sicher mehr berechnet werden. Piraterie ist effektiv die niedrigste Stufe der Preisdiscrimination. Ich denke, dass Softwareunternehmen dies verstehen und absichtlich bei einigen Arten von Piraterie ein Auge zudrücken. [9] Mit 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. Du könntest denken, dass die Leute entscheiden, etwas zu kaufen, und es dann kaufen, als zwei separate Schritte. Das dachte ich, bevor ich Viaweb kannte, soweit ich überhaupt über die Frage nachdachte. Tatsächlich kann der zweite Schritt in den ersten zurückpropagieren: Wenn etwas schwer zu kaufen ist, werden die Leute ihre Meinung darüber ändern, ob sie es wollten. Und umgekehrt: Du wirst mehr von etwas verkaufen, wenn es einfach zu kaufen ist. Ich kaufe mehr Bücher, weil es Amazon gibt. Webbasierte Software ist fast das Einfachste, was man kaufen kann, insbesondere wenn du gerade eine Online-Demo gemacht hast. Benutzer sollten nicht viel mehr tun müssen, als eine Kreditkartennummer einzugeben. (Lass sie mehr tun, auf dein eigenes Risiko.)

Manchmal wird webbasierte Software über ISPs angeboten, die als Wiederverkäufer fungieren. Das ist eine schlechte Idee. Du musst die Server verwalten, weil du ständig sowohl Hardware als auch Software verbessern musst. Wenn du die direkte Kontrolle über die Server aufgibst, gibst du die meisten Vorteile der Entwicklung webbasierter Anwendungen auf.

Mehrere unserer Wettbewerber haben sich auf diese Weise ins eigene Fleisch geschnitten – normalerweise, denke ich, weil sie von Anzugträgern überrannt wurden, die von diesem riesigen potenziellen Kanal begeistert waren, und nicht realisierten, dass es das Produkt ruinieren würde, das sie darüber verkaufen wollten. Webbasierte Software über ISPs zu verkaufen, ist wie Sushi über Verkaufsautomaten zu verkaufen.

Kunden

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

Webbasierte Anwendungen werden oft auch für große Unternehmen das Beste sein (obwohl sie langsam realisieren werden). Das beste Intranet ist das Internet. Wenn ein Unternehmen echte webbasierte Anwendungen nutzt, wird die Software besser funktionieren, die Server werden besser verwaltet, und die Mitarbeiter haben von überall Zugriff auf das System.

Das Argument gegen diesen Ansatz beruht normalerweise auf Sicherheit: Wenn der Zugang für Mitarbeiter einfacher ist, wird er auch für Bösewichte einfacher sein. Einige größere Händler waren zögerlich, Viaweb zu nutzen, weil sie dachten, die Kreditkarteninformationen der Kunden wären auf ihren eigenen Servern sicherer. Es war nicht einfach, diesen Punkt diplomatisch zu vermitteln, aber in der Tat waren die Daten in unseren Händen fast mit Sicherheit sicherer als in ihren. Wer kann bessere Leute einstellen, um die Sicherheit zu verwalten, ein Technologie-Startup, dessen ganzes 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 auch mehr Sorgen darum. Wenn jemand in die Server des Bekleidungshändlers einbricht, würde das höchstens einen Händler betreffen, könnte wahrscheinlich unter den Teppich gekehrt werden, und im schlimmsten Fall könnte es dazu führen, dass eine Person gefeuert wird. Wenn jemand in unsere Server einbricht, könnte das 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 wollen, halten Sie es dann unter Ihrer Matratze zu Hause oder legen Sie es in eine Bank? Dieses Argument gilt für jeden Aspekt der Serververwaltung: nicht nur für Sicherheit, sondern auch für Verfügbarkeit, Bandbreite, Lastmanagement, Backups usw. Unser Bestehen hing davon ab, diese Dinge richtig zu machen. Serverprobleme waren für uns ein großes No-Go, wie ein gefährliches Spielzeug für einen Spielzeughersteller oder ein Salmonellenausbruch für einen Lebensmittelverarbeiter.

Ein großes Unternehmen, das webbasierte Anwendungen nutzt, lagert in diesem Maße IT aus. So drastisch es klingt, ich denke, das ist im Allgemeinen eine gute Idee. Unternehmen werden auf diese Weise wahrscheinlich besseren Service erhalten, als sie von internen Systemadministratoren bekommen würden. Systemadministratoren können mürrisch und unresponsive werden, weil sie nicht direkt dem Wettbewerbsdruck ausgesetzt sind: Ein Verkäufer muss mit Kunden umgehen, und ein Entwickler muss sich mit der Software von Wettbewerbern auseinandersetzen, aber ein Systemadministrator, wie ein alter Junggeselle, hat wenige externe Kräfte, die ihn in Schach halten. [10] Bei Viaweb hatten wir genügend externe Kräfte, die uns in Schach hielten. Die Leute, die uns anriefen, waren Kunden, nicht nur Kollegen. Wenn ein Server feststeckte, sprangen wir; allein der Gedanke daran gibt mir Jahre später einen Adrenalinstoß.

Webbasierte Anwendungen werden normalerweise auch die richtige Antwort für große Unternehmen sein. Sie werden jedoch die letzten sein, die es realisieren, genau wie sie es bei Desktop-Computern waren. Und teilweise aus demselben Grund: Es wird viel Geld kosten, große Unternehmen davon zu überzeugen, dass sie etwas Teureres brauchen.

Es gibt immer eine Tendenz, dass reiche Kunden teure Lösungen kaufen, selbst wenn billige Lösungen besser sind, weil die Anbieter teurer Lösungen mehr ausgeben können, um sie zu verkaufen. Bei Viaweb standen wir immer vor diesem Problem. Wir verloren mehrere High-End-Händler an Webberatungsfirmen, die sie überzeugten, dass sie besser dran wären, wenn sie eine halbe Million Dollar für einen maßgeschneiderten Online-Shop auf ihrem eigenen Server bezahlen würden. Sie waren in der Regel nicht besser dran, wie mehr als einer entdeckte, als die Weihnachtszeit kam und die Lasten auf ihrem Server stiegen. Viaweb war viel ausgeklügelter als das, was die meisten dieser Händler bekamen, aber wir konnten es uns nicht leisten, es ihnen zu sagen. Bei 300 Dollar im Monat konnten wir es uns nicht leisten, ein Team von gut gekleideten und autoritär klingenden Leuten zu schicken, um Präsentationen für Kunden zu halten.

Ein großer Teil dessen, was große Unternehmen zusätzlich bezahlen, ist die Kosten für den Verkauf teurer Dinge an sie. (Wenn das Verteidigungsministerium tausend Dollar für Toilettensitze bezahlt, liegt das teilweise daran, dass es viel kostet, Toilettensitze für tausend Dollar zu verkaufen.) Und das ist ein Grund, warum Intranet-Software weiterhin gedeihen wird, auch wenn es wahrscheinlich eine schlechte Idee ist. Es ist einfach teurer. Es gibt nichts, was Sie an diesem Dilemma ändern können, also ist der beste Plan, zuerst die kleineren Kunden anzuvisieren. Der Rest wird mit der Zeit kommen.

Sohn des Servers

Software auf dem Server auszuführen, ist nichts Neues. Tatsächlich ist es das alte Modell: Mainframe-Anwendungen sind alle serverbasiert. Wenn serverbasierte Software so eine gute Idee ist, warum hat sie beim letzten Mal verloren? Warum haben Desktop-Computer Mainframes überflügelt?

Zunächst sahen Desktop-Computer nicht nach einer großen Bedrohung aus. Die ersten Benutzer waren allesamt Hacker – oder Hobbyisten, wie sie damals genannt wurden. Sie mochten Mikrocomputer, weil sie billig waren. Zum ersten Mal konnte man seinen eigenen Computer haben. Der Begriff "Personal Computer" ist jetzt Teil der Sprache, aber als er zum ersten Mal verwendet wurde, hatte er einen absichtlich gewagten Klang, wie der Begriff "persönlicher Satellit" heute.

Warum haben Desktop-Computer die Oberhand gewonnen? Ich denke, es lag daran, dass sie bessere Software hatten. Und ich denke, der Grund, warum Mikrocomputer-Software besser war, war, dass sie von kleinen Unternehmen geschrieben werden konnte.

Ich glaube nicht, dass viele Menschen realisieren, wie zerbrechlich und vorläufig Startups in der frühesten Phase sind. Viele Startups beginnen fast zufällig – als ein paar Typen, entweder mit Tagesjobs oder in der Schule, die einen Prototyp von etwas schreiben, das, wenn es vielversprechend aussieht, zu einem Unternehmen werden könnte. In diesem larvalen Stadium wird jedes signifikante Hindernis das Startup sofort stoppen. Mainframe-Software zu schreiben erforderte zu viel Engagement im Voraus. Entwicklungsmaschinen waren teuer, und da die Kunden große Unternehmen sein würden, bräuchten Sie eine beeindruckend aussehende Verkaufsforce, um es ihnen zu verkaufen. Ein Startup zu gründen, um Mainframe-Software zu schreiben, wäre ein viel ernsthafteres Unterfangen, als einfach etwas auf Ihrem Apple II abends zusammenzuhacken. Und so gab es nicht viele Startups, die Mainframe-Anwendungen schrieben.

Die Ankunft von Desktop-Computern inspirierte eine Menge neuer Software, weil das Schreiben von Anwendungen für sie ein erreichbares Ziel für larvale Startups schien. Die Entwicklung war billig, und die Kunden wären Einzelpersonen, die Sie über Computerläden oder sogar per Versandhandel erreichen konnten.

Die Anwendung, die Desktop-Computer in den Mainstream drängte, war VisiCalc, die erste Tabellenkalkulation. Sie wurde von zwei Typen geschrieben, die in einem Dachboden arbeiteten, und konnte Dinge tun, 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 diesmal gut sein wird, weil Startups sie schreiben werden. Computer sind jetzt so billig, dass Sie, wie wir, mit einem Desktop-Computer als Server beginnen können. Günstige Prozessoren haben den Arbeitsplatzmarkt erobert (das Wort hört man jetzt kaum noch) und sind fast vollständig im Servermarkt angekommen; die Server von Yahoo, die mit Lasten umgehen, die so hoch sind wie die höchsten im Internet, haben alle die gleichen günstigen Intel-Prozessoren, die Sie in Ihrem Desktop-Gerät haben. Und sobald Sie die Software geschrieben haben, brauchen Sie nur noch eine Website, um sie zu verkaufen. Fast alle unsere Benutzer kamen direkt über Mundpropaganda und Referenzen in der Presse auf unsere Seite. [12]

Viaweb war ein typisches larvales Startup. Wir hatten Angst, ein Unternehmen zu gründen, und trösteten uns in den ersten Monaten, indem wir das Ganze als Experiment betrachteten, das wir jederzeit abbrechen könnten. Glücklicherweise gab es nur wenige Hindernisse, außer technischen. Während wir die Software schrieben, war unser Webserver dasselbe Desktop-Gerät, das wir für die Entwicklung verwendeten, verbunden mit der Außenwelt über eine Einwahlverbindung. Unsere einzigen Ausgaben in dieser Phase waren Essen und Miete.

Es gibt umso mehr Gründe für Startups, jetzt webbasierte Software zu schreiben, weil das Schreiben von Desktop-Software viel weniger Spaß gemacht hat. Wenn Sie jetzt Desktop-Software schreiben wollen, tun Sie es zu Microsofts Bedingungen, indem Sie deren APIs aufrufen und sich um deren fehlerhaftes Betriebssystem herumarbeiten. Und wenn Sie es schaffen, etwas zu schreiben, das durchstartet, stellen Sie möglicherweise fest, dass Sie lediglich Marktforschung für Microsoft betrieben haben.

Wenn ein Unternehmen eine Plattform schaffen will, auf der Startups aufbauen, muss es sie so gestalten, dass Hacker selbst sie nutzen wollen. Das bedeutet, sie muss kostengünstig und gut gestaltet sein. Der Mac war bei Hackern beliebt, als er zuerst herauskam, und viele von ihnen schrieben Software dafür. [13] Das sieht man bei Windows weniger, weil Hacker es nicht verwenden. Die Art von Menschen, die gut darin sind, Software zu schreiben, verwenden jetzt tendenziell Linux oder FreeBSD.

Ich glaube nicht, dass wir ein Startup gegründet hätten, um Desktop-Software zu schreiben, weil Desktop-Software unter Windows laufen muss, und bevor wir Software für Windows schreiben könnten, müssten wir es verwenden. Das Web ließ uns einen Umweg um Windows machen und Software, die auf Unix läuft, direkt über den Browser an die Benutzer liefern. Das ist eine befreiende Aussicht, ähnlich wie die Ankunft von PCs vor fünfundzwanzig Jahren.

Microsoft

Als Desktop-Computer aufkamen, war IBM der Riese, vor dem jeder Angst hatte. Es ist jetzt schwer vorstellbar, aber ich erinnere mich sehr gut an das Gefühl. Jetzt ist der furchterregende Riese Microsoft, und ich glaube nicht, dass sie so blind gegenüber der Bedrohung sind, die ihnen gegenübersteht, wie IBM es war. Schließlich hat Microsoft absichtlich ihr Geschäft in IBMs blinder Zone aufgebaut.

Ich erwähnte früher, dass meine Mutter wirklich keinen Desktop-Computer braucht. Die meisten Benutzer wahrscheinlich auch nicht. Das ist ein Problem für Microsoft, und sie wissen es. Wenn Anwendungen auf entfernten Servern laufen, braucht niemand Windows. Was wird Microsoft tun? Werden sie in der Lage sein, ihre Kontrolle über den Desktop zu nutzen, um diese neue Generation von Software zu verhindern oder einzuschränken?

Ich vermute, dass Microsoft eine Art Server/Desktop-Hybrid entwickeln wird, bei dem das Betriebssystem mit Servern zusammenarbeitet, die sie kontrollieren. Mindestens werden Dateien zentral für Benutzer verfügbar sein, die das wollen. Ich erwarte nicht, dass Microsoft bis zum Extrem geht, die Berechnungen auf dem Server durchzuführen, mit nur einem Browser als Client, wenn sie es vermeiden können. Wenn Sie nur einen Browser als Client benötigen, brauchen Sie Microsoft nicht auf dem Client, und wenn Microsoft den Client nicht kontrolliert, können sie die Benutzer nicht zu ihren serverbasierten Anwendungen drängen.

Ich denke, 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 Wettbewerber in der Lage sein, sie zu übertrumpfen, indem sie Anwendungen anbieten, die von jedem Client aus funktionieren. [14]

In einer Welt von webbasierten Anwendungen gibt es keinen automatischen Platz für Microsoft. Sie könnten erfolgreich sein, sich einen Platz zu schaffen, aber ich glaube nicht, dass sie diese neue Welt dominieren werden, wie sie die Welt der Desktop-Anwendungen dominiert haben.

Es ist nicht so sehr, dass ein Wettbewerber sie stolpern lässt, sondern dass sie über sich selbst stolpern werden. Mit dem Aufstieg von webbasierter Software werden sie nicht nur mit technischen Problemen konfrontiert sein, sondern auch mit ihrem eigenen Wunschdenken. Was sie tun müssen, ist, ihr bestehendes Geschäft zu kannibalisieren, und ich kann nicht sehen, dass sie sich dem stellen. Die gleiche Zielstrebigkeit, die sie so weit gebracht hat, wird jetzt gegen sie arbeiten. IBM war in genau der gleichen Situation, und sie konnten sie nicht meistern. IBM trat spät und halbherzig in das Mikrocomputer-Geschäft ein, weil sie ambivalent waren, ihre Geldkuh, das Mainframe-Computing, zu bedrohen. Microsoft wird ebenfalls behindert sein, weil sie den Desktop retten wollen. Eine Geldkuh kann ein verdammtes schwerer Affe auf Ihrem Rücken sein.

Ich sage nicht, dass niemand serverbasierte Anwendungen dominieren wird. Irgendjemand wird wahrscheinlich irgendwann. Aber ich denke, dass es eine lange Zeit fröhlichen Chaos geben wird, genau wie in den frühen Tagen der Mikrocomputer. Das war eine gute Zeit für Startups. Viele kleine Unternehmen florierten und taten dies, indem sie coole Dinge machten.

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 Auswirkungen der Entscheidungen, die sie treffen. Wenn sie gewinnen, gewinnen sie groß.

In einem Startup, das webbasierte Anwendungen schreibt, wird alles, was Sie mit Startups assoziieren, auf die Spitze getrieben. Sie können ein Produkt mit noch weniger Leuten und noch weniger Geld schreiben und auf den Markt bringen. Sie müssen noch schneller sein, und Sie können es sich leisten, informeller zu sein. Sie können Ihr Produkt buchstäblich als drei Typen, die im Wohnzimmer einer Wohnung sitzen, und einem Server, der bei einem ISP untergebracht ist, auf den Markt bringen. Wir taten es.

Im Laufe der Zeit sind die Teams kleiner, schneller und informeller geworden. 1960 bedeutete Softwareentwicklung einen Raum voller Männer mit hornrimmed Brillen und schmalen schwarzen Krawatten, die fleißig zehn Zeilen Code pro Tag auf IBM-Codierungsformularen schrieben. 1980 war es ein Team von acht bis zehn Personen, die Jeans ins Büro trugen und in vt100s tippten. Jetzt sind es ein paar Typen, die mit Laptops in einem Wohnzimmer sitzen. (Und es stellt sich heraus, dass Jeans nicht das letzte Wort in der Informalität sind.)

Startups sind stressig, und das wird leider auch bei webbasierten Anwendungen bis zum Äußersten getrieben. Viele Softwareunternehmen haben, besonders am Anfang, Phasen, in denen die Entwickler unter ihren Schreibtischen schliefen und so weiter. Das Alarmierende an webbasierten Software ist, dass es nichts gibt, was verhindert, dass dies zur Norm wird. Die Geschichten über das Schlafen unter Schreibtischen enden normalerweise so: Dann haben wir es endlich ausgeliefert und sind alle nach Hause gegangen und haben eine Woche geschlafen. Webbasierte Software wird nie ausgeliefert. Man kann 16-Stunden-Tage arbeiten, so lange man will. Und weil man kann, und die Wettbewerber auch, wird man gezwungen, es zu tun. Man kann, also muss man. Es ist Parkinsons Gesetz, das rückwärts läuft.

Das Schlimmste sind nicht die Stunden, sondern die Verantwortung. Programmierer und Systemadministratoren haben traditionell jeweils ihre eigenen Sorgen. Programmierer müssen sich um Bugs kümmern, und Systemadministratoren müssen sich um die Infrastruktur kümmern. Programmierer können einen langen Tag bis zu den Ellbogen in Quellcode verbringen, aber irgendwann dürfen sie nach Hause gehen und es vergessen. Systemadministratoren lassen den Job nie ganz hinter sich, aber wenn sie um 4:00 Uhr morgens gerufen 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 scharf definierten Grenzen, die den Job normalerweise erträglich machen.

Bei Viaweb haben wir die ersten sechs Monate nur Software geschrieben. Wir arbeiteten die üblichen langen Stunden eines frühen Startups. In einem Desktop-Softwareunternehmen wäre dies der Teil gewesen, in dem wir hart arbeiteten, aber es fühlte sich wie ein Urlaub im Vergleich zur nächsten Phase an, als wir Benutzer auf unseren Server brachten. Der zweitgrößte Vorteil des Verkaufs von Viaweb an Yahoo (nach dem Geld) war, die ultimative Verantwortung für das Ganze auf die Schultern eines großen Unternehmens abzuladen.

Desktop-Software zwingt Benutzer dazu, Systemadministratoren zu werden. Webbasierte Software zwingt auch Programmierer dazu. Es gibt insgesamt weniger Stress, aber mehr für die Programmierer. Das sind nicht unbedingt schlechte Nachrichten. Wenn man ein Startup ist, das mit einem großen Unternehmen konkurriert, sind das gute Nachrichten. [[15]] Webbasierte Anwendungen bieten eine unkomplizierte Möglichkeit, die Wettbewerber zu überarbeiten. Kein Startup verlangt mehr.

Nur gut genug

Eine Sache, die dich davon abhalten könnte, webbasierte Anwendungen zu schreiben, ist die Schwäche von Webseiten als UI. Das ist ein Problem, gebe ich zu. Es gab ein paar Dinge, die wir wirklich gerne zu HTML und HTTP hinzugefügt hätten. Was zählt, ist jedoch, dass Webseiten gerade gut genug sind.

Hier gibt es eine Parallele zu den ersten Mikrocomputern. Die Prozessoren in diesen Maschinen waren eigentlich nicht dafür gedacht, die CPUs von Computern zu sein. Sie wurden entwickelt, um in Dingen wie Ampeln verwendet zu werden. Aber Leute wie Ed Roberts, der den Altair entworfen hat, erkannten, dass sie gerade gut genug waren. Man konnte einen dieser Chips mit etwas Speicher (256 Bytes im ersten Altair) und Frontpanel-Schaltern kombinieren, und man hätte einen funktionierenden Computer. Die Möglichkeit, einen eigenen Computer zu haben, war so aufregend, dass es viele Menschen gab, die sie kaufen wollten, so begrenzt sie auch waren.

Webseiten wurden nicht als UI für Anwendungen entworfen, aber sie sind gerade gut genug. Und für eine signifikante Anzahl von Benutzern wird Software, die man von jedem Browser aus verwenden kann, ein Gewinn an sich sein, der jede Unbeholfenheit in der UI überwiegt. Vielleicht kann man mit HTML nicht die am besten aussehende Tabellenkalkulation schreiben, aber man kann eine Tabellenkalkulation schreiben, die mehrere Personen gleichzeitig von verschiedenen Standorten ohne spezielle Client-Software verwenden können, oder die Live-Datenfeeds integrieren kann, oder die einen benachrichtigen kann, wenn bestimmte Bedingungen ausgelöst werden. Noch wichtiger ist, dass man neue Arten von Anwendungen schreiben kann, die noch nicht einmal Namen haben. VisiCalc war schließlich nicht nur eine Mikrocomputer-Version einer Mainframe-Anwendung – es war eine neue Art von Anwendung.

Natürlich müssen serverbasierte Anwendungen nicht webbasiert sein. Man könnte eine andere Art von Client haben. Aber ich bin mir ziemlich sicher, dass das eine schlechte Idee ist. Es wäre sehr praktisch, wenn man annehmen könnte, dass jeder seinen Client installieren würde – so praktisch, dass man sich leicht überzeugen könnte, dass sie es alle tun würden – aber wenn sie es nicht tun, ist man erledigt. Da webbasierte Software nichts über den Client annimmt, funktioniert sie überall, wo das Web funktioniert. Das ist bereits ein großer Vorteil, und der Vorteil wird wachsen, während neue Webgeräte proliferieren. Die Benutzer werden dich mögen, weil deine Software einfach funktioniert, und dein Leben wird einfacher sein, weil du sie nicht für jeden neuen Client anpassen musst. [[16]]

Ich habe das Gefühl, dass ich die Evolution des Webs so genau beobachtet habe wie jeder andere, und ich kann nicht vorhersagen, was mit Clients passieren wird. Die Konvergenz kommt wahrscheinlich, aber wo? Ich kann keinen Gewinner auswählen. Eine Sache, die ich vorhersagen kann, ist der Konflikt zwischen AOL und Microsoft. Was auch immer Microsofts .NET letztendlich sein wird, es wird wahrscheinlich die Verbindung des Desktops mit Servern beinhalten. Es sei denn, AOL wehrt sich, werden sie entweder beiseite gedrängt oder in ein Rohr zwischen Microsoft-Client- und Server-Software verwandelt. Wenn Microsoft und AOL in einen Client-Krieg geraten, wird das einzige, was auf beiden funktioniert, das Browsen des Webs sein, was bedeutet, dass webbasierte Anwendungen die einzige Art sein werden, die überall funktioniert.

Wie wird sich das alles entwickeln? Ich weiß es nicht. Und du musst es nicht wissen, wenn du auf webbasierte Anwendungen setzt. Niemand kann das brechen, ohne das Browsen zu brechen. Das Web ist vielleicht nicht der einzige Weg, Software zu liefern, aber es ist einer, der jetzt funktioniert und noch lange funktionieren wird. Webbasierte Anwendungen sind kostengünstig zu entwickeln und einfach für selbst das kleinste Startup zu liefern. Sie sind viel Arbeit und von einer besonders stressigen Art, aber das verbessert nur die Chancen für Startups.

Warum nicht?

E. B. White war amüsiert zu erfahren, dass viele elektrifizierte Zäune keinen Strom führen. Die Kühe lernen anscheinend, sich von ihnen fernzuhalten, und danach braucht man den Strom nicht mehr. „Erhebt euch, Kühe!“ schrieb er, „Nehmt eure Freiheit, während Despoten schnarchen!“

Wenn du ein Hacker bist, der daran gedacht hat, eines Tages ein Startup zu gründen, gibt es wahrscheinlich zwei Dinge, die dich davon abhalten. Eines ist, dass du nichts über das Geschäft weißt. Das andere ist, dass du Angst vor Konkurrenz hast. Keiner dieser Zäune hat Strom.

Es gibt nur zwei Dinge, die du über das Geschäft wissen musst: Baue etwas, das die Benutzer lieben, und verdiene mehr, als du ausgibst. Wenn du diese beiden Dinge richtig machst, wirst du vor den meisten Startups liegen. Den Rest kannst du herausfinden, während du vorankommst.

Du wirst vielleicht nicht sofort mehr verdienen, als du ausgibst, aber solange die Lücke schnell genug schließt, wirst du in Ordnung sein. Wenn du unterfinanziert startest, wird es zumindest eine Gewohnheit der Sparsamkeit fördern. Je weniger du ausgibst, desto einfacher ist es, mehr zu verdienen, als du ausgibst. Glücklicherweise kann es sehr günstig sein, eine webbasierte Anwendung zu starten. Wir haben mit weniger als 10.000 Dollar gestartet, und es wäre heute noch günstiger. Wir mussten Tausende für einen Server ausgeben und Tausende mehr für SSL. (Das einzige Unternehmen, das zu dieser Zeit SSL-Software verkaufte, war Netscape.) Jetzt kannst du einen viel leistungsstärkeren Server mieten, mit SSL inklusive, für weniger, als wir nur für Bandbreite bezahlt haben. Du könntest jetzt eine webbasierte Anwendung für weniger als die Kosten eines schicken Bürostuhls starten.

Was das Bauen von etwas angeht, das die Benutzer lieben, hier sind einige allgemeine Tipps. Fang an, etwas Sauberes und Einfaches zu machen, das du selbst verwenden würdest. Bring eine Version 1.0 schnell heraus, und verbessere dann die Software weiter, während du den Benutzern genau zuhörst. Der Kunde hat immer recht, aber verschiedene Kunden haben über verschiedene Dinge recht; die am wenigsten anspruchsvollen Benutzer zeigen dir, was du vereinfachen und klären musst, und die anspruchsvollsten sagen dir, welche Funktionen du hinzufügen musst. Das Beste, was Software sein kann, ist einfach, aber der Weg, dies zu tun, besteht darin, die Voreinstellungen richtig zu machen, nicht die Wahlmöglichkeiten der Benutzer einzuschränken. Werde nicht selbstzufrieden, wenn die Software deiner Wettbewerber schwach ist; der Maßstab, mit dem du deine Software vergleichen solltest, ist, was sie sein könnte, nicht was deine aktuellen Wettbewerber zufällig haben. Verwende deine Software selbst, die ganze Zeit. Viaweb sollte ein Online-Shop-Baukasten sein, aber wir haben es auch verwendet, um unsere eigene Seite zu erstellen. Höre nicht auf Marketing-Leute oder Designer oder Produktmanager, nur wegen ihrer Jobtitel. Wenn sie gute Ideen haben, nutze sie, aber es liegt an dir, zu entscheiden; Software muss von Hackern entworfen werden, die Design verstehen, nicht von Designern, die ein wenig über Software wissen. Wenn du Software nicht genauso gut entwerfen kannst, wie du sie implementierst, starte kein Startup.

Jetzt lass uns über Konkurrenz sprechen. Was du fürchtest, sind nicht vermutlich Gruppen von Hackern wie dir, sondern tatsächliche Unternehmen mit Büros und Geschäftsplänen und Verkäufern und so weiter, richtig? Nun, sie haben mehr Angst vor dir, als du vor ihnen hast, und sie haben recht. Es ist viel einfacher für ein paar Hacker herauszufinden, wie man Büroflächen mietet oder Verkäufer einstellt, als es für ein Unternehmen jeder Größe ist, Software zu schreiben. Ich war auf beiden Seiten, und ich weiß es. Als Viaweb von Yahoo gekauft wurde, fand ich mich plötzlich in einem großen Unternehmen wieder, und es war, als würde ich versuchen, durch hüfthohes Wasser zu rennen.

Ich möchte Yahoo nicht herabsetzen. Sie hatten einige gute Hacker, und das obere Management waren echte Macher. Für ein großes Unternehmen waren sie außergewöhnlich. Aber sie waren immer noch nur etwa ein Zehntel so produktiv wie ein kleines Startup. Kein großes Unternehmen kann viel besser abschneiden als das. Was an Microsoft beängstigend ist, ist, dass ein so großes Unternehmen überhaupt Software entwickeln kann. Sie sind wie ein Berg, der gehen kann.

Lass dich nicht einschüchtern. Du kannst genauso viel tun, was Microsoft nicht kann, wie sie es tun können, was du nicht kannst. Und niemand kann dich aufhalten. Du musst niemanden um Erlaubnis bitten, um webbasierte Anwendungen zu entwickeln. Du musst keine Lizenzvereinbarungen abschließen, oder Regalplatz in Einzelhandelsgeschäften bekommen, oder kriechen, um deine Anwendung mit dem Betriebssystem zu bündeln. Du kannst Software direkt an den Browser liefern, und niemand kann zwischen dir und potenziellen Benutzern stehen, ohne sie am Browsen des Webs zu hindern.

Du magst es vielleicht nicht glauben, aber ich verspreche dir, Microsoft hat Angst vor dir. Die selbstzufriedenen mittleren Manager vielleicht nicht, aber Bill hat es, denn er war einmal du, 1975, das letzte Mal, als eine neue Art der Softwarelieferung auftauchte.

Anmerkungen

[1] In dem Bewusstsein, dass ein Großteil des Geldes in den Dienstleistungen steckt, haben Unternehmen, die leichte Clients bauen, in der Regel versucht, die Hardware mit einem Online-Service zu kombinieren. Dieser Ansatz hat nicht gut funktioniert, teilweise weil man zwei verschiedene Arten von Unternehmen benötigt, um Unterhaltungselektronik zu bauen und einen Online-Service zu betreiben, und teilweise, weil die Benutzer die Idee hassen. Die Klinge zu verschenken und mit den Rasierern Geld zu verdienen, mag für Gillette funktionieren, aber ein Rasierer ist ein viel kleineres Engagement als ein Webterminal. Hersteller von Mobiltelefonen sind zufrieden, Hardware zu verkaufen, ohne zu versuchen, auch die Service-Einnahmen zu erfassen. Das sollte wahrscheinlich auch das Modell für Internet-Clients sein. Wenn jemand einfach eine hübsch aussehende kleine Box mit einem Webbrowser verkaufen würde, die man verwenden könnte, um sich über jeden ISP zu verbinden, würde jeder Technophobe im Land eine kaufen.

[2] Sicherheit hängt immer mehr davon ab, nichts falsch zu machen, als von jeder Designentscheidung, aber die Natur der serverbasierten Software wird die Entwickler dazu bringen, mehr darauf zu achten, nichts falsch zu machen. Ein Server zu kompromittieren könnte solchen Schaden anrichten, dass ASPs (die im Geschäft bleiben wollen) wahrscheinlich vorsichtig mit der Sicherheit umgehen.

[3] Im Jahr 1995, als wir Viaweb starteten, sollten Java-Applets die Technologie sein, die jeder verwenden würde, um serverbasierte Anwendungen zu entwickeln. Applets schienen uns eine altmodische Idee zu sein. Programme zum Ausführen auf dem Client herunterzuladen? Es ist einfacher, einfach den ganzen Weg zu gehen und die Programme auf dem Server auszuführen. Wir haben wenig Zeit mit Applets verschwendet, aber unzählige andere Startups müssen in diese Falle gelockt worden sein. Wenige können lebend entkommen sein, oder Microsoft hätte nicht damit durchkommen können, Java in der neuesten Version von Explorer fallen zu lassen.

[4] Dieser Punkt stammt von Trevor Blackwell, 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 Bugs behoben werden, und die Kosten können linearer sein, wenn alle Bugs schnell gefunden werden.“

[5] Die schwierigste Art von Bug, die zu finden ist, könnte eine Variante des Compound-Bugs sein, bei der ein Bug zufällig einen anderen kompensiert. Wenn man einen Bug behebt, wird der andere sichtbar. Aber es wird so erscheinen, als ob der Fix schuld ist, da das das letzte war, was man geändert hat.

[6] Innerhalb von Viaweb hatten wir einmal einen Wettbewerb, um das Schlimmste an unserer Software zu beschreiben. Zwei Kundenservicemitarbeiter teilten sich den ersten Preis mit Beiträgen, bei denen ich immer noch zittere, wenn ich daran denke. Wir haben beide Probleme sofort behoben.

[7] Robert Morris schrieb das Bestellsystem, das Käufer verwendeten, um Bestellungen aufzugeben. Trevor Blackwell schrieb den Bildgenerator und den Manager, den Händler verwendeten, um Bestellungen abzurufen, Statistiken anzusehen und Domainnamen usw. zu konfigurieren. Ich schrieb den Editor, den Händler verwendeten, um ihre Seiten zu erstellen. Das Bestellsystem und der Bildgenerator wurden in C und C++ geschrieben, der Manager hauptsächlich in Perl und der Editor in Lisp.

[8] Preisdiskriminierung ist so weit verbreitet (wie oft haben Sie gehört, dass ein Einzelhändler behauptet, seine Einkaufsmacht bedeute niedrigere Preise für Sie?), dass ich überrascht war zu erfahren, dass sie in den USA durch den Robinson-Patman Act von 1936 verboten ist. Dieses Gesetz scheint nicht energisch durchgesetzt zu werden.

[9] In No Logo sagt Naomi Klein, dass Bekleidungsmarken, die bei "urbanen Jugendlichen" beliebt sind, nicht zu sehr versuchen, Ladendiebstahl zu verhindern, weil die Ladendiebe in ihrem Zielmarkt auch die Modeführer sind.

[10] Unternehmen fragen sich oft, was sie auslagern sollen und was nicht. Eine mögliche Antwort: Lagern Sie jede Aufgabe aus, die nicht direkt dem Wettbewerbsdruck ausgesetzt ist, denn durch die Auslagerung wird sie diesem Wettbewerbsdruck ausgesetzt.

[11] Die beiden Typen 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 (hauptsächlich nachts) zusammen, um eine leistungsfähigere Version in 6502-Maschinensprache zu erstellen. Dan war zu dieser Zeit an der Harvard Business School und Bob hatte nominal einen Tagesjob, um Software zu schreiben. "Es gab kein großes Risiko, ein Geschäft zu machen", schrieb Bob, "Wenn es scheiterte, scheiterte es. Kein großes Ding."

[12] Es ist nicht ganz so einfach, wie ich es klingen lasse. Es dauerte schmerzhaft lange, bis sich Mundpropaganda entwickelte, und wir begannen nicht, viel Presseberichterstattung zu erhalten, bis wir eine PR-Agentur (zugegebenermaßen die beste in der Branche) für 16.000 Dollar pro Monat engagierten. Es war jedoch wahr, dass der einzige signifikante Kanal unsere eigene Website war.

[13] Wenn der Mac so großartig war, warum hat er dann verloren? Kosten, wieder einmal. Microsoft konzentrierte sich auf das Softwaregeschäft und ließ eine Flut von billigen Komponentenlieferanten auf Apple-Hardware los. Es half auch nicht, dass während einer kritischen Phase Anwälte übernahmen.

[14] Eine Sache, die webbasierte Anwendungen helfen würde und helfen würde, die nächste Generation von Software nicht von Microsoft überschattet zu sehen, wäre ein guter Open-Source-Browser. Mozilla ist Open Source, scheint aber darunter gelitten zu haben, so lange Unternehmenssoftware gewesen zu sein. Ein kleiner, schneller Browser, der aktiv gewartet wird, wäre an sich eine großartige Sache und würde wahrscheinlich auch Unternehmen ermutigen, kleine Webgeräte zu bauen.

Unter anderem würde ein ordentlicher Open-Source-Browser dazu führen, dass sich HTTP und HTML weiterentwickeln (wie z.B. Perl). Es würde webbasierte Anwendungen erheblich helfen, zwischen dem Auswählen eines Links und dem Folgen zu unterscheiden; alles, was Sie dazu benötigen würden, wäre eine triviale Verbesserung von HTTP, um mehrere URLs in einer Anfrage zuzulassen. Kaskadierende Menüs wären ebenfalls gut.

Wenn Sie die Welt verändern wollen, schreiben Sie ein neues Mosaic. Denken Sie, es ist zu spät? 1998 dachten viele Leute, es sei zu spät, um eine neue Suchmaschine zu starten, aber Google bewies ihnen das Gegenteil. Es gibt immer Platz für etwas Neues, wenn die aktuellen Optionen schlecht genug sind. Stellen Sie sicher, dass es zuerst auf allen kostenlosen Betriebssystemen funktioniert – neue Dinge beginnen mit ihren Nutzern.

[15] Trevor Blackwell, der wahrscheinlich mehr darüber aus persönlicher Erfahrung weiß als jeder andere, schreibt:

"Ich würde weiter gehen und sagen, dass serverbasierte Software so hart für die Programmierer ist, dass sie einen grundlegenden wirtschaftlichen Wandel von großen Unternehmen verursacht. Es erfordert die Art von Intensität und Hingabe von Programmierern, die sie nur bereit sind zu geben, wenn es ihr eigenes Unternehmen ist. Softwareunternehmen können qualifizierte Personen einstellen, um in einer nicht zu anspruchsvollen Umgebung zu arbeiten, und können unqualifizierte Personen einstellen, um Entbehrungen zu ertragen, aber sie können keine hochqualifizierten Personen einstellen, um sich abzuquälen. Da Kapital nicht mehr benötigt wird, haben große Unternehmen wenig, was sie auf den Tisch bringen können."

[16] In der ursprünglichen Version dieses Essays riet ich davon ab, Javascript zu verwenden. Das war 2001 ein guter Plan, aber Javascript funktioniert jetzt.

Danke an Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson und Dan Giffin für das Lesen von Entwürfen dieses Papiers; an Dan Bricklin und Bob Frankston für Informationen über VisiCalc; und erneut an Ken Anderson für die Einladung, bei BBN zu sprechen.

Sie finden dieses Essay und 14 weitere in Hackers & Painters.