Ask HN: क्या ऐसे प्रोजेक्ट हैं जिन्हें बहुत जल्दी रोक दिया गया या बंद कर दिया गया? क्यों?

 (news.ycombinator.com)
6 पॉइंट द्वारा GN⁺ 2025-10-13 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • अपने समय से आगे रहे या बाज़ार तैयार न होने की वजह से गायब हो गए प्रोजेक्ट्स पर सवाल और जवाब

    बस जिज्ञासा है। कौन जानता है, कोई इसे अपनाएगा या इस आइडिया के आधार पर कुछ नया बनाएगा।

Plan 9 ऑपरेटिंग सिस्टम

  • Bell Labs का वितरित ऑपरेटिंग सिस्टम, जिसे Unix का सच्चा उत्तराधिकारी माना गया, लेकिन व्यावसायीकरण में विफल रहा

    • “सब कुछ एक फ़ाइल है” वाली फ़िलॉसफ़ी को नेटवर्क शेयरिंग तक बढ़ाने वाला अभिनव डिज़ाइन
    • mouse coding, nested window manager, Plumber जैसे मौलिक UI फीचर प्रदान किए
    • मोबाइल, डेस्कटॉप, cloud और IoT को जोड़ने वाले वितरित वातावरण के लिए आदर्श था, लेकिन अपनाया नहीं गया

  • विफलता के कारण

    • लाइसेंस समस्याएँ और मुकदमों के कारण उद्योग ने इसे नज़रअंदाज़ किया
    • उस समय से मेल नहीं खाता था जब केंद्रीकृत computing का पतन हो रहा था और personal computer उभर रहे थे
    • इसे केवल research OS के रूप में पेश किया गया, इसलिए .com boom का लाभ नहीं उठा पाया
    • AT&T के टेलीफोन व्यवसाय से आय घटने पर Bell Labs को कई बार बेचा गया
    • Version 3 $350 प्रति बॉक्स में बेचा गया, लेकिन केवल गैर-व्यावसायिक उपयोग के लिए
    • 2004 तक इसे ठीक से open source के रूप में जारी नहीं किया गया

  • विरासत

    • 9P filesystem protocol आज भी WSL2, VM ecosystem और Kubernetes में इस्तेमाल होता है
    • 9front जैसे सक्रिय fork प्रोजेक्ट मौजूद हैं
    • Plan 9 Foundation open source code और अधिकारों का प्रबंधन कर रही है

Google के बंद हो चुके प्रोजेक्ट्स

  • एक उपयोगकर्ता का अनुभव, जिसमें 30~40 Google प्रोडक्ट्स का उपयोग घटकर 3~4 रह गया

    • Google Picasa: local-based तेज़ और शानदार फोटो प्रबंधन टूल
    • Google Hangouts: भ्रमित messaging app strategy का शिकार
    • G Suite Legacy: “हमेशा मुफ्त” वादे को तोड़कर paid बना दिया गया
    • Play Music: हज़ारों MP3 फ़ाइलें अपलोड कीं, लेकिन सेवा बंद होने से डेटा खो गया
    • Google Finance: stock tracking फीचर था, लेकिन बंद कर दिया गया
    • Google NFC Wallet: Apple ने उसी फीचर के साथ बाज़ार पर कब्ज़ा कर लिया
    • Chromecast Audio: एक ही काम बहुत अच्छे से करता था, फिर भी बंद कर दिया गया

  • Google Reader: इतिहास के सबसे खराब business decisions में से एक

    • लंबे समय में लगभग नगण्य maintenance की ज़रूरत वाली सेवा होने के बावजूद बंद कर दी गई
    • founder, CTO, VP of Engineering जैसे प्रभावशाली उपयोगकर्ता बहुत थे
    • इसने इंडस्ट्री को Google प्रोडक्ट्स पर भरोसा न करने का सबक दिया
    • सेवा बंद करने को लाखों डॉलर बचत के रूप में आँकने वाली संगठनात्मक संस्कृति की समस्या

Adobe Flash / Macromedia Flash

  • 15 साल बाद भी जिसका सही विकल्प नहीं है, ऐसा multimedia creation platform

    • गेम और multimedia निर्माण को Lego blocks जितना आसान बना देता था
    • MovieClip, timeline animation जैसे सहज टूलसेट प्रदान करता था
    • HTML Canvas ने इसकी जगह ली, लेकिन टूल्स की गुणवत्ता की तुलना नहीं की जा सकती

  • iPhone ने Flash को क्यों मारा

    • 2007 के hardware पर performance problems और battery drain गंभीर थे
    • Flash app ecosystem के लिए bypass बन सकता था
    • iPhone को “खराब प्रोडक्ट” की तरह दिखाने का जोखिम था

  • मौजूदा स्थिति

    • Adobe Animate JS/Canvas output को support करता है, लेकिन मूल जैसा नहीं है
    • Ruffle जैसे emulator कुछ legacy content चला सकते हैं
    • Roblox कुछ हद तक मिलती-जुलती भूमिका निभाता है, लेकिन अधिक सीमित और व्यावसायिक है

Microsoft के विफल प्रोजेक्ट्स

  • Silverlight: C#-आधारित web plugin

    • JavaScript के बजाय पूरा C# इस्तेमाल किया जा सकता था
    • vector-based DPI-aware UI, MVVM pattern, two-way binding
    • Expression Blend के ज़रिए designer-developer collaboration
    • सभी browsers में पूरी तरह एक जैसा rendering
    • iPhone ने Flash के साथ Silverlight को भी गिरा दिया

  • Midori: capability-based security OS

    • Windows code चला सकने के स्तर तक विकसित हो गया था, लेकिन आंतरिक राजनीति के कारण बंद हुआ
    • कई research परिणाम .NET में समाहित किए गए
    • retention project के रूप में 100 से अधिक लोग लगाए गए

