एक विशिष्ट ओपन सोर्स समाधान के विकास का परिचय

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

कट के तहत आपको प्रस्तुति का एक पाठ संस्करण मिलेगा, जो ओपन सोर्स के व्यक्तिपरक धारणा से भरा होगा, दोनों सकारात्मक और नकारात्मक।




तो, मेरा नाम एंटोन विनोग्रादोव है, और पिछले 4 वर्षों से मैं ओपन सोर्स अपाचे इग्नाइट प्रोजेक्ट विकसित कर रहा हूं। उनके उदाहरण का उपयोग करते हुए, मैं बात करना चाहता हूं कि ओपन सोर्स कैसे किया जाता है, आप समुदाय में भाग लेने से क्या व्यक्तिगत लाभ प्राप्त कर सकते हैं, और आखिरकार, मैं आपको भाग लेने के लिए प्रेरित करना चाहता हूं।




मैं Apache इग्नाइट के उदाहरण का उपयोग करके ओपन सोर्स के बारे में बात करूंगा - Apache Software Foundation की कई परियोजनाओं में से एक। एएसएफ लगभग 20 वर्षों के इतिहास के साथ सबसे बड़े ओपन सोर्स समुदायों में से एक है। यह अपनी सफलताओं का श्रेय देता है, सबसे पहले, प्रेरणा की प्रक्रियाओं और सिद्धांतों के लिए, 1999 तक वापस निर्धारित किया गया था, लेकिन आज भी प्रासंगिक है। समुदाय के इस "दार्शनिक" पक्ष को दिमित्री पावलोव द्वारा अपने लेख में विस्तार से वर्णित किया गया था, लेकिन हम अपाचे इग्नाइट के उदाहरण का उपयोग करते हुए ओपन सोर्स विकास के "लागू" पक्ष पर विचार करेंगे।

मान लीजिए आप सामुदायिक विकास में योगदान करने का निर्णय लेते हैं। यह कैसे करना है?


सामान्य तौर पर, कोई यह नहीं कह सकता कि ओपन सोर्स कोड के बारे में है। कई अलग-अलग गतिविधियां एक महत्वपूर्ण योगदान दे सकती हैं, और उनमें से केवल कुछ सीधे कोड से संबंधित हैं।

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

ओपन सोर्स में सबसे महत्वपूर्ण योगदान उत्पाद की समस्याओं और इसकी कमियों के बारे में समुदाय को सूचित करना है। लेकिन यहां यह समझना महत्वपूर्ण है कि ओपन सोर्स एक कस्टम डेवलपमेंट नहीं है और समुदाय आपको कुछ भी नहीं देना चाहता है। सफलता का 90% आप पर निर्भर है। यदि आप एक समस्या पाते हैं, तो ओपन सोर्स में आपका योगदान इसका विस्तृत विश्लेषण होगा और समाधान की खोज करेगा। यह उम्मीद की जाती है कि आप समस्या की चर्चा में सक्रिय रूप से भाग लेंगे। यदि आप इसे रिपोर्ट करते हैं और छोड़ देते हैं, तो समस्या हल नहीं होगी।

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

प्रत्येक समस्या पर चर्चा की गई है, लेकिन उपयोगकर्ता सूची में हल नहीं की गई है, जहां यह काम किया जा रहा है। यहां, डेवलपर्स चर्चा करते हैं कि किसी सुविधा को ठीक से कैसे लागू किया जाए या बग को कैसे बंद किया जाए।


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

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

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

हम सीधे विकास के लिए आगे बढ़ते हैं।


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

यदि आप एक अच्छे डेवलपर हैं और ओपन सोर्स को देखने के लिए तैयार हैं - आओ और काम किए गए कार्यों में से एक चुनें, इसे लेखक के साथ समन्वयित करें और देखा जाना शुरू करें।

ओपन सोर्स में, सभी संचार सार्वजनिक हैं। चर्चा या तो डिसलिस्ट पर है या इश्यू ट्रैकर में। बिना चर्चा के कुछ को लागू करने से बचने की कोशिश करना महत्वपूर्ण है, क्योंकि कुछ गलत करने की संभावना अधिक है। विकास शुरू करने से पहले सभी प्रमुख बिंदुओं को स्पष्ट करना अच्छा है, ताकि बहुत अधिक काम न किया जा सके।

अब महत्वपूर्ण के बारे में।

