Der andere Weg nach vorn | undefined

September 2001

(Dieser Artikel erklärt, warum ein Großteil der nächsten Softwaregeneration serverbasiert sein könnte, was das für Programmierer bedeutet und warum diese neue Art von Software eine großartige Gelegenheit 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. Damals lief die PR-Kampagne für den Börsengang von Netscape auf Hochtouren, und in der Presse wurde viel über den Online-Handel gesprochen. Zu dieser Zeit gab es vielleicht dreißig tatsächliche Geschäfte im Web, die alle von Hand erstellt wurden. Wenn es viele Online-Shops geben sollte, würde Software zu ihrer Erstellung benötigt, also beschlossen wir, etwas zu schreiben.

In der ersten Woche oder so beabsichtigten wir, dies zu einer gewöhnlichen Desktop-Anwendung zu machen. Dann kam uns eines Tages die Idee, die Software auf unserem Webserver laufen zu lassen und den Browser als Schnittstelle zu nutzen. Wir versuchten, die Software neu zu schreiben, damit sie über das Web funktioniert, 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 das für die Benutzer und auch für uns einfacher.

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

Als wir Viaweb gründeten, verstand kaum jemand, was wir meinten, wenn wir sagten, dass die Software auf dem Server läuft. Erst als Hotmail ein Jahr später gestartet wurde, begannen die Leute, es zu verstehen. Jetzt weiß jeder, dass dies ein valider 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. Selbst Microsoft, das am meisten zu verlieren hat, scheint die Unvermeidlichkeit zu sehen, einige Dinge vom Desktop zu verlagern. Wenn Software vom Desktop auf Server verlagert wird, bedeutet das eine ganz andere Welt für Entwickler. Dieser Artikel beschreibt die überraschenden Dinge, die wir als einige der ersten Besucher dieser neuen Welt gesehen haben. In dem Maße, in dem 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, werden wir uns wohl über die Unannehmlichkeiten wundern, die die Leute in Kauf nahmen, so wie wir uns heute über das wundern, was frühe 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 Gewinn, dass viele Leute, die keine Autoexperten waren, sie trotzdem haben wollten.

Computer befinden sich jetzt in dieser Phase. Wenn Sie einen Desktop-Computer besitzen, lernen Sie am Ende viel mehr über das, was darin vor sich geht, als Sie wissen wollten. 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 beunruhigt, als sie einen Brief von Apple erhielt, der ihr einen Rabatt auf eine neue Version des Betriebssystems anbot. Etwas stimmt nicht, wenn eine fünfundsechzigjährige Frau, die einen Computer für E-Mails und Buchführung nutzen möchte, über die Installation neuer Betriebssysteme nachdenken muss. Normale Benutzer sollten nicht einmal die Worte "Betriebssystem" kennen, geschweige denn "Gerätetreiber" oder "Patch".

Es gibt jetzt eine andere Möglichkeit, Software bereitzustellen, die Benutzer davon befreit, 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, billiger, 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 das unordentliche, sich ändernde Zeug wird irgendwo auf einem Server liegen und von den Leuten gepflegt, die gut darin sind. Und so werden Sie normalerweise keinen Computer an sich benötigen, um Software zu nutzen. Alles, was Sie brauchen, ist etwas mit einer Tastatur, einem Bildschirm und einem Webbrowser. Vielleicht hat es drahtlosen Internetzugang. Vielleicht ist es auch Ihr Handy. Was auch immer es ist, es wird Unterhaltungselektronik sein: etwas, das etwa 200 US-Dollar kostet und das die Leute hauptsächlich nach dem Aussehen des Gehäuses auswählen. Sie werden mehr für Internetdienste bezahlen, als Sie jetzt für Telefone bezahlen. [1]

Es wird etwa ein Zehntel einer Sekunde dauern, bis ein Klick zum Server und zurück gelangt, sodass Benutzer stark interaktiver Software wie Photoshop die Berechnungen weiterhin auf dem Desktop durchführen möchten. Aber wenn man sich die Dinge ansieht, für die die meisten Leute Computer verwenden, wäre eine Latenz von einer Zehntelsekunde kein Problem. Meine Mutter braucht 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 "Lieber tot als ungemütlich". Die meisten Leute werden die meiste Zeit die Wahl treffen, die am wenigsten Arbeit erfordert. Wenn sich webbasierte Software durchsetzt, dann deshalb, weil sie bequemer ist. Und es sieht so aus, als ob das sowohl für Benutzer als auch für Entwickler gilt.

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

Der dünne Keil hier war die webbasierte E-Mail. Millionen von Menschen erkennen jetzt, dass Sie auf E-Mail-Nachrichten zugreifen sollten, egal wo Sie sich befinden. Und wenn Sie Ihre E-Mails sehen können, warum nicht Ihren Kalender? Wenn Sie ein Dokument mit Ihren Kollegen besprechen können, warum können Sie es nicht bearbeiten? Warum sollten Ihre Daten auf einem Computer gefangen sein, der auf einem entfernten Schreibtisch steht?

Die gesamte Idee von "Ihrem Computer" verschwindet und wird durch "Ihre Daten" ersetzt. Sie sollten von jedem Computer auf Ihre Daten zugreifen können. 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önnen sie Telefone werden oder umgekehrt. Und da Clients kleiner werden, haben Sie einen weiteren Grund, Ihre Daten nicht darauf zu speichern: etwas, das Sie bei sich tragen, kann verloren gehen oder gestohlen werden. Wenn Sie Ihr PDA in ein Taxi legen, ist das wie ein Festplattencrash, nur dass Ihre Daten an jemand anderen weitergegeben werden, anstatt verdampft zu werden.

Bei rein webbasierter Software werden weder Ihre Daten noch die Anwendungen auf dem Client gespeichert. Sie müssen also nichts installieren, um sie zu nutzen. Und wenn keine Installation erforderlich ist, müssen Sie sich keine Sorgen machen, dass die Installation fehlschlägt. 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, wird es einfach und üblich sein, webbasierte Software auszuprobieren, bevor Sie sie "kaufen". Sie sollten erwarten, jede webbasierte Anwendung kostenlos testen zu können, indem Sie einfach die Website besuchen, auf der sie angeboten wird. Bei Viaweb war unsere gesamte Website wie ein großer Pfeil, der die Benutzer zum Testlauf führte.

Nachdem Sie die Demo ausprobiert haben, sollte die Anmeldung für den Dienst nichts weiter erfordern, als ein kurzes Formular auszufüllen (je kürzer, desto besser). Und das sollte die letzte Arbeit sein, die der Benutzer leisten muss. Mit webbasierter Software sollten Sie neue Versionen erhalten, ohne extra zu bezahlen, ohne Arbeit zu leisten oder möglicherweise sogar ohne es zu wissen.

Upgrades 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 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 Lösungen dafür.

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

Webbasierte Anwendungen können von mehreren Personen gleichzeitig genutzt werden. Dies ist ein offensichtlicher Vorteil für kollaborative Anwendungen, aber ich wette, Benutzer werden dies in den meisten Anwendungen wünschen, sobald sie erkennen, dass es möglich ist. Es wird oft nützlich sein, zwei Personen gleichzeitig an demselben Dokument arbeiten zu lassen. Viaweb erlaubte mehreren Benutzern, gleichzeitig an einer Website zu arbeiten, mehr weil das der richtige Weg war, die Software zu schreiben, als weil wir erwarteten, dass Benutzer das wollten, aber es stellte sich heraus, dass viele es taten.

Wenn Sie eine webbasierte Anwendung verwenden, sind Ihre Daten sicherer. Festplattenausfälle werden nicht der Vergangenheit angehören, aber Benutzer werden nichts mehr davon hören. Sie werden in Serverfarmen passieren. Und Unternehmen, die webbasierte Anwendungen anbieten, werden tatsächlich Backups durchführen – nicht nur, weil sie echte Systemadministratoren haben, die sich um solche Dinge kümmern, sondern weil ein ASP, der die Daten von Benutzern verliert, in große, große Schwierigkeiten geraten würde. Wenn Leute ihre eigenen Daten bei einem Festplattencrash verlieren, können sie nicht so wütend werden, weil sie nur sich selbst wütend 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 Möglichkeiten, Viren auszuführen, und keine lokalen Daten, die beschädigt werden könnten. Und ein Programm, das die Server selbst angreift, würde sie sehr gut verteidigt vorfinden. [2]

Für Benutzer wird webbasierte Software weniger stressig sein. Ich denke, wenn man sich den durchschnittlichen Windows-Benutzer ansieht, würde man einen riesigen und ziemlich unerschlossenen Wunsch nach Software finden, die diese Beschreibung erfüllt. Entfesselt 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 einer einzigen großen Binärdatei. Und so ist das Entwerfen webbasierter Software wie das Entwerfen einer Stadt anstatt eines Gebäudes: Neben Gebäuden braucht man Straßen, Straßenschilder, Versorgungsunternehmen, Polizei und Feuerwehr und Pläne für Wachstum und verschiedene Arten von Katastrophen.

Bei Viaweb umfasste die Software ziemlich große Anwendungen, mit denen Benutzer direkt interagierten, 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 ausgeführt wurden, um Statistiken zu kompilieren oder Indizes für Suchen zu erstellen, Programme, die wir explizit ausgeführt haben, um Ressourcen zu bereinigen oder Daten zu verschieben oder wiederherzustellen, Programme, die sich als Benutzer ausgaben (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 Zifferblättern steuerte, die Echtzeit-Serverstatistiken anzeigten (ein Hit bei 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 zum Verschieben von Geschäften auf neue Server im ganzen Land, ohne sie herunterzufahren, nachdem wir von Yahoo gekauft wurden. Programme riefen uns an, sendeten Faxe und E-Mails an Benutzer, führten Transaktionen mit Kreditkartenprozessoren durch und kommunizierten miteinander über Sockets, Pipes, HTTP-Anfragen, SSH, UDP-Pakete, Shared Memory und Dateien. Ein Teil von Viaweb bestand sogar aus dem Fehlen von Programmen, da einer der Schlüssel zur Unix-Sicherheit darin besteht, keine unnötigen Dienstprogramme auszuführen, die Leute verwenden könnten, um in Ihre Server einzubrechen.

Es endete nicht mit der Software. Wir haben viel Zeit mit der Überlegung von Serverkonfigurationen verbracht. Wir haben die Server selbst aus Komponenten gebaut – teilweise, um Geld zu sparen, und teilweise, um genau das zu bekommen, was wir wollten. Wir mussten überlegen, ob unser Upstream-ISP schnelle genug Verbindungen zu allen Backbones hatte. Wir haben seriell RAID-Lieferanten gedatet.

Aber Hardware ist nicht nur etwas, worüber man sich Sorgen machen muss. Wenn man sie kontrolliert, kann man mehr für die Benutzer tun. Mit einer Desktop-Anwendung können Sie bestimmte Mindesthardware angeben, aber Sie können nicht mehr hinzufügen. Wenn Sie die Server verwalten, können Sie mit einem Schritt allen Ihren Benutzern ermöglichen, Leute anzurufen, Faxe zu senden, Befehle per Telefon zu senden oder Kreditkarten zu verarbeiten usw., indem Sie einfach die entsprechende Hardware installieren. Wir suchten immer nach neuen Wegen, um mit Hardware Funktionen 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 sein wird, kann sie in beliebig vielen 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 – also C und C++. Und so wurden diese Sprachen (insbesondere bei nicht-technischen Leuten wie Managern und VCs) als Sprachen für die "ernsthafte" Softwareentwicklung angesehen. Aber das war nur ein Artefakt der Art und Weise, wie Desktop-Software ausgeliefert werden musste. Für serverbasierte Software können Sie jede gewünschte 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, da Sie das gesamte System kontrollieren, bis hin zur Hardware. Verschiedene Sprachen eignen sich für verschiedene Aufgaben. Sie können diejenige verwenden, die für jede am besten geeignet ist. Und wenn Sie Konkurrenten haben, bedeutet "können" "müssen" (darauf werden wir später zurückkommen), denn wenn Sie diese Möglichkeit nicht nutzen, werden Ihre Konkurrenten es tun.

Die meisten unserer Konkurrenten verwendeten C und C++, und das machte ihre Software sichtbar schlechter, weil sie (unter anderem) keine Möglichkeit hatten, die Zustandsunabhängigkeit von CGI-Skripten zu umgehen. Wenn Sie etwas ändern wollten, mussten alle Änderungen auf einer Seite erfolgen, mit einem Update-Button unten. Wie ich anderswo geschrieben habe, konnten wir mit Lisp, das viele immer noch als Forschungssprache betrachten, den Viaweb-Editor eher wie Desktop-Software verhalten lassen.

Releases

Eine der wichtigsten Änderungen in dieser neuen Welt ist die Art und Weise, wie Sie Releases durchführen. In der Desktop-Softwarebranche ist die Durchführung eines Releases ein riesiges Trauma, bei dem das gesamte Unternehmen schwitzt und sich anstrengt, um ein einziges, riesiges Stück Code herauszubringen. 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 in 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 Releases pro Jahr durchführen. Bei Viaweb führten wir oft drei bis fünf Releases pro Tag durch.

Wenn Sie auf dieses neue Modell umsteigen, erkennen Sie, wie sehr die Softwareentwicklung von der Art und Weise beeinflusst wird, wie sie veröffentlicht wird. Viele der schlimmsten Probleme, die Sie in der Desktop-Softwarebranche sehen, sind auf die katastrophale Natur von Releases zurückzuführen.

Wenn Sie nur eine neue Version pro Jahr veröffentlichen, neigen Sie dazu, Fehler im großen Stil zu behandeln. Einige Zeit vor dem Veröffentlichungsdatum stellen Sie eine neue Version zusammen, bei der die Hälfte des Codes herausgerissen und ersetzt wurde, was unzählige Fehler einführt. Dann tritt eine Gruppe von QA-Leuten ein und beginnt, sie zu zählen, und die Programmierer arbeiten die Liste ab und beheben sie. Sie erreichen im Allgemeinen nicht das Ende der Liste, und tatsächlich ist niemand sicher, wo das Ende ist. Es ist, als würde man Bauschutt aus einem Teich fischen. Man weiß nie wirklich, was in der Software vor sich geht. Im besten Fall erhalten Sie eine statistische Korrektheit.

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

Desktop-Software fördert eine gewisse Fatalismus gegenüber Fehlern. Sie wissen, dass Sie etwas mit Fehlern versenden, 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 fehlerhaft sind. Apple hat dies Anfang dieses Jahres getan. Sie standen unter dem Druck, ihr neues Betriebssystem zu veröffentlichen, dessen Veröffentlichungsdatum sich bereits viermal verschoben hatte, aber einige der Software (Unterstützung für CDs und DVDs) war noch nicht fertig. Die Lösung? Sie veröffentlichten das Betriebssystem ohne die unfertigen Teile, und die Benutzer mussten sie später installieren.

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

Der Branchenveteran denkt vielleicht: Es ist eine schön klingende Idee zu sagen, dass man Software nie veröffentlichen muss, bevor sie funktioniert, aber was passiert, wenn man versprochen hat, eine neue Version seiner Software bis zu einem bestimmten Datum zu liefern? Bei webbasierter Software würden Sie ein solches Versprechen nicht machen, da es keine Versionen gibt. Ihre Software ändert sich allmählich und kontinuierlich. Einige Änderungen mögen größer sein als andere, aber die Idee von Versionen passt einfach nicht natürlich zu webbasierter Software.

Wenn sich jemand an Viaweb erinnert, mag das seltsam klingen, denn wir haben immer neue Versionen angekündigt. Das geschah ausschließlich zu PR-Zwecken. Die Fachpresse, so lernten wir, denkt in Versionsnummern. Sie geben Ihnen eine große Berichterstattung für ein großes Release, was eine neue erste Ziffer in der Versionsnummer bedeutet, und im Allgemeinen höchstens einen Absatz für ein Punkt-Release, was eine neue Ziffer nach dem Dezimalpunkt bedeutet.

Einige unserer Konkurrenten boten Desktop-Software an und hatten tatsächlich Versionsnummern. Und für diese Releases, die alleinige Tatsache, die uns als Beweis für ihre Rückständigkeit erschien, erhielten sie jede Menge Publicity. Wir wollten das nicht verpassen, also begannen wir auch, unseren Software Versionsnummern zu geben. Wenn wir etwas Publicity wollten, machten wir eine Liste aller Funktionen, die wir seit dem letzten "Release" hinzugefügt hatten, klebten eine neue Versionsnummer auf die Software und gaben eine Pressemitteilung heraus, dass die neue Version sofort verfügbar sei. Erstaunlicherweise hat uns nie jemand darauf angesprochen.

Bis wir gekauft wurden, hatten wir das dreimal gemacht, also waren wir bei Version 4. Version 4.1, wenn ich mich richtig erinnere. Nachdem Viaweb zu Yahoo Store wurde, gab es keinen so verzweifelten Bedarf an Publicity mehr, sodass die gesamte Idee von Versionsnummern leise fallen gelassen wurde, obwohl die Software sich weiterentwickelte.

Bugs

Der andere große technische Vorteil von 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 versuchen zu erraten, was vor sich geht, wie bei Desktop-Software: Sie sollten den Fehler reproduzieren können, während sie am Telefon mit Ihnen sind. Sie wissen vielleicht sogar schon davon, wenn Sie Code zur Fehlererkennung in Ihre Anwendung integriert 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 werden manchmal beschuldigt, die Benutzer ihre Software debuggen zu lassen. Und genau das befürworte ich. Für webbasierte Software ist das tatsächlich ein guter Plan, weil die Fehler weniger und transient sind. Wenn Sie Software schrittweise veröffentlichen, erhalten Sie von Anfang an weitaus 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 gleichzeitig, um uns mit einem formalen Bug-Tracking-System zu befassen.

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

Frische Fehler zu beheben ist einfacher als alte zu beheben. Es ist normalerweise ziemlich schnell, einen Fehler in Code zu finden, den Sie gerade geschrieben haben. Wenn er auftritt, wissen Sie oft, was falsch ist, bevor Sie sich den Quellcode ansehen, weil Sie sich bereits unbewusst darum gesorgt haben. Einen Fehler in etwas zu beheben, das Sie vor sechs Monaten geschrieben haben (der Durchschnittsfall, wenn Sie einmal im Jahr veröffentlichen), ist viel mehr Arbeit. Und da Sie den Code nicht so gut verstehen, werden Sie ihn wahrscheinlich auf hässliche Weise beheben oder sogar mehr Fehler einführen. [4]

Wenn Sie Fehler frühzeitig erkennen, erhalten Sie auch weniger Compound-Fehler. Compound-Fehler sind zwei getrennte Fehler, die interagieren: Sie stolpern die Treppe hinunter, und wenn Sie nach dem Handlauf greifen, fällt er Ihnen aus der Hand. In der Software ist diese Art von Fehler am schwersten zu finden und hat auch tendenziell die schlimmsten Folgen. [5] Der traditionelle Ansatz "alles kaputt machen und dann die Fehler herausfiltern" liefert naturgemäß viele Compound-Fehler. Und Software, die in einer Reihe von kleinen Änderungen veröffentlicht wird, neigt naturgemäß nicht dazu. Die Böden werden ständig von losen Gegenständen gefegt, die sich später in etwas verfangen könnten.

Es hilft, wenn Sie eine Technik namens funktionale Programmierung verwenden. Funktionale Programmierung bedeutet, Seiteneffekte zu vermeiden. Es ist etwas, das man eher in Forschungsarbeiten als in kommerzieller Software findet, aber für webbasierte Anwendungen ist es wirklich nützlich. Es ist schwierig, ganze Programme als rein funktionale Codes zu schreiben, aber man kann wesentliche Teile auf diese Weise schreiben. Das macht diese Teile Ihrer Software leichter testbar, da sie keinen Zustand haben, und das ist in einer Situation, in der Sie ständig kleine Modifikationen vornehmen und testen, sehr praktisch. Ich habe einen Großteil des Editors von Viaweb in diesem Stil geschrieben, und wir haben unsere Skriptsprache, RTML, zu einer rein funktionalen Sprache gemacht.

Leute aus der Desktop-Softwarebranche werden das schwer glauben können, aber bei Viaweb wurden Fehler fast zu einem Spiel. Da die meisten veröffentlichten Fehler Grenzfälle betrafen, waren die Benutzer, die sie antrafen, wahrscheinlich fortgeschrittene Benutzer, die die Grenzen ausreizten. Fortgeschrittene Benutzer sind fehlerverzeihender, besonders da Sie sie wahrscheinlich im Zuge der Hinzufügung einer von ihnen gewünschten Funktion eingeführt haben. Tatsächlich waren fortgeschrittene Benutzer oft stolz darauf, einen Fehler zu fangen, da Fehler selten waren und man anspruchsvolle Dinge tun musste, um sie zu sehen. Sie riefen den Support eher im Geiste des Triumphs als der Wut an, als hätten sie Punkte gegen uns erzielt.

Support

Wenn Sie Fehler reproduzieren können, ändert sich Ihr Ansatz beim Kundensupport. Bei den meisten Softwareunternehmen wird der Support als Mittel angeboten, um Kunden ein besseres Gefühl zu geben. Sie rufen Sie entweder wegen eines bekannten Fehlers an oder sie tun 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 lästige Pflicht zu betrachten, die Sie von Ihren Entwicklern so weit wie möglich isolieren möchten.

So funktionierte 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 es sofort wissen, damit wir den Fehler reproduzieren und eine Korrektur veröffentlichen konnten.

So standen bei Viaweb die Entwickler immer in engem Kontakt mit dem Support. Die Kundensupport-Mitarbeiter waren etwa zehn Meter von den Programmierern entfernt und wussten, dass sie jederzeit etwas mit einem Bericht über einen echten Fehler unterbrechen konnten. Wir verließen ein Vorstandstreffen, um einen schwerwiegenden Fehler zu beheben.

Unser Ansatz beim Support machte alle glücklicher. Die Kunden waren begeistert. Stellen Sie sich vor, wie es sich anfühlt, eine Support-Hotline anzurufen und als jemand behandelt zu werden, der wichtige Nachrichten überbringt. Die Kundensupport-Mitarbeiter mochten es, weil sie den Benutzern helfen konnten, anstatt Skripte für sie vorzulesen. Und die Programmierer mochten es, weil sie Fehler reproduzieren konnten, anstatt nur vage Berichte aus zweiter Hand darüber zu hören.

Unsere Politik, Fehler im laufenden Betrieb zu beheben, veränderte die Beziehung zwischen Kundensupport-Mitarbeitern und Hackern. Bei den meisten Softwareunternehmen sind Support-Mitarbeiter unterbezahlte menschliche Schutzschilde, und Hacker sind kleine Kopien von Gottvater, Schöpfer der Welt. Unabhängig vom Verfahren zur Meldung von Fehlern ist es wahrscheinlich unidirektional: Support-Mitarbeiter, die von Fehlern 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 sehr anders. Innerhalb einer Minute, nachdem sie von einem Fehler eines Kunden gehört hatten, konnten die Support-Mitarbeiter neben einem Programmierer stehen und ihn sagen hören: "Scheiße, du hast Recht, es ist ein Fehler." Es freute die Support-Mitarbeiter, dieses "Du hast Recht" von den Hackern zu hören. Sie brachten uns Fehler mit derselben erwartungsvollen Miene wie eine Katze, die Ihnen eine gerade getötete Maus bringt. Es machte sie auch vorsichtiger bei der Beurteilung der Schwere eines Fehlers, weil nun ihre Ehre auf dem Spiel stand.

Nachdem wir von Yahoo gekauft wurden, wurden die Kundensupport-Mitarbeiter weit weg von den Programmierern verlegt. Erst da erkannten wir, dass sie effektiv QA und zu einem gewissen Grad auch Marketing waren. Zusätzlich zur Fehlererkennung waren sie die Hüter des Wissens über vage, fehlerä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 hatten immer Recht.

Moral

Die Möglichkeit, Software sofort zu veröffentlichen, ist ein großer Motivator. Oft dachte ich auf dem Weg zur Arbeit über eine Änderung nach, die ich an der Software vornehmen wollte, und erledigte sie noch am selben Tag. Das funktionierte auch für größere Funktionen. Selbst wenn etwas zwei Wochen zum Schreiben brauchte (wenige Projekte dauerten 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 Veröffentlichung hätte warten müssen, hätte ich die meisten dieser Ideen zumindest für eine Weile auf Eis gelegt. Aber Ideen führen zu mehr Ideen. Haben Sie jemals bemerkt, dass, wenn Sie sich hinsetzen, um etwas zu schreiben, die Hälfte der Ideen, die darin landen, solche sind, die Sie beim Schreiben gedacht haben? Dasselbe passiert mit Software. Die Arbeit an der Implementierung einer Idee bringt Ihnen mehr Ideen. Das Aufschieben einer Idee kostet Sie also nicht nur die Verzögerung bei ihrer Umsetzung, sondern auch all die Ideen, zu denen die Umsetzung geführt hätte. Tatsächlich hemmt das Aufschieben einer Idee wahrscheinlich sogar neue Ideen: Wenn Sie anfangen, über eine neue Funktion nachzudenken, sehen Sie das Regal und denken "aber ich habe schon viele neue Dinge, die ich für die nächste Veröffentlichung tun möchte."

Was große Unternehmen stattdessen tun, ist, sie zu planen. Bei Viaweb hatten wir manchmal deswegen Probleme. Investoren und Analysten fragten uns, was wir für die Zukunft geplant hätten. Die ehrliche Antwort wäre gewesen: Wir hatten keine Pläne. Wir hatten allgemeine Vorstellungen über Dinge, die wir verbessern wollten, aber wenn wir wüssten, wie, hätten wir es schon getan. Was würden wir in den nächsten sechs Monaten tun? Was auch immer den größten Gewinn versprach. Ich weiß nicht, ob ich diese Antwort jemals gewagt habe, aber das war die Wahrheit. Pläne sind nur ein anderes Wort für Ideen auf dem Regal. Wenn wir gute Ideen hatten, haben wir sie umgesetzt.

Bei Viaweb, wie in vielen Softwareunternehmen, hatte der meiste Code einen bestimmten Besitzer. Aber wenn man etwas besaß, besaß man es wirklich: Niemand außer dem Besitzer eines Softwareteils musste eine Veröffentlichung genehmigen (oder sogar davon wissen). Es gab keinen Schutz vor Fehlern außer der Angst, vor seinen Kollegen wie ein Idiot dazustehen, und das war mehr als genug. Ich habe vielleicht den Eindruck erweckt, dass wir einfach unbedacht vorwärtsgegangen sind und Code geschrieben haben. Wir sind schnell vorgegangen, aber wir haben sehr sorgfältig nachgedacht, bevor wir Software auf diese Server hochgeladen haben. Und Aufmerksamkeit ist wichtiger für die Zuverlässigkeit als langsames Vorgehen. Weil er genau aufpasst, kann ein Marineflieger ein 40.000 Pfund schweres Flugzeug mit 140 Meilen pro Stunde auf einem schwankenden Flugzeugträgerdeck bei Nacht sicherer landen als der durchschnittliche Teenager ein 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 weitaus besser als für ein großes Unternehmen mittelmäßiger, bei denen schlechte Ideen von Komitees und nicht von den Personen, die sie hatten, abgefangen werden.

Brooks im umgekehrten Fall

Glücklicherweise erfordert webbasierte Software weniger Programmierer. Ich habe einmal für ein mittelgroßes Desktop-Softwareunternehmen gearbeitet, das insgesamt über 100 Mitarbeiter in der Entwicklung hatte. Nur 13 davon waren in der Produktentwicklung tätig. Alle anderen arbeiteten an Releases, Ports und so weiter. Mit webbasierter Software benötigen Sie (höchstens) nur die 13 Leute, da es keine Releases, Ports und so weiter gibt.

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

Wenn Sie Software mit weniger Programmierern schreiben können, spart Ihnen das mehr als nur Geld. Wie Fred Brooks in The Mythical Man-Month feststellte, verlangsamt die Hinzufügung von Personen zu einem Projekt tendenziell dessen Fortschritt. 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 mit Besprechungen zur Aushandlung der Zusammenarbeit ihrer Software, und desto mehr Fehler erhalten sie durch unvorhergesehene Interaktionen. Glücklicherweise funktioniert dieser Prozess auch umgekehrt: Je kleiner die Gruppen werden, desto effizienter wird die Softwareentwicklung exponentiell. Ich kann mich nicht erinnern, dass die Programmierer bei Viaweb jemals eine tatsächliche Besprechung hatten. Wir hatten nie mehr zu sagen, als wir auf dem Weg zum Mittagessen sagen konnten.

Wenn es hier einen Nachteil gibt, dann ist es, 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 können dies nur die Personen tun, die die Software geschrieben haben. Bei Viaweb hatte unser System so viele Komponenten und änderte sich so häufig, dass es keine eindeutige Grenze zwischen Software und Infrastruktur gab. Eine solche Grenze willkürlich zu erklären, hätte unsere Designentscheidungen eingeschränkt. Und so, obwohl wir 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 nur war, sich um die Server zu kümmern, geschah es nie.

Ich glaube nicht, dass es anders sein könnte, solange Sie das Produkt noch aktiv entwickeln. Webbasierte Software wird niemals etwas sein, das Sie schreiben, einchecken und nach Hause gehen. Es ist ein lebendiges Ding, das gerade jetzt auf Ihren 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 Ihrem Code Daten auf der Festplatte beschädigt, müssen Sie ihn beheben. Und so weiter. Wir stellten fest, dass Sie die Server nicht jede Minute überwachen müssen (nach dem ersten Jahr oder so), aber Sie möchten definitiv die Dinge im Auge behalten, die Sie kürzlich geändert haben. Sie veröffentlichen keinen Code spät in der Nacht und gehen dann nach Hause.

Benutzer beobachten

Bei serverbasierter Software sind Sie näher an Ihrem Code. Sie können auch näher an Ihren Benutzern sein. Intuit ist dafür bekannt, sich Kunden in Einzelhandelsgeschäften vorzustellen und sie nach Hause zu begleiten. Wenn Sie jemals jemanden beim ersten Mal Ihre Software benutzen gesehen haben, wissen Sie, welche Überraschungen sie erwartet haben müssen.

Software sollte das tun, was Benutzer denken, dass sie es tun wird. Aber Sie können keine Ahnung haben, was Benutzer denken werden, glauben Sie mir, 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 betrachten werden, weil Sie die Privatsphäre der Benutzer nicht verletzen wollen, aber selbst die allgemeinste statistische Stichprobe kann 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 tatsächliche 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 sollen: Wir haben den Viaweb-Editor schließlich so weit gebracht, dass er speichergebunden und nicht CPU-gebunden war, und da wir nichts tun konnten, um die Größe der Benutzerdaten zu verringern (nun ja, nichts Einfaches), wussten wir, dass wir genauso gut dort aufhören könnten.

Effizienz ist bei serverbasierter Software wichtig, weil Sie für die Hardware bezahlen. Die Anzahl der Benutzer, die Sie pro Server unterstützen können, ist der Nenner Ihrer Kapitalkosten, sodass Sie, wenn Sie Ihre Software sehr effizient gestalten können, Konkurrenten unterbieten und trotzdem einen Gewinn erzielen können. Bei Viaweb haben wir die Kapitalkosten pro Benutzer auf etwa 5 US-Dollar gesenkt. Es wäre jetzt weniger, wahrscheinlich weniger als die Kosten für den Versand der ersten Monatsrechnung. Hardware ist jetzt kostenlos, wenn Ihre Software einigermaßen effizient ist.

Das Beobachten von Benutzern kann Sie sowohl bei der Gestaltung als auch bei der Optimierung leiten. Viaweb hatte eine Skriptsprache namens RTML, die es fortgeschrittenen Benutzern ermöglichte, ihre eigenen Seitenstile zu definieren. Wir fanden, dass RTML zu einer Art Vorschlagsbox wurde, weil Benutzer sie nur dann verwendeten, wenn die vordefinierten Seitenstile nicht das tun konnten, was sie wollten. Ursprünglich setzte der Editor Button-Leisten über die Seite, aber nachdem eine Reihe von Benutzern RTML verwendet hatte, um Buttons links anzubringen, machten wir dies zu einer Option (tatsächlich zur Standardeinstellung) in den vordefinierten Seitenstilen.

Schließlich können Sie durch die Beobachtung von Benutzern oft erkennen, wann sie in Schwierigkeiten sind. Und da der Kunde immer Recht hat, ist das ein Zeichen für etwas, das Sie beheben müssen. Bei Viaweb war der Schlüssel zur Gewinnung von Benutzern der Online-Testlauf. Es war nicht nur eine Reihe von Folien, die von Marketingleuten erstellt wurden. In unserem Testlauf nutzten die Benutzer tatsächlich die Software. Es dauerte etwa fünf Minuten, und am Ende hatten sie einen echten, funktionierenden Shop erstellt.

Der Testlauf war die Art und Weise, wie wir fast alle unsere neuen Benutzer gewonnen haben. Ich denke, das wird bei den meisten webbasierten Anwendungen genauso sein. Wenn Benutzer einen Testlauf erfolgreich absolvieren, werden sie das Produkt mögen. Wenn sie verwirrt oder gelangweilt sind, werden sie es nicht. Alles, was wir tun konnten, um mehr Leute durch den Testlauf zu bringen, würde unsere Wachstumsrate erhöhen.

Ich habe die Klickpfade von Leuten studiert, die den Testlauf machten, und festgestellt, dass sie an einem bestimmten Punkt 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 fügte ich an dieser Stelle eine Nachricht hinzu, die den Benutzern sagte, dass sie fast fertig seien, und sie daran erinnerte, nicht auf die Zurück-Schaltfläche zu klicken. Eine weitere großartige Sache an webbasierter Software ist, dass Sie sofortiges Feedback von Änderungen erhalten: Die Anzahl der Personen, die den Testlauf abschließen, stieg sofort von 60 % auf 90 %. Und da die Anzahl der neuen Benutzer eine Funktion der Anzahl der abgeschlossenen Testläufe 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. Zuerst erschien dies als eine sehr zynische Aussage. Aber später erkannte ich, dass es die Realität widerspiegelt: Softwareentwicklung ist ein fortlaufender Prozess. Ich denke, es ist sauberer, wenn Sie offen Abonnementgebühren verlangen, anstatt die Leute zu zwingen, neue Versionen zu kaufen und zu installieren, damit sie Sie weiterhin bezahlen.

Das Hosten von Anwendungen ist ein Bereich, in dem Unternehmen eine Rolle spielen werden, die wahrscheinlich nicht von Freeware ausgefüllt wird. Das Hosten von Anwendungen ist viel Stress und hat echte Kosten. Niemand wird das kostenlos tun wollen.

Für Unternehmen sind webbasierte Anwendungen eine ideale Einnahmequelle. Anstatt jedes Quartal mit einer leeren Tafel zu beginnen, haben Sie einen wiederkehrenden Umsatzstrom. Da sich Ihre Software allmählich weiterentwickelt, müssen Sie sich keine Sorgen machen, dass ein neues Modell floppt; es muss nie ein neues Modell an sich geben, und wenn Sie etwas an der Software ändern, das den Benutzern nicht gefällt, werden Sie es sofort wissen. Sie haben keine Probleme mit uneinbringlichen Rechnungen; wenn jemand nicht bezahlt, können Sie den Dienst einfach abschalten. Und es gibt keine Möglichkeit der Piraterie.

Dieser letzte "Vorteil" könnte sich als Problem erweisen. Ein gewisses Maß an Piraterie ist für Softwareunternehmen von Vorteil. Wenn ein Benutzer Ihre Software zu keinem Preis gekauft hätte, haben Sie nichts verloren, wenn er eine raubkopierte Kopie verwendet. Tatsächlich gewinnen Sie, weil er ein weiterer Benutzer ist, der hilft, Ihre Software zum Standard zu machen – oder der später eine Kopie kauft, wenn er die High School abschließt.

Wenn sie können, tun Unternehmen gerne etwas namens Preisdiskriminierung, was bedeutet, jedem Kunden so viel wie möglich in Rechnung zu stellen. [8] Software eignet sich besonders gut für Preisdiskriminierung, da die Grenzkosten nahe Null liegen. Deshalb kostet die Ausführung von Software auf Suns mehr als auf Intel-Boxen: 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 Preisdiskriminierung. Ich denke, Softwareunternehmen verstehen das und drücken bei bestimmten Arten von Piraterie ein Auge zu. [9] Mit serverbasierter Software müssen sie eine andere Lösung finden.

Webbasierte Software verkauft sich gut, insbesondere im Vergleich zu Desktop-Software, weil sie einfach zu kaufen ist. Man könnte meinen, dass Leute entscheiden, etwas zu kaufen, und es dann kaufen, als zwei getrennte Schritte. Das dachte ich vor Viaweb, soweit ich überhaupt über die Frage nachgedacht habe. Tatsächlich kann der zweite Schritt in den ersten zurückwirken: Wenn etwas schwer zu kaufen ist, werden die Leute ihre Meinung ändern, ob sie es wollten. Und umgekehrt: Sie werden mehr verkaufen, wenn es einfach zu kaufen ist. Ich kaufe mehr Bücher, weil es Amazon gibt. Webbasierte Software ist einfach eines der einfachsten Dinge der Welt zu kaufen, besonders wenn Sie gerade eine Online-Demo gemacht haben. Benutzer sollten nicht viel mehr tun müssen, als eine Kreditkartennummer einzugeben. (Tun Sie sie mehr auf eigene Gefahr.)

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

Mehrere unserer Konkurrenten haben sich auf diese Weise ins eigene Fleisch geschnitten – meistens, glaube ich, weil sie von Anzugträgern überrannt wurden, die von diesem riesigen potenziellen Kanal begeistert waren und nicht erkannten, dass dies das Produkt ruinieren würde, das sie über diesen Kanal verkaufen wollten. Der Verkauf webbasierter Software über ISPs ist wie der Verkauf von Sushi über Verkaufsautomaten.

Kunden

Wer werden die Kunden sein? Bei Viaweb waren es anfangs Einzelpersonen und kleinere Unternehmen, und ich denke, das wird die Regel bei webbasierten Anwendungen sein. Dies sind die Benutzer, die bereit sind, neue Dinge auszuprobieren, teilweise weil sie flexibler sind und teilweise, weil sie die niedrigeren Kosten neuer Technologien wünschen.

Webbasierte Anwendungen werden oft das Beste für große Unternehmen sein (obwohl sie das nur langsam erkennen 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 aus Zugriff auf das System.

Das Argument gegen diesen Ansatz dreht sich normalerweise um Sicherheit: Wenn der Zugriff für Mitarbeiter einfacher ist, dann auch für böswillige Akteure. Einige größere Händler zögerten, Viaweb zu nutzen, weil sie dachten, die Kreditkarteninformationen ihrer Kunden wären auf ihren eigenen Servern sicherer. Es war nicht einfach, diesen Punkt diplomatisch zu machen, aber tatsächlich waren die Daten fast sicher in unseren Händen 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? Nicht nur, dass wir bessere Leute hatten, die sich um die Sicherheit kümmerten, wir kümmerten uns auch mehr darum. Wenn jemand in die Server des Bekleidungshändlers einbrach, 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 einbrach, könnte es Tausende von Händlern betreffen, würde wahrscheinlich als Nachricht auf CNet landen und uns aus dem Geschäft drängen.

Wenn Sie Ihr Geld sicher aufbewahren wollen, bewahren Sie es unter Ihrer Matratze zu Hause auf oder legen Sie es bei einer Bank ab? Dieses Argument gilt für jeden Aspekt der Serververwaltung: nicht nur für die Sicherheit, sondern auch für die Verfügbarkeit, Bandbreite, Lastmanagement, Backups usw. Unsere Existenz hing davon ab, diese Dinge richtig zu machen. Serverprobleme waren für uns das große No-Go, wie ein gefährliches Spielzeug für einen Spielzeughersteller oder ein Salmonellen-Ausbruch für einen Lebensmittelverarbeiter.

Ein großes Unternehmen, das webbasierte Anwendungen nutzt, lagert damit zu einem gewissen Grad die IT aus. So drastisch es auch klingen mag, ich denke, das ist im Allgemeinen eine gute Idee. Unternehmen erhalten wahrscheinlich einen besseren Service auf diese Weise, als sie es von internen Systemadministratoren erhalten würden. Systemadministratoren können mürrisch und unempfänglich werden, weil sie keinem direkten Wettbewerbsdruck ausgesetzt sind: Ein Verkäufer muss sich mit Kunden auseinandersetzen, und ein Entwickler muss sich mit der Software von Konkurrenten auseinandersetzen, aber ein Systemadministrator hat, wie ein alter Junggeselle, wenige externe Kräfte, die ihn in Schach halten. [10] Bei Viaweb hatten wir reichlich externe Kräfte, die uns in Schach hielten. Die Leute, die uns anriefen, waren Kunden, nicht nur Kollegen. Wenn ein Server klemmte, sprangen wir ein; allein der Gedanke daran gibt mir Jahre später einen Adrenalinschub.

Daher werden webbasierte Anwendungen auch für große Unternehmen im Allgemeinen die richtige Antwort sein. Sie werden die letzten sein, die das erkennen, genau wie bei Desktop-Computern. Und teilweise aus demselben Grund: Es wird sich sehr lohnen, große Unternehmen davon zu überzeugen, dass sie etwas Teureres brauchen.

Es gibt immer eine Tendenz für wohlhabende Kunden, teure Lösungen zu kaufen, selbst wenn billigere Lösungen besser sind, weil die Anbieter teurerer Lösungen mehr ausgeben können, um sie zu verkaufen. Bei Viaweb hatten wir immer damit zu kämpfen. Wir verloren mehrere High-End-Händler an Web-Beratungsfirmen, die sie davon ü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 feststellte, als die Weihnachtseinkaufssaison kam und die Last auf ihren Servern stieg. Viaweb war weitaus ausgefeilter als das, was die meisten dieser Händler erhielten, aber wir konnten es uns nicht leisten, es ihnen zu sagen. Für 300 US-Dollar im Monat konnten wir uns kein Team von gut gekleideten und autoritativ klingenden Leuten leisten, um Präsentationen für Kunden zu halten.

Ein großer Teil dessen, wofür große Unternehmen extra bezahlen, sind die Kosten für den Verkauf teurer Dinge an sie. (Wenn das Verteidigungsministerium tausend Dollar für Toilettensitze bezahlt, dann teilweise, weil der Verkauf von Toilettensitzen für tausend Dollar viel kostet.) Und das ist ein Grund, warum Intranet-Software weiterhin florieren wird, auch wenn sie wahrscheinlich eine schlechte Idee ist. Sie ist einfach teurer. Es gibt nichts, was Sie gegen dieses Dilemma tun können, daher ist der beste Plan, sich zuerst an die kleineren Kunden zu wenden. 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 letztes Mal verloren? Warum haben Desktop-Computer Mainframes verdrängt?

Zuerst sahen Desktop-Computer nicht wie eine große Bedrohung aus. Die ersten Benutzer waren alles 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 bewusst kühnen Klang, so wie heute der Begriff "persönlicher Satellit".

Warum haben sich Desktop-Computer durchgesetzt? Ich denke, weil 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 Leute erkennen, wie zerbrechlich und vorläufig Startups im frühesten Stadium sind. Viele Startups beginnen fast zufällig – als ein paar Leute, die entweder einen Hauptjob haben oder studieren, 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. Das Schreiben von Mainframe-Software erforderte zu viel Engagement im Voraus. Entwicklungshardware war teuer, und da die Kunden große Unternehmen sein würden, bräuchten Sie eine beeindruckend aussehende Vertriebsmannschaft, um sie zu verkaufen. Die Gründung eines Startups zur Entwicklung von Mainframe-Software wäre ein viel ernsteres Unterfangen, als abends einfach etwas auf Ihrem Apple II zusammenzuhacken. Und so gab es nicht viele Startups, die Mainframe-Anwendungen schrieben.

Die Ankunft von Desktop-Computern inspirierte viele neue Software, weil das Schreiben von Anwendungen dafür für latente Startups ein erreichbares Ziel schien. Die Entwicklung war billig, und die Kunden wären Einzelpersonen, die Sie über Computerläden oder sogar per Post erreichen konnten.

Die Anwendung, die Desktop-Computer in den Mainstream trieb, war VisiCalc, die erste Tabellenkalkulation. Sie wurde von zwei Typen geschrieben, die auf einem Dachboden arbeiteten, und tat dennoch Dinge, die keine Mainframe-Software konnte. [11] VisiCalc war zu seiner Zeit ein so großer Fortschritt, dass die Leute Apple IIs kauften, nur um sie auszuführen. Und das war der Beginn eines Trends: Desktop-Computer gewannen, weil Startups Software dafür schrieben.

Es sieht so aus, als ob serverbasierte Software dieses Mal 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 Workstation-Markt gefressen (man hört das Wort jetzt selten) und sind auf dem Weg, den Servermarkt zu dominieren; die Server von Yahoo, die Lasten bewältigen, die so hoch sind wie jede auf dem Internet, haben alle dieselben günstigen Intel-Prozessoren, die Sie in Ihrer Desktop-Maschine 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 Website. [12]

Viaweb war ein typisches latentes Startup. Wir hatten Angst, ein Unternehmen zu gründen, und in den ersten Monaten trösteten wir uns, indem wir die ganze Sache als ein Experiment behandelten, das wir jederzeit abbrechen könnten. Glücklicherweise gab es außer technischen Hindernissen nur wenige. Während wir die Software schrieben, war unser Webserver dieselbe Desktop-Maschine, die wir für die Entwicklung verwendeten, verbunden mit der Außenwelt über eine DFÜ-Verbindung. 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 den Bedingungen von Microsoft, rufen Sie deren APIs auf und arbeiten Sie um deren fehlerhaftes Betriebssystem herum. Und wenn Sie es schaffen, etwas zu schreiben, das erfolgreich ist, stellen Sie möglicherweise fest, dass Sie lediglich Marktforschung für Microsoft betrieben haben.

Wenn ein Unternehmen eine Plattform erstellen möchte, auf der Startups aufbauen können, muss es etwas schaffen, das auch Hacker selbst nutzen wollen. Das bedeutet, dass es billig und gut gestaltet sein muss. Der Mac war bei seiner Einführung bei Hackern beliebt, und viele von ihnen schrieben Software dafür. [13] Das sieht man bei Windows weniger, weil Hacker es nicht benutzen. Die Art von Leuten, die gut darin sind, Software zu schreiben, laufen jetzt eher unter Linux oder FreeBSD.

Ich glaube nicht, dass wir ein Startup zur Entwicklung von Desktop-Software gegründet hätten, weil Desktop-Software unter Windows laufen muss, und bevor wir Software für Windows schreiben könnten, müssten wir sie benutzen. Das Web ermöglichte uns einen Umweg um Windows und die direkte Bereitstellung von Software, die unter Unix läuft, über den Browser an die Benutzer. 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. Heute ist das schwer vorstellbar, aber ich erinnere mich sehr gut an das Gefühl. Jetzt ist der beängstigende Riese Microsoft, und ich glaube nicht, dass sie so blind für die Bedrohung sind wie IBM. Schließlich hat Microsoft sein Geschäft absichtlich in der blinden Stelle von IBM aufgebaut.

Ich erwähnte zuvor, dass meine Mutter 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 ihre Kontrolle über den Desktop nutzen können, um diese neue Generation von Software zu verhindern oder einzuschränken?

Ich vermute, Microsoft wird eine Art Server/Desktop-Hybrid entwickeln, bei dem das Betriebssystem mit von ihnen kontrollierten Servern zusammenarbeitet. Zumindest werden Dateien zentral verfügbar sein für Benutzer, die das wünschen. 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, benötigen 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 glaube, Microsoft wird Schwierigkeiten 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 die Anwendungen von Microsoft nur mit bestimmten Clients funktionieren, werden Konkurrenten sie übertrumpfen können, indem sie Anwendungen anbieten, die von jedem Client aus funktionieren. [14]

In einer Welt webbasierter Anwendungen gibt es keinen automatischen Platz für Microsoft. Sie mögen es schaffen, sich einen Platz zu sichern, 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 Konkurrent sie stolpern lässt, sondern dass sie über sich selbst stolpern werden. Mit dem Aufkommen webbasierter Software werden sie nicht nur technischen Problemen, sondern auch ihrem eigenen Wunschdenken gegenüberstehen. Was sie tun müssen, ist, ihr bestehendes Geschäft zu kannibalisieren, und ich kann mir nicht vorstellen, dass sie sich dem stellen. Dieselbe Einzigartigkeit, die sie bisher gebracht hat, wird nun gegen sie arbeiten. IBM befand sich in genau derselben Situation, und sie konnten sie nicht meistern. IBM trat spät und halbherzig in das Mikrocomputergeschäft ein, weil sie ambivalent waren, ihr Cashcow, das Mainframe-Computing, zu bedrohen. Microsoft wird ebenso durch den Wunsch, den Desktop zu retten, behindert werden. Eine Cashcow kann ein verdammt schwerer Affe auf dem Rücken sein.

Ich sage nicht, dass niemand serverbasierte Anwendungen dominieren wird. Jemand wird es wahrscheinlich irgendwann tun. Aber ich denke, es wird eine lange Periode fröhlichen Chaos geben, 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 noch 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 von ihnen getroffenen Entscheidungen. Wenn sie gewinnen, gewinnen sie groß.

Bei 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 starten. 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 starten, die in der Wohnküche einer Wohnung sitzen, und einen Server, der bei einem ISP untergebracht ist. Wir haben es getan.

Im Laufe der Zeit sind die Teams kleiner, schneller und informeller geworden. 1960 bedeutete Softwareentwicklung einen Raum voller Männer mit Hornbrillen 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 Leuten, die Jeans ins Büro trugen und in VT100 tippten. Jetzt sind es ein paar Leute, die mit Laptops in einem Wohnzimmer sitzen. (Und Jeans erweisen sich nicht als das letzte Wort in Sachen Informalität.)

Startups sind stressig, und das wird bei webbasierten Anwendungen leider auch auf die Spitze getrieben. Viele Softwareunternehmen, insbesondere am Anfang, haben Phasen, in denen die Entwickler unter ihren Schreibtischen schliefen und so weiter. Das Beunruhigende an webbasierter Software ist, dass nichts sie daran hindert, zum Standard zu werden. Die Geschichten über das Schlafen unter Schreibtischen enden normalerweise: Dann haben wir es endlich ausgeliefert und wir sind alle nach Hause gegangen und haben eine Woche geschlafen. Webbasierte Software wird nie ausgeliefert. Sie können 16-Stunden-Tage so lange arbeiten, wie Sie wollen. Und weil Sie es können und Ihre Konkurrenten es können, sind Sie oft gezwungen, es zu tun. Sie können es, also müssen Sie es tun. Es ist Parkinsons Gesetz, das umgekehrt läuft.

Das Schlimmste sind nicht die Stunden, sondern die Verantwortung. Programmierer und Systemadministratoren haben traditionell ihre eigenen separaten Sorgen. Programmierer müssen sich um Fehler kümmern, und Systemadministratoren müssen sich um die Infrastruktur kümmern. Programmierer verbringen vielleicht einen langen Tag mit Quellcode, aber irgendwann können sie nach Hause gehen und ihn vergessen. Systemadministratoren verlassen den Job nie ganz, aber wenn sie um 4:00 Uhr morgens angerufen 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 verbrachten wir die ersten sechs Monate damit, nur Software zu schreiben. Wir arbeiteten die üblichen langen Stunden eines frühen Startups. In einem Desktop-Softwareunternehmen wäre das die Phase gewesen, in der wir hart arbeiteten, aber es fühlte sich wie Urlaub an im Vergleich zur nächsten Phase, als wir Benutzer auf unseren Server nahmen. Der zweitgrößte Vorteil des Verkaufs von Viaweb an Yahoo (nach dem Geld) war die Möglichkeit, die ultimative Verantwortung für das Ganze auf die Schultern eines großen Unternehmens abzuwälzen.

Desktop-Software zwingt Benutzer, Systemadministratoren zu werden. Webbasierte Software zwingt Programmierer dazu. Es gibt insgesamt weniger Stress, aber mehr für die Programmierer. Das ist 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 einfache Möglichkeit, Ihre Konkurrenten zu übertreffen. Kein Startup verlangt mehr.

Nur gut genug

Eine Sache, die Sie vom Schreiben webbasierter Anwendungen abhalten könnte, ist die Lahmheit von Webseiten als Benutzeroberfläche. Das ist ein Problem, das gebe ich zu. Es gab ein paar Dinge, die wir gerne zu HTML und HTTP hinzugefügt hätten. Was jedoch zählt, ist, dass Webseiten einfach 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 waren dafür konzipiert, in Dingen wie Ampeln verwendet zu werden. Aber Typen wie Ed Roberts, der den Altair entwarf, 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 hatte einen funktionierenden Computer. Die Möglichkeit, seinen eigenen Computer zu haben, war so aufregend, dass es viele Leute gab, die sie kaufen wollten, egal wie begrenzt.

Webseiten wurden nicht als Benutzeroberfläche für Anwendungen konzipiert, aber sie sind einfach gut genug. Und für eine beträchtliche Anzahl von Benutzern wird Software, die Sie von jedem Browser aus nutzen können, ein so großer Gewinn an sich sein, dass er jede Unbeholfenheit in der Benutzeroberfläche aufwiegt. Vielleicht können Sie mit HTML nicht die schönste Tabellenkalkulation schreiben, aber Sie können eine Tabellenkalkulation schreiben, die mehrere Personen gleichzeitig von verschiedenen Standorten aus ohne spezielle Client-Software nutzen können, die Live-Datenfeeds integrieren kann oder die Sie benachrichtigen kann, wenn bestimmte Bedingungen ausgelöst werden. Wichtiger noch, Sie können neue Arten von Anwendungen schreiben, die noch keine Namen haben. VisiCalc war schließlich keine reine Mikrocomputerversion einer Mainframe-Anwendung – es war ein neuer Anwendungstyp.

Natürlich müssen serverbasierte Anwendungen nicht webbasiert sein. Sie könnten eine andere Art von Client haben. Aber ich bin ziemlich sicher, dass das eine schlechte Idee ist. Es wäre sehr praktisch, wenn Sie davon ausgehen könnten, dass jeder Ihren Client installiert – so praktisch, dass Sie sich leicht davon überzeugen könnten, dass sie es alle tun werden –, aber wenn sie es nicht tun, sind Sie am Arsch. Da webbasierte Software nichts über den Client annimmt, funktioniert sie überall dort, wo das Web funktioniert. Das ist bereits ein großer Vorteil, und der Vorteil wird wachsen, wenn neue Web-Geräte aufkommen. 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, die Entwicklung des Webs so genau verfolgt zu haben wie jeder andere, und ich kann nicht vorhersagen, was mit den Clients passieren wird. Konvergenz kommt wahrscheinlich, aber wohin? Ich kann keinen Gewinner auswählen. Eines, das ich vorhersagen kann, ist der Konflikt zwischen AOL und Microsoft. Was auch immer Microsofts .NET sein wird, es wird wahrscheinlich die Verbindung des Desktops mit Servern beinhalten. Wenn AOL nicht zurückschlägt, werden sie entweder beiseite gedrängt oder zu einer Leitung zwischen Microsoft-Client- und Serversoftware gemacht. Wenn Microsoft und AOL in einen Client-Krieg geraten, wird das Einzige, das auf beiden funktioniert, das Surfen im Web sein, was bedeutet, dass webbasierte Anwendungen die einzigen sein werden, die überall funktionieren.

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

Warum nicht?

E. B. White amüsierte sich, als er von einem befreundeten Bauern erfuhr, dass viele elektrifizierte Zäune keinen Strom führen. Die Kühe lernen offenbar, sich von ihnen fernzuhalten, und danach brauchen Sie keinen Strom mehr. "Erhebt euch, Kühe!", schrieb er, "nehmt eure Freiheit, während die Despoten schnarchen!"

Wenn Sie ein Hacker sind, der eines Tages daran gedacht hat, ein Startup zu gründen, gibt es wahrscheinlich zwei Dinge, die Sie davon abhalten. Erstens wissen Sie nichts über Wirtschaft. Zweitens haben Sie Angst vor dem Wettbewerb. Keine dieser Zäune hat Strom.

Sie müssen nur zwei Dinge über Wirtschaft wissen: Bauen Sie etwas, das Benutzer lieben, und verdienen Sie mehr, als Sie ausgeben. Wenn Sie diese beiden richtig machen, sind Sie den meisten Startups voraus. Den Rest können Sie unterwegs herausfinden.

Sie verdienen vielleicht nicht sofort mehr, als Sie ausgeben, aber solange die Lücke schnell genug schließt, sind Sie in Ordnung. Wenn Sie von Anfang an unterfinanziert sind, wird das zumindest eine Gewohnheit der Sparsamkeit fördern. Je weniger Sie ausgeben, desto einfacher ist es, mehr als Sie ausgeben zu verdienen. Glücklicherweise kann es sehr billig sein, eine webbasierte Anwendung zu starten. Wir haben mit unter 10.000 US-Dollar gestartet, und heute wäre es noch billiger. Wir mussten Tausende für einen Server ausgeben und Tausende mehr für SSL. (Die einzige Firma, die damals SSL-Software verkaufte, war Netscape.) Jetzt können Sie einen viel leistungsfähigeren Server mieten, mit inklusivem SSL, für weniger, als wir allein für Bandbreite bezahlt haben. Sie könnten jetzt eine webbasierte Anwendung für weniger als die Kosten eines schicken Bürostuhls starten.

Was das Bauen von Dingen angeht, die Benutzer lieben, hier sind einige allgemeine Tipps. Beginnen Sie damit, etwas sauberes und einfaches zu machen, das Sie selbst verwenden möchten. Bringen Sie schnell eine Version 1.0 heraus, verbessern Sie dann die Software weiter und hören Sie genau auf die Benutzer. Der Kunde hat immer Recht, aber verschiedene Kunden haben in Bezug auf verschiedene Dinge Recht; die am wenigsten anspruchsvollen Benutzer zeigen Ihnen, was Sie vereinfachen und klären müssen, und die anspruchsvollsten sagen Ihnen, welche Funktionen Sie hinzufügen müssen. Das Beste, was Software sein kann, ist einfach, aber der Weg dorthin ist, die Standardeinstellungen richtig zu machen, nicht die Auswahl der Benutzer einzuschränken. Seien Sie nicht selbstgefällig, wenn die Software Ihrer Konkurrenten lahm ist; der Maßstab, mit dem Sie Ihre Software vergleichen sollten, ist das, was sie sein könnte, nicht das, was Ihre aktuellen Konkurrenten zufällig haben. Benutzen Sie Ihre Software selbst, die ganze Zeit. Viaweb sollte ein Online-Shop-Builder sein, aber wir haben ihn auch benutzt, um unsere eigene Website zu erstellen. Hören Sie nicht auf Marketingleute, Designer oder Produktmanager nur wegen ihrer Jobtitel. Wenn sie gute Ideen haben, nutzen Sie sie, aber es liegt an Ihnen zu entscheiden; Software muss von Hackern entworfen werden, die Design verstehen, nicht von Designern, die ein wenig über Software wissen. Wenn Sie Software nicht so gut entwerfen können wie implementieren, gründen Sie kein Startup.

Nun zum Wettbewerb. Wovor Sie Angst haben, sind wahrscheinlich nicht Gruppen von Hackern wie Sie, sondern tatsächliche Unternehmen mit Büros und Geschäftsplänen und Verkäufern und so weiter, richtig? Nun, sie haben mehr Angst vor Ihnen als Sie vor ihnen, und sie haben Recht. Es ist für ein paar Hacker weitaus einfacher herauszufinden, wie man Büroräume mietet oder Verkäufer einstellt, als für ein Unternehmen jeder Größe, Software schreiben zu lassen. 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 man versuchen, durch hüfthohes Wasser zu rennen.

Ich will Yahoo nicht schlechtreden. Sie hatten einige gute Hacker, und das Top-Management war wirklich durchsetzungsfähig. 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 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.

Lassen Sie sich nicht einschüchtern. Sie können genauso viel tun, was Microsoft nicht kann, wie sie tun können, was Sie nicht können. Und niemand kann Sie aufhalten. Sie müssen niemanden um Erlaubnis bitten, webbasierte Anwendungen zu entwickeln. Sie müssen keine Lizenzvereinbarungen abschließen, keine Regalfläche in Einzelhandelsgeschäften bekommen oder sich demütigen lassen, damit Ihre Anwendung mit dem Betriebssystem gebündelt wird. Sie können Software direkt an den Browser liefern, und niemand kann zwischen Ihnen und potenziellen Benutzern gelangen, ohne sie daran zu hindern, das Web zu durchsuchen.

Sie glauben es vielleicht nicht, aber ich verspreche Ihnen, Microsoft hat Angst vor Ihnen. Die selbstgefälligen mittleren Manager vielleicht nicht, aber Bill hat Angst, weil er einmal Sie war, im Jahr 1975, als das letzte Mal eine neue Art der Softwarebereitstellung erschien.

Anmerkungen

[1] Da viel Geld in den Dienstleistungen steckt, haben Unternehmen, die leichte Clients bauen, meist versucht, die Hardware mit einem Online-Dienst 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-Dienst zu betreiben, und teilweise, weil Benutzer die Idee hassen. Das Verschenken des Rasierers und das Geld mit den Klingen zu verdienen, mag für Gillette funktionieren, aber ein Rasierer ist eine viel geringere Verpflichtung als ein Web-Terminal. Handyhersteller sind zufrieden, Hardware zu verkaufen, ohne zu versuchen, auch die Serviceeinnahmen zu erzielen. Das sollte wahrscheinlich das Modell für Internet-Clients sein. Wenn jemand einfach eine schön aussehende kleine Box mit einem Webbrowser verkauft, mit dem man sich über jeden ISP verbinden kann, würden ihn alle Technophoben des Landes kaufen.

[2] Sicherheit hängt immer mehr davon ab, keine Fehler zu machen, als von jeder Designentscheidung, aber die Natur serverbasierter Software wird Entwickler dazu bringen, mehr darauf zu achten, keine Fehler zu machen. Die Kompromittierung eines Servers könnte so großen Schaden verursachen, dass ASPs (die im Geschäft bleiben wollen) wahrscheinlich vorsichtig bei der Sicherheit sein werden.

[3] 1995, als wir Viaweb gründeten, sollten Java-Applets die Technologie sein, die jeder für die Entwicklung serverbasierter Anwendungen verwenden würde. Applets schienen uns eine altmodische Idee. Programme herunterladen, um sie auf dem Client auszuführen? Einfacher, ganz darauf zu setzen und die Programme auf dem Server auszuführen. Wir verschwendeten wenig Zeit mit Applets, aber unzählige andere Startups müssen in diesen Sumpf gelockt worden sein. Wenige können lebend entkommen sein, sonst hätte Microsoft es nicht geschafft, 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 an der Behebung alter Fehler, und die Kosten können linearer sein, wenn alle Fehler schnell gefunden werden."

[5] Die schwierigste Art von Fehler zu finden, mag eine Variante des Compound-Fehlers sein, bei der ein Fehler einen anderen kompensiert. Wenn Sie einen Fehler beheben, wird der andere sichtbar. Aber es wird so aussehen, als ob die Korrektur schuld ist, da dies das Letzte war, was Sie geändert haben.

[6] Innerhalb von Viaweb hatten wir einmal einen Wettbewerb, um das Schlimmste an unserer Software zu beschreiben. Zwei Kundensupport-Mitarbeiter teilten sich den ersten Preis mit Beiträgen, an die ich mich immer noch erinnere. Wir haben beide Probleme sofort behoben.

[7] Robert Morris schrieb das Bestellsystem, das die Käufer zum Aufgeben von Bestellungen verwendeten. Trevor Blackwell schrieb den Bildgenerator und den Manager, den Händler zum Abrufen von Bestellungen, Anzeigen von Statistiken und Konfigurieren von Domainnamen usw. verwendeten. Ich schrieb den Editor, den Händler zum Erstellen ihrer Websites verwendeten. 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 Einzelhändler behaupten, ihre Kaufkraft bedeute niedrigere Preise für Sie?), dass ich überrascht war, festzustellen, dass sie in den USA durch den Robinson-Patman Act von 1936 verboten war. Dieses Gesetz scheint nicht energisch durchgesetzt zu werden.

[9] In No Logo sagt Naomi Klein, dass Bekleidungsmarken, die von "städtischen Jugendlichen" bevorzugt werden, den Diebstahl nicht zu sehr verhindern, weil in ihrem Zielmarkt die Diebe auch die Modeführer sind.

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

[11] Die beiden Typen waren Dan Bricklin und Bob Frankston. Dan schrieb einen Prototyp in Basic in ein paar Tagen, dann arbeiteten sie im Laufe des nächsten Jahres zusammen (hauptsächlich nachts), um eine leistungsfähigere Version in 6502 Maschinensprache zu erstellen. Dan war zu dieser Zeit an der Harvard Business School und Bob hatte nominell einen Hauptjob als Softwareentwickler. "Es gab kein großes Risiko, ein Geschäft zu gründen", schrieb Bob, "Wenn es fehlschlägt, schlägt es fehl. Keine große Sache."

[12] Es ist nicht ganz so einfach, wie ich es klingen lasse. Es dauerte schmerzhaft lange, bis sich Mundpropaganda verbreitete, und wir erhielten erst dann viel Presseberichterstattung, als wir eine PR-Firma (zugegebenermaßen die beste in der Branche) für 16.000 US-Dollar pro Monat einstellten. Es stimmte jedoch, dass der einzige bedeutende Kanal unsere eigene Website war.

[13] Wenn der Mac so großartig war, warum hat er verloren? Wieder einmal die Kosten. Microsoft konzentrierte sich auf das Softwaregeschäft und entfesselte einen Schwarm billiger Komponentenlieferanten auf Apple-Hardware. Es half auch nicht, dass Anzugträger während einer kritischen Phase die Kontrolle übernahmen.

[14] Eine Sache, die webbasierten Anwendungen helfen würde und dazu beitragen würde, dass die nächste Generation von Software nicht von Microsoft überschattet wird, wäre ein guter Open-Source-Browser. Mozilla ist Open Source, scheint aber darunter gelitten zu haben, so lange Software von Unternehmen zu sein. Ein kleiner, schneller Browser, der aktiv gepflegt wird, wäre an sich schon eine großartige Sache und würde wahrscheinlich auch Unternehmen dazu ermutigen, kleine Web-Appliances zu bauen.

Ein ordentlicher Open-Source-Browser würde unter anderem dazu führen, dass HTTP und HTML sich weiterentwickeln (wie z. B. Perl). Es wäre für webbasierte Anwendungen sehr hilfreich, zwischen der Auswahl eines Links und dem Folgen davon unterscheiden zu können; alles, was Sie dazu benötigen, wäre eine triviale Erweiterung von HTTP, um mehrere URLs in einer Anfrage zu ermöglichen. 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, eine neue Suchmaschine zu starten, aber Google hat sie widerlegt. Es gibt immer Platz für etwas Neues, wenn die aktuellen Optionen ausreichend schlecht sind. Stellen Sie sicher, dass es zuerst auf allen kostenlosen Betriebssystemen funktioniert – neue Dinge beginnen mit ihren Benutzern.

[15] Trevor Blackwell, der wahrscheinlich mehr persönliche Erfahrung damit hat als jeder andere, schreibt:

"Ich würde weiter gehen und sagen, dass serverbasierte Software, weil sie für Programmierer so schwierig ist, eine grundlegende wirtschaftliche Verlagerung weg von großen Unternehmen verursacht. Sie erfordert die Art von Intensität und Hingabe von Programmierern, die sie nur bereit sind zu leisten, wenn es ihr eigenes Unternehmen ist. Softwareunternehmen können qualifizierte Leute einstellen, um in einer nicht zu anspruchsvollen Umgebung zu arbeiten, und unqualifizierte Leute einstellen, um Härten zu ertragen, aber sie können keine hochqualifizierten Leute einstellen, um sich den Hintern aufzureißen. Da Kapital nicht mehr benötigt wird, haben große Unternehmen wenig beizutragen."

[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.

Dank 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 diesen Aufsatz und 14 weitere in Hackers & Painters.