अन्य

  • Apple का Copland (MacOS 8 prototype)

    • command line के बिना आधुनिकीकृत MacOS संस्करण
    • ऐसे फीचर जिनसे मोबाइल की ओर बदलाव आसान हो सकता था
    • feature creep और instability के कारण रिलीज़ नहीं हो सका
    • Apple की NeXT खरीद को सही ठहराने के लिए इसे जानबूझकर खत्म किया गया, ऐसी अफ़वाह

  • Songsmith: melody के लिए automatic accompaniment generation

    • 2009 में ही real-time chord detection और accompaniment generation
    • आज के Suno, Udio जैसे AI music tools का अग्रदूत
    • campy promo video की वजह से meme बन गया, लेकिन तकनीक बहुत मजबूत थी

Heroku का पतन

  • शुरुआती सरलता और फोकस इसकी सफलता के कारण थे

    • एक भाषा, एक deployment platform, एक database
    • decision fatigue को न्यूनतम करता था
    • अगर 15 साल पहले AI होता, तो consistent training data के कारण यह और अधिक कुशल होता

  • विफलता के कारण

    • Salesforce अधिग्रहण के बाद विशाल brand banner जोड़ने पर उपयोगकर्ताओं की नाराज़गी
    • Docker और Kubernetes के आने से इसके विकल्प उपलब्ध हो गए
    • free tier हटाने से बहुत से ग्राहक चले गए
    • crypto की वजह से free computing के दुरुपयोग की समस्या

  • मौजूदा स्थिति

    • कुछ उपयोगकर्ता अभी भी इसे production में इस्तेमाल कर रहे हैं
    • Vercel, Coolify, Dokku मिलता-जुलता अनुभव देते हैं

ReactOS - Windows NT का पुनःक्रियान्वयन

  • करीब 30 साल के विकास के बाद भी अब तक व्यावहारिक उपयोग के लायक नहीं

    • Wine + kernel + device driver compatibility + moving target
    • Windows 10 support end के करीब आने पर भी विकल्प नहीं बन पाया

  • विफलता के कारण

    • Windows source code अच्छी तरह documented या समझा हुआ नहीं है
    • clean-room reverse engineering के सिद्धांत के कारण Windows code देख चुके लोग योगदान नहीं दे सकते
    • Windows XP source leak के बाद भी प्रगति की रफ्तार धीमी रही
    • Wine, Proton और virtualization तकनीकें व्यावहारिक विकल्प बन गईं

Delphi और Pascal

  • ऐसी programming languages जो शिक्षा के लिए आदर्श थीं

    • बेहद तेज़ compiler trial-and-error learning के लिए उपयुक्त
    • साफ़-सुथरा type system (Rust जितना जटिल नहीं)
    • programming की बुनियादी अवधारणाओं को भाषा-विशिष्ट फीचर्स के बिना अच्छी तरह सिखाती थीं

  • मौजूदा स्थिति

    • Delphi version 13 तक रिलीज़ होकर अब भी मौजूद है
    • Lazarus open source विकल्प के रूप में मौजूद है
    • Python ने शिक्षा में इसकी जगह ली, लेकिन type system अब भी उलझनभरा है

नवाचारी लेकिन विफल hardware

  • MicroChannel (IBM): channel-based peripheral architecture

    • mainframe के channel concept को PC में लाया
    • साधारण channel programs चलाए जा सकते थे
    • proprietary license के कारण बाज़ार में विफल रहा
    • आज लगभग सभी आधुनिक systems समान फीचर इस्तेमाल करते हैं, लेकिन एकीकृत interface नहीं है

  • Motorola 680x0: ऐसा processor जो microcomputer युग की नींव बन सकता था

    • 1978 में आया, लेकिन MMU बहुत देर से जारी हुआ
    • Amiga और शुरुआती Macintosh का मुख्य आधार था

  • Optane persistent memory: RAM और storage की सीमा मिटाने वाली तकनीक

    • data structures को सीधे persistent बनाया जा सकता था
    • boot या app launch की ज़रूरत नहीं, जहाँ छोड़ा वहीं से तुरंत फिर शुरू
    • बहुत महँगा होने के कारण विफल रहा, लेकिन तकनीकी रूप से क्रांतिकारी था
    • business decision-makers के धैर्य की कमी

  • Lytro light-field camera: फोटो लेने के बाद focus बदलना

    • सारा डेटा capture करके focus बाद में तय किया जा सकता था
    • Gaussian splat, Meta Ray-Ban जैसी आधुनिक तकनीकों के साथ पूरी तरह संगत हो सकता था
    • पेशेवर फ़ोटोग्राफ़रों के लिए आवश्यक image quality नहीं दे पाया
    • शायद इसे Polaroid/Instax जैसे novelty market को लक्ष्य बनाना चाहिए था

वेब तकनीक की बहसें

  • XHTML की विफलता

    • strict parsing के ज़रिए HTML की अव्यवस्था सुलझाने की कोशिश
    • HTML5 ने गलत HTML के अर्थ तक को standardize कर दिया
    • Postel का नियम गलत था: उदार parsing सुरक्षा कमजोरियाँ और compatibility समस्याएँ पैदा करती है
    • “पहली गलती पर रुकें और error message दिखाएँ” वाला सिद्धांत बेहतर होता

  • प्रतिवाद: XHTML के विफल होने की असली वजह

    • IE6, application/xhtml+xml को support नहीं करता था
    • लगभग 15 साल तक IE6 support की ज़रूरत रही
    • JSX, JSON strict syntax होने के बावजूद सफल रहे
    • सभी backend languages strict syntax इस्तेमाल करती हैं
    • समस्या entry barrier नहीं, browser support थी

  • HTML की वास्तविकता

    • गलत attribute quoting से पूरा पेज render नहीं हो सकता
    • यह ऐसा format होना चाहिए जिसे आम लोग भी लिख सकें
    • HTML command नहीं, document format है
    • PDF, ZIP, CSV भी corrupted files पढ़ लेते हैं (डेटा format से ज़्यादा महत्वपूर्ण है)

