Ask HN: ¿Hay proyectos que se detuvieron o terminaron demasiado pronto? ¿Por qué?
(news.ycombinator.com)- Preguntas y respuestas sobre proyectos que desaparecieron por haberse adelantado a su época o porque el mercado no estaba listo
Solo me da curiosidad. Quién sabe quién podría adoptar esto, o si alguien podría desarrollar algo nuevo a partir de esta idea.
Sistema operativo Plan 9
-
El sistema operativo distribuido de Bell Labs, considerado el verdadero sucesor de Unix, pero que fracasó en su comercialización
- Un diseño innovador que extendía la filosofía de "todo es un archivo" hasta el compartido por red
- Ofrecía funciones de UI originales como programación con mouse, administrador de ventanas anidadas y Plumber
- Era ideal para entornos distribuidos que conectaran móvil, escritorio, nube e IoT, pero no logró adopción
-
Causas del fracaso
- La industria le dio la espalda por problemas de licencia y litigios
- No coincidió con la época en que el cómputo centralizado iba en declive y las computadoras personales estaban en ascenso
- Al posicionarse solo como un OS de investigación, no aprovechó el boom de las .com
- Bell Labs fue vendido varias veces debido a la caída en los ingresos del negocio telefónico de AT&T
- Version 3 se vendía a $350 por caja, pero solo podía usarse con fines no comerciales
- No fue liberado realmente como open source hasta 2004
-
Legado
- El protocolo de sistema de archivos 9P sigue usándose en WSL2, el ecosistema de VM y Kubernetes
- Existen proyectos de forks activos como 9front
- Plan 9 Foundation administra el código open source y los derechos
Proyectos muertos de Google
-
La experiencia de un usuario cuyos 30~40 productos de Google usados se redujeron a 3~4
- Google Picasa: herramienta de gestión de fotos rápida y excelente basada en local
- Google Hangouts: víctima de la confusa estrategia de apps de mensajería
- G Suite Legacy: rompieron la promesa de "gratis para siempre" y pasó a ser de pago
- Play Music: subió miles de archivos MP3, pero el cierre del servicio causó pérdida de datos
- Google Finance: tenía funciones de seguimiento de acciones, pero fue descontinuado
- Google NFC Wallet: Apple dominó el mercado con la misma función
- Chromecast Audio: era fiel a una sola función, pero fue descontinuado
-
Google Reader: la peor decisión de negocio de la historia
- Fue cerrado pese a ser un servicio que, a largo plazo, casi no requería mantenimiento
- Tenía una base de usuarios influyente, incluidos fundadores, CTO y VP of Engineering
- Dejó en la industria la lección de no confiar en los productos de Google
- El cierre del servicio reflejó una cultura organizacional donde ahorrar unos cuantos millones de dólares cuenta como logro
Adobe Flash / Macromedia Flash
-
Una plataforma de creación multimedia para la que ni 15 años después hay un reemplazo equivalente
- Permitía crear juegos y contenido multimedia tan fácilmente como con bloques Lego
- Ofrecía un conjunto de herramientas intuitivo como MovieClip y animación por línea de tiempo
- Fue reemplazado por HTML Canvas, pero la calidad de las herramientas no es comparable
-
Por qué el iPhone mató a Flash
- En el hardware de 2007 había graves problemas de rendimiento y consumo de batería
- Porque Flash podía convertirse en una vía alterna al ecosistema de apps
- Existía el riesgo de que el iPhone fuera percibido como un "producto basura"
-
Situación actual
- Adobe Animate soporta salida a JS/Canvas, pero no es lo mismo que el original
- Con emuladores como Ruffle todavía puede ejecutarse parte del contenido legacy
- Roblox cumple en cierta medida un papel parecido, pero es más limitado y comercial
Proyectos fallidos de Microsoft
-
Silverlight: plugin web basado en C#
- Permitía usar C# completo en lugar de JavaScript
- UI vectorial consciente de DPI, patrón MVVM y binding bidireccional
- Colaboración diseñador-desarrollador mediante Expression Blend
- Renderizaba exactamente igual en todos los navegadores
- El iPhone también precipitó la caída de Silverlight junto con Flash
-
Midori: OS seguro basado en capacidades
- Llegó a avanzar hasta poder ejecutar código de Windows, pero se canceló por política interna
- Muchos resultados de investigación fueron integrados en .NET
- Se destinaron más de 100 personas como proyecto de retención (para conservar ingenieros destacados)
Otros
-
Copland de Apple (prototipo de MacOS 8)
- Una versión modernizada de MacOS sin línea de comandos
- Tenía funciones que podrían haber facilitado la transición al móvil
- No pudo lanzarse por feature creep e inestabilidad
- Circula el rumor de que fue descartado intencionalmente para justificar la adquisición de NeXT por parte de Apple
-
Songsmith: generación automática de acompañamiento para melodías
- Ya en 2009 tenía detección de acordes y generación de acompañamiento en tiempo real
- Fue un precursor de las herramientas de música con IA como Suno y Udio
- Se volvió meme por su video promocional camp, pero la tecnología era impresionante
El declive de Heroku
-
Su éxito inicial se debió a la simplicidad y enfoque
- Un solo lenguaje, una sola plataforma de despliegue y una sola base de datos
- Minimizaba la fatiga de decisiones
- Si la IA hubiera existido hace 15 años, los datos de aprendizaje consistentes la habrían hecho más eficiente
-
Causas del fracaso
- Tras la adquisición por Salesforce, el añadido de un enorme banner de marca provocó rechazo de usuarios
- La aparición de Docker y Kubernetes hizo posible reemplazarlo
- La eliminación del tier gratuito hizo que muchos clientes se fueran
- Hubo abuso del cómputo gratuito debido a las criptomonedas
-
Situación actual
- Algunos usuarios todavía lo usan en producción
- Vercel, Coolify y Dokku ofrecen experiencias similares
ReactOS - reimplementación de Windows NT
-
Lleva casi 30 años en desarrollo, pero sigue sin ser utilizable en la práctica
- Wine + kernel + compatibilidad con drivers de dispositivo + objetivo en constante movimiento
- Incluso con el fin del soporte para Windows 10 acercándose, no logra convertirse en alternativa
-
Causas del fracaso
- El código fuente de Windows no está bien documentado ni bien entendido
- Bajo los principios de ingeniería inversa clean-room, quien haya visto código de Windows no puede contribuir
- Incluso tras la filtración del código de Windows XP, el ritmo de avance siguió siendo lento
- Wine, Proton y la virtualización se consolidaron como alternativas prácticas
Delphi y Pascal
-
Lenguajes de programación que eran ideales para educación
- Su compilador ultrarrápido era perfecto para aprender por prueba y error
- Sistema de tipos limpio (no tan complejo como Rust)
- Servían fielmente para aprender conceptos básicos de programación sin funciones demasiado específicas del lenguaje
-
Situación actual
- Delphi sigue vigente y ya va por la versión 13
- Lazarus existe como alternativa open source
- Python lo reemplazó como lenguaje educativo, pero su sistema de tipos es confuso
Hardware innovador que fracasó
-
MicroChannel (IBM): arquitectura de periféricos basada en canales
- Llevó al PC el concepto de canal de los mainframes
- Permitía ejecutar programas de canal simples
- Fracasó en el mercado por su licencia propietaria
- Hoy todos los sistemas modernos usan funciones similares, pero no existe una interfaz unificada
-
Motorola 680x0: procesador que pudo haber sido la base de la era de las microcomputadoras
- Fue lanzado en 1978, pero el MMU llegó demasiado tarde
- Fue el corazón de la Amiga y las primeras Macintosh
-
Memoria persistente Optane: tecnología que borró la frontera entre RAM y almacenamiento
- Permitía persistir estructuras de datos directamente
- Sin necesidad de arrancar ni abrir apps, era posible reanudar justo donde se quedó
- Fracasó por ser demasiado cara, aunque técnicamente era revolucionaria
- Hubo poca paciencia por parte de los tomadores de decisiones de negocio
-
Cámara de campo de luz Lytro: ajustar el enfoque después de tomar la foto
- Capturaba todos los datos para decidir el enfoque después
- Habría podido ser perfectamente compatible con tecnologías modernas como Gaussian splat y Meta Ray-Ban
- No alcanzó la calidad de imagen que necesitaban los fotógrafos profesionales
- Quizá debió apuntar a un mercado de novedad como Polaroid/Instax
Debates sobre tecnologías web
-
El fracaso de XHTML
- Intentó resolver el caos de HTML con parsing estricto
- HTML5 incluso estandarizó el significado del HTML incorrecto
- La ley de Postel estaba equivocada: el parsing permisivo causa vulnerabilidades de seguridad y problemas de compatibilidad
- El principio de "detenerse en el primer error y mostrar un mensaje" habría sido mejor
-
Contraargumento: la verdadera razón del fracaso de XHTML
- IE6 no soportaba application/xhtml+xml
- Hubo que dar soporte a IE6 durante casi 15 años
- JSX y JSON tuvieron éxito pese a tener sintaxis estricta
- Todos los lenguajes de backend usan sintaxis estricta
- No fue un problema de barrera de entrada, sino de soporte de navegadores
-
La realidad de HTML
- Unas comillas mal puestas en atributos pueden hacer que no renderice toda la página
- Debe ser un formato que la gente común pueda escribir
- HTML es un formato de documento, no un conjunto de comandos
- PDF, ZIP y CSV también leen archivos dañados (los datos importan más que el formato)
Redes sociales y comunicación
-
Google Wave: mostró el futuro, pero fue una revolución que llegó demasiado pronto
- Traducción en tiempo real, integración de distintos sistemas de mensajería y funciones ricas
- Era completamente open source
- Su UI era tan compleja que los "hilos anidados con actualizaciones en tiempo real" resultaban abrumadores
- Ya integraba funciones que hoy están dispersas entre Slack, JIRA y el correo electrónico
-
Vine: video corto antes que TikTok
- Ya en 2013 había crecido a una escala considerable
- Twitter lo descontinuó porque no sabía cómo monetizarlo
- TikTok fue lanzado meses después del cierre de Vine
- Bastaba con poner banners publicitarios sobre video cuadrado, pero dejaron pasar la oportunidad
-
Skype: videollamadas que hasta tu abuela podía usar
- Era tan simple como una llamada, pero más barato que una llamada internacional
- Fue el mejor software P2P
- Fue reemplazado de forma lamentable por Microsoft Teams
- Configurar hardware externo es difícil, hay problemas de compatibilidad y ya no existe el antiguo servicio de prueba de audio
Sistemas operativos
-
Maemo/MeeGo: el Linux móvil que Nokia debió impulsar
- El N9 era un gran dispositivo, pero solo se lanzó uno
- Reunía hackeabilidad, elegancia y seguridad
- Hoy podría haber dos Linux móviles de masas además de Android e iOS
- Sailfish OS conserva parte de ese legado
-
BeOS: OS optimizado para multimedia
- Sorprende que hubo que hacer tanto scroll para ver menciones de BeOS y Amiga
- Haiku OS está siendo reimplementado from-scratch
- Era notablemente más rápido y responsivo que Linux+X+Qt+KDE
-
OS/2: la tragedia nacida de la colaboración entre IBM y Microsoft
- Un sistema con excelente API
- Si hubieran liberado Workplace Shell y el código de SOM, podría haberse aprovechado en otros sistemas operativos
- Se usó durante mucho tiempo en cajeros automáticos bancarios sin ser hackeado
Herramientas de desarrollo
-
Quartz Composer: programación visual basada en nodos de Apple
- Un entorno de programación visual basado en patches
- Permitía implementar monitoreo de dispositivos USB con 3 nodos
- Desde 2016 ya no recibe actualizaciones, y en los OS recientes muchos nodos están rotos
- Merece revaloración por la popularidad de la programación basada en nodos en Blender y Unreal Engine
-
Atom code editor: pudo haber sido alternativa a VS Code
- Una alternativa mainstream creada por GitHub
- Cuando Microsoft adquirió GitHub, el destino de Atom quedó sellado
- El proyecto original de Electron
- Sus desarrolladores originales están trabajando en el editor Zed
-
Non DAW: DAW dividido por funciones
- Ofrecía cada función como aplicación independiente
- Cuando solo se necesitaba una función, las demás no estorbaban
- En 25 líneas de ejemplo presentaba todos los conceptos
- El desarrollador principal fue contratado por Microsoft y ahora trabaja en Rust OSS
Lenguajes de programación
-
Elm: lenguaje funcional incompleto y sin desarrollo activo
- La eliminación de operadores personalizados rompió todo el código y le hizo perder impulso
- La Elm Architecture era demasiado rígida
- F# (Fable), ReasonML, OCaml (Bucklescript), Haskell y PureScript son alternativas
-
Opa: el Next.js tipado de 2012
- Antes de TypeScript, era un framework full-stack con tipos
- Fue lanzado cuando el mercado desconfiaba del Node.js del lado del servidor
- La licencia AGPL fue el golpe decisivo; luego cambió a MIT, pero ya no hubo segunda oportunidad
-
Austral: un lenguaje con pensamiento claro y originalidad
- Ofrecía una especificación con una claridad inusual
- Su autor ya no trabaja activamente en él
- Para programadores hobby, le faltan comunidad y ecosistema
-
Ceylon: lenguaje para la JVM de Red Hat
- Competía con Groovy, Kotlin y Scala
- Ofrecía tipos unión anónimos, comprehensions y un sistema de módulos adecuado
- Iba más allá de ser simple azúcar sintáctico sobre Java
- Perdió frente a Kotlin y quedó abandonado en Eclipse
Fracasos comerciales
-
Google Stadia: plataforma de cloud gaming
- Construyó una plataforma de streaming sólida
- Fracasó por la falta de juegos interesantes
- Un pequeño catálogo de juegos que ya podían conseguirse en otros lados no era suficiente
-
Fire Phone: el smartphone de Amazon
- Apuntó a un mercado inexistente
- Viéndolo en retrospectiva, cuesta creer que alguien pensara que iba a funcionar
-
Project Ara: smartphone modular de Google/Motorola
- Un smartphone personalizable
- Habría sido bueno ver algunas iteraciones más de desarrollo
- Probablemente habría sido demasiado grueso para competir
Bases de datos y backend
-
RethinkDB: base de datos en tiempo real
- Fracasó al ampliar su alcance con Horizon BaaS
- Técnicamente sigue existiendo en la Linux Foundation, pero perdió impulso
- Su concepto original era excelente para demos, pero le faltaban casos de uso reales en producción
-
Yahoo Pipes: herramienta para combinar RSS y flujos de datos
- Mostraba cómo debería ser internet
- La conexión entre herramientas sigue estancada al nivel de los pipes de Unix
- Zapier y n8n son reemplazos modernos, pero no se siente igual
- Node-RED, Apache Camel y Apache Nifi son alternativas empresariales
Otros proyectos destacables
-
Sandstorm: plataforma web distribuida de 2014
- Basada en ideas de BitTorrent
- Código y datos de sitios web completamente distribuidos
- Podía integrarse con sitios web existentes
- Su mecanismo de Grain (aislamiento de datos) dificultaba adaptar apps existentes
- En vez de promover la portabilidad de apps, debió enfocarse en desarrollar apps desde cero para la plataforma
-
Keybase: red social basada en cifrado
- Ofrecía cifrado potente y verificación de identidad
- Tras la compra por Zoom, quedó prácticamente detenido
- FOKS es el nuevo proyecto de sus desarrolladores originales
-
del.icio.us: servicio de marcadores sociales
- Permitía compartir marcadores con gente que realmente conocías
- Ofrecía un etiquetado por categorías útil
- Fue reemplazado por Reddit y Twitter
- Pinboard ofrecía un servicio similar, pero la falta de mantenimiento y las posturas políticas de su fundador alejaron a los usuarios
6 comentarios
Son tecnologías que traen recuerdos.
Ah... ¿cerraron el proyecto Keybase??
La verdad es que usaba mucho Vine; si hubiera sobrevivido hasta la era del contenido corto, probablemente habría ganado bastante dinero como pionero de la industria del formato corto.
Beriz Webshare?.. Recuerdo que, de chico, lo usé de forma bastante fácil y cómoda aun sin tener ningún conocimiento.
Falta Cyworld..
Opiniones de Hacker News
El sistema operativo Plan 9. Era el sistema más cercano al sucesor de Unix, llevando un paso más allá la filosofía de “todo es un archivo”, permitiendo compartir archivos fácilmente por red y construir sistemas distribuidos. En Plan 9, el acceso a recursos remotos era fácil y estable, mientras que en otros sistemas había que instalar software poco compatible para cada caso de uso. También tenía funciones de UI innovadoras como edición de texto basada en codificación con mouse, un gestor de ventanas anidadas y Plumber, que ejecutaba comandos en todo el sistema según patrones de texto. Gracias a su arquitectura distribuida, habría sido ideal para la era actual de dispositivos móviles, de escritorio, nube e IoT interconectados, pero en la práctica seguimos con sistemas operativos que no fueron diseñados así. Hoy sobreviven forks como 9front, pero el original de Bell Labs desapareció. Las causas de su caída fueron problemas legales (licencias, demandas, etc.) que frenaron su adopción en la industria, que en la época en que se quería un OS distribuido la gente prefería computadoras locales, y que se le conocía solo como un OS de investigación, por lo que no aprovechó bien el boom puntocom. Finalmente, también influyeron la pérdida de la fuente de ingresos de AT&T, la venta de Bell Labs y la salida de miembros clave
La mayor razón del fracaso de Plan 9 fue que, a diferencia de Unix, los proveedores de hardware no podían licenciarlo barato y modificarlo libremente para su propio hardware. Bell Labs intentó vender Plan 9 como software comercial por 350 dólares, y por eso nunca fue realmente adoptado por la industria. Recomiendo revisar unos textos que he citado varias veces: enlace1, enlace2, enlace3
El protocolo del sistema de archivos de Plan 9 sigue vivo dentro de WSL2
Me pregunto por qué otros sistemas tipo Unix no adoptan más agresivamente la filosofía de “todo es un archivo”
En Plan 9 resolvieron el problema de los enlaces simbólicos
La interfaz gráfica Photon de QNX también estaba muy enfocada en tiempo real, pero tenía buenas funciones como widgets y medidores, e incluso soportaba dos navegadores web, todo sin latencia. Realmente se sentía como un sistema operativo de tiempo real de verdad. Y Mac OS 8, conocido como Copland, modernizaba el Mac OS original manteniendo la tradición de no tener línea de comandos. Al no haber línea de comandos, toda instalación y configuración debía ser fácil y consistente, y creo que si hubiera llegado la transición a móvil, habría sido más suave. De hecho, se entregaron versiones reales a desarrolladores, pero como Apple tuvo que comprar NeXT, el proyecto Copland quedó archivado. Además, la idea de un sistema operativo transaccional también era innovadora. Como CICS de IBM, cargaba un programa, lo ejecutaba y luego terminaba, en contraste con el hecho de que Unix y Linux son básicamente sistemas de timesharing centrados en terminal. Después está IBM MicroChannel, que intentó llevar las ventajas de los canales de mainframe al PC, pero fracasó por políticas prácticamente monopólicas. Hoy casi todos los sistemas usan conceptos parecidos, pero no cumplen el papel de una interfaz integrada que simplifique el OS. Y también los CPU con hipervisores que realmente funcionen: a diferencia de los sistemas IBM VM de antes, en x86 todas las capas son más bien trucos. La serie Motorola 680x0 debió haber sido la base de la era de las microcomputadoras, pero el MMU llegó demasiado tarde y perdió el ritmo. Modula-2 y 3 eran bastante buenas, pero Oberon fracasó, y DEC cayó junto con ello. En el caso de XHTML, en HTML5 se oficializaron los errores y se introdujeron reglas de parsing innecesariamente permisivas. Bastaba con que en un anuncio o código externo no se cerrara bien una sola etiqueta para que toda la página se rompiera de forma absurda. Por último, hubo innovaciones como Word Lens, donde al mirar el mundo con el smartphone se podía tener traducción automática y procesamiento offline, pero desapareció al integrarse en Google Translate
Quiero corregir los hechos sobre el proyecto Copland. Este proyecto estuvo gravemente mal gestionado, y además se le fueron agregando tecnologías nuevas sin control, con un fuerte feature creep y una caída severa en estabilidad. Si usas builds filtradas, se cuelga y crashea con frecuencia incluso con funciones básicas del escritorio. Dentro de Apple ya se había concluido en 1996 que Copland no podía lanzarse, y por eso empezaron a evaluar licenciar un OS externo antes de terminar comprando NeXT. No abandonaron Copland para comprar NeXT; compraron NeXT porque Copland estaba en un estado tan malo que jamás podía salir
Hubo una época en que estaba obsesionado con XHTML, pero tuve la experiencia de que si una sola etiqueta, por ejemplo de un anuncio fuera de mi control, se cerraba mal, toda la página dejaba de mostrarse y solo aparecía un gran mensaje de error. Tampoco es realista el enfoque de “mostrar el resto solo en Times New Roman”. Si al final se parsea HTML de todos modos, no es distinto de la posición anterior. Como entusiasta, yo sí podía escribir mi parte del código perfectamente, pero en la práctica la mayoría de la gente hace las cosas a medias. XHTML parece lógico en teoría, pero en la realidad era un enfoque imposible por cómo es la gente
Puede gustarte un estilo estricto como XHTML, pero un framework implacable no encaja con documentos web ampliamente compartidos. Si dividimos los formatos de archivo en dos: (1) open loop donde el consumidor no puede contactar al autor, como HTML, pdf, zip, csv, etc., donde los datos importan más que el formato y por eso incluso un pdf o zip defectuoso debe poder leerse; (2) closed loop donde el consumidor sí puede controlar al autor, como el código fuente de un programa, donde se pueden permitir parsers estrictos. XHTML es un modelo que solo funciona en (2), pero HTML es (1). Salvo en entornos intrínsecamente cerrados, como documentos internos de empresa, es difícil aplicar XHTML
Soy crítico de cómo HTML5 tolera de forma demasiado permisiva los errores de etiquetas. La mayoría de los otros formatos se detienen en el primer error; HTML es la excepción. Por eso hubo muchas vulnerabilidades de seguridad y terminó siendo difícil para todos los desarrolladores. La orientación del parsing en HTML5 terminó yéndose demasiado hacia el idealismo de quienes se oponían al Internet Explorer heredado, o hacia documentar bugs en nombre del estándar. RFC relacionado
Exigir que las etiquetas se cierren “correctamente” solo eleva la barrera de entrada del lenguaje. Antes, cuando la gente escribía HTML a mano, aunque cometiera errores igual aparecía algo en pantalla, así que muchos podían seguir intentándolo. Los lenguajes de programación de verdad sueltan mensajes de error horribles incluso por fallas pequeñas, y eso hace que la gente se rinda rápido. Los lenguajes recientes han mejorado eso, como Rust, pero en la época de XHTML no era fácil identificar ni errores pequeños
Diría Google Wave. Vi una demo de Chris DiBona y fue realmente impresionante. Traducción en tiempo real, integración de varios tipos de mensajería, open source y un montón de funciones geniales. Pero el Wave que de verdad salió fue una versión recortada, y el mercado también lo ignoró, lo que fue una gran lástima. Al final uno siente mucho la ausencia de Wave al quedarse con cosas como JIRA, Slack y correo electrónico
Google Wave tenía un stack tecnológico excelente, pero cometió un error fatal en el diseño de UI. Trató Wave no como un solo documento sino como varios elementos individuales, así que solo se veía complejo y perdía sus ventajas
Vi la demo y me quedé maravillado, pero poco después llegué a la conclusión de que era terrible. Como en Slack, habría que revisar una por una las actualizaciones de cada canal, pero en Wave esa estructura era mucho más compleja, así que sentí que sería imposible seguirle el ritmo
La capacidad técnica de Wave era impresionante, pero si vuelves a ver el video de demo te das cuenta de que no era un buen producto. Intentaron hacer un producto all-in-one que cubriera todo, pero no funcionó. Más bien, estas tecnologías se repartieron entre varios productos de Google, y quedó claro que tener una UI separada por función era mucho más intuitivo
Era perfecto para gestionar cosas compartidas con amigos, como itinerarios de viaje, y el formato de Wave también era eficaz para discusiones ad hoc con documentos y enlaces. Sentía que estaba viendo el futuro, así que cuando recién empezaba hasta hice yo mismo un plugin de administración de servidores: Wave-ServerAdmin. Ya pasaron 16 años, así que supongo que es hora de archivarlo
Llegué a bajar el servidor open source de Wave para ver si podía construir algún producto encima, pero la mayor limitación era que no podía almacenar datos de forma persistente. Por eso, para mí no tenía futuro, y la reacción de la gente del equipo de Wave también daba la impresión de que estaban atrapados en una fantasía y no entendían la realidad. Aun así, era un concepto genial
Adobe Flash / Shockwave. Incluso hoy, después de varias décadas, sigue sin haber una herramienta tan fácil para hacer juegos o multimedia. Me recuerda que la humanidad no siempre avanza en una sola dirección y que a veces también pierde para siempre cosas valiosas
Como incluso principiantes podían hacer juegos con facilidad, esto hizo que brotaran ideas frescas en toda la industria del gaming. Por ejemplo, desarrolladores indie como Zachtronics debutaron de esa manera. Por otro lado, cada juego flash venía acompañado de montones de anuncios y navegación flash malísima, y hubo una época en que prácticamente todos los sitios web de restaurantes estaban hechos en flash. Los reproductores de video en flash eran un dolor en Linux, y fueron uno de los principales culpables de retrasar el soporte de video decente en el navegador
Flash fue un desastre para la web. Era una caja negra donde no funcionaban ni el zoom, ni seleccionar texto, ni el botón atrás, ni nada. Que muriera casi se siente como el mayor logro de Steve Jobs
Godot se le acerca bastante. Es fácil de aprender, soporta 2D y 3D, y puede exportar ampliamente a HTML5/webasm, los principales OS y también móvil. Todavía no es perfecto, pero en los últimos años ha avanzado muchísimo, y parece que se acerca un gran punto de inflexión como el de Blender
Aunque Adobe hubiera resuelto por completo los problemas de seguridad, Apple lo habría matado de todos modos. El éxito masivo de Flash era una amenaza para Apple. Incluso ahora, ya pasada la fiebre de HTML canvas, sigue sin existir un reemplazo para que un diseñador haga interacciones vistosas sin suscripción y las embeba en cualquier parte
El problema fue que Flash se abusó demasiado. En una empresa vi una app que insistía en usar Flash hasta el final, y cuando investigué por qué, resultó que una simple línea divisoria horizontal de la página estaba hecha en Flash. Menús desplegables en flash, pantallas splash de sitios de autos, todo era abuso y mal uso. Solo pudo morir cuando llegó la era móvil, y para entonces casi nadie lo extrañó demasiado
Hay muchísimos servicios de Google que pueden verse en killedbygoogle.com. En algún momento usé entre 30 y 40, pero ahora solo uso 3 o 4. Google Picasa era rápido en local, Google Hangouts es un caos por tantas apps de chat, G Suite Legacy prometía ser gratis de por vida y al final se volvió de pago, así que me fui de Google. En Google Play Music tenía miles de MP3 subidos, pero el servicio cerró y no pienso volver a subirlos. También me cambié de Google Finance y NFC Wallet porque se rompió la confianza en los datos. Chromecast Audio hacía exactamente la única cosa que necesitaba, y cuando anunciaron su fin lo vendí enseguida. Incluso me enteré de que Chromecast también había muerto mientras lo estaba usando
Google Reader también me hará falta para siempre. Ni siquiera debía de ser tan caro de operar, y era una función a la que nadie le habría reclamado aunque no la arreglaran durante mucho tiempo. Antes y ahora sigo usando RSS igual
No es que toda la música subida a Google Play Music haya desaparecido. Si migraste a YouTube Music, todas las canciones se movieron y no hay que volver a subir nada
Chromecast Audio todavía funciona perfectamente. Solo que ya no lo venden, así que siempre ando revisando el mercado de segunda mano
El reconocimiento facial de Picasa estaba adelantado a su época, y el paquete offline era realmente bueno. Lamentablemente, la última versión tenía un bug donde las etiquetas faciales cambiaban aleatoriamente, así que el reconocimiento de miles de fotos familiares quedó inservible. Digikam apenas cumple un papel parecido, pero como reemplazo se queda corto
Es curioso que después de cerrar Google Notebook, años más tarde Google hiciera Google Keep, y que las funciones fueran casi las mismas
La cámara de campo de luz Lytro era técnicamente impresionante y hasta lanzó dos productos, pero no llegaba a la resolución que requieren los fotógrafos profesionales. Sin embargo, con la aparición de medios como las pantallas lightfield de Meta Ray-Ban y los gaussian splats, ya estamos en un momento donde se puede aprovechar mucha más información de sensores. Más allá de la tecnología, también hay un mercado grande para cámaras ingeniosas y de baja resolución, como Polaroid o Instax, así que la primera Lytro también habría podido llevar una impresora en un formato divertido sin problema
Como los lightfields registran mezclando píxeles a varias profundidades de enfoque, estructuralmente el resultado no puede más que tener menos resolución que una cámara normal. No es difícil de fabricar, pero es una pena ese límite físico
Parece que hoy algunos smartphones implementan parte de esta función. Recuerdo haberme emocionado bastante cuando apareció la cámara Lytro
La memoria persistente Optane tenía un valor revolucionario: guardar datos directamente y poder continuar de inmediato sin boot ni carga de apps. Fracasó por ser demasiado cara, pero sus límites ya eran evidentes desde antes. Aun así, esta línea no desaparece del todo gracias a cosas como snapshots de memoria de VM o contenedores de macOS
Le tengo fe absoluta a la tecnología 3dxpoint. Es una tecnología madurada durante décadas, pero del lado del negocio no tuvieron la paciencia para esperar a que el mundo la alcanzara
La forma de pensar de los sistemas existentes está demasiado atrapada en la separación entre RAM y disco, así que no estaba lista para aceptar hardware nuevo como Optane. Aun así, en servidores sí aparecieron algunos casos de uso y también muchos proyectos de investigación relacionados
Optane era técnicamente increíble. Estuvo a punto de borrar la frontera entre RAM y disco; con un solo stick se podía usar toda la memoria
Yo de hecho tengo el kernel en una unidad Optane y experimento arranque instantáneo
No fue solo por precio; tampoco logró difundirse lo suficiente como base de ecosistema, y la forma de pensar existente tampoco estaba preparada. Es un modelo más cercano a entornos basados en imágenes (live), como los primeros Lisp o Smalltalk. Yo también tengo un sistema con firmware y Optane de baja capacidad compatibles. La capacidad es pequeña y está atado a un OS viejo, pero vale la pena experimentar. Si tienes suficiente RAM, puedes imitar algo parecido con suspend/resume. Sumado al avance de los SSD, la diferencia de velocidad casi desaparece. Solo queda la durabilidad, como el TBW. También se pueden mezclar ambos
La red Ricochet era un sistema singular que, en la época de las líneas telefónicas, ofrecía velocidades tipo ISDN mediante una malla inalámbrica de paquetes. Se invirtieron 5 mil millones de dólares en redes de 23 ciudades, pero casi no hubo clientes y cerró en 2001. Su marketing se centró en los “profesionales móviles”, pero en realidad ignoró al mercado doméstico, que quería internet más rápido. Hoy las femtoceldas 5G se parecen en el concepto físico, pero carecen de la redundancia y el autoenrutamiento
Ricochet fue un sistema genial adelantado a su tiempo. También recomiendo las impresiones que dejó Joel Spolsky: reseña del módem inalámbrico Ricochet
Realmente amaba mi módem Ricochet. Tengo recuerdos de ir a cafés de Palo Alto con un Ricochet de segunda generación y una PowerBook, navegando la web a 56k y usando sesiones ssh. Todavía debo tenerlo en alguna caja en la casa, y a veces pienso si intentar conectarlo por diversión en modo star
Usé un módem Ricochet en San Francisco en 1998-99. Diez años después, el iPhone inauguró la era 3G y la mejora de rendimiento fue aplastante. Si pienso si mi vida habría sido mejor si Ricochet hubiera sobrevivido, en realidad siento que el progreso tecnológico fue en una dirección mucho más correcta
Era un servicio que había olvidado por completo, pero pensándolo bien, en ese momento sí que era extraordinario. Supongo que yo también fui uno de sus cuatro únicos clientes
Midori de Microsoft era un OS orientado a la seguridad basada en capacidades. Según rumores, estaba lo bastante avanzado como para ejecutar código de Windows, pero también se dice que fue cancelado por política interna. Era una especie de antecesor de Fuchsia. Wiki de Midori
Midori era realmente fascinante. El blog de Joe Duffy es probablemente la fuente más detallada que hay: blog sobre Midori. Dentro de Microsoft también se le veía como un moonshot y un proyecto para retener talento clave. Había más de cien personas, muchos ingenieros muy senior. Parte de los resultados de investigación se aprovechó en .NET, así que no desapareció del todo
No sé de dónde salió el rumor de que ejecutaba código de Windows. Según toda la documentación pública, Midori apuntaba a una incompatibilidad total con el código existente. Quizá internamente alguien soñó con una migración, pero el diseño mismo era el de un sistema nuevo y radical, sin transición
La base técnica es interesante, pero siendo Microsoft, probablemente habría terminado convertido en software inflado lleno de problemas nuevos y exclusivos. A estas alturas seguramente también estaría repleto de spyware y funciones de IA que los usuarios nunca pidieron
Me pregunto si conoces Genode(genode.org). Está en un espacio parecido a Midori y sigue desarrollándose activamente
Yahoo Pipes era realmente bueno para crear feeds RSS y workflows personalizados. Hoy existen alternativas como Zapier o n8n, pero a mí me gustaba especialmente Pipes. Y también coincido con la nostalgia por Google Reader
Recomiendo mucho leer el archivo de la historia de Pipes. Contiene retrospectivas de los desarrolladores reales
Yahoo Pipes era el futuro al que debía dirigirse internet. Incluso después de tantas décadas, esa interconexión entre herramientas apenas se implementa al nivel de los verdaderos unix pipes
Nunca lo usé directamente, pero cada vez que escucho recuerdos positivos sobre pipes, se nota que fue una herramienta increíble. No sé si lo que murió de verdad fue Pipes, o si desapareció el internet masivo basado en estándares y protocolos abiertos
Me encantaba Pipes. Reunía contenido de varios sitios, lo formateaba con pipes y lo traía por RSS a mi blog en php. Pero poco a poco los sitios fueron dejando de soportar RSS, Pipes perdió sentido y al final lo cerraron. Durante un tiempo usé una librería de Python llamada riko para hacer algo parecido sin editor visual, y gracias a eso terminé pasando de PHP a Python
Si quieres revivir la idea de Yahoo! Pipes, Node-RED(nodered.org) es un buen punto de partida. Tiene muchas fortalezas: open source, API sólida, más de 10 años de experiencia acumulada, backend robusto, etc. También he usado Browser-Red, que toma solo el frontend de Node-RED, y Erlang-Red, que lo reconstruye con backend en Erlang. La diferencia es que Node-RED hace que todos los nodos tengan un solo puerto de entrada o ninguno, mientras que Pipes permitía varias líneas de entrada. El frontend es bueno porque, si sabes jQuery, se aprende fácil. Si tienes preguntas sobre Node-RED o flow-based programming, con gusto puedes contactarme en cualquier momento