37 पॉइंट द्वारा GN⁺ 2025-03-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें

open source को मशहूर बनाने से पहले जानने वाली बातें

  • अगर आप open source के जरिए मशहूर होना या अमीर बनना चाहते हैं, तो यह गलत approach है
  • लोकप्रिय project बनाने से ज़्यादा असरदार ब्लॉग लिखना या conference में बोलना हो सकता है
  • Redux और React Router लोकप्रिय project हैं, लेकिन उनके maintainers के social media followers बहुत ज़्यादा नहीं हैं → project की लोकप्रियता हमेशा व्यक्ति की लोकप्रियता में नहीं बदलती

resume में लिखने के लिए open source मत बनाइए

  • यह धारणा कि open source contribution ज़रूरी है, गलत है
  • सिर्फ मशहूर होने के लिए open source शुरू करने पर सफलता की कोई गारंटी नहीं है
  • project अच्छा हो, फिर भी अगर सिर्फ एक star मिले तो आप उदास हो सकते हैं
  • hiring में open source activity मदद कर सकती है, लेकिन अपना project बनाने से ज़्यादा किसी मौजूदा प्रसिद्ध project में contribute करना असरदार है

पहले contribution से शुरुआत करें

  • बड़े open source project में documentation fixes या bug fixes से शुरुआत करें
  • code लिखने की तुलना में PR बनाना कहीं आसान है
  • अच्छा open source बनाने की सबसे अच्छी वजह है कि आप दुनिया बदलना चाहते हैं

open source के जरिए दुनिया कैसे बदलें

  • PostCSS बनाने का कारण CSS tooling ecosystem में विविधता लाना और CSS processing को आसान बनाना था → यह सफल रहा
  • लोकप्रियता और सफलता महत्वपूर्ण factors हैं

लोकप्रिय project का फ़ॉर्मूला

project की लोकप्रियता = पहचान + promotion + users को मिलने वाला फ़ायदा + luck

  • किसी लोकप्रिय developer का project आसानी से लोकप्रिय होने की ज़्यादा संभावना रखता है → यह अनुचित लग सकता है, लेकिन यही हक़ीक़त है
  • लोकप्रियता के कारणों को समझकर रणनीतिक तरीके से आगे बढ़ना चाहिए

लोग open source कैसे चुनते हैं

  • लोग tools को पूरी तरह तर्कसंगत तरीके से नहीं चुनते
  • ज़्यादातर लोग GitHub पर stars की संख्या देखकर फैसला करते हैं
  • या फिर conference में ज़िक्र हुए framework को अपनाते हैं

लोग वास्तव में जानकारी कैसे पढ़ते हैं

  • users README या documentation को शुरू से अंत तक नहीं पढ़ते
  • जानकारी को 'progressive JPEG' की तरह सरल और क्रमिक रूप से देना चाहिए
  • पहले block में फ़ायदे साफ़-साफ़ बताने चाहिए

लोकप्रियता पाने की रणनीति

  • social media account को अच्छी तरह व्यवस्थित रखना चाहिए
    • लेखक ने शुरुआत में English social account नहीं बनाया, इसलिए लोगों के लिए उन्हें ढूँढना मुश्किल था
    • अगर आप non-English developer हैं, तो English social media account बनाना फ़ायदेमंद है
    • जब project का ज़िक्र हो, तब profile link देना चाहिए ताकि users आसानी से जुड़ सकें
  • realistic mindset रखें
    • luck महत्वपूर्ण है, लेकिन सब कुछ नहीं
    • लेखक के 56 projects में से सिर्फ 4 सफल हुए
    • लोकप्रिय project बनाने से पहले कई बार असफलता मिली
    • सफल project लगातार कोशिश और बार-बार की गई असफलताओं का परिणाम थे
  • असफलता को स्वाभाविक मानें
    • लोकप्रिय project के लिए marathon जैसी लंबी मेहनत चाहिए
    • असफलता प्रक्रिया का हिस्सा है → लगातार सुधार और दोहराव ज़रूरी है
    • शुरू से ही असफलता की संभावना मानकर चलें, लेकिन काम की quality से समझौता न करें