ओपन सोर्स डेवलपमेंट एक अच्छा और मुफ्त स्कूल है। कूल डेवलपर्स, अपने क्षेत्र के पेशेवरों, कार्यों को विघटित करते हैं, आप उन्हें लागू करते हैं, किसी भी कठिनाइयों के साथ मदद करते हैं - और अंततः एक प्रतिबद्धता दिखाई देती है जो आपको एक उत्कृष्ट डेवलपर के रूप में दर्शाती है। जैसा कि मैंने कहा, यह गुगली हो सकता है, यह आपके पोर्टफोलियो का हिस्सा है।

यदि आप मुफ्त में कुछ बेचना नहीं चाहते हैं, तो विचार करें कि यह योगदान, मोटे तौर पर बोल रहा है, आपका क्रेडिट इतिहास है। यह दर्शाता है कि आप सब कुछ सही कर रहे हैं, आप कोड लिख सकते हैं और कार्यों पर चर्चा कर सकते हैं, और आपके साथ काम करना आसान है।

ओपन सोर्स डेवलपमेंट में एक खतरनाक क्षण यह है कि बिल्कुल कोई भी इसमें आ सकता है। मुझे लगता है कि प्रत्येक ओपन सोर्स प्रोजेक्ट में एक ऐसा व्यक्ति होता है जो सालों तक सभी को विचलित करता है, और फिर बिना कोई योगदान दिए निकल जाता है। और अगर वह छोड़ देता है तो अच्छा है।

ऐसा नहीं है कि व्यक्ति ओपन सोर्स समुदाय के लिए एक महत्वपूर्ण योगदान है!

इसलिए, आपने ओपन सोर्स में कुछ दर्ज करने का फैसला किया है। यह संभावना है कि पहली बार जब आप सब कुछ गलत करते हैं। समय के साथ, आप अनुभव प्राप्त करेंगे जो आपको सब कुछ सही करने में मदद करेगा - लेकिन पहली बार नहीं।

इस मामले में, समीक्षा आपकी मदद करेगी।


अधिकांश परियोजनाओं में (अपाचे में आग लगना सुनिश्चित के लिए), समीक्षा प्रतिबद्ध से पहले होती है, जो आपको मास्टर- या विकास-ब्रंच को साफ रखने की अनुमति देती है। और हमारे पास कई मूलभूत आवश्यकताएं हैं जो समीक्षा के लिए कोड प्रस्तुत करने से पहले पूरी होनी चाहिए।

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

प्रत्येक सुविधा को एक प्रतिगमन के माध्यम से जाना चाहिए।
यदि परियोजना बड़ी है, तो आप कभी भी यह अनुमान नहीं लगाएंगे कि आपकी थोड़ी सी पूर्णता सभी कार्यक्षमता को कैसे प्रभावित करेगी। वर्तमान में, हमारे पास लगभग 50 हजार परीक्षण हैं, प्रत्येक सुविधा एक या अधिक द्वारा कवर की गई है। गिरे हुए परीक्षणों के बारे में, प्रतिगमन यह निर्धारित करने में मदद करेगा कि आपने कुछ तोड़ा है। आपके लिए, यह बहुत अच्छा तरीका है कि आप बहुत अधिक न सोचें और जल्दी से सब कुछ समझ लें - क्या कोई टूटना है या नहीं। अगर हम परीक्षण की लागतों के बारे में बात करते हैं, तो हमारे पास ~ सौ मशीनों का एक समूह है जो दो घंटों में एक ब्रंच का प्रतिगमन चलाते हैं।

भौतिक क्षेत्रों में परिवर्तन।
यदि आप "कोर" में कुछ बदलते हैं - तो आपको बेंचमार्किंग से गुजरना होगा। कोई फर्क नहीं पड़ता कि सभी समस्याओं को कितना कठिन और हल करना है, अगर यह थ्रूपुट / विलंबता जोड़ी को खराब करता है, तो इसे विलय नहीं किया जा सकता है। हमारे उत्पाद में प्रदर्शन में गिरावट अस्वीकार्य है।

एपीआई।
दो बिंदु हैं। नए एपीआई को उन लोगों के संकलन को नहीं तोड़ना चाहिए जिन्होंने उत्पाद के पुराने संस्करण का उपयोग किया था। और तरीकों को प्रकट नहीं होना चाहिए जो कुछ महीनों में हटा दिया जाएगा। एपीआई करना - इसे तुरंत करें।

समीक्षक का इनपुट सबसे कठिन ओपन सोर्स योगदान के लिए सबसे महत्वपूर्ण है। समीक्षक वह व्यक्ति है जो आपकी मदद करने के लिए तैयार है, कुछ मामलों में वह 90% तक काम करता है। समीक्षक धक्का देता है, समझाता है, यदि आवश्यक हो तो लगभग आपके लिए कोड लिखता है। समस्या यह है कि जब कोई विशेषता मास्टर में आती है, तो यह योगदानकर्ता द्वारा सूचीबद्ध होती है, न कि समीक्षक द्वारा। समीक्षक के कृतज्ञतापूर्ण कार्य की सराहना करें।

