ओपन सोर्स प्रोजेक्ट के किस चरण में आपको समुदाय से योगदान आमंत्रित करना चाहिए? [बन्द है]

Question

मैं एक नए खुले स्रोत उत्पाद में योगदान प्राप्त करने के बारे में सोच रहा हूं जो मेरी टीम विकसित कर रही है। हमारे लिए व्यापक समुदाय से उतना ही समर्थन पाने के लिए प्रोत्साहन है, जितना हम सक्षम हैं, लेकिन मैं यह भी देख सकता हूं कि यह सुनिश्चित करने में बहुत समय लगता है कि हमारे कार्यालय के बाहर स्थित 3 पार्टियां कोड गुणवत्ता जैसी चीजों के बारे में ट्रैक पर हैं। इसके अलावा परियोजना की शुरुआत में हमें कोर टीम के भीतर सिस्टम, स्पाइक्स इत्यादि के डिजाइन के बारे में बहुत सारी अनौपचारिक चर्चाएं होने की संभावना है और सामुदायिक भागीदारी की अनुमति देने के लिए इन्हें ऑनलाइन लेने में समय लगेगा और मैं कल्पना कर सकता हूं। चर्चा कम प्रभावी।

इसके लिए एक अधिक मानवीय पक्ष है जिस पर शायद विचार करने की आवश्यकता है: डिजाइन प्रक्रिया में सामुदायिक भागीदारी की अनुमति देने से इसके लाभ परियोजना के कथित स्वामित्व के संबंध में हो सकते हैं, और हमेशा एक मौका है कि प्रारंभिक भागीदारी उन समस्याओं पर उठा सकती है जो कोर टीम का ध्यान नहीं गया।

तो सवाल: एक ओपन सोर्स प्रोजेक्ट के किस चरण में आपको समुदाय से योगदान आमंत्रित करना चाहिए?

Comments

अभी विकास खोलें, लेकिन उपयोगकर्ताओं के स्थिर होने तक बीटा जारी करें। मैं इसके बारे में यहाँ बात करता हूँ stackoverflow.com/questions/3066648/… बड़ी लंबाई में।

— इवान प्लाइस

Answer 1

बहुत शुरुआत में ही सही! आप चाहते हैं कि समुदाय को यह महसूस हो कि आपकी परियोजना में उनकी वास्तविक हिस्सेदारी है, अन्यथा उन्हें ऐसा लगेगा कि उन्हें मुफ्त श्रम के रूप में इस्तेमाल किया जा रहा है।

सभी संचार सार्वजनिक मेलिंग सूची या फ़ोरम पर होने चाहिए, फिर से यह समुदाय के विचार को बढ़ाता है।

आप मेलिंग सूची में अपने प्रारंभिक पदों में एक स्पष्ट दृष्टि बिछाकर 'डिजाइन बाय कमेटी' समस्या को कम कर सकते हैं, जैसे

"इसलिए हम अपने पेट स्टोर (जेआईआरएआर -4 के अनुसार) का प्रतिनिधित्व करने के लिए एक डोमेन मॉडल देख रहे हैं। क्या कोई भी इस मॉडल के साथ कोई प्रमुख मुद्दा देखता है?"

वास्तविक भौतिक योगदान को स्वीकार करने के संदर्भ में, आपको पैच स्वीकार करने और उन पर सार्वजनिक कोड समीक्षा करने से शुरू करना चाहिए। इस तरह से योगदानकर्ता पहले से ही सार्वजनिक रूप से देख सकते हैं कि उन्हें किस तरह के कोडिंग मानकों का पालन करना है। सुनिश्चित करें कि आपके कमिट्स एक प्रतिबद्ध मेलिंग सूची में भी उपलब्ध हैं - आपको समान मानकों पर आयोजित होने की आवश्यकता है!

यह विकी या इस तरह के कुछ दस्तावेज़ों पर परियोजना मानकों का भी भुगतान करता है।

सफल ओपन सोर्स प्रोजेक्ट को चलाने के तरीके के बारे में अधिक जानकारी के लिए http://www.producingoss.org पढ़ें ।

Comments

