Ask HN: Gibt es Projekte, die zu früh eingestellt oder beendet wurden? Warum?

 (news.ycombinator.com)
6 Punkte von GN⁺ 2025-10-13 | 6 Kommentare | Auf WhatsApp teilen
  • Frage und Antworten zu Projekten, die ihrer Zeit voraus waren oder verschwanden, weil der Markt noch nicht bereit war

    Ich bin einfach nur neugierig. Wer weiß schon, ob jemand das übernimmt oder ob auf Basis dieser Idee etwas Neues entwickelt wird.

Das Betriebssystem Plan 9

  • Das verteilte Betriebssystem der Bell Labs galt als wahrer Nachfolger von Unix, scheiterte jedoch an der Kommerzialisierung

    • Innovatives Design, das die Philosophie „alles ist eine Datei“ sogar auf die Freigabe im Netzwerk ausweitete
    • Bot originelle UI-Funktionen wie Mouse Coding, einen verschachtelten Fenstermanager und Plumber
    • Wäre ideal für verteilte Umgebungen gewesen, die Mobile, Desktop, Cloud und IoT verbinden, wurde aber nicht übernommen

  • Gründe für das Scheitern

    • Die Branche wandte sich wegen Lizenzproblemen und Klagen davon ab
    • Es passte zeitlich nicht zu einer Phase, in der zentrale Rechenmodelle zurückgingen und Personal Computer aufstiegen
    • Es wurde nur als Forschungs-OS positioniert und konnte den .com-Boom nicht nutzen
    • Wegen sinkender Einnahmen aus dem Telefongeschäft von AT&T wurde Bell Labs mehrfach verkauft
    • Version 3 wurde für 350 US-Dollar pro Box verkauft, durfte aber nur nichtkommerziell genutzt werden
    • Erst 2004 wurde es wirklich als Open Source freigegeben

  • Vermächtnis

    • Das 9P-Dateisystemprotokoll wird weiterhin in WSL2, im VM-Ökosystem und in Kubernetes verwendet
    • Es gibt aktive Forks wie 9front
    • Die Plan 9 Foundation verwaltet den Open-Source-Code und die Rechte

Tote Projekte von Google

  • Erfahrungsbericht eines Nutzers, dessen 30–40 genutzte Google-Produkte auf 3–4 schrumpften

    • Google Picasa: ein lokal arbeitendes Tool für schnelle und hervorragende Fotoverwaltung
    • Google Hangouts: Opfer einer chaotischen Messaging-App-Strategie
    • G Suite Legacy: Das Versprechen „für immer kostenlos“ wurde gebrochen und das Produkt kostenpflichtig gemacht
    • Play Music: Tausende MP3-Dateien hochgeladen, dann durch die Abschaltung Daten verloren
    • Google Finance: Hatte Funktionen zur Aktienverfolgung, wurde aber eingestellt
    • Google NFC Wallet: Apple dominierte den Markt mit derselben Funktion
    • Chromecast Audio: Auf eine einzige Funktion fokussiert, wurde aber eingestellt

  • Google Reader: eine der schlechtesten Geschäftsentscheidungen aller Zeiten

    • Wurde eingestellt, obwohl der Dienst langfristig kaum Wartung benötigt hätte
    • Hatte viele einflussreiche Nutzer wie Gründer, CTOs und VPs of Engineering
    • Hinterließ in der Branche die Lehre, Google-Produkten nicht zu vertrauen
    • Die Abschaltung offenbart eine Organisationskultur, in der eingesparte Millionen als Erfolg bewertet werden

Adobe Flash / Macromedia Flash

  • Eine Multimedia-Plattform, für die es selbst nach 15 Jahren keinen echten Ersatz gibt

    • Spiele und Multimedia ließen sich so einfach wie mit Lego-Steinen erstellen
    • Bot ein intuitives Toolset mit MovieClip und Timeline-Animationen
    • Wurde zwar durch HTML Canvas ersetzt, aber die Qualität der Werkzeuge ist nicht vergleichbar

  • Warum das iPhone Flash getötet hat

    • Auf der Hardware von 2007 waren Leistungsprobleme und hoher Akkuverbrauch gravierend
    • Flash hätte zu einem Umgehungsweg für das App-Ökosystem werden können
    • Es bestand das Risiko, dass das iPhone als „Schrottprodukt“ wahrgenommen würde

  • Aktuelle Lage

    • Adobe Animate unterstützt JS/Canvas-Ausgabe, ist aber nicht dasselbe wie das Original
    • Mit Emulatoren wie Ruffle lassen sich einige Legacy-Inhalte weiter ausführen
    • Roblox erfüllt teilweise eine ähnliche Rolle, ist aber stärker eingeschränkt und kommerzieller

Gescheiterte Projekte von Microsoft

  • Silverlight: ein webbasiertes Plug-in auf C#-Basis

    • Statt JavaScript konnte vollwertiges C# verwendet werden
    • Vektorbasierte DPI-bewusste UI, MVVM-Muster und Two-Way-Binding
    • Zusammenarbeit zwischen Designern und Entwicklern über Expression Blend
    • Rendering war in allen Browsern vollständig identisch
    • Das iPhone brachte neben Flash auch Silverlight zu Fall

  • Midori: ein sicherheitsorientiertes OS mit Capabilities

    • Wurde so weit entwickelt, dass es Windows-Code ausführen konnte, wurde aber durch interne Politik eingestellt
    • Viele Forschungsergebnisse wurden in .NET integriert
    • Als Retention-Projekt zur Bindung starker Engineers arbeiteten mehr als 100 Personen daran