यदि आप ओपन सोर्स समुदाय में काम करते हैं, तो समीक्षक को सहज बनाने का प्रयास करें। मूल नियम हैं कि फिक्स को यथासंभव कम से कम किया जाए, लेकिन जितना संभव हो उतना स्पष्ट। यदि आप समीक्षा से पहले देखते हैं कि आप फिक्स की मात्रा कम कर सकते हैं और इसकी समझ बढ़ा सकते हैं, तो यह करें।

अपाचे इग्नाइट का वर्तमान संस्करण 2.6 है। लगभग हर 3 महीने में दर्द होता है।


रिलीज़ 2.7 Sbertekh निकोलाई Izhikov के एक कर्मचारी द्वारा तैयार किया जा रहा है, लगभग एक साल के लिए अब परियोजना में एक कमिट के रूप में। यह परियोजना के लिए एक महत्वपूर्ण घटना है, क्योंकि इसके इतिहास में पहली बार, रिलीज को ग्रिडेन के एक कर्मचारी द्वारा नहीं किया गया है, जो कंपनी ने अपाचे इग्नाइट बनाया और इसे एएसएफ में स्थानांतरित कर दिया। यह बहुत अच्छा है, क्योंकि हम आदर्श ओपन सोर्स की ओर बढ़ रहे हैं, जब उत्पाद एक विशिष्ट वाणिज्यिक कंपनी से अछूता है और स्वतंत्र रूप से मौजूद है। हमें उम्मीद है कि अनुभव सफल होगा, और अगली रिलीज़ अन्य कंपनियों के कर्मचारियों द्वारा पहले से ही आयोजित की जाएगी, जिनमें से हमारे पास आयुक्त हैं - ट्रेंड माइक्रो, व्हाट्सएप, नेक्साइन, औरेया, पिवटल, याहू, आदि।


समाधान के लोकप्रियकरण - जैसा कि डेविटल के मामले में - न केवल परियोजना के लिए, बल्कि स्वयं के लिए भी एक योगदान है। इस तरह की बातें गुगली होती हैं और काम पर रखने के फैसले को प्रभावित करती हैं। इसके अलावा, यह आपके लिए कुछ समय के लिए कोड को स्थगित करने और कुछ दिलचस्प करने का एक तरीका है, लेकिन कोई कम उपयोगी नहीं है।

हम मुख्य प्रश्न की ओर मुड़ते हैं: यह ओपन सोर्स परियोजनाओं में भाग लेने के लायक क्यों है?


मैं दोहराना बंद नहीं करूंगा: ओपन सोर्स में भागीदारी आपकी तीव्र वृद्धि है। मेरे अवलोकन के अनुसार, लागू विकास की तुलना में, लगभग तीन साल, अगर यह अधिक नहीं है। यह एक साक्षात्कार में आपके प्रतिद्वंद्वी को वाक्यांश के साथ झटका देने का मौका है "मैंने इस चीज को देखा, मुझे पता है कि यह कैसे काम करता है, लेकिन आप गलत हैं!" - मैंने ऐसा दो बार किया, अनुभव अविस्मरणीय है।

किसी भी अच्छे प्रोग्रामर को ट्रेंड पर नजर रखनी चाहिए। ओपन सोर्स सॉफ्टवेयर डेवलपमेंट में हमारे समय का सबसे हॉट, सबसे आशाजनक ट्रेंड है। इस प्रवृत्ति में भागीदारी आपके सहकर्मियों से सम्मान की गारंटी देती है (अभी) और कुछ स्थिरता, वित्तीय गारंटी (भविष्य में)।


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

साक्ष्य के रूप में, हमारी टीम, जो कि Sberbank Technologies में Open Source काट रही है, में बेहद दिलचस्प रिक्तियाँ ( MSK और SPB ) हैं और Apache इग्नाइट केवल एकमात्र उत्पाद नहीं है जिसे हम अंतिम रूप दे रहे हैं।



मुझे आशा है कि सभी को दिलचस्पी थी, और कई लोग ओपन सोर्स आंदोलन में भाग लेने के बारे में सोचेंगे, और जो लोग पहले से ही इसके बारे में सोच चुके हैं, वे ठोस कार्यों पर आगे बढ़ेंगे।

Ps उन लोगों के लिए जो गर्म और ट्यूब ध्वनि पसंद करते हैं - "Uncategorized" का एक ऑडियो संस्करण उपलब्ध है।