@karianna धन्यवाद, लिंक को एक रीड देगा! लेकिन अगर पहले से ही 123 JIRA टिकट हैं और आप जानते हैं कि आप एक REST इंटरफ़ेस चाहते हैं, तो आप पहले से ही डिज़ाइन पथ के लिए एक उचित तरीका हैं, क्या आप नहीं हैं?

— आर्मंड

@karianna LOL, अच्छा संपादन ;-) सुनिश्चित नहीं हैं कि यह मेरे डिजाइन प्रश्न को संबोधित करता है। यह किताब सोने की है; आप पूरी बात पढ़ा है, और आप इसे पर विचार करेंगे इस विषय पर संदर्भ?

— आर्मंड

@ एलिसन - हाँ, यह विहित पाठ माना जाता है, लेकिन यह हमेशा अच्छी तरह से विज्ञापित नहीं है मुझे लगता है? यह इस क्षेत्र में सम्मेलनों में दी गई वार्ता का आधार है। यह संभवतः एक छोटे से अद्यतन के साथ कर सकता है - मैं अगले साल कार्ल के बारे में बोलूंगा :)।

— मार्टिनेज वर्बर्ग 12

Answer 2

ब्रायन फिट्ज़पैट्रिक और बेन कोलिंस-सूसमैन ऑफ सबवर्सन द्वारा गूगल के आईओ टॉक मिथक ऑफ जीनियस प्रोग्रामर में इसकी लंबाई पर चर्चा की गई । संक्षेप में उन्होंने निष्कर्ष निकाला कि यह इतनी जल्दी नहीं होना चाहिए कि वहाँ अभी तक कुछ भी नहीं है (यानी। "मेरे भयानक काम को देखो! वास्तव में यहाँ बहुत कुछ नहीं है लेकिन बहुत सारी भयानक चीजों की योजना है!") या बहुत देर हो चुकी है इसलिए सभी निर्णय पहले से ही किए जा रहे हैं (एक एकल परियोजना पर एक शब्द प्राप्त करना कठिन है।)

Answer 3

मैं Martijn Verburg से सहमत हूं । आपको शुरू से ही योगदान का आग्रह करना शुरू कर देना चाहिए। मैंने इसके बारे में थोड़ा पहले लिखा था ।

उस पोस्ट का सारांश यह है कि सॉफ्टवेयर रॉस करता है। यदि आप इसे ताजा रखना चाहते हैं, तो आपको रखरखाव करना होगा। और एक परियोजना जितनी अधिक लोकप्रिय हो जाती है, उतने ही अधिक कीड़े मिलने वाले हैं, उतनी ही अधिक सुविधाएँ जुड़ने जा रही हैं, और जितना अधिक यह रखरखाव कार्य आपको नीचे लाने वाला है।

वास्तव में, यह एक बहुत ही आम समस्या है। मोटी द्वारा एक महान बात की जाती है जिसे ओपन सोर्स कहा जाता है और मैं इसे इतना दोषी क्यों महसूस करता हूं? इस बातचीत में (जो मैं आपको देखने की अत्यधिक सलाह देता हूं) वह अपने ओएसएस परियोजनाओं में से एक की कहानी बताता है, और समय के साथ, उसने खुद को अपना अधिकांश खाली समय टिकट ट्राइएज और प्रबंधन कार्यों को करने में पाया। और वह इस बारे में बात करता है कि यह कितना हानिकारक था। ऐसी कौन सी चीज है जिससे मैं पूरी तरह से सहानुभूति रख सकता हूं।

निस्संदेह इसका समाधान यह है कि लोगों को जल्दी और अक्सर परियोजना से जोड़ा जाए। आपका समय सीमित है, और मूल्यवान है। इसे अपने योगदानकर्ता आधार को बढ़ाने में निवेश करें, और आपकी बाकी समस्याएं स्वयं का ध्यान रखना शुरू कर दें।

जैसा कि मैं अपनी पोस्ट के अंत में कहता हूं: "आपकी परियोजना के लिए क्या अधिक महत्वपूर्ण है: विशेषताएं या भविष्य? एक को चुनें, और अपने प्रयासों को तदनुसार प्राथमिकता दें।"