- लोकल-फर्स्ट सॉफ़्टवेयर एक ऐसा दृष्टिकोण है जो cloud-आधारित collaboration और व्यक्तिगत data ownership, दोनों के फ़ायदे एक साथ हासिल करना चाहता है
- मौजूदा cloud apps real-time collaboration और accessibility में बेहतरीन हैं, लेकिन data ownership और long-term accessibility जैसी समस्याएँ भी पैदा करते हैं
- लोकल-फर्स्ट सॉफ़्टवेयर local storage को data के प्राथमिक storage location के रूप में मानता है, और sync तथा collaboration features को अतिरिक्त रूप से प्रदान करता है
- ऐसा सॉफ़्टवेयर speed, offline support, privacy और user control जैसे क्षेत्रों में फ़ायदे देता है, लेकिन real-time collaboration या multi-device sync जैसी चीज़ों में implementation complexity भी मौजूद रहती है
- लोकल-फर्स्ट सॉफ़्टवेयर को व्यवहारिक बनाने के लिए कई मौजूदा technology models की तुलना और विश्लेषण किया जा रहा है, और भविष्य में इससे भी बेहतर models विकसित होने की संभावना तलाश की जा रही है
cloud apps और data ownership की सीमाएँ
- ज़्यादातर users Google Docs, Figma, Slack जैसे विभिन्न cloud apps का उपयोग document writing, design, collaboration और कई अन्य उद्देश्यों के लिए करते हैं
- ये services browser या mobile app के ज़रिए access की जाती हैं, और अधिकांश data को server पर store करती हैं
- cloud-आधारित software में collaboration और कहीं से भी data access करने का फ़ायदा होता है, लेकिन जैसे-जैसे कोई app में समय लगाता है, उसके भीतर मौजूद data की value बढ़ती जाती है
- experts के साथ interviews से यह सामने आया कि cloud apps के functional benefits के पीछे ownership का खोना और long-term accessibility की अनिश्चितता जैसी गंभीर कमियाँ भी हैं
- users द्वारा स्वयं बनाए या उत्पादित materials और data को सुरक्षित रखने और own करने के अधिकार के सीमित होने से मानसिक असुरक्षा और वास्तविक जोखिम, दोनों मौजूद रहते हैं
data के वास्तविक ownership का अर्थ
- cloud में stored data देखने में “अपना” लगता है, लेकिन वास्तविक management और access control authority cloud service provider के पास होती है
- service बंद होने या server failure की स्थिति में data तक पहुँच असंभव हो सकती है और long-term data preservation भी मुश्किल हो जाता है
- असली मुद्दा कानूनी intellectual property नहीं, बल्कि user द्वारा महसूस किया जाने वाला data ownership और control है
- local storage पर आधारित पुराने applications (text editors, version control, विभिन्न tools) पूर्ण data ownership और autonomy सुनिश्चित करते हैं
cloud और local के फ़ायदों-नुक़सानों की तुलना
- "cloud app = collaboration और accessibility", "local app = ownership और autonomy"
- इसे either-or विकल्प की तरह नहीं, बल्कि hybrid approach के best combination के रूप में देखने की ज़रूरत है
- data ownership और real-time collaboration एक-दूसरे के विरोधी नहीं हैं; ऐसा software model डिज़ाइन किया जा सकता है जो दोनों हासिल करे
- इसी को लोकल-फर्स्ट सॉफ़्टवेयर कहा गया है, और local storage, network तथा auxiliary servers के संयोजन को इसकी मूल संरचना के रूप में प्रस्तावित किया गया है
लोकल-फर्स्ट सॉफ़्टवेयर के 7 आदर्श
- cloud apps में server data की “primary copy” की भूमिका निभाता है, इसलिए हर request के लिए server round-trip की ज़रूरत पड़ती है और user experience में latency आती है
- इसके विपरीत, लोकल-फर्स्ट सॉफ़्टवेयर local storage की copy को data का primary version मानता है, जबकि (server के माध्यम से) sync को secondary रूप से संभाला जाता है
- यह नज़रिया बदलने से response speed, offline support और data control जैसे क्षेत्रों में वास्तविक लाभ मिलते हैं
1. speed (तेज़ responsiveness)
- लोकल-फर्स्ट apps सारे operations local file system पर process करते हैं, इसलिए server request का इंतज़ार किए बिना तुरंत user responsiveness हासिल की जा सकती है
- sync background में चुपचाप process होता रहता है, इसलिए किसी भी समय user experience बाधित नहीं होता
2. multi-device sync
- आधुनिक users कई devices पर काम करते हैं, इसलिए लोकल-फर्स्ट apps में भी devices के बीच data sync अनिवार्य है
- file-level sync एकल user के लिए आसान है, लेकिन कई लोगों द्वारा एक साथ editing करने पर conflict की समस्या पैदा होती है
3. offline-first
- लोकल-फर्स्ट सॉफ़्टवेयर में offline स्थिति में भी data को लिखना और edit करना हमेशा संभव होता है, और बाद में network लौटने पर automatic sync हो जाता है
- Bluetooth, local WiFi जैसी कई विधियों से devices के बीच data sharing और sync संभव है
- वास्तविक offline support के लिए locally installed executable रूप को प्राथमिकता दी जाती है
4. collaboration और conflict management
- पारंपरिक तरीक़ों (email attachments, version control tools आदि) में कई लोग एक ही file पर साथ काम करें तो conflict और manual merge की असुविधा रहती है
- cloud apps (Google Docs आदि) real-time concurrent editing के ज़रिए collaboration की कठिनाई और टकराव को कम करते हैं
- लोकल-फर्स्ट सॉफ़्टवेयर में भी real-time collaboration, change suggestions और approvals जैसे विभिन्न collaboration flows को लागू करने की संभावना है, और यही एक तकनीकी चुनौती वाला क्षेत्र है
5. data का long-term preservation
- लोकल-फर्स्ट apps का उपयोग करने पर software vendor के समाप्त हो जाने पर भी data access का अधिकार सुरक्षित रह सकता है
- सामान्य file formats (text, PDF, JPEG आदि) लंबे समय तक compatibility बनाए रख सकते हैं, और incompatible formats तक भी virtual machine या emulator से पहुँचा जा सकता है
- data का वास्तविक long-term preservation न हो तो digital dark age की समस्या—यानी भविष्य की मानवता आज के data को access या interpret न कर पाए—वास्तविकता बन सकती है
6. privacy और security
- cloud की centralized structure hacking और internal employee misuse जैसी कई security incidents के प्रति संवेदनशील होती है
- personal information या sensitive data संभालने वाले professionals लोकल-फर्स्ट संरचना में end-to-end encryption के ज़रिए security और data independence हासिल कर सकते हैं
- Google जैसी बड़ी कंपनियाँ internal रूप से data का कई तरीक़ों से उपयोग कर सकती हैं, जबकि लोकल-फर्स्ट सॉफ़्टवेयर data subject को नियंत्रण देता है
7. user ownership और control
- cloud service providers द्वारा मनमाने ढंग से data access को block या restrict किया जा सकता है (गलत automatic flagging, policy changes आदि)
- लोकल-फर्स्ट environment में data use, modification, backup और retention से जुड़े सभी अधिकार user स्वयं तय करता है
- यह सिर्फ़ कानूनी copyright का मुद्दा नहीं, बल्कि user की वास्तविक autonomy और data control का प्रश्न है
विभिन्न software models की तुलना
- email attachment + local files: speed, offline, long-term preservation और control में मज़बूत, लेकिन collaboration और device sync में असुविधाजनक
- cloud web apps (Google Docs, Trello आदि): real-time collaboration और accessibility में बेहतरीन, लेकिन speed, offline, ownership और privacy में कमज़ोर
- file sync services (Dropbox आदि): speed, offline, long-term preservation और control में अच्छे, लेकिन collaboration और mobile environment में सीमाएँ
- version control systems (Git आदि): speed, offline, long-term preservation और control में उत्कृष्ट, लेकिन non-text files और real-time collaboration में कमज़ोरी
- mobile clients (Firebase, CloudKit आदि): sync और offline में मज़बूत, लेकिन personal information, privacy और long-term service continuity में सीमाएँ
- multi-master replication approaches (DB, जैसे: CouchDB): offline और sync में मज़बूत, लेकिन collaboration, privacy और control जैसे आदर्शों को पूरा करना कठिन या अपर्याप्त
software developers का नज़रिया और भविष्य की दिशा
- आदर्श लोकल-फर्स्ट सॉफ़्टवेयर को शुरुआत से ही offline, multi-device sync, real-time collaboration, privacy और user control को डिज़ाइन और implement करना होगा
- लेकिन व्यवहारिक रूप से इन सभी आदर्शों को एक साथ पूरा करने वाली open technology अभी उपलब्ध नहीं है
- आधुनिक computer science research में विकसित नई technologies (जैसे: Conflict-free Replicated Data Types(CRDTs), distributed data sync approaches आदि) भविष्य के लोकल-फर्स्ट सॉफ़्टवेयर की नींव बन सकती हैं
निष्कर्ष
- लोकल-फर्स्ट सॉफ़्टवेयर digital युग में collaboration, independence, privacy और data sovereignty के संतुलन को साकार करने वाली एक महत्वपूर्ण दिशा है
- यह experts, creators आदि को data पर ownership की भावना और long-term protection देता है, और आगे चलकर पूरे उद्योग में सकारात्मक बदलाव ला सकता है
- आगे ऐसे बेहतर infrastructure, development tools, architecture और algorithms पर शोध और प्रयोग जारी रखने की ज़रूरत होगी, जो इन आदर्शों को वास्तविकता में बदल सकें
1 टिप्पणियां
Hacker News टिप्पणियाँ
इससे मैं सौ फ़ीसदी सहमत हूँ। मैं भी इसी तरह की समस्या हल करने के लिए डेवलप कर रहा हूँ, और अपने डेटा को cloud में डालकर सिर्फ subscription fee देते रहना अब थका चुका है। अभी मैं एक fitness tracking app बना रहा हूँ, जिसमें Sublime model लागू करने का इरादा है। शुरुआत में एक बार खरीदें, कई सालों तक updates मिलें, सभी devices के साथ sync हो, और lifetime इस्तेमाल किया जा सके। बाद में updates चाहिए हों तो नया version फिर से खरीदना काफ़ी है। लक्ष्य यह है कि quality इतनी अच्छी हो कि लोग उसी version को लंबे समय तक इस्तेमाल कर सकें। कुल software में से 90% के लिए मैं यही model चाहता हूँ। लोग उचित कीमत पर खरीद सकें, product ख़ुद अच्छा हो, और cloud integration के बिना भी ठीक से काम करे—यह बहुत ज़रूरी है। सिर्फ data privacy ही नहीं, इस model के और भी कई फ़ायदे हैं। अभी tooling वगैरह में चुनौतियाँ बाकी हैं, लेकिन तकनीकी बुनियाद काफ़ी मज़बूत है। local-first software की सबसे बड़ी ताकत इसका स्वस्थ incentive structure है। यह ads, user tracking, या ‘engagement’ maximize करने के बजाय product ख़ुद के लिए reward पाने वाला ढाँचा है। सच में user-centered software जैसा लगता है.
Obsidian का note app model भी बहुत अच्छा उदाहरण है। client मुफ़्त है, और sync service एक optional paid service के रूप में बेची जाती है। notes Markdown files में होते हैं, इसलिए client के बिना भी काम चल सकता है—यही इसकी ताकत है.
यह जानना दिलचस्प होगा कि cloud infrastructure इस्तेमाल किए बिना आप sync कैसे करने की योजना बना रहे हैं.
पूरी तरह सहमत। अगर ठीक लगे तो fitness tracking app का tech stack भी जानना चाहूँगा, ख़ासकर cross-device sync कैसे handle कर रहे हैं.
ads से कमाई करने वाले pure local apps भी काफ़ी हैं, इसलिए ‘ads नहीं होंगे’ वाली बात हमेशा सही नहीं होती.
अभी Berlin में Ink and Switch की मेज़बानी में Local-first Software conference (https://www.localfirstconf.com/) काफ़ी सक्रिय रूप से हो रही है, और इस साल नवंबर में San Francisco में Sync Conf(https://syncconf.dev/) भी शुरू हुआ है। हाल की conference में paper के co-authors ने ख़ुद panel discussion किया, जहाँ local-first software के dev tools के संदर्भ में सीखी गई बातों पर चर्चा हुई—काफ़ी उपयोगी था। panel discussion video ज़रूर देखें। अभी community में “Sync” को local-first का core element माना जाने लगा है, और sync engine जैसे dev tools को local-first की विशेषताओं को enable करने वाले tools के रूप में देखा जा रहा है, न कि उन्हें local-first ख़ुद माना जा रहा है। पिछले कुछ वर्षों की talks का पूरा संग्रह भी यहाँ upload किया गया है। realtime और asynchronous collaboration को support करने वाले tools पर तेज़ी से काम हो रहा है, और हाल में AI के उभार के कारण ऐसे sync engines की ज़रूरत वाला बाज़ार और भी बन रहा है। AI apps मूल रूप से multi-user collaboration environments होते हैं, इसलिए sync engine community की तकनीकी नींव अब पहले से ज़्यादा ज़रूरी है.
इस विषय पर पहले भी बहुत सक्रिय चर्चा हुई है, इसलिए रुचि हो तो इन्हें पढ़ना फ़ायदेमंद रहेगा: 2019-05, 191 टिप्पणियाँ
2019-11, 241 टिप्पणियाँ
2020-07, 9 टिप्पणियाँ
2020-08, 134 टिप्पणियाँ
2021-02, 90 टिप्पणियाँ
2022-06, 30 टिप्पणियाँ
2023-10, 50 टिप्पणियाँ
मेरा तर्क है कि हर app को अपना अलग sync platform रखने की ज़रूरत नहीं है। यह रुझान शायद mobile apps में program-to-program composition और modularization की कठिनाइयों से निकला है। अगर सच में local-first चाहिए, तो file system का इस्तेमाल किया जा सकता है। user के नज़रिए से git, box जैसी कई मौजूदा solutions में से सीधे चुनाव किया जा सकता है। हर app की अपनी sync signup प्रक्रिया अपने-आप में SaaS जितनी ही opaque और fragile हो सकती है, इसलिए यह बोझिल लगता है.
मैं इस बात से सहमत हूँ कि हर app को sync engine की ज़रूरत नहीं होती, लेकिन file system को local-first का universal solution नहीं मानता। इसके दो कारण हैं। पहला है concurrency। अगर सिर्फ basic local-first चाहिए तो कोई भी sync काफ़ी हो सकता है, लेकिन मैं उससे ज़्यादा चाहता हूँ। उदाहरण के लिए, मैं चाहता हूँ कि मैं और मेरी पत्नी दोनों network कटे होने पर भी अपने-अपने फ़ोन पर स्वतंत्र रूप से edits करें, और बाद में वह अपने-आप ठीक से merge हो जाए। DropBox जैसा सहज sync अनुभव चाहिए। दूसरा, बेहतर sync experience के लिए sync engine को data structure और semantics की गहरी समझ होनी चाहिए। git या box में semantic concurrent editing जैसी ज़रूरतों के सामने कई सीमाएँ हैं.
मैंने वास्तव में सिर्फ file system वाला तरीका implement करके देखा है, लेकिन clients के बीच यह coordinate करना मुश्किल था कि editing कब allow की जाए, इसलिए file conflicts लगभग अपरिहार्य थे.
जिन systems में online dependency होती है, उनमें अनिवार्य रूप से maintenance और operations cost भी होती है। अगर design local-first या local-only न हो, तो लंबे समय तक भरोसेमंद system बनाना मुश्किल है। connected appliances और cars इस दृष्टि से सच में बेवकूफ़ाना engineering के उदाहरण हैं.
मैं उल्टा इस बात की आलोचना करता हूँ कि cloud reliability की समस्या को तकनीकी तरीके से, यानी centralized structure से बचकर, हल करने की कोशिश की जा रही है। पहले closed software में नियंत्रण और trust की समस्या को business model से हल किया जाता था—जैसे open source development, maintenance contracts वगैरह। मेरा कहना है कि cloud की समस्या के लिए भी ऐसे business-model solutions की ज़रूरत है। उदाहरण के लिए, standard contracts या licenses बनाए जा सकते हैं जिनमें users के अधिकार स्पष्ट हों, और बाज़ार को इस दिशा में ले जाया जा सकता है कि लोग सिर्फ उन्हीं vendors को चुनें जो ऐसे certified licenses लागू करें। इसमें data portability की गारंटी, data usage का transparent disclosure, service बंद होने पर क्या होगा इसकी स्पष्ट प्रक्रिया—ऐसी बहुत सी शर्तें जोड़ी जा सकती हैं। बेशक सबसे बड़ी अड़चन यह है कि vendors इसे मानें ही क्यों। ग्राहक खोने के डर से वे ऐसे licenses के बदले सिर्फ annual subscription की अनुमति दें या extra cost माँगें—ऐसी संभावना है.
जब business या political समस्याओं को तकनीकी समाधान से संभाला जा सकता है, तो मुझे वह अक्सर ज़्यादा मज़बूत तरीका लगता है, क्योंकि विरोधी हितों को तकनीकी रूप से ही block किया जा सकता है। client-side encryption इसका अच्छा उदाहरण है। privacy policy या bureaucratic rules पर निर्भर रहना मुश्किल है, क्योंकि लुभावन बहुत है और निगरानी/पकड़ना भी कठिन है। अगर data गणितीय रूप से इस तरह encrypted हो कि server उसे पढ़ ही न सके, तो चिंता काफ़ी हद तक ख़त्म हो जाती है। हाँ, अगर server पर data को वास्तव में process करना हो, तो फिर अपने server का इस्तेमाल करने जैसी स्थिति आ जाती है.
मान लीजिए shutdown के समय contract जैसी व्यवस्था हो भी, तो अगर cloud service company बंद हो जाए और सिर्फ notice देकर data export करा दे, तो आख़िर में हाथ में एक विशाल JSON file ही बचेगी। जब तक आप ख़ुद app न बनाएँ या कोई और न बनाए, वह लगभग बेकार है। इरादा अच्छा है, लेकिन यह उस local app से कमज़ोर है जिसमें app के ख़त्म हो जाने के बाद भी data लंबे समय तक उपयोगी बना रहता है.
data portability guarantee जैसी शर्तें भी व्यवहार में बड़े पैमाने पर data migration को आसान नहीं बनातीं। इसमें बहुत समय लगता है, और अगर crisis की स्थिति में जल्दबाज़ी में करना पड़े तो और भी बुरा हो सकता है। एक ही version के open source DBs के बीच भी हर service में अलग variables होते हैं, इसलिए चीज़ें आसान नहीं होतीं। आख़िरकार डेटा को शुरू से ही अपने environment में रखना, और ज़रूरत पड़ने पर ‘unplug’ कर पाने वाला ढाँचा ज़्यादा व्यावहारिक विकल्प लगता है। BYOC(Bring Your Own Cloud) और open source का संयोजन एक संभावित रास्ता है। हमारी company भी BYOC data product चलाती है, इसलिए मैं अनुभव से कह सकता हूँ कि यह संरचना वास्तव में संभव है.
cloud service के shutdown पर contract में responsibility लिख देने से भी, जब company वास्तव में बंद होने का फ़ैसला कर ले, तब उसे लागू और manage करने का व्यावहारिक तरीका साफ़ नज़र नहीं आता.
सिर्फ business issue नहीं, data safety भी समस्या है। subscription या cloud model से बचने की एक बड़ी वजह अपने data की सुरक्षा की इच्छा है। local encryption के बिना भेजा गया data तो किसी भी समय लीक हो सकता है.
यह लेख पढ़कर ताज़गी का एहसास हुआ। मुझे लगता है कि और ज़्यादा apps को local-first होना चाहिए। अगर user cloud sync नहीं चाहता, तो उसे वह विकल्प ज़रूर मिलना चाहिए। मेरा Brisqi(https://brisqi.com) भी इसी offline-first दर्शन पर बना app है। local-first app का मतलब है कि वह मूल रूप से offline में अनिश्चितकाल तक पूरी तरह काम करे। offline experience आधार होना चाहिए, और cloud sync एक अतिरिक्त enhancement होना चाहिए। temporary cache पर आधारित apps को offline-first नहीं कहा जा सकता। data को local DB में store किया जाना चाहिए; सच्चे offline-first का मतलब है कि data internet से स्वतंत्र रूप से बना रहे। ज़्यादातर तथाकथित “offline-first” apps वास्तव में सिर्फ offline-tolerant होते हैं, यानी सीमित offline support। offline-first app बनाना online-only web app बनाने से काफ़ी कठिन है। offline और online के बीच switch होने पर भी data loss के बिना भरोसेमंद sync mechanism होना अनिवार्य है। मैंने यह कैसे implement किया, उस पर मेरा blog देखें(https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...).
ये सिद्धांत consumer-facing products तक सीमित हों, तब भी इनकी अहमियत है। हम अभी Sentinel Devices(www.sentineldevices.com) में SCADA/industrial automation जैसे ऐसे environments के लिए काम कर रहे हैं जहाँ data को किसी भी हालत में बाहर नहीं भेजा जा सकता। हम ऐसा ढाँचा बना रहे हैं जिसमें execution, analysis, और decision-making सब कुछ पूरी तरह local, यानी customer के अपने hardware पर हो। हम कोई external server देते ही नहीं। on-device principle पर इतना केंद्रित यह approach customers और vendors—दोनों के लिए लगभग दिमाग़ खोल देने वाला अनुभव बनता है। बहुत-सी data/AI companies ऐसे markets को इसलिए नज़रअंदाज़ करती हैं क्योंकि customer site पर service देना बहुत मुश्किल होता है। लेकिन हमें अक्सर ग्राहकों को यह ज़ोर देकर समझाना पड़ता है कि यह no-connectivity, fully local processing है। अगर consumer space में लोग local-first के आदी हो जाएँ, तो industrial क्षेत्र में भी बदलाव और तेज़ होगा.
SCADA industry भी हाल में सब कुछ cloud की ओर धकेल रही है। उनका catchphrase है, “अपनी factory को smartphone से manage करें।” लेकिन इससे अब साधारण hobby hackers के लिए भी factory control के रास्ते खुल रहे हैं, जो ख़तरनाक है.
यह क्षेत्र बहुत दिलचस्प है, और आपके काम के लिए शुभकामनाएँ। एक बात जाननी थी—career page पर देखा कि सभी roles onsite हैं। क्या local-first development के कारण वास्तव में offline काम ज़रूरी है, या यह management से जुड़ा फ़ैसला है?
मेरे projects(selfhostblocks, skarabox) का लक्ष्य भी NixOS के आधार पर self-hosting को सबके लिए आसान बनाना है। https, SSO, LDAP, backups, ZFS snapshots आदि लगभग सब कुछ declaratively उपलब्ध कराया जाता है। Vaultwarden, Nextcloud जैसी services समेत ज़्यादातर data store किया जा सकता है, और Home assistant जैसी services भी शामिल हैं। यह YUNoHost के लिए एक competitor जैसा है, लेकिन बेहतर लक्ष्य के साथ। SelfHostBlocks कई package building blocks के रूप में बना है, इसलिए कोई भी इसे freely extend करके self-host कर सकता है। यह framework से ज़्यादा library जैसा approach है। यह NAS का alternative भी है, और पूरी तरह open source है। तकनीकी जानकारी रखने वालों के लिए शायद यह आसान हो, लेकिन लक्ष्य यह है कि आम लोग भी (nix या CLI के बिना) hardware पर इसे install कर सकें.
ऐसे projects के लिए मैं सच में समर्थन महसूस करता हूँ। बहुत सारे शानदार FOSS alternatives हैं, लेकिन उनकी installation व्यवहार में सिर्फ technical लोगों के लिए आसान है (“docker compose up” स्तर की आसानी), आम users के लिए नहीं। self-hosting वाले कई apps web app + DB + server + frontend structure में आते हैं, लेकिन मेरे जैसे कई लोगों को असल में सिर्फ एक device पर उनका इस्तेमाल करना होता है। एक पूरी तरह local desktop program ही काफ़ी हो सकता है, लेकिन non-developers के लिए वह भी बहुत मुश्किल रहता है। high-quality self-hosted FOSS और वास्तविक end users के बीच साफ़ mismatch है। इस gap को भरने वाले और projects होने चाहिए। मैं भी selfhostblocks आज़माने वाला हूँ—इसके विकास के लिए शुभकामनाएँ.
hledger शामिल होना बहुत अच्छा लगा। plain-text accounting की दुनिया में नए लोगों को यह थोड़ा अनोखा लग सकता है, लेकिन यह वाकई बेहतरीन software है.
इसे इतने साफ़-सुथरे ढंग से बनाने के लिए सच में धन्यवाद.
लेख को सरसरी तौर पर देखकर लगा कि उसने ज़्यादातर मुख्य बिंदुओं को छू लिया है, लेकिन पहले paragraph की motivation कुछ कमज़ोर लगी। यह कुछ ऐसा लगता है जैसे कहा जा रहा हो, “apple pie स्वादिष्ट और पौष्टिक है, लेकिन कभी न कभी वह अचानक जलकर गायब हो सकती है, और आपके प्रिय bib को भी साथ ले जा सकती है।”