open source को लोकप्रिय बनाने का तरीका: README

  • README और documentation project का पहला impression तय करते हैं
  • user को README के जरिए project की value जल्दी समझ आनी चाहिए
  • README users तक इन रास्तों से पहुँच सकता है
    • talks, blog posts, podcasts जैसे कई promotion channels
    • आखिर में सब README तक ही पहुँचते हैं, इसलिए इसे ध्यान से लिखना चाहिए
  • readers README को शुरू से अंत तक ध्यान से नहीं पढ़ते
  • इसलिए README के शुरुआती हिस्से में project की value साफ़ बतानी चाहिए
  • पहले block में लोगों को project के benefits जल्दी समझ आने चाहिए

सवाल: क्या आप project की value को प्रभावी ढंग से बता रहे हैं?

  • लोग आराम से बैठकर documentation विस्तार से नहीं पढ़ते
  • इसलिए core information और benefits को साफ़ और संक्षेप में व्यवस्थित करना चाहिए
  • documentation को अच्छी तरह व्यवस्थित करके user experience बेहतर किया जा सकता है और project की लोकप्रियता बढ़ाई जा सकती है

1. users तक benefits प्रभावी ढंग से पहुँचाना

  • users को project के benefits बताना सीधे promotion से जुड़ा है
  • पहले बताए गए success formula में users को फ़ायदा देना एक महत्वपूर्ण तत्व है

project की लोकप्रियता = पहचान + promotion + users को मिलने वाला फ़ायदा + luck

  • README, documentation या छोटे intro text में users को benefits साफ़-साफ़ बताने चाहिए
  • सिर्फ popularity या reputation नहीं, बल्कि वास्तविक value के आधार पर ध्यान आकर्षित करने के लिए इन बातों पर ध्यान दें
    • readability: users जल्दी core point समझ सकें
    • scanability: महत्वपूर्ण जानकारी तुरंत नज़र आनी चाहिए
    • first impression: पहले कुछ seconds में project की value साफ़ दिखनी चाहिए

2. message को तेज़ और असरदार तरीके से पहुँचाना

  • README के पहले block में ये तीन चीज़ें ज़रूर होनी चाहिए
    1. स्पष्ट explanation
    2. यह users की कैसे मदद करता है, इसकी स्पष्ट जानकारी
    3. दूसरे products से यह कैसे अलग है, यह साफ़ बताना
  • users को documentation पढ़ने की वजह पहली ही line में समझ आ जानी चाहिए
    • पहली line सबसे महत्वपूर्ण है → ज़्यादातर users पहली line पढ़कर ही project की value का अंदाज़ा लगाते हैं
    • इसलिए पहले block में project के benefits स्पष्ट दिखने चाहिए
  • README के पहले block को लिखने में कुछ दिन से एक हफ़्ता लगाना भी ठीक है
  • PostCSS का पहला block लिखने में लगभग एक हफ़्ता लगा था
  • पहले block में पर्याप्त मेहनत project की सफलता की संभावना बढ़ाती है

3. product को लोगों के लिए आसानी से समझ आने वाला बनाकर समझाना

  • project का explanation साफ़ और intuitive होना चाहिए
  • fancy लगने वाले वाक्यों से ज़्यादा व्यावहारिक explanation महत्वपूर्ण है
  • "Svelte is cybernetically enhanced web apps"
    • बहुत अस्पष्ट है → यह साफ़ नहीं कि असल फ़ायदा क्या है
  • "Svelte is a web UI framework with a unique compiler which generates smaller JS fixes."
    • यह ठोस और स्पष्ट है → कौन-सी समस्या हल होती है और क्या benefit है, यह बताता है
  • ऐसे लिखिए जैसे किसी सहकर्मी से bar में बात कर रहे हों
    • "नया tool बनाया? क्या करता है?" → स्वाभाविक ढंग से समझाइए
  • explanation तैयार हो जाए तो उसे और संक्षिप्त बनाइए
    • explanation लिखने के बाद 2~4 बार और सुधारकर छोटा और स्पष्ट बनाइए

