Die Geschichte der Technologie ist reich an Innovationen, die das Potenzial hatten, die digitale Welt zu verändern, aber aus verschiedenen Gründen scheiterten. Von Betriebssystemen ohne Befehlszeile bis hin zu Programmiersprachen, die heute als modern gelten würden – viele dieser Ideen verschwanden, bevor sie ihre volle Wirkung entfalten konnten. Sie scheiterten oft an proprietären Geschäftsmodellen, unzureichendem Timing oder der Dominanz etablierter Marktführer.
Ein Rückblick auf diese „toten“ Technologien zeigt jedoch, dass viele ihrer Kernkonzepte später in anderer Form wieder auftauchten. Ideen wie Serverless Computing, komponentenbasierte Software und sogar die Funktionsweise moderner mobiler Betriebssysteme haben ihre Wurzeln in Projekten, die längst als gescheitert gelten. Diese technologischen Sackgassen sind daher nicht nur historische Fußnoten, sondern wichtige Lektionen über Innovation, Marktdynamik und die unvorhersehbaren Wege des Fortschritts.
Wichtige Erkenntnisse
- Viele gescheiterte Technologien führten Konzepte ein, die heute in Produkten wie AWS Lambda (Serverless) oder modernen Betriebssystemen Standard sind.
- Geschäftsentscheidungen, wie proprietäre Standards (IBM MicroChannel) oder die Einstellung vielversprechender Produkte (Google Reader), haben oft mehr Einfluss auf das Scheitern als technische Mängel.
- Die Debatte um strikte vs. nachsichtige Standards (XHTML vs. HTML5) zeigt einen grundlegenden Konflikt zwischen technischer Perfektion und praktischer Benutzerfreundlichkeit im Web.
- Projekte wie OpenDoc und Silverlight boten fortschrittliche Entwicklungsmodelle, die sich gegen monolithische Anwendungen etablierter Anbieter nicht durchsetzen konnten.
Betriebssysteme: Alternative Wege, die nicht beschritten wurden
Die Entwicklung von Betriebssystemen war geprägt von entscheidenden Weichenstellungen. Einige vielversprechende Ansätze wurden jedoch aufgegeben, obwohl ihre Ideen bis heute relevant sind. Sie zeigen, wie anders unsere digitale Umgebung hätte aussehen können.
MacOS 8 Copeland und der Verzicht auf die Befehlszeile
Lange vor der Übernahme von NeXT und der Entwicklung von Mac OS X arbeitete Apple an einem Projekt namens „Copeland“, das als MacOS 8 auf den Markt kommen sollte. Dieses System setzte die Tradition eines vollständig grafischen Betriebssystems ohne Kommandozeile fort. Ein solches Design zwingt Entwickler dazu, Installations- und Konfigurationsprozesse nutzerfreundlich zu gestalten – ein Prinzip, das später den Erfolg von iOS prägte.
Eine Entwicklerversion wurde ausgeliefert, doch das Projekt wurde eingestellt, um den Kauf von NeXT und die Rückkehr von Steve Jobs zu rechtfertigen. Ironischerweise basierte das daraus resultierende Mac OS X auf einem UNIX-Kern, der die Kommandozeile wieder in den Mittelpunkt rückte.
Was war NeXTSTEP?
NeXTSTEP war das von Steve Jobs' Firma NeXT entwickelte Betriebssystem. Es basierte auf UNIX und zeichnete sich durch eine fortschrittliche objektorientierte Entwicklungsumgebung aus. Nach der Übernahme von NeXT durch Apple im Jahr 1996 bildete NeXTSTEP die technische Grundlage für Mac OS X, das heutige macOS, sowie für iOS, iPadOS, watchOS und tvOS.
Transaktionsbasierte Systeme und Serverless Computing
Ein weiteres vergessenes Konzept sind transaktionsbasierte Betriebssysteme wie IBMs Customer Information Control System (CICS). Bei diesem Modell wird für jede Aufgabe ein Programm geladen, führt eine Aktion aus und wird sofort wieder beendet. Dieser Ansatz steht im Gegensatz zu traditionellen Systemen wie Unix oder Linux, die für den dauerhaften Betrieb von Prozessen in einer Time-Sharing-Umgebung ausgelegt sind.
Heute erlebt dieses Prinzip eine Renaissance unter dem Namen „Serverless Computing“. Dienste wie AWS Lambda, Google Cloud Functions und Azure Functions basieren auf genau diesem Zyklus: Code wird nur bei Bedarf ausgeführt und dann wieder beendet. Das alte Konzept wurde für die Cloud neu erfunden.
Hardware-Innovationen, die sich nicht durchsetzten
Nicht nur bei der Software, auch bei der Hardware gab es entscheidende Momente, in denen sich eine Technologie gegen eine potenziell überlegene Alternative durchsetzte. Oft waren es strategische Fehler oder Marktbedingungen, die den Ausschlag gaben.
IBM MicroChannel und der Kampf um den Bus-Standard
In den Anfängen der Mikrocomputer kommunizierten Peripheriegeräte über einen „Bus“ direkt mit dem Speicher. Mainframes nutzten hingegen „Kanäle“ – einfache Prozessoren, die den Datenaustausch zwischen CPU und Peripheriegeräten verwalteten. IBM versuchte, dieses überlegene Kanal-Konzept mit dem MicroChannel-Bus (MCA) in seinen PS/2-Computern einzuführen.
Der entscheidende Fehler: IBM machte den Standard proprietär und verlangte hohe Lizenzgebühren. Die Konkurrenz reagierte mit der Entwicklung des offenen EISA-Standards und später des PCI-Busses. IBMs Versuch, den Markt zu kontrollieren, führte zum Scheitern einer technisch fortschrittlichen Idee. Heute nutzen moderne Systeme wie PCIe und NVMe ähnliche Konzepte der direkten Kommunikation, aber als offene Standards.
Der Motorola 680x0 Prozessor
Die Motorola 680x0-Prozessorfamilie hätte die Grundlage der Mikrocomputer-Ära bilden können. Der ursprüngliche 68000-Chip von 1978 war seiner Zeit voraus und wurde in frühen Apple Macintosh-, Amiga- und Atari-ST-Computern eingesetzt. Allerdings verzögerte sich die Entwicklung einer entscheidenden Komponente, der Memory Management Unit (MMU), erheblich. Diese Verzögerung ermöglichte es der x86-Architektur von Intel, den aufstrebenden PC-Markt zu dominieren, obwohl sie technisch in vielen Aspekten unterlegen war.
Web- und Softwareentwicklung: Verlorene Paradigmen
Die Art und Weise, wie wir heute Webseiten und Anwendungen erstellen, ist das Ergebnis einer langen Evolution. Dabei wurden einige Ansätze verworfen, die eine sauberere und strukturiertere digitale Welt versprachen.
Der Traum von XHTML und strukturiertem Code
XHTML war der Versuch, die Flexibilität von HTML mit der strengen Syntax von XML zu kombinieren. Die Idee war einfach: Webseiten sollten nur dann korrekt angezeigt werden, wenn der Code fehlerfrei ist. Jeder nicht geschlossene Tag oder Syntaxfehler hätte zu einer Fehlermeldung geführt, ähnlich wie bei einem Compiler für eine Programmiersprache.
„Würde es die Leute umbringen, ihre Tags ordnungsgemäß zu schließen? Wir stoppen bei fast jedem anderen Format beim ersten Anzeichen von Problemen, wir brauchen keine laxe Analyse für HTML.“
Dieser Ansatz scheiterte am Widerstand der Praxis. Browser-Hersteller entschieden sich stattdessen für den Weg des HTML5, das eine extrem fehlertolerante Verarbeitung vorschreibt. Die Philosophie dahinter war, dass das Web für Menschen da ist und nicht umgekehrt. Die Nachsichtigkeit von HTML5 erleichterte zwar die Veröffentlichung von Inhalten, führte aber auch zu einer Kultur von unsauberem Code und erhöhte die Komplexität für Browser-Entwickler, die unzählige Fehlerfälle abfangen müssen.
Macromedia Fireworks: Der vergessene Vektor-Editor
Vor der Übernahme durch Adobe war Macromedia Fireworks ein beliebtes Werkzeug für Webdesigner. Es kombinierte Vektor- und Rasterbearbeitung auf einzigartige Weise und war perfekt für pixelgenaues UI-Design. Im Gegensatz zu Adobe Illustrator, das rein vektorbasiert ist, behandelte Fireworks Vektorformen so, als wären sie bearbeitbare Bitmaps. Nach der Übernahme wurde das Produkt zugunsten von Photoshop und Illustrator eingestellt, obwohl es bis heute eine treue Anhängerschaft hat.
Microsoft Silverlight und die Vision von Rich-Internet-Applications
Microsoft Silverlight war eine direkte Antwort auf Adobe Flash und sollte die Entwicklung interaktiver Webanwendungen revolutionieren. Es bot Entwicklern die Möglichkeit, mit C# und den leistungsstarken Werkzeugen von Visual Studio komplexe, plattformübergreifende Anwendungen zu erstellen, die direkt im Browser liefen. Features wie Zwei-Wege-Datenbindung und das MVVM-Muster waren ihrer Zeit weit voraus.
Silverlight war besonders im Unternehmensumfeld beliebt, da es die einfache Verteilung von internen Anwendungen über das Web ermöglichte. Das Ende kam mit dem Aufstieg des mobilen Webs. Steve Jobs' Entscheidung, Flash und andere Plugins auf dem iPhone nicht zu unterstützen, besiegelte auch das Schicksal von Silverlight. Die Industrie wandte sich offenen Webstandards wie HTML5, CSS und JavaScript zu.
Die Friedhof der eingestellten Google-Dienste
Kein Unternehmen ist so bekannt für das Einstellen beliebter Produkte wie Google. Diese Entscheidungen haben oft zu einem erheblichen Vertrauensverlust bei den Nutzern geführt, insbesondere bei denen, die stark in die jeweiligen Ökosysteme investiert hatten.
Google Reader: Ein Verlust für die Informationsgesellschaft
Die Einstellung von Google Reader im Jahr 2013 war für viele ein Schock. Der RSS-Reader war ein zentrales Werkzeug für Journalisten, Entwickler, Forscher und Power-User, um Nachrichten und Blogs zu organisieren. Obwohl die Nutzerbasis im Vergleich zu anderen Google-Diensten klein war, handelte es sich um eine äußerst einflussreiche Gruppe.
Die Abschaltung lehrte eine ganze Generation von Tech-Experten eine schmerzhafte Lektion: Verlasse dich niemals vollständig auf einen kostenlosen Dienst eines einzigen Anbieters. Viele argumentieren, dass Google damit nicht nur ein Produkt, sondern auch einen Teil des offenen, dezentralen Webs geopfert hat.
Weitere bemerkenswerte Einstellungen
- Picasa: Eine schnelle, lokale Fotoverwaltungssoftware, die durch das cloudbasierte Google Photos ersetzt wurde. Viele Nutzer vermissen die Geschwindigkeit und die Offline-Funktionalität.
- Google Wave: Ein ambitioniertes Echtzeit-Kommunikations- und Kollaborationstool, das E-Mail, Instant Messaging und Wikis vereinen sollte. Die Technologie war beeindruckend, aber das Produkt war für die meisten Nutzer zu komplex. Teile der Technologie leben in Google Docs weiter.
- Word Lens: Eine App, die Text in der realen Welt über die Handykamera in Echtzeit und offline übersetzen konnte. Sie wurde von Google gekauft und in Google Translate integriert, verlor dabei aber ihre reine Offline-Fähigkeit.
Diese Beispiele zeigen ein wiederkehrendes Muster: Technisch brillante oder von einer Nische geliebte Produkte werden oft zugunsten einer stärker integrierten, aber nicht immer besseren, zentralisierten Strategie geopfert. Die Geschichte dieser vergessenen Technologien ist eine Mahnung, dass technologische Überlegenheit allein kein Garant für Erfolg ist.