Sonstiges

  • Apples Copland (MacOS-8-Prototyp)

    • Eine modernisierte Version von MacOS ohne Kommandozeile
    • Hätte Funktionen geboten, die den Übergang zu Mobile leichter gemacht hätten
    • Wegen Feature Creep und Instabilität nicht veröffentlichbar
    • Es gibt Gerüchte, dass es absichtlich verworfen wurde, um Apples Übernahme von NeXT zu rechtfertigen

  • Songsmith: automatische Begleitung für Melodien

    • Bot 2009 bereits Echtzeit-Akkorderkennung und automatische Begleitung
    • Ein Vorläufer heutiger KI-Musiktools wie Suno und Udio
    • Wurde durch ein campiges Promo-Video zum Meme, war technisch aber stark

Der Niedergang von Heroku

  • Der frühe Erfolg beruhte auf Einfachheit und Fokus

    • Eine Sprache, eine Deployment-Plattform, eine Datenbank
    • Minimale Entscheidungserschöpfung
    • Hätte es vor 15 Jahren KI gegeben, wäre sie mit konsistenten Trainingsdaten effizienter gewesen

  • Gründe für das Scheitern

    • Nach der Übernahme durch Salesforce sorgte das Hinzufügen eines riesigen Markenbanners für Nutzerproteste
    • Mit dem Aufkommen von Docker und Kubernetes wurde Heroku leichter ersetzbar
    • Die Abschaffung des Free-Tiers ließ viele Kunden abwandern
    • Missbrauch kostenloser Rechenleistung durch Krypto war ein Problem

  • Aktuelle Lage

    • Einige Nutzer setzen es weiterhin in Produktion ein
    • Vercel, Coolify und Dokku bieten ähnliche Erfahrungen

ReactOS – Reimplementierung von Windows NT

  • Wird seit fast 30 Jahren entwickelt, ist aber noch immer nicht praktisch nutzbar

    • Wine + Kernel + Geräte­treiber-Kompatibilität + ein bewegliches Ziel
    • Selbst vor dem Support-Ende von Windows 10 keine echte Alternative

  • Gründe für das Scheitern

    • Der Windows-Quellcode ist weder gut dokumentiert noch vollständig verstanden
    • Nach den Prinzipien des Clean-Room-Reverse-Engineerings dürfen Personen, die Windows-Code gesehen haben, nicht beitragen
    • Selbst nach dem Leak des Windows-XP-Quellcodes blieb das Entwicklungstempo langsam
    • Wine, Proton und Virtualisierung wurden zu praktischen Alternativen

Delphi und Pascal

  • Programmiersprachen, die ideal für die Lehre waren

    • Mit extrem schnellem Compiler gut geeignet für Lernen durch Ausprobieren
    • Sauberes Typsystem (nicht so komplex wie Rust)
    • Vermittelte Grundlagen der Programmierung ohne sprachspezifische Spezialfunktionen

  • Aktuelle Lage

    • Delphi lebt weiter und ist bereits bei Version 13 angekommen
    • Lazarus existiert als Open-Source-Alternative
    • Python hat es als Lehrsprache weitgehend ersetzt, aber sein Typsystem ist verwirrend

Innovative, aber gescheiterte Hardware

  • MicroChannel (IBM): kanalbasierte Peripherie-Architektur

    • Brachte das Channel-Konzept von Mainframes auf PCs
    • Konnte einfache Channel-Programme ausführen
    • Scheiterte am Markt wegen proprietärer Lizenzen
    • Moderne Systeme nutzen ähnliche Funktionen, aber ohne einheitliche Schnittstelle

  • Motorola 680x0: ein Prozessor, der zur Grundlage des Mikrocomputer-Zeitalters hätte werden können

    • 1978 erschienen, aber die MMU kam viel zu spät
    • Das Herzstück von Amiga und frühen Macintosh-Systemen

  • Optane Persistent Memory: eine Technologie, die die Grenze zwischen RAM und Storage aufhob

    • Erlaubte es, Datenstrukturen direkt persistent zu machen
    • Kein Booten oder App-Start nötig, Fortsetzung genau an der Unterbrechungsstelle
    • Scheiterte, weil es zu teuer war, technisch aber revolutionär
    • Zu wenig Geduld bei geschäftlichen Entscheidern

  • Lytro-Lichtfeldkamera: Fokus erst nach der Aufnahme festlegen

    • Erfasste alle Daten und erlaubte die Fokusentscheidung später
    • Hätte perfekt mit modernen Technologien wie Gaussian splatting und Meta Ray-Ban harmonieren können
    • Erreichte nicht die Bildqualität, die Profifotografen brauchen
    • Hätte eher den Neuheitenmarkt wie Polaroid/Instax anvisieren sollen

Kontroversen um Webtechnologien

  • Das Scheitern von XHTML

    • Sollte mit strengem Parsing das Chaos von HTML lösen
    • HTML5 standardisierte sogar die Bedeutung fehlerhaften HTMLs
    • Postels Gesetz ist falsch: tolerantes Parsing führt zu Sicherheitslücken und Kompatibilitätsproblemen
    • Das Prinzip „beim ersten Fehler stoppen und eine Fehlermeldung anzeigen“ wäre besser gewesen

  • Gegenargument: der eigentliche Grund für das Scheitern von XHTML

    • IE6 unterstützte application/xhtml+xml nicht
    • Fast 15 Jahre lang musste IE6 unterstützt werden
    • JSX und JSON sind ebenfalls strenge Syntaxen und waren trotzdem erfolgreich
    • Alle Backend-Sprachen verwenden strenge Syntax
    • Es war kein Problem der Einstiegshürde, sondern eines der Browser-Unterstützung

  • Die Realität von HTML

    • Schon falsch gesetzte Attribut-Anführungszeichen können dazu führen, dass eine ganze Seite nicht rendert
    • Es muss ein Format sein, das auch Laien schreiben können
    • HTML ist ein Dokumentformat, keine Befehlssprache
    • Auch PDF, ZIP und CSV lesen beschädigte Dateien (die Daten sind wichtiger als das Format)

