लोकप्रिय open source प्रोजेक्ट बनाने के टिप्स
(skerritt.blog)"नेटवर्क प्रभाव: जितने ज़्यादा लोग इसे खोजेंगे, उतने ज़्यादा उपयोगकर्ता बढ़ेंगे, उतनी ज़्यादा भागीदारी होगी, फीचर्स बेहतर होंगे, और यह उतना ही अधिक प्रसिद्ध होता जाएगा"
लोकप्रिय बनने के लिए क्या करना चाहिए?
#1. अच्छी तरह डिज़ाइन किया गया README
- शुरुआत में संक्षेप में समझाएँ
→ यह क्या करता है?
→ क्या यह मेरी समस्या हल करता है?
→ क्या यह मेरी समस्या को प्रतिस्पर्धियों से बेहतर हल करता है?
→ इसे install कैसे करूँ?
→ मुझे कौन-कौन से बुनियादी commands जानने चाहिए?
→ मदद चाहिए तो कहाँ जाऊँ?
1.1 प्रोजेक्ट का सार बताने वाला header बनाना
→ logo: Canva जैसी जगहों पर GIF logo बनाना
→ slogan: एक पंक्ति में प्रोजेक्ट का वर्णन। इसे GitHub के Desc में लगाएँ
⇨ तुरंत ध्यान खींचने वाला हो
⇨ उपयोगकर्ता को इसकी ज़रूरत क्यों है
⇨ यह दूसरों से बेहतर क्यों है
⇨ समझने में आसान हो
⇨ उदाहरण) hugo : The world’s fastest framework for building websites
→ badge: छोटे image/link जिनसे प्रोजेक्ट समझाया जा सके
⇨ हाल की activity count, downloads, chat room में कितने लोग हैं, supported versions, license.. आदि
→ quick install: आसान और तेज़ installation command तुरंत दिखाई दे
⇨ जो लोग पहले से जानकर आए हैं वे तुरंत इसे आज़मा सकें
⇨ जैसे Docker/PIP से one-line install हो सकता है, ऐसी बात को शुरुआत में ही दिखाएँ
⇨ docker run -it --rm remnux/ciphey
→ quick links (ज़रूरी नहीं)
⇨ website, forum, docs, install guide, contribution guide, Twitter आदि
1.2 "What is This?" प्रोजेक्ट को संक्षेप में समझाना
→ छोटा परिचय + प्रोजेक्ट कैसे काम करता है यह दिखाने वाला GIF + वे ज़रूरी फीचर्स जिन्हें लोग देखना चाहेंगे
→ उदाहरण) Starship: दो columns में बाईं ओर मुख्य फीचर्स का परिचय, दाईं ओर काम करता हुआ GIF
→ सभी फीचर्स दिखाने की ज़रूरत नहीं। केवल वे चीज़ें सूचीबद्ध करें जिन्हें उपयोगकर्ता देखना चाहेंगे, और उन्हें आसान भाषा में समझाएँ
1.3 "X vs Y" प्रतिस्पर्धियों से तुलना
→ यह दिखाना चाहिए कि प्रतिस्पर्धियों के बजाय इस प्रोजेक्ट को क्यों चुनना चाहिए
→ फ़ायदे आसानी से दिखाई देने चाहिए
→ यह Lean Startup में "औसत उपयोगकर्ता" से पहले "early adopter" खोजने जैसा है
⇨ यदि आपके पास बेहतर फीचर्स हैं, तो ऐसे लोग जो नए टूल पर जाने से हिचकिचाते नहीं
→ केवल तब "औसत उपयोगकर्ता" को लक्ष्य बनाना सही है जब कोई प्रतिस्पर्धी ही न हो, या मौजूदा solutions आपकी तुलना में बहुत जटिल हों
→ सबसे आसान तरीका है मुख्य फीचर्स की comparison table बनाना
⇨ बातों की बजाय numbers में दिखाएँ
⇨ काम करने के तरीके को GIF से तुलना करके दिखाना भी अच्छा है
1.4 बेहतरीन documentation बनाना
→ सारी documentation को README में डालने की ज़रूरत नहीं। इससे update और search करना मुश्किल हो जाता है और README देखना भी कठिन बनता है
→ ऊपर installation method लिख चुके हैं, तो अतिरिक्त रूप से यह दिखाएँ
⇨ इसे चलाना कैसे है
⇨ documentation कहाँ मिल सकती है
⇨ support कैसे प्राप्त किया जा सकता है
→ इसे चलाने का तरीका GIF से दिखाना भी अच्छा है
1.5 contribution का तरीका बताना, contributors को धन्यवाद देना और उनका स्वागत करना
→ प्रोजेक्ट में योगदान कैसे करें
→ पुराने contributors को धन्यवाद दें
→ all-contributors जैसे bot का उपयोग करें
#2. वही बनाइए जो लोग चाहते हैं
→ अच्छा README लोगों का ध्यान खींचता है, और जो प्रोजेक्ट उनकी "समस्या हल" करता है वह लोगों को उसके बारे में बात करने पर मजबूर करता है
2.1 पहले समस्या, बाद में उत्पाद
→ किसी उत्पाद को बनाने के लिए कुछ न बनाएँ, बल्कि किसी समस्या को हल करें
→ "प्रगति केवल बड़े छलांगों से नहीं, बल्कि सैकड़ों छोटे कदमों से भी आती है"
2.2 समस्या के साथ जीना
→ यदि समस्या ही नहीं है, तो उसे प्रभावी ढंग से हल भी नहीं किया जा सकता
→ random ideas बनाने की तुलना में, अपनी ही ज़िंदगी में मौजूद समस्याओं को देखना कहीं आसान है
→ जब आपको पता चलता है कि समस्या है, तो आप दो बातें जान लेते हैं: सच में समस्या मौजूद है, और यह कि दूसरे लोगों के पास भी वही समस्या है।
2.3 community में समस्याएँ ढूँढना
→ community को ध्यान से देखें तो लोग अपने सामने आने वाली समस्याएँ खुद ही दिखा देते हैं
→ जितने ज़्यादा लोग होंगे, और जितना ज़्यादा आप सुनेंगे, उतने ज़्यादा ideas सीधे अपने दम पर सोचने से भी अधिक मिलेंगे
→ community की समस्या को हल करने वाला MVP(Minimum Viable Product) बनाकर देखें
→ उसे community के साथ साझा करें, असर मापें, बेहतर बनाना सीखें, फिर दोबारा बनाएँ या चीज़ें जोड़कर सुधार करें
#3. इसे लोगों तक पहुँचाइए
→ चाहे कितना भी अच्छा बनाया हो, अगर उसे सार्वजनिक नहीं किया तो कोई नहीं देखेगा
→ यदि आपने पहले community का उपयोग किया है, तो अच्छी बात है कि वे पहले से उसके बारे में जानेंगे और उसे इस्तेमाल करेंगे
→ GitHub Star का 0 से 1 होना मुश्किल है, लेकिन 10 से 100 जाना आसान है
3.1 community में साझा करें
→ Build, Measure, Learn loop
→ पहले असली release के समय यह ज़रूर सुनिश्चित करें कि community को पता चले। वे इसे अपने दोस्तों के साथ साझा करेंगे
3.2 News Aggregators
→ इच्छित Subreddit
→ HackerNews (संपादकीय टिप्पणी: GeekNews भी!)
→ Lobste.rs
3.3 Awesome List
→ topic से संबंधित list खोजें और PR भेजें
2 टिप्पणियां
एक दिन में 500 GitHub stars जुटाने की कहानी
https://black7375.tumblr.com/post/653140399088631808/
यह मैंने पहले लिखा था।
इसे मैंने प्रचार रणनीति पर फोकस करके लिखा था।
इसमें मैंने प्रचार पोस्ट डालने के तरीके और समय, डेवलपमेंट दिशा और डेडलाइन तय करने के तरीकों आदि के बारे में लिखा है.
यह बात भले ही स्वाभाविक लगे, लेकिन ओपन सोर्स का README वास्तव में बहुत महत्वपूर्ण होता है.
चाहे वह ऐसा प्रोजेक्ट हो जो ऐसी समस्या हल करता हो जिसे कोई और हल नहीं कर पा रहा/रही है या कर ही नहीं रहा/रही, या फिर ऐसा प्रोजेक्ट हो जिसमें प्रतिस्पर्धियों से आगे निकल जाने वाली शानदार सुविधाएँ हों, README में उसे कैसे लिखा गया है, इसके अनुसार परिणाम बदल सकते हैं.
उम्मीद है कि सिर्फ देश में ही नहीं बल्कि विदेशों में भी जाने जाने वाले ओपन सोर्स प्रोजेक्ट्स और बढ़ें.
इन दिनों सबसे प्रसिद्ध घरेलू डेवलपर्स द्वारा बनाए गए ओपन सोर्स प्रोजेक्ट्स के GitHub About और README भी ज़रूर देखें.
swc : "Make the web (development) faster." swc is a super-fast compiler written in rust; producing widely-supported javascript from modern standards and typescript.
fzf : fzf is a general-purpose command-line fuzzy finder.