Ask HN : Existe-t-il des projets interrompus ou abandonnés trop tôt ? Pourquoi ?
(news.ycombinator.com)- Question et réponses sur des projets disparus parce qu’ils étaient en avance sur leur temps ou parce que le marché n’était pas prêt
Je suis juste curieux. Qui sait qui pourrait adopter ça, ou développer quelque chose de nouveau à partir de cette idée.
Système d’exploitation Plan 9
-
Système d’exploitation distribué de Bell Labs, considéré comme le véritable successeur d’Unix, mais qui a échoué à se commercialiser
- Conception innovante qui étendait la philosophie « tout est fichier » jusqu’au partage réseau
- Proposait des fonctionnalités d’interface originales comme le codage à la souris, un gestionnaire de fenêtres imbriquées et Plumber
- Idéal pour les environnements distribués reliant mobile, desktop, cloud et IoT, mais n’a pas été adopté
-
Causes de l’échec
- Problèmes de licence et poursuites judiciaires ayant détourné l’industrie
- Décalage avec une époque où l’informatique centralisée déclinait et où l’ordinateur personnel montait en puissance
- Positionné uniquement comme OS de recherche, il n’a pas profité du boom des .com
- Avec la baisse des revenus téléphoniques d’AT&T, Bell Labs a été revendu à plusieurs reprises
- La Version 3 était vendue 350 $ par boîte, mais réservée à un usage non commercial
- Le projet n’a pas été réellement publié en open source avant 2004
-
Héritage
- Le protocole de système de fichiers 9P continue d’être utilisé dans WSL2, l’écosystème des VM et Kubernetes
- Il existe des forks actifs comme 9front
- La Plan 9 Foundation gère le code open source et les droits
Les projets morts de Google
-
Témoignage d’un utilisateur qui est passé de 30 à 40 produits Google utilisés à seulement 3 ou 4
- Google Picasa : outil de gestion photo local, rapide et excellent
- Google Hangouts : victime de la stratégie confuse de Google sur la messagerie
- G Suite Legacy : Google a rompu sa promesse de « gratuit à vie » pour le rendre payant
- Play Music : après avoir uploadé des milliers de fichiers MP3, l’arrêt du service a entraîné une perte de données
- Google Finance : permettait de suivre des actions, puis a été abandonné
- Google NFC Wallet : Apple a pris le marché avec la même fonction
- Chromecast Audio : excellent dans sa fonction unique, mais abandonné
-
Google Reader : la pire décision business de l’histoire
- Service arrêté malgré des besoins de maintenance minimes à long terme
- Comptait parmi ses utilisateurs des fondateurs, CTO, VP of Engineering et d’autres profils influents
- A laissé à l’industrie la leçon de ne pas faire confiance aux produits Google
- Sa fermeture illustre une culture d’entreprise où économiser quelques millions de dollars devient un indicateur de performance
Adobe Flash / Macromedia Flash
-
Plateforme de création multimédia dont, 15 ans plus tard, aucun outil de remplacement équivalent n’existe vraiment
- Permettait de créer jeux et contenus multimédias aussi facilement qu’avec des briques Lego
- Offrait un ensemble d’outils intuitifs comme MovieClip et l’animation sur timeline
- Remplacé par HTML Canvas, mais sans comparaison possible sur la qualité des outils
-
Pourquoi l’iPhone a tué Flash
- Sur le matériel de 2007, les problèmes de performance et la consommation de batterie étaient graves
- Flash pouvait devenir un contournement de l’écosystème d’apps
- Risquait de faire percevoir l’iPhone comme un « produit poubelle »
-
Situation actuelle
- Adobe Animate prend en charge la sortie JS/Canvas, mais ce n’est plus l’original
- Des émulateurs comme Ruffle permettent d’exécuter une partie du contenu legacy
- Roblox joue en partie un rôle similaire, mais de façon plus limitée et plus commerciale
Les projets ratés de Microsoft
-
Silverlight : plugin web basé sur C#
- Permettait d’utiliser du vrai C# à la place de JavaScript
- UI vectorielle consciente du DPI, pattern MVVM et binding bidirectionnel
- Collaboration designer-développeur via Expression Blend
- Rendu totalement identique sur tous les navigateurs
- L’iPhone a aussi provoqué la chute de Silverlight, en plus de Flash
-
Midori : OS à sécurité par capacités
- Avait progressé jusqu’à pouvoir exécuter du code Windows, mais a été arrêté pour des raisons politiques internes
- De nombreux résultats de recherche ont été intégrés à .NET
- Plus de 100 personnes y ont travaillé comme projet de rétention pour garder de très bons ingénieurs
Divers
-
Copland d’Apple (prototype de MacOS 8)
- Version modernisée de MacOS sans ligne de commande
- Comportait des fonctions qui auraient pu faciliter la transition vers le mobile
- Impossible à sortir à cause du feature creep et de l’instabilité
- Selon une rumeur, il aurait été abandonné intentionnellement pour justifier l’acquisition de NeXT par Apple
-
Songsmith : génération automatique d’accompagnement pour une mélodie
- Proposait dès 2009 la détection d’accords en temps réel et la génération d’accompagnement
- Précurseur des outils de musique IA comme Suno ou Udio
- Est devenu un mème à cause d’une vidéo promotionnelle kitsch, malgré une vraie qualité technique
Le déclin de Heroku
-
Son succès initial venait de sa simplicité et de sa focalisation
- Un seul langage, une seule plateforme de déploiement, une seule base de données
- Fatigue décisionnelle minimale
- Si l’IA avait existé il y a 15 ans, elle aurait été plus efficace grâce à des données d’apprentissage cohérentes
-
Causes du déclin
- Après l’acquisition par Salesforce, l’ajout d’un énorme bandeau de marque a suscité un rejet des utilisateurs
- L’arrivée de Docker et Kubernetes l’a rendu remplaçable
- La suppression de l’offre gratuite a fait fuir beaucoup de clients
- Les abus de calcul gratuit liés aux cryptomonnaies ont aggravé le problème
-
Situation actuelle
- Certains l’utilisent encore en production
- Vercel, Coolify et Dokku offrent une expérience similaire
ReactOS - réimplémentation de Windows NT
-
En développement depuis près de 30 ans, mais toujours inutilisable en pratique
- Wine + noyau + compatibilité pilotes de périphériques + cible mouvante
- Même à l’approche de la fin du support de Windows 10, il ne constitue pas une alternative
-
Causes de l’échec
- Le code source de Windows est mal documenté et mal compris
- Le principe de rétro-ingénierie en clean room empêche quiconque a vu le code Windows de contribuer
- Même après la fuite du code source de Windows XP, les progrès sont restés lents
- Wine, Proton et la virtualisation se sont imposés comme alternatives pratiques
Delphi et Pascal
-
Langages de programmation idéaux pour l’enseignement
- Compilateur ultra-rapide, adapté à l’apprentissage par essais et erreurs
- Système de types propre (moins complexe que Rust)
- Excellents pour apprendre les bases de la programmation sans fonctionnalités de langage trop spécialisées
-
Situation actuelle
- Delphi existe toujours, avec des versions sorties jusqu’à la 13
- Lazarus existe comme alternative open source
- Python l’a remplacé comme langage d’enseignement, mais avec un système de types plus confus
Du hardware innovant mais raté
-
MicroChannel (IBM) : architecture de périphériques basée sur des canaux
- Transposait au PC le concept de canal des mainframes
- Permettait d’exécuter de petits programmes de canal
- A échoué sur le marché à cause d’une licence propriétaire
- Tous les systèmes modernes utilisent aujourd’hui des fonctions similaires, mais sans interface unifiée
-
Motorola 680x0 : processeur qui aurait pu devenir la base de l’ère des micro-ordinateurs
- Lancé en 1978, mais le MMU est arrivé trop tard
- C’était le cœur de l’Amiga et des premiers Macintosh
-
Optane Persistent Memory : technologie brouillant la frontière entre RAM et stockage
- Permettait de rendre persistantes directement les structures de données
- Plus besoin de redémarrer ni de relancer une app : on reprend exactement là où on s’était arrêté
- Échec à cause d’un coût trop élevé, malgré une technologie révolutionnaire
- Manque de patience des décideurs business
-
Lytro, appareil photo light field : mise au point après la prise de vue
- Capture toutes les données, puis permet de choisir la mise au point ensuite
- Aurait été parfaitement compatible avec des technologies modernes comme Gaussian splat ou les lunettes Meta Ray-Ban
- N’atteignait pas la qualité d’image exigée par les photographes professionnels
- Aurait peut-être dû viser un marché de niche gadget à la Polaroid/Instax
Les débats autour des technologies web
-
L’échec de XHTML
- Voulait corriger le chaos de HTML grâce à un parsing strict
- HTML5 a fini par standardiser jusqu’au sens du HTML invalide
- La loi de Postel est mauvaise : un parsing permissif entraîne des failles de sécurité et des problèmes de compatibilité
- Le principe « s’arrêter à la première erreur et afficher un message » aurait été préférable
-
Contre-argument : la vraie raison de l’échec de XHTML
- IE6 ne prenait pas en charge
application/xhtml+xml - Il a fallu supporter IE6 pendant près de 15 ans
- JSX et JSON ont réussi malgré une syntaxe stricte
- Tous les langages backend utilisent une syntaxe stricte
- Le problème n’était pas la barrière à l’entrée, mais le support navigateur
- IE6 ne prenait pas en charge
-
La réalité de HTML
- Une erreur de guillemets dans un attribut peut empêcher le rendu de toute la page
- Le format doit pouvoir être écrit par des non-spécialistes
- HTML est un format de document, pas un ensemble d’instructions
- PDF, ZIP et CSV lisent aussi des fichiers corrompus (les données importent plus que le format)
Réseaux sociaux et communication
-
Google Wave : a montré le futur, mais trop tôt
- Traduction en temps réel, intégration de multiples messageries, nombreuses fonctions
- Était entièrement open source
- Son UI trop complexe, avec des « fils de mises à jour temps réel imbriqués », était écrasante
- Intégrait déjà des fonctions aujourd’hui éparpillées entre Slack, JIRA et l’e-mail
-
Vine : la vidéo courte avant TikTok
- Avait déjà atteint une taille importante en 2013
- Twitter l’a stoppé parce qu’il ne savait pas comment le monétiser
- TikTok est arrivé quelques mois après la fin de Vine
- Il aurait suffi de mettre des bannières pub autour des vidéos carrées, mais l’occasion a été ratée
-
Skype : la visioconférence que même votre grand-mère savait utiliser
- Aussi simple qu’un téléphone, mais moins cher qu’un appel international
- L’un des meilleurs logiciels P2P
- A été très mal remplacé par Microsoft Teams
- Configuration matérielle externe difficile, problèmes de compatibilité, disparition de l’ancien service de test audio
Systèmes d’exploitation
-
Maemo/MeeGo : le Linux mobile que Nokia aurait dû pousser
- Le N9 était un appareil exceptionnel, mais un seul modèle est sorti
- Réunissait hackabilité, élégance et sécurité
- On pourrait aujourd’hui avoir deux Linux mobiles grand public autres qu’Android et iOS
- Le projet survit en partie avec Sailfish OS
-
BeOS : OS optimisé pour le multimédia
- Il est surprenant d’avoir dû scroller si loin avant de voir mentionner BeOS et Amiga
- Une réimplémentation from-scratch est en cours avec Haiku OS
- Nettement plus rapide et réactif que Linux+X+Qt+KDE
-
OS/2 : la tragédie née de la collaboration entre IBM et Microsoft
- Système doté d’une excellente API
- Si Workplace Shell et le code SOM avaient été publiés, ils auraient pu être réutilisés dans d’autres OS
- A longtemps été utilisé dans les ATM bancaires sans se faire pirater
Outils de développement
-
Quartz Composer : programmation visuelle nodale d’Apple
- Environnement de programmation visuelle basé sur des patches
- Surveiller un périphérique USB pouvait se faire avec 3 nœuds seulement
- Plus de mises à jour depuis 2016, et beaucoup de nœuds sont cassés sur les OS récents
- Mériterait d’être réévalué à l’heure où la programmation nodale est populaire dans Blender et Unreal Engine
-
Atom, éditeur de code : aurait pu devenir une alternative à VS Code
- Alternative grand public créée par GitHub
- Le destin d’Atom a été scellé après le rachat de GitHub par Microsoft
- Projet à l’origine d’Electron
- Ses développeurs d’origine travaillent maintenant sur l’éditeur Zed
-
Non DAW : DAW séparée par fonctions
- Chaque fonction était fournie comme application indépendante
- Quand on n’utilise qu’une partie des fonctions, les autres ne gênent pas
- Tous les concepts étaient présentés en 25 lignes d’exemple
- Le développeur principal a été recruté par Microsoft et travaille sur de l’OSS Rust
Langages de programmation
-
Elm : langage fonctionnel incomplet et peu actif
- La suppression des opérateurs personnalisés a cassé tout le code et fait perdre l’élan du projet
- L’architecture Elm est jugée trop rigide
- F# (Fable), ReasonML, OCaml (Bucklescript), Haskell et PureScript sont cités comme alternatives
-
Opa : le Next.js typé de 2012
- Framework full-stack typé avant TypeScript
- Sorti à une époque où le marché était sceptique vis-à-vis de Node.js côté serveur
- La licence AGPL a porté le coup fatal ; le passage ultérieur à MIT n’a pas suffi à offrir une seconde chance
-
Austral : langage d’une grande clarté et originalité
- Offre une spec à la clarté inhabituelle
- Son auteur n’y travaille plus activement
- Pour les hobbyists, il manque de communauté et d’écosystème
-
Ceylon : langage JVM de Red Hat
- En concurrence avec Groovy, Kotlin et Scala
- Proposait des types union anonymes, des compréhensions et un vrai système de modules
- Offrait plus qu’un simple sucre syntaxique au-dessus de Java
- A perdu face à Kotlin et a été laissé à l’abandon dans Eclipse
Échecs commerciaux
-
Google Stadia : plateforme de cloud gaming
- A bâti une plateforme de streaming solide
- A échoué faute de jeux intéressants
- Une petite sélection de jeux déjà disponibles ailleurs ne suffisait pas
-
Fire Phone : smartphone d’Amazon
- Visait un marché inexistant
- Avec le recul, il est difficile de croire que certains y voyaient un succès possible
-
Project Ara : smartphone modulaire de Google/Motorola
- Smartphone personnalisable
- On aurait aimé voir quelques itérations de plus
- Il aurait sans doute été trop épais pour rivaliser
Bases de données et backend
-
RethinkDB : base de données temps réel
- A échoué en voulant élargir son périmètre avec Horizon BaaS
- Existe encore techniquement sous l’égide de la Linux Foundation, mais a perdu son élan
- Le concept initial était excellent pour les démos, mais manquait de vrais cas d’usage en production
-
Yahoo Pipes : outil de combinaison de flux RSS et de data flows
- Montrait ce que l’internet aurait dû être
- L’interconnexion entre outils reste au niveau de pipes Unix rudimentaires
- Zapier et n8n sont des remplaçants modernes, mais sans le même esprit
- Node-RED, Apache Camel et Apache Nifi sont des alternatives enterprise
Autres projets notables
-
Sandstorm : plateforme web distribuée de 2014
- Basée sur des idées proches de BitTorrent
- Code et données de sites web entièrement distribués
- Pouvait s’intégrer à des sites web existants
- Le mécanisme de Grain (isolation des données) compliquait l’adaptation des apps existantes
- Il aurait mieux valu le marketer comme une plateforme pour développer des apps from scratch plutôt que pour en porter
-
Keybase : réseau social fondé sur le chiffrement
- Offrait un chiffrement fort et une vérification d’identité solide
- A été de facto interrompu après son rachat par Zoom
- FOKS est le nouveau projet des développeurs d’origine
-
del.icio.us : service de bookmarking social
- Permettait de partager des bookmarks avec de vraies connaissances
- Offrait un système utile de tags par catégories
- A été remplacé par Reddit et Twitter
- Pinboard proposait un service similaire, mais le manque de maintenance et les opinions politiques du fondateur ont fait partir les utilisateurs
6 commentaires
Ce sont des technologies qui rappellent de bons souvenirs.
Ah... le projet Keybase a été abandonné ??
J’utilisais vraiment beaucoup Vine ; s’il avait survécu jusqu’à l’ère des formats courts, il aurait sans doute gagné pas mal d’argent en tant que pionnier du secteur des vidéos courtes.
Berryz WebShare ?.. Je me souviens l’avoir utilisé assez facilement et confortablement quand j’étais jeune, même sans aucune connaissance.
Cyworld n'y est pas..
Avis Hacker News
Le système d’exploitation Plan 9. C’était le système le plus proche d’un successeur d’Unix, poussant encore plus loin la philosophie du « tout est fichier », en facilitant le partage de fichiers sur le réseau et la construction de systèmes distribués. Dans Plan 9, l’accès aux ressources distantes était simple et fiable, alors que sur les autres systèmes il fallait installer, pour chaque cas d’usage, des logiciels peu compatibles entre eux. Il proposait aussi des innovations d’interface comme l’édition de texte fondée sur le codage à la souris, un gestionnaire de fenêtres imbriquées, et le Plumber, qui exécutait des commandes à l’échelle du système selon des motifs textuels. Grâce à son architecture distribuée, il aurait été idéal pour l’époque actuelle où mobiles, desktops, cloud et objets connectés sont interconnectés, mais nous restons en pratique sur des systèmes d’exploitation qui n’ont pas été conçus ainsi. Des forks comme 9front existent encore, mais l’original de Bell Labs a disparu. Les raisons de cet échec incluent des problèmes juridiques (licences, procès, etc.) qui ont freiné son adoption dans l’industrie, le fait qu’à l’époque où l’on voulait des OS distribués les gens préféraient les ordinateurs locaux, son image d’OS de recherche qui l’a empêché de profiter pleinement du boom des dot-com, ainsi que la perte de la source de revenus d’AT&T, la vente de Bell Labs et le départ de membres clés.
La principale raison de l’échec de Plan 9 est qu’à la différence d’Unix, les fournisseurs de matériel ne pouvaient pas obtenir une licence bon marché et le modifier librement pour leur propre matériel. Bell Labs voulait vendre Plan 9 comme logiciel commercial à 350 dollars, ce qui a empêché sa véritable adoption par l’industrie. J’ai déjà mis en avant plusieurs textes à ce sujet, je recommande leur lecture : lien1, lien2, lien3
Le protocole de système de fichiers de Plan 9 survit encore à l’intérieur de WSL2
Je me demande pourquoi les autres systèmes de type Unix n’adoptent pas plus activement la philosophie du « tout est fichier »
Dans Plan 9, le problème des liens symboliques a été résolu
L’interface graphique Photon de QNX était elle aussi orientée temps réel, tout en offrant de bons widgets, jauges et autres fonctionnalités, et elle prenait même en charge deux navigateurs web sans latence. Cela donnait vraiment la sensation d’un véritable OS temps réel. Et Mac OS 8, appelé Copland, modernisait le Mac OS d’origine tout en conservant la tradition sans ligne de commande. Sans ligne de commande, toutes les installations et configurations de fonctions devaient être simples et cohérentes, et je pense que s’il y avait eu une transition vers le mobile, elle se serait faite en douceur. En réalité, une version avait bien été fournie aux développeurs, mais Apple a dû racheter NeXT, donc le projet Copland a été enterré. Le concept d’OS transactionnel était aussi innovant. Comme IBM CICS, il chargeait un programme, l’exécutait puis l’arrêtait, ce qui contraste avec Unix et Linux, fondamentalement conçus comme des systèmes de time-sharing à terminal. Ensuite, IBM MicroChannel cherchait à appliquer aux PC les avantages des canaux de mainframe, mais a échoué à cause d’une politique de quasi-monopole. Aujourd’hui encore, même si presque tous les systèmes utilisent des concepts similaires, ils ne jouent pas le rôle d’interface unifiée qui simplifierait l’OS. Et les CPU avec un hyperviseur réellement fonctionnel : contrairement aux anciens systèmes IBM VM, sur x86 toutes les couches sont des bricolages. La série Motorola 680x0 aurait dû devenir la base de l’ère des micro-ordinateurs, mais la sortie trop tardive du MMU l’a empêchée de suivre le rythme du Mac. Modula-2 et 3 étaient plutôt bons, mais Oberon a échoué et DEC s’est effondré avec lui. Quant à XHTML, HTML5 a officialisé les erreurs et introduit des règles de parsing inutilement tolérantes. Il suffisait qu’une seule balise soit mal fermée dans une pub ou un code externe pour que toute la page se casse de manière absurde. Enfin, il y avait des innovations comme Word Lens, qui permettait, en regardant le monde avec un smartphone, de faire de la traduction automatique et même du traitement hors ligne, mais qui a disparu après son intégration à Google Translate.
Je veux corriger les faits concernant le projet Copland. Ce projet était gravement mal géré, avec des ajouts de nouvelles technologies dans tous les sens, ce qui a provoqué une énorme dérive fonctionnelle et une forte baisse de stabilité. Si l’on essaie les builds ayant fuité, rien que les fonctions de base du desktop se figent et plantent fréquemment. En 1996, Apple était déjà arrivé en interne à la conclusion que Copland ne pouvait pas sortir, puis a étudié la licence d’OS externes avant de racheter NeXT. Ce n’est pas qu’Apple ait supprimé Copland pour acheter NeXT, c’est que Copland était à un niveau tel qu’il ne pouvait absolument pas sortir, et la décision était inévitable.
Il fut un temps où j’étais passionné par XHTML, mais j’ai connu l’expérience où une seule balise mal fermée, par exemple dans une publicité hors de mon contrôle, suffisait à faire disparaître toute la page au profit d’un énorme message d’erreur. L’approche consistant à « afficher le reste en Times New Roman » n’était pas réaliste non plus. Si, au fond, on parse quand même du HTML, cela revient au même qu’avant. En passionné, je peux écrire mon propre code parfaitement, mais dans la réalité la plupart des gens bricolent. XHTML semble logique en théorie, mais en pratique c’était une approche impossible compte tenu de la nature humaine.
On peut aimer un style strict comme XHTML, mais un framework impitoyable ne convient pas à des documents web largement partagés. Si l’on divise les formats de fichiers en deux catégories : (1) dans une boucle ouverte où le consommateur ne peut pas contacter l’auteur (HTML, pdf, zip, csv, etc.), les données elles-mêmes sont plus importantes que le format, donc il faut pouvoir lire même des pdf ou zip défectueux ; (2) dans une boucle fermée où le consommateur peut contrôler l’auteur (comme le code source d’un programme), un parseur strict est acceptable. XHTML est un modèle qui ne fonctionne que dans le cas (2), alors que HTML relève du cas (1). Sauf dans un environnement intrinsèquement fermé, comme des documents internes d’entreprise, il est difficile d’appliquer XHTML.
Je suis critique envers la tolérance excessive de HTML5 vis-à-vis des erreurs de balises mal formées. La plupart des autres formats s’arrêtent à la première erreur, HTML faisant exception. Cela a créé de nombreuses failles de sécurité et n’a fait que compliquer la vie de tous les développeurs. L’approche de parsing de HTML5 a fini soit par poursuivre des idéaux excessifs chez ceux qui s’opposaient à l’inertie d’Internet Explorer, soit par dériver vers une documentation de bugs au nom de la normalisation. RFC associé
Exiger de fermer les balises « correctement » ne fait qu’augmenter la barrière à l’entrée du langage. Avant, les gens écrivaient leur HTML à la main, et même avec des erreurs il se passait au moins quelque chose à l’écran, ce qui les encourageait à continuer. Les vrais langages de programmation, eux, crachent des messages d’erreur horribles pour de petites fautes, ce qui pousse facilement à abandonner. Les langages récents se sont améliorés, comme Rust, mais à l’époque de XHTML il n’était pas simple d’identifier une petite erreur.
Je citerais Google Wave. J’avais vu une première démo de Chris DiBona et c’était vraiment impressionnant : traduction en temps réel, intégration de différents systèmes de messagerie, open source, plein de fonctionnalités géniales. Mais la version réellement lancée était une version réduite, le marché l’a boudée, et c’était très décevant. Au final, on ressent fortement son absence à travers des outils comme JIRA, Slack ou l’e-mail.
Google Wave avait une excellente stack technique, mais a commis une erreur fatale dans la conception de l’UI. Au lieu de traiter une wave comme un document unique, il l’a découpée en plusieurs éléments individuels, ce qui la rendait seulement complexe et lui faisait perdre ses avantages.
J’avais été émerveillé par la démo, puis en y repensant je suis vite arrivé à la conclusion que c’était affreux. Comme avec Slack, il faut déjà suivre toutes les mises à jour de chaque canal, mais dans Wave cette structure était bien plus complexe, et j’ai immédiatement senti qu’il serait impossible de suivre.
La prouesse technique de Wave était remarquable, mais si l’on revoit la vidéo de démo, on se rend compte que ce n’était pas un très bon produit. Ils ont essayé de créer un produit tout-en-un couvrant tout, sans réussir. À la place, ces technologies ont été réparties dans plusieurs produits Google, et on a vu qu’avoir des UI séparées selon les fonctions était bien plus intuitif.
C’était parfait pour gérer avec des amis des choses partagées comme un itinéraire de voyage, et le form factor de Wave était efficace pour des discussions ad hoc incluant documents et liens. J’avais l’impression de voir le futur, au point qu’à mes débuts j’avais moi-même créé un plugin d’administration de serveur : Wave-ServerAdmin. Seize ans ont passé, il est peut-être temps de l’archiver.
J’avais effectivement téléchargé le serveur Wave open source pour voir si je pouvais en faire un produit, mais sa plus grande limite était l’impossibilité de stocker les données de façon permanente. À mes yeux, cela lui enlevait tout avenir, et la réaction des membres de l’équipe Wave donnait aussi l’impression qu’ils vivaient dans une sorte de fantasme déconnecté de la réalité. Cela restait malgré tout un concept génial.
Adobe Flash / Shockwave : même plusieurs décennies plus tard, il n’existe toujours pas d’outil aussi simple pour créer des jeux ou du multimédia. Cela rappelle que l’humanité n’avance pas toujours dans une seule direction et qu’elle peut aussi perdre à jamais des choses précieuses.
Comme il permettait même aux débutants de créer facilement des jeux, toute l’industrie du jeu a vu affluer des idées nouvelles. Par exemple, des développeurs indés comme Zachtronics ont débuté de cette manière. En revanche, chaque jeu Flash s’accompagnait d’innombrables publicités et d’une navigation web médiocre fondée sur Flash ; à une époque, presque tous les sites de restaurants étaient en Flash. Les lecteurs vidéo Flash étaient une plaie sous Linux et ont largement retardé l’arrivée d’un vrai support vidéo dans le navigateur.
Flash a été un désastre pour le web. C’était une boîte noire où rien ne marchait : zoom, sélection de texte, retour arrière, rien. Sa mort donne presque l’impression d’être la plus grande réussite de Steve Jobs.
Godot s’en rapproche beaucoup. Il est facile à apprendre, prend en charge la 2D comme la 3D, et peut exporter largement vers les principaux OS, le mobile et même HTML5/webasm. Ce n’est pas encore parfait, mais les progrès de ces dernières années ont été spectaculaires, et j’ai l’impression qu’un tournant majeur, comme celui de Blender, est en train d’arriver.
Même si Adobe avait entièrement résolu les problèmes de sécurité, Apple l’aurait tué de toute façon. Le succès populaire de Flash représentait une menace pour Apple. Et même maintenant que la vague HTML canvas est retombée, il n’existe toujours pas d’alternative permettant à un designer de créer, sans abonnement, de beaux designs interactifs à intégrer partout.
Le problème, c’est surtout que Flash a été énormément détourné de son usage. Dans une entreprise, on utilisait une app qui s’obstinait à rester en Flash ; en cherchant pourquoi, j’ai découvert qu’une simple ligne horizontale de séparation sur la page était faite en Flash. Menus déroulants en Flash, splash screens de sites automobiles, tout cela relevait d’un mauvais usage. Il a fallu l’arrivée de l’ère mobile pour qu’il puisse mourir, et à ce moment-là, il n’y avait presque plus personne pour le regretter.
Il y a tous les nombreux services Google qu’on peut voir sur killedbygoogle.com. J’en ai utilisé 30 à 40 à une époque, mais aujourd’hui seulement 3 ou 4. Google Picasa était rapide en local, et Google Hangouts me laisse surtout une impression de confusion à cause de la multiplication des apps de chat. G Suite Legacy promettait la gratuité à vie, puis est finalement devenu payant, ce qui m’a fait quitter Google. Google Play Music contenait des milliers de MP3 que j’avais uploadés, mais le service a fermé et je n’ai aucune envie de tout remettre. J’ai aussi quitté Google Finance et NFC Wallet après avoir perdu confiance dans leurs données. Chromecast Audio ne faisait qu’une seule chose, mais il la faisait exactement comme il fallait ; à l’annonce de son arrêt, je l’ai vite revendu. J’ai même appris que Chromecast avait lui aussi été abandonné alors que je l’utilisais encore.
Google Reader me manquera aussi pour toujours. Son coût d’exploitation ne devait probablement même pas être si élevé, et c’était le genre de fonction qui pouvait rester des années sans correction sans que cela ne me dérange. Le RSS, hier comme aujourd’hui, je l’utilise exactement de la même manière.
Toute la musique uploadée sur Google Play Music n’a pas disparu. Pour les utilisateurs passés à YouTube Music, tous les morceaux ont été transférés sans qu’il soit nécessaire de les re-uploader.
Chromecast Audio fonctionne toujours très bien. Il n’est simplement plus vendu, donc je regarde encore régulièrement le marché de l’occasion.
La reconnaissance faciale de Picasa était en avance sur son temps et le package hors ligne était vraiment excellent. Malheureusement, la dernière version avait un bug qui changeait les tags de visages de manière aléatoire, ce qui a rendu inutile la reconnaissance sur plusieurs milliers de photos de famille. Digikam remplit à peine un rôle comparable, sans être un vrai remplaçant.
Il est intéressant de voir que Google a fermé Google Notebook, puis a créé Google Keep quelques années plus tard, avec pratiquement les mêmes fonctionnalités.
L’appareil photo à champ lumineux Lytro était techniquement impressionnant, et deux produits ont bien été lancés, mais ils n’atteignaient pas la résolution requise pour les photographes professionnels. Toutefois, avec des appareils comme l’affichage light field des Meta Ray-Ban et l’émergence de médias comme les gaussian splats, on arrive maintenant à un moment où il devient possible d’exploiter davantage de données de capteurs. Au-delà de la technique, il existe aussi un grand marché pour des appareils photo inventifs et basse résolution, comme les Polaroid ou les Instax, donc le premier Lytro aurait très bien pu adopter un format ludique avec même une imprimante intégrée.
Le light field enregistre des pixels mélangés à différentes profondeurs de mise au point, donc il est structurellement inévitable que le résultat ait une résolution inférieure à celle d’un appareil photo classique. La fabrication n’est pas difficile, mais cette limite physique est regrettable.
Aujourd’hui, les smartphones semblent en implémenter une partie. Je me souviens avoir été vraiment enthousiaste à l’apparition de l’appareil photo Lytro.
La mémoire persistante Optane apportait une valeur révolutionnaire : avec le stockage direct des données, on pouvait reprendre immédiatement son travail sans boot ni chargement d’application. Le prix trop élevé l’a fait échouer, mais ses limites étaient déjà évidentes avant cela. Avec les snapshots mémoire des VM, les conteneurs macOS et autres, cette direction n’a pas totalement disparu.
J’ai une confiance absolue dans la technologie 3dxpoint. C’est une technologie mûrie pendant des décennies, mais côté business on n’a pas eu la patience d’attendre que le monde suive.
La manière traditionnelle de penser les systèmes, enfermée dans la distinction entre RAM et disque, n’était pas encore prête à accepter un nouveau matériel comme Optane. Cela dit, quelques cas d’usage ont émergé dans le monde des serveurs, et de nombreux projets de recherche liés sont apparus.
Optane était techniquement formidable. Il a failli effacer la frontière entre RAM et disque, au point qu’un seul stick aurait pu suffire pour toute la mémoire.
J’utilise réellement un noyau placé sur un disque Optane pour faire l’expérience d’un démarrage instantané.
Ce n’est pas seulement une question de prix : l’écosystème n’a pas eu le temps de se diffuser suffisamment, et les schémas de pensée existants n’étaient pas prêts. C’est un modèle plus proche des environnements à base d’images (live), comme les premiers Lisp ou Smalltalk. J’ai moi-même un système avec firmware et petit Optane compatibles. La capacité est faible et cela reste lié à un ancien OS, mais cela vaut la peine d’expérimenter. Avec assez de RAM, on peut déjà imiter ce comportement comme avec suspend/resume. Combiné aux progrès des SSD, l’écart de vitesse devient presque nul. Il ne reste guère que des questions d’endurance comme le TBW. On peut aussi combiner les deux.
Le réseau Ricochet était un système unique qui, à l’époque des lignes téléphoniques, fournissait une vitesse de niveau ISDN grâce à un réseau maillé sans fil à paquets. 5 milliards de dollars ont été engloutis dans 23 réseaux urbains, mais il n’y avait pratiquement aucun client, et le service a fermé en 2001. Le marketing visait les « professionnels mobiles », alors qu’en réalité il ignorait le marché domestique, qui voulait simplement un Internet plus rapide. Aujourd’hui, les femtocells 5G rappellent son concept physique, mais sans ses notions de redondance et d’auto-routage.
Ricochet était un système génial en avance sur son temps. Je recommande aussi le témoignage laissé par Joel Spolsky : Review of the Ricochet Wireless Modem
J’adorais vraiment le modem Ricochet. J’ai le souvenir d’avoir fait du web en 56k et des sessions ssh dans un café de Palo Alto avec un Ricochet de deuxième génération et un PowerBook. J’en ai encore un quelque part dans une boîte chez moi, et je me demande parfois si je ne devrais pas tenter une connexion en mode star pour m’amuser.
J’ai utilisé un modem Ricochet à San Francisco en 98-99. Dix ans plus tard, l’iPhone a lancé l’ère de la 3G, avec des performances bien supérieures. Si je me demande si ma vie aurait été meilleure si Ricochet avait survécu, j’ai plutôt l’impression que le progrès technique a finalement pris une direction beaucoup plus juste.
C’est un service que j’avais complètement oublié, mais en y repensant c’était vraiment remarquable à l’époque. J’étais peut-être moi aussi l’un de ses quatre seuls clients.
Midori de Microsoft était un OS orienté vers la sécurité fondée sur les permissions. Selon certaines rumeurs, son développement aurait été assez avancé pour exécuter du code Windows, mais il aurait été abandonné à cause de la politique interne. C’était une sorte de précurseur de Fuchsia. Wiki Midori
Midori était vraiment passionnant. Le blog de Joe Duffy reste probablement la source la plus détaillée : blog Midori. En interne chez Microsoft, certains le décrivaient aussi comme un moonshot et un projet de rétention des talents clés. Plus d’une centaine d’ingénieurs très seniors y avaient été affectés. Une partie des résultats de la recherche a été réutilisée dans .NET, donc tout n’a pas complètement disparu.
Je ne sais pas d’où vient cette rumeur sur l’exécution de code Windows. D’après tous les documents publics, Midori visait une incompatibilité totale avec l’existant. Il y avait peut-être en interne des gens qui rêvaient d’une migration, mais la conception elle-même relevait d’un nouveau système fondamental, sans transition.
Les bases techniques sont intéressantes, mais venant de Microsoft, cela aurait sans doute fini en logiciel hypertrophié rempli de nouveaux problèmes spécifiques. À l’heure qu’il est, il serait probablement aussi bourré de spyware et de fonctions IA dont les utilisateurs ne veulent pas au départ.
Je me demande si vous connaissez Genode(genode.org). C’est dans un domaine proche de Midori et le développement y reste très actif.
Yahoo Pipes était vraiment excellent pour créer des flux RSS et des workflows personnalisés. Aujourd’hui, il existe des remplaçants comme Zapier ou n8n, mais j’aimais particulièrement Pipes. Et je partage aussi la nostalgie autour de Google Reader.
Je recommande vraiment de lire l’archive History of Pipes. On y trouve des rétrospectives des développeurs eux-mêmes.
Yahoo Pipes était le futur qu’Internet aurait dû devenir. Même après plusieurs décennies, ce type d’interconnexion entre outils n’est encore mis en œuvre qu’au niveau minimal de vrais unix pipes.
Je ne l’ai jamais utilisé moi-même, mais à chaque fois que j’entends des retours positifs sur Pipes, je sens que c’était un outil incroyable. Je ne sais pas si ce qui est mort, c’est vraiment Pipes, ou bien l’Internet grand public fondé sur des standards et protocoles ouverts.
J’adorais Pipes. Je récupérais du contenu depuis plusieurs sites, le reformatais avec Pipes, puis le réintégrais en RSS dans un blog php. Mais peu à peu, les sites ont cessé de prendre en charge RSS, Pipes a perdu sa raison d’être, puis a fini par fermer. Pendant un temps, j’ai utilisé une bibliothèque Python appelée riko pour retrouver des fonctions similaires sans éditeur visuel, et cela m’a même servi de transition de PHP vers Python.
Si vous voulez faire revivre l’idée de Yahoo! Pipes, Node-RED(nodered.org) est un très bon point de départ. Open source, API solides, plus de dix ans d’expérience accumulée, backend robuste : les atouts ne manquent pas. J’ai aussi réellement utilisé Browser-Red, qui reprend seulement le frontend de Node-RED, ainsi que Erlang-Red, qui le reconstruit avec un backend Erlang. Contrairement à Pipes, où plusieurs lignes d’entrée étaient possibles, dans Node-RED chaque nœud n’a qu’un seul port d’entrée, ou aucun. Le frontend est agréable aussi parce qu’il est facile à comprendre si l’on connaît jQuery. Si vous avez des questions sur Node-RED ou le flow-based programming, n’hésitez pas à me contacter.