Soziale Netzwerke und Kommunikation

  • Google Wave: zeigte die Zukunft, kam aber als Revolution zu früh

    • Echtzeitübersetzung, integrierte verschiedene Messaging-Arten und bot viele Funktionen
    • War vollständig Open Source
    • Die zu komplexe UI mit „verschachtelten Threads mit Echtzeit-Updates“ war überwältigend
    • Vereinte Funktionen, die heute auf Slack, JIRA und E-Mail verteilt sind

  • Vine: Kurzvideos vor TikTok

    • War bereits 2013 erheblich skaliert
    • Twitter stellte es ein, weil man nicht wusste, wie man es monetarisieren sollte
    • TikTok erschien nur wenige Monate nach dem Ende von Vine
    • Ein Quadratvideo mit nur einem Werbebanner hätte gereicht, aber die Chance wurde verpasst

  • Skype: Videotelefonie, die selbst Großmütter nutzen konnten

    • So einfach wie ein Telefon, aber günstiger als Auslandsgespräche
    • War die beste P2P-Software ihrer Art
    • Wurde durch Microsoft Teams miserabel ersetzt
    • Schwierige Einrichtung externer Hardware, Kompatibilitätsprobleme und der frühere Audio-Testdienst fehlt

Betriebssysteme

  • Maemo/MeeGo: das mobile Linux, auf das Nokia hätte setzen sollen

    • Das N9 war ein herausragendes Gerät, aber es erschien nur eines
    • Es war hackbar, elegant und sicher zugleich
    • Heute könnten es zwei gängige mobile Linux-Plattformen neben Android und iOS sein
    • Lebt teilweise in Sailfish OS weiter

  • BeOS: ein für Multimedia optimiertes OS

    • Dass man so weit scrollen musste, bevor BeOS und Amiga erwähnt wurden, sei überraschend
    • Mit Haiku OS läuft eine Reimplementierung from scratch
    • Spürbar schneller und reaktionsfreudiger als Linux+X+Qt+KDE

  • OS/2: die Tragödie aus der Zusammenarbeit von IBM und Microsoft

    • Ein System mit hervorragender API
    • Wären Workplace Shell und SOM-Code offengelegt worden, hätten andere Betriebssysteme davon profitieren können
    • Wurde lange in Bankautomaten genutzt, ohne gehackt zu werden

Entwicklungswerkzeuge

  • Quartz Composer: Apples nodebasiertes visuelles Programmieren

    • Eine patchbasierte visuelle Programmierumgebung
    • Monitoring von USB-Geräten ließ sich mit drei Nodes umsetzen
    • Seit 2016 nicht mehr aktualisiert, viele Nodes sind auf aktuellen OS-Versionen defekt
    • Sollte angesichts der Popularität von nodebasiertem Programmieren in Blender und Unreal Engine neu bewertet werden

  • Atom Code Editor: hätte eine Alternative zu VS Code werden können

    • Eine von GitHub geschaffene Mainstream-Alternative
    • Nach Microsofts Übernahme von GitHub war Atoms Schicksal besiegelt
    • Das ursprüngliche Electron-Projekt
    • Die ursprünglichen Entwickler arbeiten nun am Zed-Editor

  • Non DAW: eine nach Funktionen getrennte DAW

    • Stellte jede Funktion als eigenständige Anwendung bereit
    • Wenn nur einzelne Funktionen gebraucht wurden, störten die anderen nicht
    • Mit einem Beispiel von 25 Zeilen wurden alle Konzepte eingeführt
    • Der Hauptentwickler wurde von Microsoft eingestellt und arbeitet nun an Rust OSS

Programmiersprachen

  • Elm: eine unvollständige und nicht mehr aktiv weiterentwickelte funktionale Sprache

    • Durch die Entfernung benutzerdefinierter Operatoren brach sämtlicher Code und das Momentum ging verloren
    • Die Elm Architecture ist zu starr
    • F# (Fable), ReasonML, OCaml (Bucklescript), Haskell und PureScript sind Alternativen

  • Opa: ein typbasiertes Next.js aus dem Jahr 2012

    • Schon vor TypeScript ein typisiertes Full-Stack-Framework
    • Kam auf den Markt, als man gegenüber serverseitigem Node.js skeptisch war
    • Die AGPL-Lizenz war der Todesstoß; später wurde zwar auf MIT umgestellt, aber eine zweite Chance gab es nicht

  • Austral: eine Sprache mit Klarheit im Denken und Originalität

    • Bietet eine Spezifikation mit ungewöhnlicher Klarheit
    • Der Autor arbeitet nicht mehr aktiv daran
    • Für Hobbyprogrammierer fehlen Community und Ökosystem

  • Ceylon: Red Hats JVM-Sprache

    • Trat gegen Groovy, Kotlin und Scala an
    • Bot anonyme Union-Typen, Comprehensions und ein ordentliches Modulsystem
    • Mehr als nur einfache Syntax-Zuckerglasur über Java
    • Verlor den Wettbewerb gegen Kotlin und wurde in Eclipse vernachlässigt

Kommerzielle Fehlschläge

  • Google Stadia: Cloud-Gaming-Plattform

    • Aufbau einer soliden Streaming-Plattform
    • Scheiterte am Mangel an interessanten Spielen
    • Ein paar Spiele, die man anderswo bereits bekommen konnte, reichten nicht aus

  • Fire Phone: Amazons Smartphone

    • Zielte auf einen Markt mit praktisch null Nachfrage
    • Rückblickend ist kaum zu glauben, dass man an den Erfolg glaubte

  • Project Ara: das modulare Smartphone von Google/Motorola

    • Ein anpassbares Smartphone
    • Man hätte gern noch einige weitere Iterationen gesehen
    • Für den Wettbewerb wäre es wohl zu dick gewesen