social network और communication

  • Google Wave: भविष्य दिखाने वाला, लेकिन बहुत जल्दी आ गया क्रांतिकारी प्रोजेक्ट

    • real-time translation, विभिन्न messaging का एकीकरण, और समृद्ध फीचर
    • यह पूरी तरह open source था
    • बहुत जटिल UI के कारण “nested real-time update threads” भारी लगते थे
    • आज Slack, JIRA और email में बिखरे हुए फीचर्स तब यह एक साथ लाता था

  • Vine: TikTok से पहले आया short-form video

    • 2013 में ही काफ़ी बड़े पैमाने तक बढ़ चुका था
    • Twitter ने इसे monetise कैसे करें, यह न समझ पाने के कारण बंद किया
    • TikTok, Vine बंद होने के कुछ महीनों बाद लॉन्च हुआ
    • square video में सिर्फ ad banner जोड़ना था, लेकिन मौका चूक गया

  • Skype: ऐसा video calling जिसे दादी भी इस्तेमाल कर सकें

    • फोन जितना सरल, लेकिन अंतरराष्ट्रीय कॉल से सस्ता
    • यह बेहतरीन P2P software था
    • Microsoft Teams ने इसकी जगह बहुत खराब तरीके से ली
    • बाहरी hardware setup की कठिनाई, compatibility issues, और पुराने audio test service का न होना

ऑपरेटिंग सिस्टम

  • Maemo/MeeGo: मोबाइल Linux जिसे Nokia को आगे बढ़ाना चाहिए था

    • N9 बेहतरीन डिवाइस था, लेकिन सिर्फ एक ही मॉडल आया
    • hackable, stylish, secure — सब कुछ था
    • आज Android और iOS के अलावा दो मुख्यधारा mobile Linux हो सकते थे
    • कुछ विरासत Sailfish OS में जारी रही

  • BeOS: multimedia-optimized OS

    • यह आश्चर्यजनक था कि BeOS और Amiga का ज़िक्र आने तक इतना scroll करना पड़ा
    • Haiku OS के रूप में from-scratch पुनःक्रियान्वयन जारी है
    • Linux+X+Qt+KDE से स्पष्ट रूप से तेज़ और अधिक responsive था

  • OS/2: IBM और Microsoft के सहयोग से जन्मी त्रासदी

    • बेहतरीन API वाला सिस्टम
    • अगर Workplace Shell और SOM code जारी कर दिए जाते, तो दूसरे ऑपरेटिंग सिस्टम भी उनका उपयोग कर सकते थे
    • बैंक ATM में बिना हैक हुए लंबे समय तक इस्तेमाल होता रहा

development tools

  • Quartz Composer: Apple का node-based visual programming

    • patch-based visual programming environment
    • USB device monitoring को 3 nodes में implement किया जा सकता था
    • 2016 के बाद updates रुक गए, और नए OS पर कई nodes टूट गए
    • Blender और Unreal Engine में node-based programming की लोकप्रियता के कारण फिर से मूल्यांकन योग्य

  • Atom code editor: जो VS Code का विकल्प बन सकता था

    • GitHub द्वारा बनाया गया mainstream विकल्प
    • Microsoft द्वारा GitHub अधिग्रहण के बाद Atom की किस्मत तय हो गई
    • Electron का मूल प्रोजेक्ट
    • मूल डेवलपर्स अब Zed editor बना रहे हैं

  • Non DAW: फीचर के हिसाब से अलग किया गया DAW

    • हर फीचर स्वतंत्र application के रूप में दिया गया
    • जब केवल ज़रूरी फीचर चाहिए हों, तब बाकी फीचर बाधा नहीं बनते
    • 25 लाइनों के उदाहरण से सभी concepts समझाए गए
    • मुख्य डेवलपर Microsoft में काम कर रहे हैं और Rust OSS पर काम कर रहे हैं

programming languages

  • Elm: अधूरी और सक्रिय विकास से वंचित functional language

    • custom operators हटाने से सारा code टूट गया और momentum खो गया
    • Elm Architecture बहुत कठोर थी
    • F# (Fable), ReasonML, OCaml (Bucklescript), Haskell, PureScript विकल्प हैं

  • Opa: 2012 का type-based Next.js

    • TypeScript से पहले का typed full-stack framework
    • तब लॉन्च हुआ जब बाज़ार server-side Node.js को लेकर संदेह में था
    • AGPL license अंतिम झटका साबित हुआ; बाद में MIT किया गया, लेकिन दूसरा मौका नहीं मिला

  • Austral: स्पष्ट सोच और मौलिकता वाली भाषा

    • असामान्य स्पष्टता वाला spec प्रदान करती थी
    • लेखक अब सक्रिय रूप से काम नहीं कर रहे
    • hobby programmers के लिए community और ecosystem की कमी

  • Ceylon: Red Hat की JVM language

    • Groovy, Kotlin, Scala से प्रतिस्पर्धा
    • anonymous union types, comprehension, और उचित module system
    • Java के ऊपर सिर्फ syntax sugar से अधिक देता था
    • Kotlin से प्रतिस्पर्धा हार गया, और Eclipse में उपेक्षित रह गया

व्यावसायिक विफलताएँ

  • Google Stadia: cloud gaming platform

    • मजबूत streaming platform बनाया
    • दिलचस्प games की कमी से विफल रहा
    • वे कुछ गिने-चुने games जो पहले से कहीं और मिलते थे, पर्याप्त नहीं थे

  • Fire Phone: Amazon का smartphone

    • शून्य बाज़ार को target किया
    • पीछे मुड़कर देखें तो यह मानना ही अविश्वसनीय है कि यह सफल होगा

  • Project Ara: Google/Motorola का modular smartphone

    • customisable smartphone
    • अच्छा होता अगर इसके कुछ और iteration देखने को मिलते
    • प्रतिस्पर्धा के लिए यह बहुत मोटा साबित होता

