हाल ही में, मैंने स्वतंत्र विकास पर अपने विचारों के बारे में काफी कुछ लिखा है। मैं उन्हें संक्षेप में बताना चाहता था कि कैसे Mole एक ओपन-सोर्स CLI से एक सशुल्क Mac सॉफ़्टवेयर बना—उस समय मैं क्या सोच रहा था, वास्तव में क्या काम आया, और शायद उन दोस्तों के लिए कुछ इनपुट प्रदान करूँ जो अपने प्रोजेक्ट पर काम कर रहे हैं।
Mole की आधिकारिक वेबसाइट है
mole.fit , और CLI को ओपन-सोर्स किया गया है
GitHub पर। आप पहले इसे आज़मा सकते हैं।
पिछले साल राष्ट्रीय दिवस की छुट्टियों के दौरान, मैंने सान्या में एक स्विमिंग पूल के पास कुछ सौ लाइनों का कोड लिखा और एक Mac क्लीनअप कमांड-लाइन टूल बनाया जिसे Mole CLI कहा जाता है, जिसे मैंने GitHub पर ओपन-सोर्स किया। मेरा मूल इरादा केवल अपने और अपने सहकर्मियों के लिए था। जैसा कि हुआ, एक साल से भी कम समय में, इसने 60K स्टार प्राप्त किए, 50 से अधिक वर्ज़न जारी किए, और दुनिया भर के 121 डेवलपर्स ने कोड सबमिट किया, लगभग 800 फीचर सुझावों और बग्स को हल किया।
वास्तव में, मुझे इस बात का अंदाज़ा नहीं था कि कितने लोग इसका उपयोग कर रहे हैं, जब तक एक बार, README में Vercel द्वारा एक्सेलरेट की गई दो इमेज के कारण, ट्रैफ़िक बिलिंग सीमा से अधिक हो गया, और मुझ पर Vercel का $80 बकाया हो गया। तब मुझे एहसास हुआ कि डेस्कटॉप वर्ज़न बनाने का समय आ गया है।
पहले, मुझे सबसे अधिक बार अंतर्राष्ट्रीय उपयोगकर्ताओं से ईमेल मिलते थे, जिनमें सामान्य भावना यह होती थी: "मेरे माता-पिता Mac का उपयोग करते हैं, मेरी बहन भी इसका उपयोग करती है, लेकिन वे टर्मिनल खोलना नहीं जानते। क्या आप एक ऐसा वर्ज़न बना सकते हैं जिसमें कमांड टाइप करने की आवश्यकता न हो?" मैंने इसे कुछ समय के लिए टाल दिया, मुख्यतः क्योंकि मुझे लगा कि CLI स्वयं अभी पर्याप्त परिपक्व नहीं है। बाद में, मैंने दो सप्ताहांत Mac डेस्कटॉप वर्ज़न बनाने में बिताए। मैंने उस रात 10 बजे इसे जारी किया, और पूरी रात नोटिफिकेशन बजते रहे—फ्रेंच, जर्मन, सभी प्रकार की मुद्राएँ। मैंने आखिरकार सोने के लिए ईमेल नोटिफिकेशन बंद कर दिए। पीछे मुड़कर देखने पर, वह प्रारंभिक रिलीज़ वास्तव में काफी पतली थी; दो सप्ताहांत में बनाई गई चीज़ कितनी पूर्ण हो सकती है? कई सुविधाएँ अगले कुछ महीनों में थोड़ी-थोड़ी करके जोड़ी गईं। यह मूल रूप से उपयोगकर्ताओं का एक समूह था जिसने पहले भुगतान किया और फिर इसे पूरा करने में मेरा साथ दिया। CLI अपरिवर्तित रहता है, अभी भी ओपन-सोर्स और मुफ़्त है, और अपडेट होता रहेगा; केवल डेस्कटॉप वर्ज़न का भुगतान किया जाता है।
AI द्वारा बनाए गए तीन प्रकार के कबाड़
डेस्कटॉप वर्ज़न बनने के बाद, मैंने स्वयं जिस सुविधा का सबसे अधिक उपयोग किया वह थी क्लीनअप, क्योंकि AI वास्तव में मेरे Mac को अपनी सीमा तक धकेल रहा था। मैं पूरे दिन कुछ लिखने के लिए Claude Code और Cursor को खुला रखता हूँ। पहले, मैंने इस पर ज्यादा ध्यान नहीं दिया, लेकिन बाद में मैंने पाया कि AI द्वारा छोड़ा गया कबाड़ पारंपरिक सॉफ़्टवेयर से बहुत अलग है, मोटे तौर पर तीन श्रेणियों में आता है।
पहली श्रेणी है कंपाइलेशन आर्टिफैक्ट। यह कोई नई बात नहीं है, लेकिन AI ने पैमाने को बढ़ा दिया है। पहले, मैं शायद कुछ सौ लाइनों का कोड हाथ से लिखता और दिन में तीन से पाँच बार कंपाइल करता; अब, मैं एक एजेंट को एक दोपहर में एक दर्जन राउंड चलाने देता हूँ, हर राउंड में एक बार कंपाइल करता हूँ। Rust प्रोजेक्ट के targets, फ्रंटएंड के .next और dist फ़ोल्डर, और Xcode का DerivedData बहुत तेज़ी से बढ़ते हैं। मैंने एक बार इनमें से सिर्फ 86GB साफ़ किया था। दूसरी श्रेणी है AI टूल्स द्वारा छोड़े गए पुराने वर्ज़न। Claude Code, Cursor Agent, और GitHub Copilot जैसे कमांड-लाइन टूल सभी ऑटो-अपडेट होते हैं। वे पूरे नए वर्ज़न को एक नई डायरेक्ट्री में डाउनलोड करके अपडेट करते हैं—प्रत्येक वर्ज़न लगभग 250MB होता है—और पुराने डिलीट नहीं होते। कुछ महीनों में, एक दर्जन बेकार वर्ज़न जमा हो सकते हैं। तीसरी श्रेणी है मॉडल फ़ाइलें—Ollama और LM Studio द्वारा खींचे गए मॉडल, और HuggingFace कैश, जो अक्सर दर्जनों गीगाबाइट जगह लेते हैं।
Mole पहली दो श्रेणियों को साफ़ करता है लेकिन तीसरी के एक बाइट को भी नहीं छूता। बाद में, मैंने धीरे-धीरे इसे तीन स्तरों में सोचा, स्कैन की गई हर चीज़ को वर्गीकृत किया और फिर तय किया कि क्या इसे डिफ़ॉल्ट रूप से चेक किया जाना चाहिए। पहला स्तर नवीकरणीय है: HTTP कैश, GPU कैश, कंपाइलेशन आर्टिफैक्ट, और अधिकांश लॉग। यदि संबंधित ऐप बंद हो गया है और पथ स्पष्ट है, तो इसे साफ़ किया जा सकता है। दूसरे स्तर की पुनर्निर्माण लागत अधिक है: पैकेज मैनेजर रजिस्ट्री कैश, स्थानीय मॉडल वेट, और iOS DeviceSupport सभी का पुनर्निर्माण किया जा सकता है, लेकिन इसमें बैंडविड्थ और समय लगता है, इसलिए उपयोगकर्ता को स्वयं देखना चाहिए। तीसरा स्तर अपूरणीय है: चैट हिस्ट्री, ईमेल डेटाबेस, फोटो लाइब्रेरी, और वर्तमान प्रोजेक्ट की स्थिति। मेरा मानना है कि इन चीज़ों को कभी भी वन-क्लिक क्लीनअप सूची में नहीं डाला जाना चाहिए।
इन तीन स्तरों को एक "डिलीट करने के लिए सुरक्षित" सूची में संपीड़ित करना आसान होगा, लेकिन इसकी कीमत उपयोगकर्ता के लिए निर्णय लेना है। क्लीनअप पेज पर दस श्रेणियां इसी क्रम में व्यवस्थित हैं: नवीकरणीय कैश शीर्ष पर हैं, और जितना नीचे जाएंगे, उतना ही अधिक आपको स्वयं जांचना होगा।
target, build, dist, __pycache__, और DerivedData जैसी चीज़ों को फिर से कंपाइल करके वापस लाया जा सकता है, जिसमें कुछ मिनटों के CPU की लागत आती है। node_modules, Pods, venv, और vendor भी डिपेंडेंसी डायरेक्ट्री की तरह दिखते हैं, लेकिन उन्हें डिलीट करने के लिए इंटरनेट से फिर से डाउनलोड करना पड़ता है। यदि आप हाई-स्पीड ट्रेन या हवाई जहाज पर हैं और कोई प्रोजेक्ट चलाना चाहते हैं, तो आपको बस इंतजार करना होगा। ये दो श्रेणियां समान दिखती हैं और आसानी से कबाड़ के रूप में साफ़ हो जाती हैं। Mole CLI ने शुरू में ऐसा किया था, लेकिन बाद में मैंने Mac वर्ज़न की क्लीनअप सूची से सभी डाउनलोड-प्रकार की डायरेक्ट्री को विशेष रूप से हटा दिया।
मॉडल यहाँ सबसे भारी श्रेणी हैं। दर्जनों गीगाबाइट को फिर से डाउनलोड करना एक आपदा है, और एक सामान्य क्लीनअप टूल उन्हें सही ढंग से डिलीट भी नहीं करेगा। Ollama मॉडल को हैश द्वारा नामित ब्लॉकों के समूह में विभाजित करता है; कई मॉडल एक ही ब्लॉक साझा कर सकते हैं। ollama rm यह गणना करता है कि क्या कोई और उस ब्लॉक का संदर्भ दे रहा है, तभी उसे जारी करने की हिम्मत करता है। यदि आप फ़ाइल सिस्टम से एक बड़ा दिखने वाला ब्लॉक मैन्युअल रूप से डिलीट करते हैं, तो आप दूसरे मॉडल को तोड़ सकते हैं। केवल टूल ही इन संदर्भों को समझता है।
इसलिए, ~/.ollama/models और ~/.cache/huggingface जैसे पथ कोड में एक सुरक्षा सूची में हार्डकोड किए गए हैं। वे स्कैनिंग चरण के दौरान भी दिखाई नहीं देंगे; वे केवल डिस्क विश्लेषण अनुभाग में अपने कब्जे वाले आकार को दिखाते हैं, मॉडल को स्वयं Ollama या LM Studio द्वारा प्रबंधित करने के लिए छोड़ देते हैं।
मॉडल से भी अधिक अछूती चीज़ों की एक और श्रेणी है: AI सत्र रिकॉर्ड। ~/.codex/sessions, ~/.claude/projects, और ~/.grok/sessions महीनों या एक साल तक AI के साथ आपके पूर्ण संवादों को संग्रहीत करते हैं। उनमें उस समय आपके विचार, अस्वीकृत समाधान और हर बदलाव के कारण शामिल होते हैं। यदि डिलीट कर दिए जाएं, तो वे वास्तव में चले जाते हैं, और एक तरह से, वे कोड से भी अधिक कीमती होते हैं। इसलिए ये पथ Mole में कभी साफ़ नहीं किए जाएंगे, चाहे वे कितने भी समय से वहां पड़े हों। मेमोरी, प्लान, स्किल और जनरेट की गई इमेज भी सुरक्षित हैं।
ये सुरक्षा सूचियाँ शुरुआत में सभी के बारे में नहीं सोची गई थीं; ये ज्यादातर परीक्षण और त्रुटि के माध्यम से सीखी गई थीं। सबसे मूर्खतापूर्ण गलती com.apple.e5rt.e5bundlecache थी। इसके नाम में "Caches" है और यह कैश डायरेक्ट्री में स्थित है, इसलिए यह कैश जैसा दिखता है, लेकिन यह वास्तव में Apple के Neural Engine द्वारा संकलित एक मॉडल है। शुरुआती CLI ने इसे कैश मानकर साफ़ कर दिया, जिससे रिकॉग्निशन सुविधाओं का उपयोग करने वाले सभी ऐप रीबूट होने तक क्रैश हो गए। तब से, मैंने एक आदत विकसित की है: जब मैं अपने नाम में "cache" वाली कोई डायरेक्ट्री देखता हूँ, तो मैं खुद से तीन सवाल पूछता हूँ: इसे किसने लिखा? रीबूट के बाद इसे कौन पढ़ेगा? अगर मैं गलती से इसे डिलीट कर दूं तो मैं इसे कैसे वापस पाऊंगा? अगर मैं एक का भी जवाब नहीं दे सकता, तो मैं इसे नहीं छूता।
डिलीट करने से पहले देखें
मैं इस प्रकार के टूल की गुणवत्ता इस बात से नहीं आंकता कि यह कितना साफ़ कर सकता है, बल्कि इस बात से आंकता हूँ कि क्या यह आपको डिलीट करने से पहले स्पष्ट रूप से देखने देता है।
जब Mole साफ़ करता है, तो वह पहले स्कैन करता है, एक-एक करके आइटम सूचीबद्ध करता है, और दिखाता है कि प्रत्येक आइटम वास्तव में क्या है, कहाँ है, और कितनी जगह लेता है। जिन आइटमों के बारे में मुझे यकीन नहीं है, वे डिफ़ॉल्ट रूप से अनचेक होते हैं। आप डिलीट करने से पहले पुष्टि करते हैं, और डिलीट करते समय, आइटम पहले ट्रैश में जाते हैं ताकि यदि आपको पछतावा हो तो उन्हें पुनर्प्राप्त किया जा सके। स्कैनिंग और क्लीनअप पूरी तरह से स्थानीय रूप से किए जाते हैं; फ़ाइलें और परिणाम कभी अपलोड नहीं किए जाते। इसकी कीमत यह है कि यह धीमा है और इसमें एक अतिरिक्त पुष्टिकरण चरण की आवश्यकता होती है, जो जल्दी में होने पर थकाऊ लग सकता है, लेकिन मैं गलती से डिलीट करने के बजाय एक डिलीट को मिस करना पसंद करूंगा।
अनइंस्टॉलेशन भी इसी तर्क का पालन करता है। जब आप कोई ऐप चुनते हैं, तो Mole सिस्टम में बिखरी हुई हर चीज़ ढूंढता है, प्रत्येक आइटम को उसके पथ और आकार के साथ लेबल करता है। ऊपर दी गई इमेज में, Claude ऐप स्वयं केवल 781MB है, लेकिन ~/Library/Application Support/claude 7.67 GB है। यह कभी भी एप्लिकेशन पैकेज नहीं है जो वास्तव में जगह लेता है। लॉगिन आइटम और बैकग्राउंड सेवाएं भी उसी पेज पर हैं, इसलिए आपको उन्हें सिस्टम सेटिंग्स में ढूंढने की आवश्यकता नहीं है।
उदाहरण के लिए, macOS सिस्टम अपडेट इंस्टॉलर—/macOS Install Data डायरेक्ट्री—अक्सर 10GB से अधिक होती है और सही क्लीनअप लक्ष्य की तरह दिखती है। लेकिन सिस्टम को अभी भी अपडेट पूरा करने के लिए इसकी आवश्यकता हो सकती है; इसे बहुत जल्दी डिलीट करने से मशीन बूट नहीं हो सकती है। इसलिए Mole में, यह तीन स्तरों की सुरक्षा के साथ एक अनचेक समीक्षा आइटम है: यदि इंस्टॉल होने की प्रतीक्षा में कोई अपडेट है, तो पूरी पंक्ति छिपी हुई है; यदि इंस्टॉलर को पिछले 14 दिनों में छुआ गया था, तो यह छिपा हुआ है; यदि इंस्टॉलेशन से संबंधित प्रक्रियाएं अभी भी चल रही हैं, तो यह छिपा हुआ है। यदि कोई भी सिग्नल नहीं पढ़ा जा सकता है, तो इसे जोखिम माना जाता है और बिल्कुल प्रदर्शित नहीं किया जाता है।
निष्पादन के समय, रूट-प्रिविलेज्ड स्क्रिप्ट इन जांचों को फिर से चलाती है। यदि वे विफल होती हैं, तो यह गैर-शून्य कोड के साथ बाहर निकलती है। आपको ऐसी स्थिति नहीं दिखेगी जहाँ "रिपोर्ट कहती है कि 12GB साफ़ किया गया लेकिन एक बाइट भी नहीं हिलाया गया।"
मेरे पास यह आंकने का एक बहुत ही सरल तरीका है कि कोई क्लीनअप टूल अच्छा है या नहीं। एक ही विक्रेता से दो उत्पाद स्थापित करें, केवल एक को अनइंस्टॉल करें, और देखें कि क्या इसमें साझा Application Support पैरेंट डायरेक्ट्री या ग्रुप कंटेनर शामिल है। यदि ऐसा है, तो इसका मतलब है कि यह नाम से मिलान कर रहा है, स्वामित्व से नहीं। मैं ऐसे टूल को बल्क में डिलीट नहीं करने दूंगा जो स्वामित्व को स्पष्ट भी नहीं कर सकता।
यह आम तौर पर आपको परेशान नहीं करेगा
एक बार में 86GB साफ़ करना कुछ लॉग डिलीट करने से हासिल नहीं होता; Claude को अनइंस्टॉल करते समय, आप ऐप से दस गुना बड़ी चीज़ें सिस्टम में बिखरी हुई पा सकते हैं। यह वह ढूंढेगा जो इसे ढूंढने की आवश्यकता है, लेकिन यह सक्रिय रूप से आपको परेशान नहीं करेगा।
एक बार स्थापित होने के बाद, यह आपको साफ़ करने की याद दिलाने के लिए हर कुछ दिनों में नोटिफिकेशन पॉप नहीं करेगा, न ही यह स्कैन करने के बाद यह कहने के लिए कूदेगा कि आपका कंप्यूटर कितना खतरनाक है। जब आप साफ़ करना चाहते हैं तो इसे खोलें; जब आप नहीं चाहते, तो यह ऐसे है जैसे इसका अस्तित्व ही नहीं है।
इंटरफ़ेस भी उसी दर्शन का पालन करता है। यदि स्कैन समाप्त नहीं हुआ है, तो यह परिणाम पृष्ठ में प्रवेश नहीं करता है। उन चीज़ों के लिए जो एक पल में तैयार हो जाएंगी, यह लोडिंग प्रॉम्प्ट भी नहीं देता है; केवल थोड़ी देर बाद एक "व्यस्त" एनिमेशन दिखाई देता है। पूर्णता पृष्ठ में भी पहले से जगह आरक्षित होती है ताकि परिणाम आने पर विंडो कूदे नहीं। ये सभी नियम बहुत तुच्छ हैं, लेकिन साथ में यही कारण हैं कि यह उपयोग करने में स्थिर लगता है।
अंतर्निहित कार्य स्वाभाविक रूप से अप्रत्याशित होते हैं, इसलिए एनिमेशन जोड़ने से मदद नहीं मिलती; प्रक्रिया स्वयं विश्वसनीय होनी चाहिए। मुझे ऐसा रखरखाव टूल नहीं चाहिए जिसकी निरंतर निगरानी की आवश्यकता हो। कार्य शुरू करें, इसके समाप्त होने की प्रतीक्षा करें, और फिर स्क्रीन वापस लें—यही काफी है। इसे आपको देखने की याद दिलाने के लिए रोशनी चमकती रहने की आवश्यकता नहीं है।
एक्सेसिबिलिटी भी इसका हिस्सा है। पढ़ने का क्रम, कीबोर्ड ऑपरेशन और फोकस स्थिरता सभी एक ही "शांत" अनुभव का हिस्सा हैं। जब सिस्टम का "Reduce Motion" चालू होता है, तो ग्रह अपना सजावटी घूर्णन बंद कर देते हैं, और स्थिति परिवर्तन स्थानिक गति को कम कर देते हैं। कोई भी ऑपरेशन उपयोगकर्ता द्वारा एनिमेशन को समझने पर निर्भर नहीं करता है।
इसे 70 वर्षीय व्यक्ति के लिए भी उपयोगी बनाना
पहले, जब मैं चीज़ें बनाता था, तो मैं मूल रूप से केवल इस बात पर विचार करता था कि क्या वे मेरे सहकर्मियों और दोस्तों के लिए उपयोग करने में आसान हैं। CLI से डेस्कटॉप वर्ज़न पर जाने पर, मुझे एहसास हुआ कि इसे 70 वर्षीय दादा के लिए उपयोगी बनाने में बहुत कुछ शामिल है, और यह बहुत अधिक दिलचस्प है। निम्नलिखित सभी पिछले तीन महीनों में उपयोगकर्ता ईमेल से लिए गए हैं; मेरे सबसे बड़े लाभ लगभग सभी यहीं हैं।
लगभग 70 वर्षीय एक ब्रिटिश उपयोगकर्ता ने कहा कि उसे "सीनियर मोमेंट" आया और उसने Mole को फिर से खरीद लिया। "दूसरे भुगतान को आपके लिए एक उपहार समझें; इस उत्कृष्ट टूल के लिए धन्यवाद, इसने मुझे CleanMyMac से कहीं अधिक पाउंड बचाए।" मैंने सुझाव दिया कि वह रिफंड ले या अतिरिक्त लाइसेंस दे दे। उसने चारों ओर जांच की और अगले दिन उत्तर दिया, "मेरे किसी भी पड़ोसी के पास Mac नहीं है, न ही Bluesky पर मेरे फॉलोअर्स के पास। यह राउंड मेरी तरफ से है।" ऐसे पत्र प्राप्त करने से मुझे लगता है कि मुझे उस विश्वास के योग्य बनने के लिए उत्पाद को और भी बेहतर बनाना होगा।
एक अमेरिकी उपयोगकर्ता ने क्षेत्रीय आदतों के बारे में मेरी गलत धारणा को सुधारा। मैंने हमेशा सोचा कि अमेरिकियों को तापमान के लिए फ़ारेनहाइट का उपयोग करना होगा, इसलिए मैंने US क्षेत्र के लिए डिफ़ॉल्ट रूप से फ़ारेनहाइट सेट किया। उसने कहा: "अमेरिकी सभी तकनीकी संदर्भों में सेल्सियस का उपयोग करते हैं; केवल मौसम और शरीर का तापमान अपवाद हैं। जब मैंने Mole स्थापित किया तो 110 देखकर मैं चौंक गया। Apple अमेरिकियों को जो स्पेक दिखाता है वह भी सेल्सियस में है, और fastfetch/neofetch US सिस्टम पर सेल्सियस पर डिफ़ॉल्ट होता है। मैं फ़ारेनहाइट टॉगल रखने का सुझाव देता हूं लेकिन सभी क्षेत्रों के लिए डिफ़ॉल्ट रूप से सेल्सियस रखूं।" मैंने बाद में इसे डिफ़ॉल्ट रूप से सेल्सियस में बदल दिया जिसमें फ़ारेनहाइट टॉगल था। उसने मूल्य निर्धारण के बारे में एक अनुवर्ती भी भेजा, जिसमें कहा कि मैंने जो संख्या दी वह जानबूझकर निर्धारित मूल्य की तरह नहीं दिखती बल्कि किसी अन्य मुद्रा से रूपांतरण की तरह दिखती है। उसने आगे कहा, "'विदेशी' से मेरा मतलब चीनी विरोधी नहीं है, बल्कि यह है कि लोग यह महसूस करना चाहते हैं कि लेखक उन्हें समझता है।" सच कहूं तो, मैंने वह कीमत अपने दिमाग से निकाली थी; उत्पाद बनाने से पहले मैंने मूल्य निर्धारण के बारे में कभी गंभीरता से नहीं सोचा था। एक अजनबी द्वारा पकड़ा जाना काफी शर्मनाक था—पता चला कि एक मूल्य आंकड़ा भी उपयोगकर्ता के निर्णयों को प्रभावित करता है।
हल्की दृश्य हानि वाले एक उपयोगकर्ता ने कहा: "यह एक बहुत अच्छा ऐप लगता है, लेकिन दुर्भाग्य से मैं इसका उपयोग नहीं कर सकता; ऐसा लगता है कि इसमें डार्क मोड हार्डकोड है। मेरा सिस्टम लाइट मोड पर सेट है, और मैं केवल लाइट मोड वाले ऐप का उपयोग करता हूं।" Mole को केवल डार्क बनाना एक जानबूझकर किया गया निर्णय था; मेनू बार पैनल वॉलपेपर पर HUD की तरह तैरता है, और डार्क ग्लास में कम चमक होती है, जिससे थीम स्विच की आवश्यकता समाप्त हो जाती है। लेकिन यह कारण उसके लिए मान्य नहीं था। मुझे हमेशा लगता था कि मैं एक्सेसिबिलिटी के बारे में गंभीर हूं, फिर भी मैं पूरी तरह से यह महसूस करने में विफल रहा कि लाइट मोड स्वयं एक एक्सेसिबिलिटी आवश्यकता है। उस ईमेल को प्राप्त किए हुए काफी समय हो गया है, और Mole अभी भी केवल डार्क है; लाइट मोड अभी भी सूची में है, अधूरा है। मुझे थोड़ा दोषी महसूस होता है कि एक उत्पाद जो एक्सेसिबिलिटी की परवाह करने का दावा करता है, उसने एक ऐसे उपयोगकर्ता को इतने लंबे समय तक प्रतीक्षा करने के लिए छोड़ दिया है जिसने स्पष्ट रूप से कहा था कि वह इसका उपयोग नहीं कर सकता।
एक जर्मन विश्वविद्यालय के एक व्याख्याता ने शैक्षिक लाइसेंस के लिए आवेदन किया, यह कहते हुए कि यह "न केवल व्यक्तिगत रूप से मेरे लिए समर्थन है बल्कि शैक्षिक स्तर पर भी सार्थक समर्थन है।" पता चला कि अंतर्राष्ट्रीय शिक्षक कक्षा के वातावरण में मेरे उत्पाद का उपयोग कर रहे हैं, एक ऐसा उपयोग मामला जिसकी मैंने कल्पना नहीं की थी। एक हंगेरियन डॉक्टर ने सबसे ईमानदार नकारात्मक समीक्षा दी: "सच कहूं तो, एक मुफ्त ऐप भी जो कर सकता है, उसके लिए कीमत थोड़ी अधिक है।" मुझे यह बिल्कुल भी कठोर नहीं लगा; देशों के बीच क्रय शक्ति बहुत भिन्न होती है। वह शिकायत नहीं कर रहा था; वह मुझे एक समस्या का पता लगाने में मदद कर रहा था।
Mole में मेरी पसंदीदा विशेषताएं वास्तव में मेरे विचार नहीं थीं। AirPods की बैटरी कम होने पर नोटिफिकेशन तब जोड़ा गया जब मैं बैटरी हेल्थ पर काम कर रहा था; मुझे उस परिदृश्य का सामना तब तक नहीं हुआ था जब तक एक दोपहर मुझे वास्तव में यह प्राप्त नहीं हुआ—यह बहुत विचारशील था और दखल देने वाला नहीं था। मैंने एक उपयोगकर्ता अनुस्मारक के बाद स्क्रीन को चालू रखने के लिए तीन अलग-अलग व्यवहार जोड़े; जब मैं सप्ताहांत में अचानक बाहर जाता हूं, तो AI कोडिंग चलती रह सकती है, जिससे मेरा बहुत सारा अतुल्यकालिक समय बच जाता है। स्टेटस में iPhone की बैटरी का स्तर देखने में सक्षम होना पहले लागू करना मुश्किल था, लेकिन मुझे अंततः एक रास्ता मिल गया। ये सभी ऐसी चीज़ें थीं जिन्हें उपयोगकर्ताओं ने मुझे जोड़ने के लिए कहा था, और अंत में मुझे इनसे सबसे अधिक लाभ हुआ।
मैं वास्तव में मैन्युअल रूप से ईमेल का जवाब दे रहा हूं
Q&A, रिफंड और एक्टिवेशन कोड रीसेट करना उपयोगकर्ता आधार के 1% से भी कम है। मैं आधे घंटे में यह सब स्वचालित करने के लिए एक स्क्रिप्ट लिख सकता था, लेकिन मैंने नहीं लिखी। केवल एक-एक करके प्रोसेस करके ही मैं महसूस कर सकता हूं कि उपयोगकर्ता वास्तव में क्या चाहते हैं, वे रिफंड क्यों लेते हैं, और क्या चीज़ उन्हें असहज करती है—और यह अक्सर वह पहली चीज़ नहीं होती जो वे पूछते हैं। ऑटोमेशन के लिए मेरी सीमा तब है जब तीन चीज़ें सत्य हों: समस्या दोहराई जाती है, उत्तर स्थिर होता है, और सभी अपवाद समझ में आ जाते हैं। तब तक, मैं एक-एक करके जवाब देना पसंद करूंगा। यह अभी भी प्रभावी है; मैंने मार्केटिंग पर पैसा खर्च नहीं किया है, और विकास ज्यादातर वर्ड-ऑफ-माउथ से आता है। रिफंड दर 0.8% से नीचे है। कई खरीदार CLI के लंबे समय के उपयोगकर्ता हैं।
रिलीज़ से पहले, मैंने कोई टिकट सिस्टम, ग्राहक सेवा प्लेटफ़ॉर्म या नॉलेज बेस स्थापित नहीं किया था। इंजीनियरों को पहले ये सपोर्ट सिस्टम बनाना पसंद है क्योंकि यह परिचित काम है, और AI ने इसे आधे दिन तक संपीड़ित कर दिया है, जिससे बहुत जल्दी शुरू करना आसान हो जाता है। लेकिन जबकि इसे बनाने में केवल आधा दिन लगता है, रखरखाव एक दीर्घकालिक प्रतिबद्धता है, और अभी इसकी बिल्कुल आवश्यकता नहीं है। जिस दिन इनबॉक्स अनुरोधों को खोना शुरू कर देता है, प्रतिक्रिया समय अस्पष्ट हो जाता है, या एक ही प्रश्न के अलग-अलग उत्तर मिलते हैं—तब वास्तव में एक नई प्रणाली की आवश्यकता होती है। AI इस उत्पाद के कई हिस्सों को संभव बनाता है, लेकिन लोगों के साथ संचार को AI द्वारा प्रतिस्थापित नहीं किया जा सकता है; अन्यथा, यह दिलचस्प नहीं होगा। यह दक्षता में सुधार कर सकता है, लेकिन आपसी भावनाओं और विश्वास में सुधार करना कठिन है। यह AI कोडिंग से पैदा हुए उत्पादों के लिए मानवीय स्पर्श बनाए रखने का एक तरीका भी हो सकता है।
वे चीज़ें जो मुझे उपयोगी लगीं
एक उत्पाद बनाने में, मुझे लगता है कि कोडिंग क्षमता केवल लगभग 30% है। अधिक प्रयास आपके अपने दर्द बिंदुओं को अधिकांश उपयोगकर्ताओं के साथ जोड़ने, कुछ ऐसा बनाने में लगता है जो बिना मैनुअल के उपयोग करने में आसान हो, और इसे सही लोगों के सामने धकेलने में लगता है ताकि वे महसूस करें कि इसने एक बड़ी समस्या हल कर दी है। एक उत्पाद इंजीनियर मोटे तौर पर शोधकर्ता, उत्पाद प्रबंधक, इंजीनियर, ऑपरेटर, डेटा विश्लेषक और व्यवसाय रणनीतिकार का संयोजन होता है।
आप जो नहीं करते हैं वह आप जो करते हैं उससे कहीं अधिक महत्वपूर्ण है। एक टूल के लिए जो आपकी फ़ाइलों को डिलीट करता है, यह वह बन जाता है जिसे आप डिलीट नहीं करते हैं। वे हार्डकोडेड सुरक्षा सूचियाँ सभी इसी नियम से आई हैं। मैं भाग्यशाली था कि जब मैंने एक नए व्यक्ति के रूप में शुरुआत की तो मैंने इंजीनियरिंग कल्टीवेशन पर कई किताबें पढ़ीं; "entities should not be multiplied without necessity" और "simplicity is the ultimate sophistication" जैसे वाक्यांश धीरे-धीरे मेरे जीवन, काम और कोड में समा गए। उत्पाद बनाने के बाद मैं इसे और भी गहराई से महसूस करता हूं। एक अच्छे उत्पाद और एक औसत उत्पाद के बीच का अंतर काफी हद तक यह तय करने की क्षमता में निहित है कि क्या नहीं करना है। कुछ सुविधाएं अपने आप में अच्छी होती हैं, लेकिन यदि वे मुख्य पथ पर नहीं हैं, तो मैं उन्हें शामिल नहीं करता; अन्यथा, यह आसानी से सुविधाओं का एक ढेर बन जाता है जिसे बनाए रखना मुश्किल होता है।
एक और भावना यह है कि आपके दिमाग में अगले छह महीनों का एक रोडमैप होना चाहिए, यह स्पष्ट रूप से जानना चाहिए कि प्रत्येक वर्ज़न में क्या जोड़ना है, कौन सी नकली ज़रूरतें हैं, और किन सुविधाओं को वहां रखा जाना चाहिए जहां वे उपयोगकर्ताओं के लिए सुविधाजनक हों। सामान्य उपयोगकर्ताओं के लिए, जिसे आप बिना मैनुअल पढ़े उपयोग कर सकते हैं वह अच्छा है। Mole की स्थिति Mac सिस्टम रखरखाव के एक शांत संरक्षक के रूप में है। कई दोस्तों ने शानदार सुविधाओं का सुझाव दिया है जिन्हें मैंने विनम्रता से अस्वीकार कर दिया है। मेरा लक्ष्य सरल है: यदि प्रत्येक सौ Mac उपयोगकर्ताओं में से एक Mole को रखने को तैयार है, तो यह पहले से ही काफी उपयोगी है।
अब, किसी सुविधा के रोडमैप में प्रवेश करने से पहले, उसे तीन द्वारों से गुजरना होगा: यदि उपयोगकर्ता ने सुविधा में क्लिक नहीं किया है तो कोई स्थायी टाइमर, लिसनर या सैंपलिंग ओवरहेड नहीं हो सकता है; आप एक छोटी सी सुविधा के लिए विशेषाधिकार प्राप्त सहायकों का विस्तार या नई सिस्टम अनुमतियां नहीं जोड़ सकते हैं; और जब उचित डिफ़ॉल्ट मान हों तो आप सेटिंग्स नहीं जोड़ सकते हैं। ये सभी सॉफ़्टवेयर के लिए सार्वभौमिक सिद्धांत नहीं हैं, बल्कि वे नियम हैं जो Mole ने अपने लिए निर्धारित किए हैं। प्रत्येक अतिरिक्त स्थायी कार्य, विशेषाधिकार और कॉन्फ़िगरेशन के लिए उपयोगकर्ता को आप पर थोड़ा और भरोसा करने की आवश्यकता होती है।
मैं मूल रूप से "बड़ी चालों" के लिए बचत नहीं करता; मैं हर हफ्ते एक वर्ज़न जारी करने की कोशिश करता हूं ताकि उपयोगकर्ता की समस्याओं का तुरंत समाधान किया जा सके और मैं आगे-पीछे बातचीत कर सकूं। हर रिलीज़, अपडेट और प्रमोशन एक शानदार संचार अवसर है और उन लोगों को बताता है जिन्होंने खबर नहीं देखी है कि आप क्या कर रहे हैं।
AI युग में, कोड बाधाएं छोटी होती जा रही हैं। अधिक नियंत्रण की आवश्यकता है कि उपयोगकर्ता की समस्याओं को हल करने पर Tokens को ठीक से कैसे खर्च किया जाए। मुझे अधिक खर्च करने में कोई आपत्ति नहीं है, लेकिन इसे प्रभावी ढंग से खर्च किया जाना चाहिए—उदाहरण के लिए, आवश्यकताओं पर अच्छी तरह से चर्चा करना, वास्तविक समस्या खोजने के लिए डेटा में गहराई से जाना, और ऐसी कॉपी लिखना जिसे लोग एक नज़र में समझ जाएं। ये क्षेत्र खर्च करने लायक हैं। मैं Tokens को एक निवेश के रूप में देखता हूं, और निवेश से रिटर्न मिलना चाहिए।
Mole पहले दिन से वैश्विक रहा है, और मैं चीनी की तुलना में अधिक अंग्रेजी सामग्री पोस्ट करता हूं। इस दौरान मेरी भावना यह है कि दुनिया बहुत बड़ी है, उपयोगकर्ता आधार व्यापक है, और वे शुरू से ही आप पर भरोसा करने को तैयार हैं। जिन लोगों की आप गुजरते हुए मदद करते हैं, वे अक्सर बाद में आपके उपयोगकर्ता बन जाते हैं क्योंकि एक वास्तविक बातचीत हुई थी। मैंने प्रचार पर पैसा खर्च नहीं किया है; X पर स्पाइक्स ऊंचे हैं लेकिन अल्पकालिक हैं, जबकि YouTube पर पोस्ट की गई चीज़ें बहुत धीरे-धीरे क्षय होती हैं। जब तक सामग्री अच्छी है और कोई इसकी अनुशंसा करता है, यह लंबे समय तक वहां रह सकती है।
मैंने कल्पना से अधिक समय डेटा पर बिताया। आयाम और समय के अनुसार बिक्री को देखना, ट्रैफ़िक डेटा, उपयोगकर्ता टिप्पणियों, उपयोगकर्ताओं के साथ बातचीत के सभी रिकॉर्ड, रिफंड के कारणों और ओपन-सोर्स पक्ष के सभी मुद्दों के साथ संयुक्त—ये सभी बहुमूल्य संसाधन हैं। वे मुझे कई ऐसी समस्याओं की खोज करने में मदद करते हैं जिनके बारे में मुझे पता नहीं था और यह देखने में मदद करते हैं कि बिक्री फ़नल वास्तव में कहाँ टूटा है।
अंतिम बिंदु मेरे अपने दृष्टिकोण के बारे में अधिक है। गहन उपयोगितावाद के साथ एक खाता बनाना व्यक्ति को चिंतित करता है; मैं इसे एक ब्रांड के रूप में बनाना पसंद करता हूं, जिसमें मैं स्वयं ब्रांड हूं। मेरे विचार, विचारधारा, उत्पाद अपडेट, अंतर्दृष्टि, बातचीत और टिप्पणियां सभी इस ब्रांड में विश्वास जोड़ रहे हैं। आज के नकली फिर भी समृद्ध AI विश्व में विश्वास विशेष रूप से महत्वपूर्ण है। जो चीज़ें सुनने में अद्भुत लगती हैं लेकिन एक बार क्लिक करने पर औसत लगती हैं, उन्होंने पहले ही कई उपयोगकर्ताओं की अपेक्षाओं को कम कर दिया है। भले ही आपके पास वास्तव में एक अच्छा उत्पाद हो, विश्वास के बिना आपको ध्यान नहीं मिलेगा। यह बहुत लंबी अवधि के लिए किया जा सकता है; जब तक आप इंटरनेट पर हैं, यह ब्रांड जीवित रहेगा—यह आपके जीवन का सबसे लंबा जीवनचक्र वाला उत्पाद है।
पाँच ग्रह क्यों
Mole डेस्कटॉप में वर्तमान में पाँच मॉड्यूल हैं: क्लीनअप, अनइंस्टॉल, ऑप्टिमाइज़, डिस्क विश्लेषण और हार्डवेयर स्थिति। प्रत्येक मॉड्यूल इंटरफ़ेस में एक ग्रह से मेल खाता है: क्लीनअप पृथ्वी है, अनइंस्टॉल मंगल है, ऑप्टिमाइज़ बुध है, विश्लेषण बृहस्पति है, और स्थिति सूर्य है। यह ग्रहों की कक्षाओं को देखने के मेरे बचपन के प्यार से संबंधित है, साथ ही इस तथ्य से भी कि दस साल पहले फ्रंटएंड सीखने के बाद मैं वास्तव में जो पहली चीज़ सीखना चाहता था वह WebGL थी। ग्रहों की बनावट को 10 बार से कम नहीं बदला गया; मैंने NASA की आधिकारिक वेबसाइट से कई डाउनलोड किए और फिर उन्हें अंतिम रूप दिया। घूर्णन की दिशा, गति और पूरा होने के बाद उड़ान प्रभाव सभी वास्तविक खगोलीय पिंडों का पालन करते हैं।
इस भाग को छोड़ा जा सकता था; एक छोटा मेनू बार टूल जो एक क्लिक से साफ़ करता है वह भी काम करेगा। लेकिन AI द्वारा उत्पन्न साइबर कबाड़ पहले से ही काफी है। Tokens का उपयोग करके एक और इंटरफ़ेस बनाने के बजाय जो मुश्किल से चलता है, मैं कुछ और आरामदायक बनाना चाहता था—अपने Tokens को बर्बाद नहीं करना, और आपकी टाइमलाइन को प्रदूषित नहीं करना।
मुझे चीज़ों को स्वाभाविक रूप से होते देखना पसंद है, न कि थोड़े समय में तत्काल परिणामों का पीछा करना; इन तीन महीनों ने इसे मजबूत किया है। कुछ समय पहले, मैंने एक वाक्य सोचा: दुनिया की सबसे अच्छी नौकरी शायद एक मुक्त बाजार में एक सतत सीखने वाले के लिए है जो अपने निर्णय, क्षमता और सौंदर्यशास्त्र का उपयोग करके लगातार ऐसा मूल्य बनाता है जिसके लिए दूसरे भुगतान करने को तैयार हैं।
CLI GitHub पर ओपन-सोर्स और मुफ़्त है, और Mac डेस्कटॉप वर्ज़न आधिकारिक वेबसाइट mole.fit पर है।
चूंकि यह पहली बार है जब मैं कोई सशुल्क उत्पाद बना रहा हूँ, हो सकता है कि कुछ ऐसे पहलू हों जिनके बारे में मैंने पूरी तरह से नहीं सोचा हो। मैं अनुभवी मित्रों से सुझाव और सलाह का स्वागत करता हूँ। ऊपर बताए गए बदलाव मेरे विचार नहीं थे; ये सब किसी उपयोगकर्ता के ईमेल या किसी मुद्दे (issue) के कारण आए। इसलिए, उपयोगकर्ताओं से संवाद करने का अवसर कभी न छोड़ें; उनकी शिकायतों और सुझावों को पूरे मन से सुनें—वे आपकी बहुत मदद कर सकते हैं और आपको अपने उपयोगकर्ताओं को बेहतर ढंग से समझने में सक्षम बना सकते हैं।