Datenbanken und Backend

  • RethinkDB: Echtzeit-Datenbank

    • Scheiterte beim Versuch, den Umfang mit Horizon BaaS zu erweitern
    • Existiert technisch unter der Linux Foundation weiter, hat aber sein Momentum verloren
    • Das ursprüngliche Konzept war großartig für Demos, aber es fehlten reale Produktions-Use-Cases

  • Yahoo Pipes: Tool zum Kombinieren von RSS und Datenflüssen

    • Zeigte, wie das Internet eigentlich sein sollte
    • Die Verbindung zwischen Tools ist bis heute kaum über das Niveau von Unix-Pipes hinausgekommen
    • Zapier und n8n sind moderne Alternativen, fühlen sich aber nicht gleich an
    • Node-RED, Apache Camel und Apache Nifi sind Enterprise-Alternativen

Weitere bemerkenswerte Projekte

  • Sandstorm: eine dezentrale Webplattform von 2014

    • Basierte auf BitTorrent-Ideen
    • Vollständig dezentraler Website-Code und dezentrale Daten
    • Hätte sich in bestehende Websites integrieren lassen
    • Der Grain-Mechanismus (Datenisolierung) erschwerte die Anpassung bestehender Apps
    • Statt auf App-Portierung hätte man die Vermarktung auf neu für die Plattform entwickelte Apps ausrichten sollen

  • Keybase: ein kryptografiebasiertes soziales Netzwerk

    • Bot starke Verschlüsselung und Identitätsprüfung
    • Wurde nach der Übernahme durch Zoom de facto eingestellt
    • FOKS ist das neue Projekt der ursprünglichen Entwickler

  • del.icio.us: Social-Bookmarking-Dienst

    • Teilen von Bookmarks mit Menschen, die man tatsächlich kannte
    • Bot nützliches Tagging nach Kategorien
    • Wurde durch Reddit und Twitter ersetzt
    • Pinboard bot einen ähnlichen Dienst, verlor aber Nutzer durch schlechte Pflege und die politischen Ansichten des Gründers

Verwandte Beiträge

6 Kommentare

 
soonil 2025-10-20

Das sind Technologien, die Erinnerungen wecken.
 
roxie 2025-10-13

Ah … wurde das Keybase-Projekt eingestellt??
 
click 2025-10-13

Ich habe Vine wirklich oft genutzt; wenn es bis ins Zeitalter der Kurzvideos überlebt hätte, hätte es als Pionier der Kurzvideo-Branche wohl ziemlich viel Geld verdient.
 
unknowncyder 2025-10-13

Berriz Webshare?.. Ich erinnere mich, dass ich es als Kind trotz völliger Ahnungslosigkeit ziemlich einfach und bequem benutzt habe.
 
chicol 2025-10-13

Cyworld fehlt ...
 