4. lists और bold text से जानकारी जल्दी पहुँचाना

  • जानकारी स्पष्ट देने के लिए lists और bold text का सक्रिय इस्तेमाल करें
  • Nano Stores का पुराना description (text block के रूप में)
    • Nano Stores एक state manager है जिसे कई frontend frameworks में इस्तेमाल किया जा सकता है
    • यह छोटा है और इसमें dependencies नहीं हैं
  • बदला हुआ description (list और bold emphasis के साथ)
    • Nano Stores की ये विशेषताएँ हैं:
      • छोटा size: 286~818 bytes (minified और brotlied)
      • कई frameworks का support: React, Vue, Svelte, Angular आदि
      • कोई dependencies नहीं
  • readability बढ़ाने के points

    • list का इस्तेमाल: जानकारी structured होती है और एक नज़र में समझ आती है
    • bold text का इस्तेमाल: core information पर जल्दी ध्यान जाता है
    • छोटे वाक्य: सिर्फ ज़रूरी जानकारी रखें, अनावश्यक बातें हटाएँ
      • text कम होने पर भी message साफ़ पहुँचना चाहिए

5. code examples और images का इस्तेमाल

  • जटिल concepts को example code या images से आसानी से समझाया जा सकता है
    • "सौ बातों से एक तस्वीर बेहतर" की तरह visual सामग्री समझ बढ़ाने का शक्तिशाली tool है

6. वास्तविक statistics का इस्तेमाल

  • अस्पष्ट दावे या abstract promises से भरोसा बनाना मुश्किल होता है
    • performance, size, speed जैसी चीज़ों के ठोस statistics दिखाने चाहिए
  • उदाहरण: Nano ID में वास्तविक statistics का इस्तेमाल

    • size का प्रमाण: Nano ID सिर्फ 141 bytes है → स्पष्ट संख्या दी गई
    • speed का प्रमाण: Nano ID, UUID से 16% तेज़ है → benchmark result दिया गया
  • statistics को प्रभावी ढंग से इस्तेमाल करने के tips
    • quantified performance data दें → credibility बढ़ती है
    • benchmark results साफ़ लिखें → दूसरे products से अंतर उभरता है
    • API performance या usage भी वास्तविक examples के साथ स्पष्ट दिखाएँ
      • performance, size, speed आदि को ठोस numbers और data से साबित करें

7. step-by-step getting started guide देना

  • अगर project के फ़ायदे साफ़ हो गए हैं, तो अगला कदम इसे इस्तेमाल करने का ठोस तरीका देना है
  • user README पढ़ने के बाद अगर project में रुचि ले, तो उसे स्वाभाविक रूप से अगले चरण तक पहुँचना चाहिए
  • असरदार getting started guide लिखने के tips

    • स्पष्ट step-by-step guide दें
      • "PostCSS इस्तेमाल करें" जैसे अस्पष्ट वाक्य की जगह साफ़ और ठोस steps दें
      • हर step में ज़रूरी commands और configuration का तरीका बताएं
    • वैकल्पिक रास्ते दें
      • user की स्थिति के अनुसार अलग approach बताएं
      • उदाहरण: अगर PostCSS install नहीं है, तो क्या करना है
    • अलग-अलग user types के लिए sections दें
      • बड़े libraries और छोटे libraries के users के लिए अलग guide दें
  • testing ज़रूरी है

    • अपनी लिखी guide को खुद follow करके टेस्ट करें कि वह सच में काम करती है या नहीं
      • जहाँ संभव हो, project की background knowledge भूलकर शुरू से फिर करके देखें
      • समस्या मिले तो तुरंत सुधारें और पूरा करें