database और backend

  • RethinkDB: real-time database

    • Horizon BaaS तक दायरा बढ़ाते हुए विफल हुआ
    • Linux Foundation के भीतर तकनीकी रूप से मौजूद है, लेकिन momentum खो चुका है
    • मूल concept demo के लिए शानदार था, लेकिन वास्तविक production use cases कम थे

  • Yahoo Pipes: RSS और data-flow संयोजन टूल

    • इसने दिखाया कि इंटरनेट कैसा होना चाहिए था
    • टूल्स के बीच कनेक्शन अभी भी Unix pipes स्तर पर अटका है
    • Zapier और n8n आधुनिक विकल्प हैं, लेकिन वैसा एहसास नहीं देते
    • Node-RED, Apache Camel, Apache Nifi enterprise विकल्प हैं

अन्य उल्लेखनीय प्रोजेक्ट्स

  • Sandstorm: 2014 का distributed web platform

    • BitTorrent ideas पर आधारित
    • पूरी तरह distributed website code और data
    • मौजूदा websites में integrate किया जा सकता था
    • Grain (data isolation) mechanism के कारण मौजूदा apps को अपनाना कठिन था
    • app porting के बजाय platform पर शुरू से app development को market करना चाहिए था

  • Keybase: encryption-आधारित social network

    • मजबूत encryption और identity verification
    • Zoom अधिग्रहण के बाद व्यावहारिक रूप से बंद हो गया
    • FOKS मूल डेवलपर्स का नया प्रोजेक्ट है

  • del.icio.us: social bookmarking service

    • जिन लोगों को आप वास्तव में जानते थे, उनके साथ bookmarks साझा करना
    • उपयोगी category tagging
    • Reddit और Twitter ने इसकी जगह ले ली
    • Pinboard मिलती-जुलती सेवा थी, लेकिन खराब रखरखाव और संस्थापक के राजनीतिक विचारों के कारण उपयोगकर्ता दूर हो गए

संबंधित पढ़ाई

6 टिप्पणियां

 
soonil 2025-10-20

ये ऐसी तकनीकें हैं जो पुरानी यादें ताज़ा कर देती हैं
 
roxie 2025-10-13

आह.. Keybase प्रोजेक्ट बंद हो गया क्या??
 
click 2025-10-13

मैंने Vine का सच में बहुत इस्तेमाल किया था, अगर वह short-form के दौर तक टिक पाता तो short-form इंडस्ट्री के pioneer के रूप में वह काफ़ी पैसा कमा लेता।
 
unknowncyder 2025-10-13

Berries Webshare?.. याद है, बचपन में बिना किसी जानकारी के भी मैंने इसे काफ़ी आसानी और आराम से इस्तेमाल किया था
 
chicol 2025-10-13

Cybworld का नाम ही नहीं है..
 