GN⁺ 2025-10-13
Hacker-News-Kommentare

  • Das Betriebssystem Plan 9. Es war das System, das einem Nachfolger von Unix am nächsten kam, und entwickelte die Philosophie „alles ist eine Datei“ noch einen Schritt weiter, sodass sich Dateien einfach über das Netzwerk teilen und verteilte Systeme aufbauen ließen. In Plan 9 war der Zugriff auf Remote-Ressourcen einfach und zuverlässig, während man auf anderen Systemen für jeden Anwendungsfall inkompatible Software installieren musste. Es bot außerdem innovative UI-Funktionen wie mausgesteuerte Textbearbeitung, einen verschachtelten Window-Manager und den Plumber, der systemweit anhand von Textmustern Befehle ausführen konnte. Dank seiner verteilten Architektur wäre es eigentlich ideal für die heutige Zeit, in der mobile Geräte, Desktops, Cloud und IoT miteinander verbunden sind, doch stattdessen leben wir weiter mit Betriebssystemen, die nie dafür entworfen wurden. Heute existieren Forks wie 9front noch, aber das Original von Bell Labs ist verschwunden. Die Gründe für seinen Niedergang waren rechtliche Probleme wie Lizenzen und Klagen, wodurch die Einführung in der Industrie stockte, außerdem bevorzugten die Leute zu der Zeit, als man ein verteiltes OS hätte wollen können, lieber lokale Computer, und Plan 9 galt nur als Forschungs-OS, sodass es den Dotcom-Boom nicht nutzen konnte. Schließlich spielten auch der Wegfall von AT&Ts Einnahmequellen, der Verkauf von Bell Labs und der Abgang zentraler Mitglieder eine Rolle

    • Der größte Grund für das Scheitern von Plan 9 war, dass Hardwareanbieter es anders als Unix nicht günstig lizenzieren und frei für ihre eigene Hardware anpassen konnten. Bell Labs wollte Plan 9 als kommerzielle Software für 350 Dollar verkaufen, und deshalb wurde es in der Industrie nie richtig angenommen. Ich habe mehrfach Beiträge dazu verlinkt, die ich sehr zur Lektüre empfehle: Link1, Link2, Link3

    • Das Plan-9-Dateisystemprotokoll lebt in WSL2 immer noch weiter

    • Ich frage mich, warum andere Unix-artige Systeme die Philosophie „alles ist eine Datei“ nicht offensiver übernommen haben

    • In Plan 9 wurde das Problem symbolischer Links gelöst

  • Auch die Photon-Grafikoberfläche von QNX war trotz Echtzeitfokus funktional stark, mit Widgets, Anzeigen und mehr, und sie unterstützte sogar zwei Webbrowser ohne spürbare Latenz. Es fühlte sich wie ein echtes Echtzeitbetriebssystem an. Und Mac OS 8, genannt Copland, modernisierte das ursprüngliche Mac OS und behielt dabei die Tradition ohne Kommandozeile bei. Ohne Kommandozeile mussten Installation und Konfiguration aller Funktionen einfach und konsistent sein, und mit einem Übergang ins mobile Zeitalter wäre das vermutlich nahtlos gelungen. Tatsächlich bekamen Entwickler eine echte Version davon, aber weil Apple NeXT übernehmen musste, wurde das Copland-Projekt eingestampft. Auch das Konzept transaktionsorientierter Betriebssysteme war innovativ. Wie bei IBMs CICS werden Programme geladen, ausgeführt und dann beendet, was im Kontrast dazu steht, dass Unix und Linux im Kern terminalbasierte Time-Sharing-Systeme sind. IBM MicroChannel wiederum wollte die Vorteile der Mainframe-Kanäle auf PCs übertragen, scheiterte aber faktisch an seiner monopolistischen Politik. Heute verwenden fast alle Systeme ähnliche Konzepte, doch sie dienen nicht als integrierte Schnittstelle, die das OS vereinfacht. Und CPUs mit einem wirklich sauber funktionierenden Hypervisor gibt es im Unterschied zu den alten IBM-VM-Systemen kaum; bei x86 sind all diese Schichten letztlich Workarounds. Die Motorola-680x0-Serie hätte die Grundlage der Mikrocomputer-Ära werden sollen, aber die MMU kam zu spät, sodass sie den Takt nicht halten konnte. Modula-2 und 3 waren ziemlich gut, aber Oberon scheiterte, und DEC ging mit unter. Bei XHTML wurden in HTML5 Fehler formalisiert, was im Ergebnis unnötig tolerante Parsing-Regeln einführte. Schon ein einziges nicht korrekt geschlossenes Tag in Werbung oder Fremdcode konnte die ganze Seite sinnlos zerstören. Schließlich gab es mit Word Lens eine Innovation, bei der man mit dem Smartphone auf die Welt zeigen und maschinelle Übersetzung sogar offline nutzen konnte, aber sie verschwand nach der Integration in Google Translate

    • Ich möchte zu Copland einige Fakten korrigieren. Das Projekt war schwer missmanaged, und durch ungezügeltes Hinzufügen neuer Technologien litt es massiv unter Feature Creep und mangelnder Stabilität. Wenn man geleakte Builds ausprobiert, frieren schon einfache Desktop-Funktionen häufig ein oder stürzen ab. 1996 kam Apple intern zu dem Schluss, dass Copland nicht veröffentlichbar war, und prüfte deshalb externe OS-Lizenzen, was schließlich zur Übernahme von NeXT führte. Nicht Copland wurde beendet, um NeXT zu kaufen, sondern Copland war so weit von einer möglichen Veröffentlichung entfernt, dass es keine andere Wahl gab

    • Ich hatte einmal eine Phase, in der ich mich stark mit XHTML beschäftigt habe, aber ich habe erlebt, dass die gesamte Seite gar nicht mehr angezeigt wurde und nur noch eine große Fehlermeldung erschien, weil ein einziges Werbe-Tag oder etwas anderes außerhalb meiner Kontrolle falsch geschlossen war. Der Ansatz, „den Rest einfach in Times New Roman auszugeben“, ist praktisch ebenfalls nicht realistisch. Wenn man letztlich doch HTML parst, ist man wieder kaum anders aufgestellt als zuvor. Als Enthusiast kann ich meinen eigenen Code perfekt schreiben, aber in der Realität arbeiten die meisten Menschen schlampig. XHTML wirkte logisch plausibel, war in der Praxis wegen der menschlichen Natur aber kein gangbarer Ansatz

    • Man kann einen strengen Stil wie bei XHTML mögen, aber für Webdokumente, die breit geteilt werden, passt kein unnachgiebiges Framework. Bei Dateiformaten würde ich zwei Kategorien unterscheiden: (1) Open Loop, bei dem der Empfänger den Autor nicht kontaktieren kann (HTML, pdf, zip, csv usw.) — hier sind die Daten selbst wichtiger als das Format, also muss man auch defekte pdfs oder zips lesen können. (2) Closed Loop, bei dem der Empfänger den Autor kontrollieren kann (etwa Programmquellcode) — hier sind strenge Parser vertretbar. XHTML ist ein Modell, das höchstens in (2) funktioniert, HTML gehört aber zu (1). Außer in inhärent geschlossenen Umgebungen wie internen Unternehmensdokumenten ist XHTML schwer durchzusetzen

    • Ich sehe die tolerante Behandlung fehlerhafter Tags in HTML5 kritisch. Die meisten anderen Formate stoppen beim ersten Fehler, nur HTML ist eine Ausnahme. Das hat viele Sicherheitslücken geschaffen und es für alle Entwickler nur schwieriger gemacht. Die Parsing-Linie von HTML5 ist aus meiner Sicht dadurch entstanden, dass Leute, die gegen das träge Internet Explorer-Ökosystem antraten, entweder zu idealistisch wurden oder unter dem Namen von Standards einfach Bugs dokumentierten. Relevantes RFC

    • Die Forderung, Tags „korrekt“ zu schließen, erhöht nur die Einstiegshürde der Sprache. Früher haben viele HTML von Hand geschrieben, dabei Fehler gemacht, aber trotzdem erschien erst einmal irgendetwas auf dem Bildschirm, sodass sie weitergemacht haben. Echte Programmiersprachen hingegen spucken bei kleinen Fehlern furchtbare Fehlermeldungen aus, wodurch man leicht aufgibt. Neuere Sprachen haben das verbessert, etwa Rust, aber in der XHTML-Zeit waren selbst kleine Fehler oft schwer zu verstehen

  • Ich würde Google Wave nennen. Ich habe damals zuerst eine Demo von Chris DiBona gesehen, und sie war wirklich großartig. Echtzeitübersetzung, Integration verschiedener Messaging-Dienste, Open Source und jede Menge beeindruckender Funktionen. Aber das tatsächlich veröffentlichte Wave war eine abgespeckte Version, und der Markt ignorierte es, was ich sehr bedauerlich fand. Am Ende bleiben JIRA, Slack und E-Mail zurück, und man spürt deutlich die Lücke, die Wave hinterlassen hat

    • Der Tech-Stack von Google Wave war hervorragend, aber beim UI-Design wurde ein fataler Fehler gemacht. Wave behandelte eine Wave nicht als einzelnes Dokument, sondern als mehrere getrennte Einträge, wodurch alles nur komplex wirkte und die Vorteile verloren gingen

    • Ich war von der Demo beeindruckt, kam nach kurzem Nachdenken aber zu dem Schluss, dass es schrecklich war. Wie bei Slack muss man jedes Channel-Update einzeln verfolgen, nur war diese Struktur bei Wave noch deutlich komplizierter, sodass ich sofort das Gefühl hatte, dass man unmöglich Schritt halten könnte

    • Die technische Leistung von Wave war enorm, aber wenn man sich das Demovideo heute noch einmal ansieht, erkennt man, dass es einfach kein besonders gutes Produkt war. Man wollte ein All-in-one-Produkt für alles bauen und scheiterte damit. Stattdessen wurden diese Technologien auf verschiedene Google-Produkte verteilt, und es stellte sich heraus, dass getrennte UIs pro Funktion viel intuitiver sind

    • Es war perfekt, um gemeinsam mit Freunden Reisepläne und Ähnliches zu verwalten, und auch für Ad-hoc-Diskussionen mit Dokumenten und Links war das Formfaktor von Wave sehr effektiv. Es fühlte sich an, als würde man in die Zukunft blicken, und als Anfänger habe ich sogar selbst ein Server-Management-Plugin gebaut: Wave-ServerAdmin. 16 Jahre sind vergangen, also ist es wohl Zeit, das Repository zu archivieren

    • Ich habe tatsächlich einmal den Open-Source-Wave-Server heruntergeladen, um vielleicht ein Produkt darauf aufzubauen, aber die größte Einschränkung war, dass Daten nicht dauerhaft gespeichert werden konnten. Für mich hatte es deshalb keine Zukunft, und die Reaktion der Leute im Wave-Team wirkte auf mich, als hätten sie den Realitätsbezug verloren und würden in einer Fantasie leben. Trotzdem war es ein großartiges Konzept

  • Adobe Flash / Shockwave: Selbst Jahrzehnte später gibt es kaum ein Tool, mit dem sich Spiele oder Multimedia so einfach erstellen lassen. Es erinnert daran, dass die Menschheit sich nicht immer nur in eine Richtung weiterentwickelt und manchmal dauerhaft etwas Wertvolles verliert

    • Weil selbst Einsteiger damit leicht Spiele machen konnten, entstand in der gesamten Spielebranche eine Welle frischer Ideen. Indie-Entwickler wie Zachtronics haben auf diesem Weg debütiert. Andererseits war jedes einzelne Flash-Spiel mit einer Flut von Werbung und billiger Flash-Navigation umgeben, und zeitweise bestanden praktisch alle Restaurant-Websites aus Flash. Flash-basierte Videoplayer waren unter Linux eine Qual und haben die Einführung ordentlicher Video-Unterstützung im Browser erheblich verzögert

    • Flash war eine Katastrophe fürs Web. Es war ein schwarzer Kasten, bei dem nichts funktionierte: Zoomen, Text markieren, Zurück-Taste — nichts. Dass es gestorben ist, fühlt sich fast wie Steve Jobs’ größte Leistung an

    • Godot kommt dem inzwischen ziemlich nahe. Es ist leicht zu lernen, unterstützt 2D und 3D und kann via HTML5/webasm auf die großen Betriebssysteme und auch auf Mobilgeräte exportieren. Perfekt ist es noch nicht, aber in den letzten Jahren hat es enorme Fortschritte gemacht, und es fühlt sich ein wenig an wie bei Blender kurz vor dem großen Durchbruch

    • Selbst wenn Adobe alle Sicherheitsprobleme vollständig gelöst hätte, hätte Apple es ohnehin getötet. Der populäre Erfolg von Flash war für Apple eine Bedrohung. Und obwohl der HTML-canvas-Hype längst abgeflaut ist, gibt es bis heute keine echte Alternative, mit der Designer ohne Abo großartige interaktive Designs erstellen und überall einbetten können

    • Das Problem war, dass Flash viel zu sehr missbraucht wurde. In einer Firma bestand eine Anwendung bis zuletzt auf Flash, und als ich nach dem Grund suchte, stellte sich heraus, dass die einfache horizontale Trennlinie auf der Seite in Flash umgesetzt war. Flash-Dropdown-Menüs, Splash-Screens auf Auto-Websites — alles Fehlgebrauch. Erst mit dem mobilen Zeitalter konnte Flash wirklich sterben, und damals haben das nur noch sehr wenige betrauert

  • Es gibt unzählige Google-Dienste, die man auf killedbygoogle.com sehen kann. Ich habe einmal 30 bis 40 davon genutzt, heute sind es nur noch 3 oder 4. Google Picasa war lokal schnell nutzbar, Google Hangouts hat wegen der vielen Chat-Apps nur Verwirrung hinterlassen. G Suite Legacy sollte lebenslang kostenlos sein, wurde dann aber doch kostenpflichtig, woraufhin ich Google verlassen habe. In Google Play Music hatte ich Tausende hochgeladene MP3s, doch nach dem Ende des Dienstes habe ich keine Lust, sie noch einmal hochzuladen. Bei Google Finance und NFC Wallet war das Vertrauen in die Daten weg, deshalb bin ich umgezogen. Chromecast Audio konnte genau die eine Sache, die ich brauchte, und als ich von der Einstellung erfuhr, habe ich es bald verkauft. Dass sogar Chromecast eingestellt wurde, habe ich erst während der Nutzung erfahren

    • Google Reader vermisse ich ebenfalls bis heute. Die Betriebskosten dürften nicht einmal besonders hoch gewesen sein, und es wäre so eine Funktion gewesen, bei der es mich nicht gestört hätte, wenn sie jahrelang nicht weiterentwickelt worden wäre. Früher wie heute nutze ich RSS auf die gleiche Weise

    • Die in Google Play Music hochgeladene Musik ist nicht komplett verschwunden. Wenn man zu YouTube Music migriert ist, wurden die Titel übertragen, ohne dass man sie erneut hochladen musste

    • Chromecast Audio funktioniert immer noch hervorragend. Es wird nur nicht mehr verkauft, deshalb halte ich auch ständig Ausschau nach gebrauchten Geräten

    • Die Gesichtserkennung in Picasa war ihrer Zeit voraus, und das Offline-Paket war wirklich hervorragend. Leider gab es in der letzten Version einen Bug, durch den Gesichts-Tags zufällig vertauscht wurden, womit die Erkennung bei ein paar tausend Familienfotos praktisch unbrauchbar wurde. Digikam schafft etwas Ähnliches nur mit Mühe und ist als Ersatz eher schwach

    • Es ist interessant, dass Google einige Jahre nach dem Ende von Google Notebook mit Google Keep fast dasselbe Produkt noch einmal gebaut hat

  • Die Light-Field-Kamera von Lytro war technisch beeindruckend, und es kamen sogar zwei Produkte auf den Markt, aber für professionelle Fotografie reichte die Auflösung nicht aus. Mit Metas Ray-Ban-Light-Field-Display und Medien wie gaussian splats scheint nun jedoch ein Punkt erreicht zu sein, an dem sich mehr Sensordaten sinnvoll nutzen lassen. Abseits der Technik ist der Markt für pfiffige Kameras mit niedriger Auflösung wie Polaroid oder Instax groß genug, sodass die erste Lytro mit ihrem interessanten Formfaktor auch mit eingebautem Drucker gut hätte funktionieren können

    • Light Field zeichnet Pixel auf, indem Informationen aus mehreren Fokustiefen gemischt werden, daher ist die resultierende Auflösung strukturell zwangsläufig geringer als bei einer normalen Kamera. Die Herstellung ist nicht das Problem, schade ist eher diese physikalische Grenze

    • Es wirkt so, als würden Smartphones diese Funktion heutzutage teilweise ebenfalls umsetzen. Ich erinnere mich noch daran, wie begeistert ich vom Erscheinen der Lytro-Kamera war

  • Optane Persistent Memory hatte mit direkter Datenspeicherung das revolutionäre Potenzial, sofort dort weiterzuarbeiten, ohne neu zu booten oder Apps zu laden. Es scheiterte am hohen Preis, doch seine Grenzen waren schon vorher sichtbar. Durch Dinge wie Memory-Snapshots von VMs oder Container in macOS ist diese Richtung aber nicht vollständig verschwunden

    • Ich habe grenzenloses Vertrauen in die 3dxpoint-Technologie. Sie war über Jahrzehnte gereift, aber auf der Business-Seite fehlte die Geduld, darauf zu warten, dass die Welt ihr folgt

    • Die Denkweise bestehender Systeme war zu sehr in der Trennung zwischen RAM und Festplatte gefangen und daher nicht bereit, neue Hardware wie Optane wirklich aufzunehmen. Trotzdem gibt es im Server-Bereich einige Anwendungsfälle, und auch viele Forschungsprojekte sind daraus entstanden

    • Optane war technisch unglaublich. Es hätte die Grenze zwischen RAM und Festplatte fast aufgehoben, sodass ein einziger Stick für den gesamten Speicher gereicht hätte

    • Ich habe den Kernel tatsächlich auf einem Optane-Laufwerk liegen und erlebe dadurch quasi Sofort-Boots

    • Es lag nicht nur am Preis; auch das Ökosystem war nicht weit genug verbreitet, und die bestehende Denkweise war noch nicht bereit dafür. Das Modell liegt eher näher an frühen Lisp- oder Smalltalk-Umgebungen mit (Live-)Images. Ich selbst besitze auch ein System mit Firmware-Unterstützung und kleinem Optane-Modul. Die Kapazität ist gering und an ein altes OS gebunden, aber zum Experimentieren lohnt es sich. Mit genug RAM kann man so etwas wie suspend/resume auch nachbilden. Zusammen mit den Fortschritten bei SSDs ist der Geschwindigkeitsunterschied fast verschwunden. Übrig bleibt vor allem die Haltbarkeit wie etwa TBW. Man kann auch beides kombiniert nutzen

  • Das Ricochet-Netzwerk war ein einzigartiges System, das im Zeitalter der Telefonleitungen per drahtlosem Paket-Mesh Geschwindigkeiten auf ISDN-Niveau bot. 5 Milliarden Dollar wurden in Netze in 23 Städten investiert, aber es gab praktisch keine Kunden, und 2001 war Schluss. Das Marketing zielte auf „mobile Professionals“, ignorierte damit jedoch den Haushaltsmarkt, der in Wirklichkeit schlicht schnelleres Internet wollte. Heutige 5G-Femtocells ähneln dem physischen Konzept, aber ihnen fehlen Redundanz und die Idee des Self-Routing

    • Ricochet war ein großartiges System, das seiner Zeit voraus war. Auch Joel Spolskys Rückblick dazu ist lesenswert: Review des Ricochet-Wireless-Modems

    • Ich habe mein Ricochet-Modem wirklich geliebt. Ich erinnere mich daran, wie ich mit einem Ricochet der zweiten Generation und einem PowerBook in einem Café in Palo Alto saß und mit 56k im Web surfte und SSH-Sessions hatte. Irgendwo zu Hause habe ich es noch in einer Kiste und überlege, ob ich es aus Spaß einmal im Star-Modus verbinde

    • 1998 bis 1999 habe ich in San Francisco ein Ricochet-Modem genutzt. Zehn Jahre später brachte das iPhone das 3G-Zeitalter, und die Leistungssteigerung war überwältigend. Wenn ich darüber nachdenke, ob mein Leben besser gewesen wäre, wenn Ricochet überlebt hätte, komme ich eher zu dem Schluss, dass der technologische Fortschritt am Ende in eine deutlich sinnvollere Richtung gegangen ist

    • Diesen Dienst hatte ich völlig vergessen, aber wenn ich so darüber nachdenke, war er damals wirklich außergewöhnlich. Ich war wohl einer der nur vier Kunden

  • Midori von Microsoft war ein OS mit dem Ziel einer fähigkeitsbasierten Sicherheit. Gerüchten zufolge war es so weit entwickelt, dass Windows-Code darauf laufen konnte, und wurde dann durch interne Politik eingestellt. Es war so etwas wie ein Vorläufer von Fuchsia. Midori-Wiki

    • Midori war wirklich spannend. Joe Duffys Blog ist wohl die detaillierteste Quelle dazu: Midori-Blog. Innerhalb von Microsoft galt es wohl als Moonshot und auch als Projekt zur Bindung wichtiger Talente. Es waren über hundert Leute beteiligt, darunter sehr viele ausgesprochen erfahrene Ingenieure. Ein Teil der Forschungsergebnisse floss später in .NET ein und ist also nicht komplett verschwunden

    • Ich weiß nicht, woher das Gerücht kommt, dass Windows-Code darauf laufen konnte. Nach allem, was öffentlich dokumentiert ist, zielte Midori gerade auf vollständige Inkompatibilität zu bestehendem Code. Vielleicht träumten intern manche von einer Migration, aber das Design war von Grund auf ein neues System ohne sanften Übergang

    • Die technischen Grundlagen sind interessant, aber bei Microsoft wäre am Ende vermutlich ohnehin aufgeblähte Software voller neuer Spezialprobleme daraus geworden. Inzwischen wäre sie wahrscheinlich zusätzlich mit Spyware und AI-Funktionen vollgestopft, die niemand ursprünglich wollte

    • Kennst du Genode (genode.org)? Das liegt in einem ähnlichen Bereich wie Midori und wird noch aktiv weiterentwickelt

  • Yahoo Pipes war wirklich großartig, um RSS-Feeds und benutzerdefinierte Workflows zu bauen. Heute gibt es Alternativen wie Zapier oder n8n, aber Pipes mochte ich besonders gern. Und auch beim Rückblick auf Google Reader stimme ich zu

    • Ich empfehle dringend, das Archiv Die Geschichte von Pipes zu lesen. Darin stecken Rückblicke der tatsächlichen Entwickler

    • Yahoo Pipes war die Zukunft, in die sich das Internet hätte entwickeln sollen. Selbst Jahrzehnte später wird diese Art von Verknüpfung zwischen Werkzeugen nur mühsam auf dem Niveau echter Unix-Pipes umgesetzt

    • Ich habe es nie selbst benutzt, aber jedes Mal, wenn ich positive Erinnerungen an Pipes höre, wirkt es wie ein unglaubliches Werkzeug. Ich weiß nicht, ob wirklich Pipes gestorben ist oder ob vielmehr das offene, auf Standards und Protokollen basierende Masseninternet verschwunden ist

    • Ich habe Pipes geliebt. Ich habe Inhalte von mehreren Websites gesammelt, sie mit Pipes formatiert und per RSS in ein PHP-Blog gezogen. Aber nach und nach stellten die Websites ihre RSS-Unterstützung ein, wodurch auch Pipes an Bedeutung verlor und schließlich beendet wurde. Eine Zeit lang nutzte ich dann die Python-Bibliothek riko, um ohne visuellen Editor etwas Ähnliches zu machen, und das wurde für mich sogar der Einstieg von PHP in Richtung Python

    • Wenn man die Idee von Yahoo! Pipes wiederbeleben möchte, ist Node-RED (nodered.org) ein guter Ausgangspunkt. Open Source, solide API, mehr als zehn Jahre angesammelte Erfahrung, robustes Backend und vieles mehr sprechen dafür. Ich habe auch Browser-Red ausprobiert, das nur das Node-RED-Frontend übernimmt, sowie Erlang-Red, das das Backend in Erlang neu aufbaut. Ein Unterschied ist, dass Node-RED bei allen Nodes nur einen oder keinen Input-Port hat, während Pipes mehrere Eingangsverbindungen erlaubte. Das Frontend ist angenehm zugänglich, wenn man jQuery kennt. Falls jemand Fragen zu Node-RED oder zu flow-based programming hat, kann er sich jederzeit melden