प्रभावी open source promotion strategy

1. बार-बार promotion का महत्व

  • बहुत लोग ये गलती करते हैं
    1. social media पर सिर्फ एक बार post करते हैं
    2. कोई response नहीं आता
    3. वे उदास हो जाते हैं
    4. project छोड़ देते हैं
  • एक बार का बड़ा promotion असरदार नहीं होता → क्रमिक और बार-बार promotion ज़रूरी है
  • असरदार repeated promotion cycle
    1. new feature release, blog post, social media post जैसी content बनाएँ
    2. users से feedback लें
    3. feedback के आधार पर project सुधारें
    4. बदलावों पर नई content बनाएँ → फिर से शुरू करें
  • शुरुआत में users कम होना उल्टा फ़ायदेमंद हो सकता है → बिना ज़्यादा stress के सुधार संभव है
  • लगातार improvement और repeated promotion से पहचान बढ़ती है

2. प्रभावी social media promotion strategy

  • सिर्फ link share करके या बहुत छोटा explanation देकर न रुकें
  • इन 2 चीज़ों को ज़रूर शामिल करें
    • code example या image → लोग जल्दी समझते हैं
    • project का स्पष्ट explanation → नए users भी समझ सकें
  • promotion post template example

    • new feature announcement → स्पष्ट explanation → code example शामिल → social media पर share
    • Reddit के संबंधित subreddit में post करें (हर subreddit के rules देखें)
    • Hacker News पर post करें → शुरुआती traction मिल सकता है
    • Dev.to, Smashing Magazine, CSS-Tricks आदि में article लिखें → visibility बढ़ती है

3. PR के जरिए promotion strategy

  • दूसरे projects में अपने open source को adopt कराने के लिए PR submit करें
    • उदाहरण: PostCSS ने दूसरे projects में PR के जरिए promotion में सफलता पाई
    • "अगर मदद चाहिए, तो मैं इस tool को apply करके देख सकता हूँ।"
  • PR approve हो जाए तो README में use cases लिखें → भरोसा बढ़ता है
  • अगर लोकप्रिय projects आपके tool का इस्तेमाल करते हैं, तो यह लिखने से credibility और मज़बूत होती है

4. दोहराइए, लेकिन spam मत कीजिए

  • लगातार repeated promotion ज़रूरी है
  • लेकिन spam बिल्कुल नहीं
    • वही message बार-बार न दोहराएँ, बल्कि नई value दें
    • बदलाव और प्रगति दिखाई देनी चाहिए
  • हर user हर post नहीं पढ़ता → इसलिए समय-समय पर अलग रूपों में promotion दोहराना ज़रूरी है

repeated promotion क्यों ज़रूरी है

  • लोग tools को पूरी तरह तर्कसंगत तरीके से नहीं चुनते
  • repeated promotion से पहचान स्वाभाविक रूप से बनती है
  • लंबे समय तक पहचान बनानी पड़ती है, तभी सफलता की संभावना बढ़ती है

बोनस

1. जब project मशहूर हो जाए, तब समस्याओं को कैसे संभालें

  • project लोकप्रिय होने पर हल करने के लिए issues बहुत तेज़ी से बढ़ सकते हैं
  • अगर आप हर समस्या खुद हल करने की कोशिश करेंगे, तो बोझ बढ़ेगा और इससे उदासी व productivity में कमी आ सकती है
  • समाधान

    • हर समस्या खुद हल करने की कोशिश न करें → users को PR भेजने के लिए कहें
    • "अगर आप इस समस्या को हल करना चाहते हैं, तो क्या आप PR भेज सकते हैं?" जैसा अनुरोध करें
    • issues पर काम करने के लिए तय समय रखें (जैसे रोज़ 15 मिनट) और उसी सीमा में काम करें
    • कठिन समस्याओं को तुरंत हल करने की कोशिश न करें; "मैं समाधान पर विचार कर रहा हूँ" जैसा जवाब दें → users को सिर्फ यह जानना भी आश्वस्त करता है कि समस्या देखी जा चुकी है
    • documentation fixes भी users से कराए जा सकते हैं → "क्या आप यह हिस्सा ठीक कर सकते हैं?"

