अपना काम सार्वजनिक करो, तो किस्मत साथ देती है
(github.com/readme)- किस्मत एक अनियंत्रित बाहरी कारक जैसी लग सकती है, लेकिन अपने काम को सार्वजनिक करके अच्छे मौकों से मिलने की संभावना बढ़ाई जा सकती है
- Luck Surface Area को “कुछ करना(Doing Things)” और “लोगों को बताना(Telling People)” के गुणनफल के रूप में परिभाषित किया जाता है
- काम करना और उसे सार्वजनिक करना डेवलपर, डिज़ाइनर और अन्य क्रिएटर्स के लिए अनिवार्य प्रक्रिया है, और यह व्यक्ति की जिज्ञासा और विशेषज्ञता दिखाने का माध्यम भी है
- परफेक्ट नतीजे का इंतज़ार करने के बजाय प्रक्रिया, सीख और trial and error को साथ में साझा करना ज़्यादा महत्वपूर्ण है, और यह दूसरों को प्रेरित करने का काम करता है
- सार्वजनिक किया गया काम नई नौकरी, collaboration, talks, community connections जैसे अप्रत्याशित अवसर पैदा कर सकता है; यह सिर्फ़ किस्मत नहीं बल्कि साझा करने की क्रिया से बना संभाव्य परिणाम है
Luck Surface Area की अवधारणा
- किस्मत को “अप्रत्याशित रूप से अच्छी चीज़ का होना” के रूप में परिभाषित किया जाता है
- उदाहरण: OSS library की सफलता, conference invite, नई नौकरी का प्रस्ताव, client मिलना, podcast में शामिल होना, community में network बनना आदि
- Jason Roberts की परिभाषा के अनुसार, Luck Surface Area उस स्तर के अनुपात में बढ़ता है, जितनी शिद्दत से आप कुछ करते हैं और जितने लोगों तक आप उसे प्रभावी ढंग से पहुँचाते हैं
- सूत्र के रूप में: Luck = [Doing Things] × [Telling People]
- जितना ज़्यादा काम करेंगे और जितने ज़्यादा लोगों को बताएँगे, Luck Surface Area उतना बड़ा होगा
काम करना (Doing the work)
- सार्वजनिक करने से पहले वास्तविक काम करना ज़रूरी है
- डेवलपर, डिज़ाइनर और क्रिएटर्स मूल रूप से कुछ बनाने वाले लोग होते हैं, और यही किस्मत की नींव बनता है
- लोगों के दो प्रकार होते हैं
1. जो पहले से बहुत काम कर रहे हैं, लेकिन उन्हें लगता है कि उनका काम साझा करने लायक नहीं है
2. जो कुछ शुरू करना चाहते हैं, लेकिन उसे अमल में नहीं ला पाते - पहला समूह अक्सर अपने ज्ञान की क़ीमत को कम करके आँकता है; community में साझा किए गए उदाहरणों को देखकर यह समझा जा सकता है कि वे पहले से बहुत कुछ कर सकते हैं
- दूसरे समूह के लिए “छोटी शुरुआत करना” ज़रूरी है
- परफेक्ट idea का इंतज़ार मत कीजिए; छोटे project या experiment से शुरू करना चाहिए
- “गतिविधि से गतिविधि पैदा होती है”
जिज्ञासा और विशेषज्ञता का प्रदर्शन
- personal projects जिज्ञासा को explore करने की बेहतरीन जगह हैं
- उदाहरण: GitHub issues प्रिंट करने वाला receipt printer बनाना, prefabricated shed को office में बदलना, SVG drawing tool बनाना, financial infrastructure पर लंबा newsletter लिखना आदि
- काम से जुड़े projects विशेषज्ञता दिखाने के लिए अच्छे क्षेत्र हैं
- नौकरी में हल की गई समस्याओं या सीखी गई बातों को blog, talk, open source project में बदला जा सकता है
- भले ही बारीकियाँ गोपनीय हों, concepts, lessons, patterns साझा किए जा सकते हैं
- अगर आप एक महीने तक काम के दौरान सामने आए दिलचस्प problems या patterns नोट करें, तो साझा करने के लिए ढेरों ideas मिलेंगे
Publish बटन दबाना (Hitting the publish button)
- बहुत से लोग sharing के चरण में डर महसूस करते हैं
- वजहें: आलोचना का डर, perfectionism, marketing से असहजता आदि
- लेकिन साझा करना घमंड नहीं बल्कि सीख को फैलाने की क्रिया है, जो दूसरों को प्रेरित और शिक्षित करती है
- publish करने का platform Twitter, GitHub, blog, newsletter, YouTube आदि कुछ भी हो सकता है; बस वह “hard drive के बाहर” होना चाहिए
- साझा करना भी सीखी जाने वाली skill है, और सिर्फ़ तैयार नतीजे ही नहीं बल्कि प्रक्रिया, असफलता और सोचने का तरीका भी बाँटना महत्वपूर्ण है
- शुरुआत में यह अटपटा लग सकता है, लेकिन लगातार करने पर स्वाभाविक हो जाता है
किस्मत को पकड़ना (Capturing the luck)
- जब आप अपना काम सार्वजनिक करते हैं, तो अप्रत्याशित सकारात्मक नतीजों की संभावना बढ़ जाती है
- उदाहरण: किसी विषय का expert माना जाना, पाठकों का feedback, job offers, client inquiries, speaking invites, community connections, OSS project की visibility बढ़ना आदि
- ये उदाहरण लेखक के वास्तविक अनुभव हैं, और साझा करने से Luck Surface Area बढ़ने का परिणाम हैं
- मूल सूत्र बहुत सरल है
- Do the work. Tell people.
- अपनी जिज्ञासा और विशेषज्ञता को गहराई से explore करें, और जो सीखा है उसे खुले तौर पर साझा करें
- online criticism से पूरी तरह बचना संभव नहीं, लेकिन आलोचना से कहीं ज़्यादा लोग चुपचाप आपका समर्थन कर रहे होते हैं
- अंततः उन्हीं में से कोई एक आपके जीवन को बदल देने वाला अवसर दे सकता है
3 टिप्पणियां
मुझे लगता है मैंने यह फ़ॉर्मूला कुछ साल पहले भी देखा था, लेकिन इस दौरान मैं इसे ठीक से अमल में नहीं ला पाया।
मैं जूनियर्स से हमेशा जिन बातों पर ज़ोर देता था, उनमें से एक यह थी
'जिस समस्या का आपने समाधान किया है, उसे अच्छी तरह व्यवस्थित करके एक सार्वजनिक पोस्ट के रूप में छोड़ें।'
सबसे पहले, उसे व्यवस्थित करते समय आप पूरी प्रक्रिया को एक बार फिर से रिव्यू करते हैं, इसलिए उसे याद रखना आसान हो जाता है।
और अगर वही समस्या फिर से आए, तो Google पर खोजने से मेरी ही पोस्ट मिल जाती है, इसलिए जल्दी समाधान हो जाता है (पुराने वाले मैं, धन्यवाद!)
साथ ही, वह किसी और के भी काम आ सकती है, इसलिए आपकी प्रतिष्ठा भी बढ़ सकती है — मैं उन्हें यही समझाता था।
Hacker News की टिप्पणियाँ
मैं OSS इंडस्ट्री में काम कर चुका हूँ, और दिल से चाहता हूँ कि मेरा GitHub प्रोजेक्ट मशहूर न हो
50 से ज़्यादा stars पाने वाले experimental projects रहे हैं, लेकिन अच्छा हुआ कि वे ‘वास्तविक’ OSS में विकसित नहीं हुए
पुराने projects के bug-fix requests या जिन PRs में मेरी रुचि नहीं थी, उनकी review करते-करते मेरे weekend भी गए हैं
OSS maintenance लगभग बिना भुगतान वाली part-time नौकरी जैसा है। पहचान भी सीमित मिलती है, और बेहतरीन OSS developers को भी इंडस्ट्री में सही नौकरी ढूँढना मुश्किल होता है
मुझे लगता है OSS maintainers दुनिया के software को संभालकर रखने वाले संत जैसे लोग हैं
GitHub README में “PR welcome”, “सिर्फ security·critical bugs fix होंगे”, “नया maintainer चाहिए” जैसे status badges जोड़ना अच्छा होगा
इसलिए आजकल सवाल उठता है: “आख़िर ऐसा social contract क्यों किया जाए?”
एक विकल्प self-hosted Git community के ज़रिए autonomous project operation है। यह तरीका maintainers की मेहनत को commoditize किए बिना open source को फिर से मज़ेदार बना सकता है
उदाहरण के लिए, अगर 5 साल से untouched repository में PR आए, तो वह automatically code review summary दे सकता है, या rude comments filter करने जैसी सुविधा ला सकता है
अगर code public न हो, तो community में trust build करना मुश्किल है, और “अपना email छोड़िए, whitepaper PDF पाइए” वाला तरीका 2025 में नहीं चलेगा
0 डॉलर का 100% अब भी 0 ही है, लेकिन विशाल बाज़ार का 0.001% भी काफ़ी बड़ा मौका है
इस पोस्ट की बात का सार देखें तो अंततः कोई दूसरा व्यक्ति (आमतौर पर कोई company) open source public करने से सबसे बड़ा फ़ायदा उठाता है
यही वजह है कि GitHub (=Microsoft) को “free labor extractor” की तरह देखा जा सकता है
अगर लेख संतुलित होता, तो उसे इस तरह के conflict of interest के बारे में चेतावनी देनी चाहिए थी
companies हमारी free labor पसंद करती हैं, लेकिन नौकरी नहीं देतीं। मतलब, “आपकी वजह से बहुत काम आया, लेकिन hiring नहीं करेंगे”
अब तो हमारा code LLM training data में समा भी जाता है और नाम तक नहीं बचता
मुझे ऐसा लगता है जैसे मैं समुद्र में लिखकर फेंक रहा हूँ और कोई प्रतिक्रिया ही नहीं सुनाई देती
platforms फुसफुसाते हैं, “बस एक बार और पोस्ट करो, इस बार चल जाएगा”, लेकिन सच में ऐसा है या नहीं, इस पर संदेह होता है
किसी ने product-led marketing से 3 साल में सफलता पाई, और किसी ने 5 साल तक blog से audience बनाने के बाद OSS से कमाई की
आख़िरकार “luck बढ़ाओ” जैसी बात motivation slogan के ज़्यादा क़रीब है, लेकिन असल में कम से कम 5~6 साल की लगातार मेहनत चाहिए
हमारी लिखी चीज़ें companies के training data में समा जाती हैं, readers उन्हीं companies को पैसे देते हैं, और हमें धन्यवाद तक नहीं मिलता
सिर्फ़ वही closed communities अपवाद हैं जहाँ इंसानों के बीच सीधा संवाद संभव है
मैं भी इस लेख से गहराई से सहमत हूँ
OSS की वजह से मुझे resume या coding test के बिना कई कंपनियों से offers मिले
GitHub customer support के साथ bug debug करते-करते मुझे Microsoft MD से recommendation मिली थी, और Cloudflare में भी कुछ ऐसा ही हुआ
आखिरकार OSS trust-based network बनाने का एक tool है
किताबें लिखते हुए, conferences में signing करते हुए, मौक़े स्वाभाविक रूप से आते गए
मेरे हिसाब से open source के चरण कुछ ऐसे हैं
1. अपने काम में महसूस होने वाला pain point पहचानो
2. उस समस्या को हल करने वाला tool बनाओ
3. उसे Reddit, HN, Bluesky आदि पर स्वाभाविक रूप से share करो
open source एक signal broadcasting mechanism है। अच्छा चला तो visiting card बन जाता है, और consulting या hiring के मौक़ों तक ले जाता है
उदाहरण के तौर पर, अप्रैल 2023 में LangChain देखकर मैंने Langroid LLM agent framework बनाया,
और Claude Code Tools नाम का एक CLI toolkit भी चला रहा हूँ।
यह पूरी प्रक्रिया open source को academic publishing जैसी trust accumulation method बना देती है
(व्यंग्य) “नमस्ते, open source किसानों! हमारी AI आपकी नौकरी replace कर सके, इसके लिए थोड़ा और data दीजिए!”
मैंने गणित की कुछ किताबें लिखी हैं, और luck थोड़ा बढ़ा ज़रूर, लेकिन 1200 घंटे की मेहनत का भुगतान minimum wage पर भी नहीं मिला
मैंने भी कुछ चीज़ें public करके कई बार अच्छी नौकरियाँ पाई हैं। अमीर नहीं बना, लेकिन career में बहुत मदद मिली
(लेखक) यह लेख मैंने कुछ साल पहले लिखा था, और इसे फिर से HN पर देखकर अच्छा लगा
उस समय की thread में भी इसी तरह की चर्चा हुई थी
बहुत लोग कहते हैं कि यह “machines को खिलाने वाला लेख” है, लेकिन इस लेख ने मेरी ज़िंदगी बदल दी। उम्मीद है कि यह किसी और के भी काम आए
लेखक का पदनाम “Aaron Francis, Marketing Engineer” है, तो यह सवाल उठता है कि अब marketing को भी engineering कहा जाता है क्या
मेरा GitHub profile