GN⁺ 2025-10-13
Hacker News राय

  • Plan 9 ऑपरेटिंग सिस्टम। यह Unix के उत्तराधिकारी के सबसे करीब का सिस्टम था, जिसने "everything is a file" की दर्शनशास्त्र को एक कदम आगे बढ़ाया, ताकि फ़ाइलों को नेटवर्क पर आसानी से साझा किया जा सके और distributed systems बनाए जा सकें। Plan 9 में remote resources तक पहुँचना आसान और भरोसेमंद था, जबकि दूसरे सिस्टमों में हर use case के लिए compatibility में कमजोर अलग-अलग software इंस्टॉल करने पड़ते थे। इसके अलावा mouse-driven text editing, nested window manager, और पूरे सिस्टम में text patterns के आधार पर commands चलाने वाला Plumber जैसी innovative UI features भी थीं। इसकी distributed architecture आज के उस दौर के लिए आदर्श होती, जहाँ mobile, desktop, cloud, और IoT डिवाइस एक-दूसरे से जुड़े हैं, लेकिन हम अब भी ऐसे operating systems पर अटके हुए हैं जिन्हें इस तरह डिज़ाइन नहीं किया गया था। आज 9front जैसे forks ज़िंदा हैं, लेकिन Bell Labs का original गायब हो चुका है। इसके पतन के कारणों में कानूनी समस्याएँ (license, मुकदमे आदि) शामिल थीं, जिनकी वजह से industry adoption धीमा रहा; जब distributed OS की ज़रूरत थी तब लोग local computers को पसंद करते थे; और इसे सिर्फ research OS के रूप में जाना गया, इसलिए यह dot-com boom का फायदा नहीं उठा सका। अंत में AT&T के revenue sources का खत्म होना, Bell Labs की बिक्री, और core members का अलग हो जाना भी असरदार रहा

    • Plan 9 की सबसे बड़ी विफलता यह थी कि Unix के विपरीत hardware vendors इसे सस्ते में license लेकर अपनी hardware के लिए मनचाहे बदलाव नहीं कर सकते थे। Bell Labs Plan 9 को commercial software की तरह 350 डॉलर में बेचना चाहता था, और इसी वजह से इसे industry में सही adoption नहीं मिला। मैंने इस पर कई बार ज़ोर दिया है, इसलिए ये पोस्ट्स देखने की सलाह दूँगा: लिंक1, लिंक2, लिंक3

    • Plan 9 filesystem protocol अब भी WSL2 के अंदर ज़िंदा है

    • यह जानने की जिज्ञासा है कि दूसरे Unix-जैसे systems "everything is a file" दर्शन को इतनी सक्रियता से क्यों नहीं अपनाते

    • Plan 9 ने symbolic link की समस्या हल कर दी थी

  • QNX का Photon graphical interface भी real-time केंद्रित होते हुए widgets, gauges वगैरह में काफ़ी अच्छा था, और दो web browsers तक सपोर्ट करता था, इसलिए latency नहीं लगती थी। सच में एक real-time operating system जैसा एहसास देता था। और Copeland नाम से जाना जाने वाला Mac OS 8 original Mac OS को modernize कर रहा था, जबकि command line न होने की परंपरा बनाए रखता था। Command line न होने का मतलब था कि हर feature की installation और configuration आसान और consistent होनी चाहिए, और अगर mobile transition का दौर आया होता तो शायद यह smoothly adapt कर जाता। असल में developers को इसका एक real version दिया भी गया था, लेकिन Apple को NeXT खरीदना पड़ा, इसलिए Copeland project बंद कर दिया गया। Transaction processing operating system का विचार भी innovative था। IBM के CICS की तरह program को लोड करके चलाना और फिर terminate करना, यह Unix और Linux के मूल रूप से terminal-based timesharing systems होने के ठीक उलट था। फिर IBM MicroChannel था, जिसने mainframe channel के फ़ायदों को PC पर लाने की कोशिश की, लेकिन असल में monopoly policies की वजह से असफल रहा। आज लगभग हर system किसी न किसी रूप में ऐसे concepts इस्तेमाल करता है, फिर भी यह OS को सरल बनाने वाला integrated interface नहीं बन पाया। और सही तरह काम करने वाले hypervisor वाले CPU भी, पुराने IBM VM systems के विपरीत, x86 पर हर layer में किसी-न-किसी workaround पर टिके हैं। Motorola 680x0 series को microcomputer युग की बुनियाद बनना चाहिए था, लेकिन MMU बहुत देर से आया और इसका मौका निकल गया। Modula-2 और 3 काफ़ी अच्छे थे, लेकिन Oberon विफल रहा, और DEC भी साथ डूब गया। XHTML के मामले में HTML5 ने errors को औपचारिक रूप से स्वीकार कर लिया, और इससे parsing rules अनावश्यक रूप से ज़्यादा उदार हो गए। अगर ads या external code में सिर्फ एक tag भी ठीक से बंद न हो, तो पूरा page बेकार तरीके से टूट जाता था। और अंत में Word Lens जैसी innovation थी, जहाँ smartphone से दुनिया को देखकर machine translation और offline processing तक संभव थी, लेकिन Google Translate में merge होकर वह गायब हो गई

    • Copland project को लेकर मैं एक तथ्य-सुधार करना चाहता हूँ। इस project का management बुरी तरह विफल था, और नई technologies बिना सोचे-समझे जोड़ी जाती रहीं, जिससे feature creep और instability बहुत गंभीर हो गई थी। Leaked builds चलाकर देखें तो सिर्फ basic desktop features के साथ भी यह बार-बार freeze और crash करता है। 1996 में Apple के अंदर यह निष्कर्ष निकल चुका था कि Copland को ship करना असंभव है, और उसी के बाद external OS licensing पर विचार करते-करते NeXT acquisition हुआ। ऐसा नहीं था कि Copland को बंद करके NeXT खरीदा गया; बल्कि Copland इतना असंभव हो चुका था कि यह फैसला मजबूरी में लेना पड़ा

    • एक समय मैं XHTML में बहुत डूबा हुआ था, लेकिन मैंने यह अनुभव किया कि मेरे नियंत्रण से बाहर किसी ad वगैरह का सिर्फ एक tag भी अगर गलत बंद हो जाए, तो पूरा page दिखना बंद हो जाता था और सिर्फ एक बड़ा error message आता था। “बाक़ी सब कुछ Times New Roman में render कर दो” वाला approach भी व्यावहारिक नहीं था। अगर मूल रूप से HTML ही parse करना है, तो फिर पहले वाली स्थिति से अलग कुछ नहीं बचता। एक उत्साही व्यक्ति के रूप में मैं अपना code पूरी तरह सही लिख सकता हूँ, लेकिन हक़ीक़त में ज़्यादातर लोग चीज़ें जैसे-तैसे बनाते हैं। XHTML तर्क की दृष्टि से अच्छा लग सकता है, लेकिन इंसानी व्यवहार की वास्तविकता में यह असंभव approach था

    • आपको XHTML जैसी strict style पसंद आ सकती है, लेकिन जिन web documents को व्यापक रूप से साझा किया जाता है, उनके लिए एक unforgiving framework उपयुक्त नहीं है। File formats को broadly दो हिस्सों में बाँटा जा सकता है: (1) open loop, जहाँ consumer author से संपर्क नहीं कर सकता (HTML, pdf, zip, csv आदि) — यहाँ data format से ज़्यादा महत्वपूर्ण होता है, इसलिए खराब pdf या zip भी पढ़ने पड़ते हैं। (2) closed loop, जहाँ consumer author को नियंत्रित कर सकता है (जैसे program source code) — यहाँ strict parser स्वीकार्य है। XHTML मॉडल सिर्फ (2) में काम करता, जबकि HTML (1) में आता है। जब तक environment स्वभावतः बंद न हो, जैसे enterprise documents के अंदर, XHTML लागू करना मुश्किल है

    • मैं HTML5 में malformed tag errors को इतनी उदारता से स्वीकार करने की प्रवृत्ति की आलोचना करता हूँ। दूसरे formats ज़्यादातर पहली error पर रुक जाते हैं, लेकिन HTML अपवाद है। इससे बहुत-सी security vulnerabilities पैदा हुईं और developers के लिए सब कुछ और मुश्किल हुआ। HTML5 parsing का रुख उन लोगों के idealism या standards के नाम पर bugs को document कर देने की दिशा में बह गया, जो inertia में फँसे Internet Explorer के खिलाफ लड़ रहे थे। संबंधित RFC

    • tags को “ठीक से” बंद करने की मांग भाषा में प्रवेश की बाधा ही बढ़ाती है। पहले लोग HTML हाथ से लिखते थे, और गलती होने पर भी स्क्रीन पर कुछ-न-कुछ दिखाई दे जाता था, इसलिए बहुत लोग कोशिश जारी रख पाते थे। असली programming languages छोटी-सी गलती पर भी भयानक error messages उगल देती हैं, जिससे लोग जल्दी हार मान लेते हैं। हाल की languages, जैसे Rust, ने इसमें सुधार किया है, लेकिन XHTML के दौर में छोटी-सी गलती पकड़ना भी आसान नहीं था

  • मैं Google Wave को चुनूँगा। मैंने Chris DiBona का शुरुआती demo देखा था, और वह वाकई शानदार था। Real-time translation, अलग-अलग messaging का integration, open source, और बहुत-से शानदार features थे। लेकिन जो Wave वास्तव में लॉन्च हुआ वह एक छोटा, कमज़ोर version था, और बाज़ार ने भी उसे ठुकरा दिया, जो बहुत अफ़सोस की बात है। आख़िरकार JIRA, Slack, email जैसी चीज़ों के रहते Wave की कमी बहुत महसूस होती है

    • Google Wave का tech stack शानदार था, लेकिन UI design में उसने घातक गलती की। उसने Wave को एक single document की तरह नहीं बल्कि कई अलग-अलग items की तरह ट्रीट किया, जिससे सब कुछ सिर्फ जटिल लगा और उसके फ़ायदे गायब हो गए

    • demo देखकर मैं दंग रह गया था, लेकिन थोड़ी देर बाद सोचने पर निष्कर्ष निकला कि यह भयानक है। Slack की तरह हर channel update को अलग-अलग check करना पड़ता है, और Wave में यह ढाँचा उससे भी ज़्यादा जटिल था, इसलिए मुझे तुरंत लगा कि इसे follow करना असंभव होगा

    • Wave की technology बहुत प्रभावशाली थी, लेकिन demo video दोबारा देखें तो साफ़ हो जाता है कि यह बहुत अच्छा product नहीं था। वह सब कुछ समेट लेने वाला एक all-in-one product बनाना चाहता था, लेकिन सफल नहीं हुआ। उल्टा, यही technologies बाद में Google के कई products में बँट गईं, और feature-specific अलग UI होना ज़्यादा intuitive निकला

    • दोस्तों के साथ trip itinerary जैसी shared planning के लिए यह बिल्कुल सही था, और documents व links के साथ ad-hoc discussions में भी Wave का form factor बहुत प्रभावी था। शुरुआती दिनों में यह भविष्य की झलक जैसा लगा और मैंने इसके लिए एक server management plugin भी खुद बनाया था: Wave-ServerAdmin. अब 16 साल हो गए, तो लगता है इसे archive कर देना चाहिए

    • मैंने असली open-source Wave server डाउनलोड करके उससे कोई product बनाने की सोची थी, लेकिन सबसे बड़ी सीमा यह थी कि वह data को permanently store नहीं कर सकता था। मेरी नज़र में वहीं इसका future खत्म हो गया, और Wave team के लोगों की प्रतिक्रिया भी कुछ ऐसी लगी जैसे वे वास्तविकता से कटे हुए किसी fantasy में हों। फिर भी concept शानदार था

  • Adobe Flash / Shockwave के बाद भी, कई दशक गुजर जाने पर, games या multimedia बनाना उतना आसान करने वाला tool अभी तक नहीं आया। यह याद दिलाता है कि मानव प्रगति हमेशा एक ही दिशा में नहीं बढ़ती, और कभी-कभी हम कुछ कीमती चीज़ें हमेशा के लिए खो भी देते हैं

    • इससे beginners के लिए भी game बनाना बहुत आसान हो गया था, इसलिए पूरे game industry में ताज़े ideas की बाढ़ आ गई। उदाहरण के लिए Zachtronics जैसे indie developers ने इसी रास्ते से शुरुआत की। दूसरी तरफ, हर flash game के साथ बेहिसाब ads और घटिया flash-based navigation भी फैल गई, और एक समय ऐसा था जब लगभग हर restaurant website Flash पर बनी होती थी। Flash-based video players Linux पर सिरदर्द थे, और browser में सही video support आने में देरी के बड़े कारणों में से एक थे

    • Flash वेब पर एक आपदा था। वह एक काले डिब्बे की तरह मौजूद रहता था जिसमें zoom, text selection, back button — कुछ भी काम नहीं करता था। उसके मरने को Steve Jobs की सबसे बड़ी उपलब्धियों में से एक मानने का मन करता है

    • Godot काफ़ी करीब पहुँचता है। इसे सीखना आसान है, यह 2D और 3D दोनों को support करता है, और HTML5/webasm के ज़रिए major OS और mobile तक export किया जा सकता है। अभी यह perfect नहीं है, लेकिन पिछले कुछ वर्षों में इसने बहुत तेज़ प्रगति की है, और Blender की तरह कोई बड़ा turning point आता दिख रहा है

    • भले Adobe ने security issues पूरी तरह हल कर लिए होते, Apple फिर भी इसे मार ही देता। Flash की mass popularity Apple के लिए ख़तरा थी। HTML canvas का craze भी ठंडा पड़ चुका है, फिर भी आज तक ऐसा विकल्प नहीं है जिससे कोई designer subscription के बिना शानदार interactive designs बना सके और उन्हें कहीं भी embed कर सके

    • समस्या यह थी कि Flash का दुरुपयोग बहुत ज़्यादा हुआ। हमारी company में एक app आख़िर तक Flash पर अड़ा रहा, और वजह खोजने पर पता चला कि page पर एक साधारण horizontal divider line Flash में बनाई गई थी। Flash dropdown menus, car sites के splash screens — सब कुछ misuse था। mobile era आने के बाद ही यह मर सका, और तब तक इसे लेकर अफ़सोस करने वाले भी बहुत कम रह गए थे

  • killedbygoogle.com पर दिखने वाली अनगिनत Google services हैं। मैंने एक समय उनमें से 30–40 इस्तेमाल की थीं, लेकिन अब सिर्फ 3–4 ही उपयोग करता हूँ। Google Picasa local में तेज़ और अच्छा था, Google Hangouts के साथ कई chat apps की वजह से काफ़ी उलझन रही। G Suite Legacy को lifetime free बताया गया था, लेकिन आख़िरकार paid कर दिया गया, तो मैंने Google छोड़ दिया। Google Play Music में मैंने हज़ारों MP3 upload किए थे, लेकिन service बंद हो गई, इसलिए दोबारा upload करने का मन नहीं है। Google Finance और NFC Wallet में data reliability पर भरोसा टूट गया, तो वहाँ से भी हट गया। Chromecast Audio सिर्फ वही एक काम बेहतरीन तरीके से करता था जिसकी मुझे ज़रूरत थी, और discontinue होने की ख़बर मिलते ही मैंने उसे बेचने का सोच लिया। Chromecast के मरने की बात भी मुझे इस्तेमाल करते समय ही पता चली

    • Google Reader की कमी हमेशा खलेगी। शायद इसकी operational cost भी बहुत ज़्यादा नहीं रही होगी, और यह उन rare features में से था जिन्हें सालों तक बिना सुधार के भी लोग खुशी से इस्तेमाल करते रहते। पहले भी और आज भी RSS को लगभग उसी तरह इस्तेमाल कर रहा हूँ

    • Google Play Music पर upload किया गया सारा संगीत गायब नहीं हुआ। अगर किसी user ने YouTube Music में migrate किया था, तो बिना दोबारा upload किए भी सारी tracks वहाँ चली गईं

    • Chromecast Audio अब भी ठीक काम करता है। बस अब वह बिकता नहीं है, इसलिए मैं second-hand listings पर नज़र रखता रहता हूँ

    • Picasa का face recognition अपने समय से आगे था, और इसका offline package वाकई शानदार था। अफ़सोस यह कि आख़िरी version में एक bug था जो face tags को random तरीके से बदल देता था, और इससे परिवार की हज़ारों फ़ोटो की पहचान बेकार हो गई। Digikam किसी तरह मिलती-जुलती भूमिका निभाता है, लेकिन replacement के तौर पर बहुत कमज़ोर है

    • Google Notebook बंद करने के कुछ साल बाद Google Keep बनाया गया, और दिलचस्प यह है कि उसके features लगभग वही थे

  • Lytro light-field camera तकनीकी रूप से प्रभावशाली था, और उसके दो products भी आए, लेकिन वह professional photographers के लिए ज़रूरी resolution तक नहीं पहुँच पाया। हालाँकि अब Meta Ray-Ban के light-field displays और gaussian splats जैसे media formats के उभरने के साथ हम ऐसे दौर में हैं जहाँ कहीं ज़्यादा sensor data इस्तेमाल किया जा सकता है। Technology के बाहर भी, Polaroid या Instax जैसी quirky low-resolution cameras का बाज़ार काफ़ी बड़ा है, इसलिए पहला Lytro एक मज़ेदार form factor के साथ printer सहित भी आ सकता था

    • light field कई अलग focus depths पर pixels को मिलाकर रिकॉर्ड करता है, इसलिए संरचनात्मक रूप से उसका resolution साधारण camera से कम होना तय है। इसे बनाना असंभव नहीं, लेकिन इसकी physical limits अफ़सोसजनक हैं

    • लगता है आजकल smartphones भी यह feature कुछ हद तक implement करते हैं। मुझे याद है Lytro camera का आना काफ़ी रोमांचक लगा था

  • Optane persistent memory में data को सीधे store करके बिना boot या app load किए वहीं से तुरंत काम जारी रखने जैसा क्रांतिकारी मूल्य था। यह बहुत महँगा होने की वजह से असफल हुआ, लेकिन उससे पहले ही इसकी सीमाएँ स्पष्ट थीं। VM memory snapshots, macOS containers जैसी चीज़ों की वजह से यह दिशा पूरी तरह गायब भी नहीं हुई है

    • मुझे 3dxpoint technology पर अटूट भरोसा है। यह दशकों में परिपक्व हुई technology थी, लेकिन business side में दुनिया के तैयार होने का इंतज़ार करने का धैर्य नहीं था

    • मौजूदा systems की सोच RAM और disk के विभाजन में इतनी बँधी हुई थी कि Optane जैसे नए hardware को स्वीकार करने की तैयारी कम थी। फिर भी server space में कुछ use cases उभरे, और इससे जुड़े research projects भी बहुत निकले

    • Optane तकनीकी रूप से अद्भुत था। यह RAM और disk की सीमा मिटा देने के क़रीब पहुँच गया था, मानो एक ही stick में सारी memory समा जाए

    • मैं सचमुच kernel को Optane drive पर रखकर instant boot जैसा अनुभव ले रहा हूँ

    • सिर्फ price ही कारण नहीं था; ecosystem का आधार पर्याप्त फैल नहीं पाया, और पुरानी सोच भी तैयार नहीं थी। यह शुरुआती Lisp या Smalltalk की तरह (live) image-based environments के ज़्यादा करीब का model था। मेरे पास भी ऐसा system है जिसमें firmware और low-capacity Optane supported था। Capacity छोटी है और पुराना OS ही चल सकता है, लेकिन experimentation के लिए फिर भी काफ़ी क़ीमती है। अगर RAM पर्याप्त हो तो suspend/resume जैसा असर नकल करके पाया जा सकता है। SSD की प्रगति के साथ speed gap लगभग मिट गया। अब बस TBW जैसी endurance concerns बचती हैं। दोनों को मिलाकर भी इस्तेमाल किया जा सकता है

  • Ricochet network एक अनोखा system था, जिसने landline के दौर में wireless packet mesh के जरिए ISDN जैसी speed दी। 23 city networks पर 5 अरब डॉलर खर्च किए गए, लेकिन customers लगभग नहीं मिले और 2001 में यह बंद हो गया। Marketing “mobile professionals” पर केंद्रित थी, जबकि उसने उस घरेलू बाज़ार को नज़रअंदाज़ किया जो असल में तेज़ internet चाहता था। आज के 5G femtocells उसके physical concept से मिलते-जुलते हैं, लेकिन उनमें redundancy और self-routing की सोच नहीं है

    • Ricochet अपने समय से आगे का शानदार system था। Joel Spolsky की यह टिप्पणी भी पढ़ने लायक है: Ricochet Wireless modem review

    • मुझे Ricochet modem से सचमुच प्यार था। 2nd-gen Ricochet और PowerBook लेकर Palo Alto के कैफ़े में 56k web browsing और ssh sessions करने की यादें हैं। शायद वह अब भी घर में किसी box में पड़ा है; सोच रहा हूँ मज़े के लिए उसे star mode में जोड़कर देखूँ

    • मैंने 98–99 में San Francisco में Ricochet modem इस्तेमाल किया था। दस साल बाद iPhone ने 3G युग की शुरुआत की, और performance improvement भी भारी थी। अगर Ricochet बचा रहता तो क्या मेरी ज़िंदगी बेहतर होती? सोचने पर लगता है कि technology progress कहीं ज़्यादा सही दिशा में गई

    • यह सेवा मैं पूरी तरह भूल चुका था, लेकिन अब सोचता हूँ तो उस समय यह सच में शानदार थी। शायद मैं उसके केवल चार customers में से एक था

  • Microsoft का Midori एक ऐसा OS था जो capability-based security की ओर बढ़ रहा था। अफ़वाह है कि यह Windows code चलाने लायक स्तर तक विकसित हो चुका था, लेकिन internal politics की वजह से इसे बंद कर दिया गया। यह कुछ हद तक Fuchsia का पूर्वज जैसा लगता है। Midori wiki

    • Midori वाकई बहुत दिलचस्प था। Joe Duffy का blog शायद इस पर सबसे विस्तृत public source है: Midori blog. Microsoft के अंदर इसे moonshot और key talent retention project दोनों तरह से देखा जाता था। सौ से ज़्यादा, बहुत senior engineers इसमें लगाए गए थे। इसकी कुछ research उपलब्धियाँ .NET में काम आईं, इसलिए सब कुछ पूरी तरह गायब नहीं हुआ

    • Windows code execution वाली अफ़वाह कहाँ से आई, यह समझ नहीं आता। उपलब्ध सारे documents के अनुसार Midori का लक्ष्य legacy code से पूरी तरह incompatibility था। हो सकता है भीतर कुछ लोग migration का सपना देखते रहे हों, लेकिन design अपने मूल में बिना transition वाला एक बिल्कुल नया system था

    • इसका technical foundation दिलचस्प है, लेकिन Microsoft के हाथों में यह आख़िरकार नए proprietary problems से भरा हुआ bloated software बन जाता। आज तक शायद इसमें users की इच्छा के बिना spyware और AI features भी ठूँस दिए गए होते

    • क्या आप Genode(genode.org) को जानते हैं? यह Midori जैसे क्षेत्र में है और अब भी actively developed है

  • Yahoo Pipes RSS feeds और custom workflows बनाने के लिए वाकई शानदार था। आज Zapier या n8n जैसे alternatives हैं, लेकिन मुझे Pipes खास तौर पर पसंद था। और Google Reader को लेकर की गई nostalgia से भी मैं सहमत हूँ

    • Pipes का इतिहास archive ज़रूर पढ़ें। इसमें असली developers की यादें दर्ज हैं

    • Yahoo Pipes वही भविष्य था जिसकी ओर internet को जाना चाहिए था। कई दशक बाद भी ऐसे inter-tool integrations मुश्किल से असली unix pipes के स्तर तक ही पहुँच पाए हैं

    • मैंने इसे खुद कभी इस्तेमाल नहीं किया, लेकिन जब भी Pipes के बारे में सकारात्मक यादें सुनता हूँ, साफ़ लगता है कि यह बहुत शानदार tool रहा होगा। समझ नहीं आता कि वास्तव में मरा क्या — Pipes, या फिर open standards और protocols पर आधारित public internet?

    • मुझे Pipes बहुत पसंद था। मैं कई sites से content इकट्ठा करता, उसे pipes से format करता, और फिर RSS के ज़रिए अपने php blog में लाता था। लेकिन धीरे-धीरे sites ने RSS support बंद करना शुरू किया, और Pipes का मतलब ही खत्म हो गया, फिर वह बंद भी हो गया। कुछ समय तक मैंने riko नाम की Python library से visual editor के बिना वैसा ही काम किया, और उसी ने मुझे PHP से Python की ओर ले जाने में मदद की

    • अगर आप Yahoo! Pipes के विचार को फिर से ज़िंदा करना चाहते हैं, तो Node-RED(nodered.org) अच्छी शुरुआत है। इसके फायदे हैं: open source, मज़बूत API, 10 साल से ज़्यादा का जमा अनुभव, solid backend वगैरह। मैंने Browser-Red भी इस्तेमाल किया है, जो सिर्फ Node-RED frontend लाता है, और Erlang-Red भी, जो इसे Erlang backend पर दोबारा बनाता है। Node-RED में हर node के पास एक input port या कोई port नहीं होता, जबकि Pipes में कई input lines हो सकती थीं। अगर आपको jQuery आती है, तो इसका frontend जल्दी समझ में आ जाता है। Node-RED या flow-based programming के बारे में कोई सवाल हो तो कभी भी संपर्क करें