2. negative feedback से कैसे निपटें

  • negative feedback motivation कम कर सकता है
  • project के शुरुआती दौर में negative feedback उत्साह तोड़ सकता है, और project लोकप्रिय होने पर आत्मविश्वास कम कर सकता है
  • response strategy

    • भावनात्मक प्रतिक्रिया न दें
    • आलोचना पर सवाल पूछें → "आपको क्यों लगता है कि B, A से बेहतर है?"
    • कई बार आलोचना सिर्फ भावनात्मक प्रतिक्रिया होती है → user से बात करके trust बनाने की कोशिश करें
    • आलोचना सुधार का मौका भी दे सकती है

3. प्रतिस्पर्धी project आने पर क्या करें

  • अगर कोई competing project आ जाए, तो घबराने की ज़रूरत नहीं है
  • competing project आने से ये फ़ायदे हो सकते हैं
    • project maintain करने का बोझ कम हो सकता है
    • competition से बेहतर solution निकल सकता है → अंततः users को ही फ़ायदा होगा
  • open source का अंतिम उद्देश्य दुनिया बदलना है → monopoly या domination नहीं
  • competing project का आना → बेहतर tool का जन्म → win-win स्थिति

अंतिम सार

लोकप्रिय open source बनाना और visibility पाना कैसे संभव है

  1. open source बनाने की सबसे अच्छी वजह प्रसिद्धि या resume मज़बूत करना नहीं, बल्कि दुनिया बदलना है
  2. अच्छा idea लोकप्रिय project बनेगा, इसकी कोई गारंटी नहीं
  3. open source project की popularity का formula = पहचान + promotion + users को फ़ायदा + luck
  4. social media accounts सक्रिय रखें, search में मिलने लायक बनाएं, और English जैसी व्यापक भाषाओं में लिखें

असरदार documentation लिखने का तरीका

  1. README और documentation को ऐसे लिखें जैसे आप किसी दोस्त को समझा रहे हों—स्पष्ट और स्वाभाविक
  2. emphasis text, lists और व्यवस्थित structure के जरिए जटिल जानकारी को क्रमिक रूप से दें
  3. वास्तविक benchmarks और code examples जैसे ठोस प्रमाण दें
  4. जहाँ संभव हो, beginners और advanced users दोनों के लिए ठोस getting started guide दें

promotion strategy

  1. एक बार के बड़े promotion से बेहतर repeated promotion है → release → feedback → improvement → repeat
  2. नियमित रूप से post करें, लेकिन spam से बचें
  3. code examples और images वाले posts बनाएं
  4. दूसरे projects में PR submit करके promotion का असर बढ़ाएँ

जब project मशहूर हो जाए, तब के tips

  1. हर समस्या खुद हल करने की कोशिश न करें; users को PR submit करने के लिए प्रोत्साहित करें
  2. issue handling के लिए तय समय रखें (जैसे रोज़ 15 मिनट)
  3. negative feedback मिलने पर सवाल पूछकर बातचीत शुरू करें
  4. competing projects से न डरें → competition आपको ज़िम्मेदारी के बोझ से मुक्त भी कर सकता है

1 टिप्पणियां

 
roxie 2025-03-28

ऐसी जगहें ढूँढना भी महत्वपूर्ण लगता है जहाँ थोड़ा-थोड़ा अलग, लेकिन दूर से देखने पर दोहराव जैसा लगने वाला प्रचार स्वीकार्य हो। उदाहरण के लिए, Twitter।