ओपन सोर्स प्रोजेक्ट कसा तयार करायचा

या आठवड्यात सेंट पीटर्सबर्ग येथे आयटी महोत्सव आयोजित केला जाणार आहे टेकट्रेन. स्पीकर्सपैकी एक रिचर्ड स्टॉलमन असेल. एम्बॉक्स उत्सवात देखील सहभागी होतो आणि अर्थातच आम्ही विनामूल्य सॉफ्टवेअरच्या विषयाकडे दुर्लक्ष करू शकत नाही. म्हणूनच आमचा एक अहवाल मागवला आहे “विद्यार्थी हस्तकलेपासून ते ओपनसोर्स प्रकल्पांपर्यंत. Embox अनुभव". हे मुक्त स्रोत प्रकल्प म्हणून एम्बॉक्सच्या विकासाच्या इतिहासाला समर्पित केले जाईल. या लेखात मला मुख्य कल्पनांबद्दल बोलायचे आहे जे माझ्या मते, ओपनसोर्स प्रकल्पांच्या विकासावर परिणाम करतात. लेख, अहवालाप्रमाणे, वैयक्तिक अनुभवावर आधारित आहे.

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

खुल्या परवान्यांच्या समस्यांना आम्ही स्पर्श करणार नाही. हा खूप मोठा आणि गुंतागुंतीचा विषय आहे ज्यासाठी सखोल चौकशी आवश्यक आहे. या विषयावर बरेच चांगले लेख आणि साहित्य लिहिले गेले आहे. परंतु मी स्वतः कॉपीराइटच्या क्षेत्रातील तज्ञ नसल्यामुळे, मी एवढेच म्हणेन की परवान्याने प्रकल्पाची उद्दिष्टे पूर्ण केली पाहिजेत. उदाहरणार्थ, एम्बॉक्ससाठी GPL परवान्याऐवजी BSD ची निवड अपघाती नव्हती.

ओपन सोर्स प्रोजेक्टने बदल करण्याची आणि ओपन सोर्स प्रकल्पाच्या विकासावर प्रभाव टाकण्याची क्षमता प्रदान केली पाहिजे हे तथ्य सूचित करते की प्रकल्प वितरित केला जातो. केंद्रीकृत व्यवस्थापन असलेल्या प्रकल्पाच्या तुलनेत ते व्यवस्थापित करणे, अखंडता आणि कार्यप्रदर्शन राखणे अधिक कठीण आहे. एक वाजवी प्रश्न उद्भवतो: प्रकल्प अजिबात का उघडायचे? उत्तर व्यावसायिक व्यवहार्यतेच्या क्षेत्रामध्ये आहे; प्रकल्पांच्या विशिष्ट वर्गासाठी, या दृष्टिकोनाचे फायदे खर्चापेक्षा जास्त आहेत. म्हणजेच, हे सर्व प्रकल्पांसाठी योग्य नाही आणि एक मुक्त दृष्टीकोन सामान्यतः स्वीकार्य आहे. उदाहरणार्थ, खुल्या तत्त्वावर आधारित पॉवर प्लांट किंवा विमानासाठी नियंत्रण प्रणाली विकसित करण्याची कल्पना करणे कठीण आहे. नाही, अर्थातच, अशा प्रणालींमध्ये खुल्या प्रकल्पांवर आधारित मॉड्यूल समाविष्ट केले पाहिजेत, कारण यामुळे अनेक फायदे मिळतील. परंतु अंतिम उत्पादनासाठी कोणीतरी जबाबदार असणे आवश्यक आहे. जरी सिस्टीम पूर्णपणे ओपन प्रोजेक्ट्सच्या कोडवर आधारित असली तरीही, विकसकाने, सर्वकाही एका सिस्टममध्ये पॅकेज केले आहे आणि विशिष्ट बिल्ड आणि सेटिंग्ज बनवल्या आहेत, ते अनिवार्यपणे बंद करतो. कोड सार्वजनिकरित्या उपलब्ध असू शकतो.

ओपन सोर्स प्रकल्प तयार करणे किंवा त्यात योगदान देण्यापासून या प्रणालींसाठी बरेच फायदे आहेत. मी आधीच म्हटल्याप्रमाणे, एंड सिस्टम कोड सार्वजनिकरित्या उपलब्ध असू शकतो. का, कारण हे उघड आहे की या प्रणालीची चाचणी घेण्यासाठी कोणाकडेही तेच विमान असण्याची शक्यता नाही. हे खरे आहे, परंतु कोडचे काही विभाग तपासू इच्छिणारे कोणीतरी असू शकते किंवा, उदाहरणार्थ, कोणीतरी शोधून काढू शकते की वापरलेली लायब्ररी योग्यरित्या कॉन्फिगर केलेली नाही.

कंपनीने प्रणालीचा काही मूलभूत भाग वेगळ्या प्रकल्पात वाटप केल्यास आणखी मोठा फायदा दिसून येतो. उदाहरणार्थ, काही प्रकारच्या डेटा एक्सचेंज प्रोटोकॉलला समर्थन देण्यासाठी लायब्ररी. या प्रकरणात, जरी प्रोटोकॉल दिलेल्या विषयाच्या क्षेत्रासाठी विशिष्ट असला तरीही, आपण या क्षेत्रातील इतर कंपन्यांसह सिस्टमच्या या भागाची देखभाल करण्यासाठी खर्च सामायिक करू शकता. याव्यतिरिक्त, सार्वजनिक डोमेनमध्ये सिस्टमच्या या भागाचा अभ्यास करू शकणार्‍या तज्ञांना ते प्रभावीपणे वापरण्यासाठी खूप कमी वेळ लागतो. आणि शेवटी, तृतीय-पक्ष विकासक वापरत असलेल्या स्वतंत्र घटकामध्ये तुकडा विभक्त केल्याने आम्हाला हा भाग अधिक चांगला बनवता येतो, कारण आम्हाला प्रभावी API ऑफर करणे, दस्तऐवजीकरण तयार करणे आवश्यक आहे आणि मी चाचणी कव्हरेज सुधारण्याबद्दल देखील बोलत नाही.

कंपनी मुक्त-स्रोत प्रकल्प तयार न करता व्यावसायिक लाभ मिळवू शकते; कंपनीमध्ये वापरल्या जाणार्‍या तृतीय-पक्षाच्या प्रकल्पांमध्ये सहभागी होणे तिच्या तज्ञांसाठी पुरेसे आहे. शेवटी, सर्व फायदे राहतात: कर्मचार्‍यांना प्रकल्प अधिक चांगल्या प्रकारे माहित आहे, म्हणून ते ते अधिक प्रभावीपणे वापरतात, कंपनी प्रकल्पाच्या विकासाच्या दिशेवर प्रभाव टाकू शकते आणि रेडीमेड, डीबग केलेला कोड वापरल्याने कंपनीच्या खर्चात कपात होते.

ओपनसोर्स प्रकल्प तयार करण्याचे फायदे तिथेच संपत नाहीत. मार्केटिंग सारखा व्यवसायाचा महत्त्वाचा घटक घेऊ. त्याच्यासाठी, हा एक चांगला सँडबॉक्स आहे जो त्याला बाजाराच्या आवश्यकतांचे प्रभावीपणे मूल्यांकन करण्यास अनुमती देतो.

आणि अर्थातच, आपण हे विसरू नये की ओपनसोर्स प्रकल्प हा स्वतःला कोणत्याही स्पेशलायझेशनचा वाहक म्हणून घोषित करण्याचा एक प्रभावी मार्ग आहे. काही प्रकरणांमध्ये, बाजारात प्रवेश करण्याचा हा एकमेव मार्ग आहे. उदाहरणार्थ, एम्बॉक्सने आरटीओएस तयार करण्याचा प्रकल्प म्हणून सुरुवात केली. बरेच स्पर्धक आहेत हे समजावून सांगण्याची गरज नाही. समुदाय तयार केल्याशिवाय, आमच्याकडे प्रकल्प अंतिम वापरकर्त्यापर्यंत आणण्यासाठी, म्हणजेच तृतीय-पक्ष विकासकांसाठी प्रकल्प वापरणे सुरू करण्यासाठी पुरेशी संसाधने नसतात.

ओपनसोर्स प्रकल्पात समुदाय महत्त्वाचा आहे. हे तुम्हाला प्रकल्प व्यवस्थापन खर्च लक्षणीयरीत्या कमी करण्यास, प्रकल्पाचा विकास आणि समर्थन करण्यास अनुमती देते. आम्ही असे म्हणू शकतो की समुदायाशिवाय कोणताही मुक्त स्त्रोत प्रकल्प नाही.

ओपन सोर्स प्रोजेक्ट कम्युनिटी कशी तयार करावी आणि व्यवस्थापित करावी याबद्दल बरेच साहित्य लिहिले गेले आहे. आधीच ज्ञात तथ्ये पुन्हा सांगू नये म्हणून, मी एम्बॉक्सच्या अनुभवावर लक्ष केंद्रित करण्याचा प्रयत्न करेन. उदाहरणार्थ, समुदाय तयार करण्याची प्रक्रिया ही एक अतिशय मनोरंजक समस्या आहे. म्हणजेच, अस्तित्वात असलेल्या समुदायाचे व्यवस्थापन कसे करावे हे अनेकजण सांगतात, परंतु हे दिलेले लक्षात घेऊन त्याच्या निर्मितीचे क्षण कधी कधी दुर्लक्षित केले जातात.

ओपनसोर्स प्रोजेक्ट समुदाय तयार करताना मुख्य नियम असा आहे की कोणतेही नियम नाहीत. मला असे म्हणायचे आहे की कोणतेही सार्वत्रिक नियम नाहीत, जसे की चांदीची बुलेट नाही, जर केवळ प्रकल्प खूप भिन्न आहेत. js लॉगिंग लायब्ररी आणि काही अत्यंत विशिष्ट ड्रायव्हरसाठी समुदाय तयार करताना तुम्ही समान नियम वापरू शकता हे संभव नाही. शिवाय, प्रकल्पाच्या विकासाच्या वेगवेगळ्या टप्प्यांवर (आणि म्हणून समुदाय), नियम बदलतात.

Embox एक विद्यार्थी प्रकल्प म्हणून सुरू झाला कारण त्याला सिस्टम प्रोग्रामिंग विभागातील विद्यार्थ्यांपर्यंत प्रवेश होता. खरे तर आम्ही दुसऱ्याच समाजात प्रवेश करत होतो. आम्ही या समुदायातील सहभागींना, विद्यार्थ्यांना, त्यांच्या विशेषतेमध्ये, प्रणाली प्रोग्रामिंग, कोर्सवर्क आणि डिप्लोमाच्या क्षेत्रातील वैज्ञानिक कार्यामध्ये चांगल्या औद्योगिक व्यवहारात रस घेऊ शकतो. म्हणजेच, आम्ही समुदाय आयोजित करण्याच्या मूलभूत नियमांपैकी एकाचे पालन केले: समुदायाच्या सदस्यांना काहीतरी मिळणे आवश्यक आहे आणि ही किंमत सहभागीच्या योगदानाशी संबंधित असणे आवश्यक आहे.

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

Embox चे पहिले वापरकर्ते सैद्धांतिक सायबरनेटिक्स विभाग होते. त्यांनी Lego Mindstorm साठी पर्यायी फर्मवेअर तयार करण्याचे सुचवले. आणि जरी हे अजूनही स्थानिक वापरकर्ते होते (आम्ही त्यांच्याशी वैयक्तिकरित्या भेटू शकतो आणि त्यांना काय हवे आहे यावर चर्चा करू शकतो). पण तरीही तो खूप चांगला अनुभव होता. उदाहरणार्थ, आम्ही डेमो विकसित केले आहेत जे इतरांना दाखवले जाऊ शकतात, कारण रोबोट मजेदार आहेत आणि लक्ष वेधून घेतात. परिणामी, आम्हाला खरोखर तृतीय-पक्ष वापरकर्ते मिळाले ज्यांनी एम्बॉक्स म्हणजे काय आणि ते कसे वापरावे हे विचारण्यास सुरुवात केली.

या टप्प्यावर, आम्हाला दस्तऐवजीकरण, वापरकर्त्यांशी संवाद साधण्याच्या माध्यमांबद्दल विचार करावा लागला. नाही, नक्कीच, आम्ही या महत्त्वाच्या गोष्टींबद्दल आधी विचार केला, परंतु ते अकाली होते आणि त्याचा सकारात्मक परिणाम झाला नाही. परिणाम ऐवजी नकारात्मक होता. मी तुम्हाला एक दोन उदाहरणे देतो. आम्ही googlecode वापरला, ज्याचे विकीने बहुभाषिकतेला समर्थन दिले. आम्ही अनेक भाषांमध्ये पृष्ठे तयार केली आहेत, केवळ इंग्रजी आणि रशियनच नाही, ज्यामध्ये आम्ही क्वचितच संवाद साधू शकलो, परंतु जर्मन आणि स्पॅनिश देखील. परिणामी, या भाषांमध्ये विचारले असता ते खूप हास्यास्पद दिसते, परंतु आम्ही अजिबात उत्तर देऊ शकत नाही. किंवा त्यांनी दस्तऐवज लिहिणे आणि टिप्पणी करणे याविषयी नियम सादर केले, परंतु API बर्‍याचदा आणि लक्षणीय बदलल्यामुळे, असे दिसून आले की आमचे दस्तऐवजीकरण जुने आहे आणि ते मदत करण्यापेक्षा अधिक दिशाभूल करणारे आहे.

परिणामी, आमचे सर्व प्रयत्न, अगदी चुकीच्या प्रयत्नांमुळे, बाह्य वापरकर्ते दिसू लागले. आणि एक व्यावसायिक ग्राहक देखील दिसला ज्याला त्याच्यासाठी स्वतःचे आरटीओएस विकसित करायचे होते. आणि आम्ही ते विकसित केले कारण आमच्याकडे अनुभव आणि काही आधार आहे. येथे आपल्याला चांगले आणि वाईट दोन्ही क्षणांबद्दल बोलण्याची आवश्यकता आहे. मी वाईटांपासून सुरुवात करेन. अनेक विकासक या प्रकल्पात व्यावसायिक आधारावर गुंतलेले असल्याने, समुदाय आधीच खूप अस्थिर आणि विभाजित होता, ज्याचा प्रकल्पाच्या विकासावर परिणाम होऊ शकला नाही. एक अतिरिक्त घटक असा होता की प्रकल्पाची दिशा एका व्यावसायिक ग्राहकाने सेट केली होती आणि त्याचे ध्येय प्रकल्पाचा पुढील विकास नव्हता. किमान हे मुख्य ध्येय नव्हते.

दुसरीकडे, अनेक सकारात्मक पैलू होते. आम्हाला खरोखर तृतीय-पक्ष वापरकर्ते मिळाले. हे केवळ ग्राहकच नव्हते, तर ज्यांच्यासाठी ही प्रणाली तयार केली गेली होती. प्रकल्पात सहभागी होण्याची प्रेरणा वाढली आहे. शेवटी, जर तुम्ही एखाद्या मनोरंजक व्यवसायातून पैसे कमवू शकत असाल तर ते नेहमीच छान असते. आणि सर्वात महत्त्वाचे म्हणजे, आम्ही ग्राहकांकडून एक इच्छा ऐकली, जी त्या वेळी आम्हाला वेडी वाटली, परंतु आता सिस्टममध्ये आधीच विकसित कोड वापरणे ही एम्बॉक्सची मुख्य कल्पना आहे. आता एम्बॉक्सची मुख्य कल्पना म्हणजे लिनक्सशिवाय लिनक्स सॉफ्टवेअर वापरणे. म्हणजेच, प्रकल्पाच्या पुढील विकासात योगदान देणारी मुख्य सकारात्मक बाब म्हणजे प्रकल्प तृतीय-पक्ष वापरकर्त्यांद्वारे वापरला जातो आणि त्यांच्या काही समस्या सोडवल्या पाहिजेत ही जाणीव होती.

त्या वेळी, एम्बॉक्स आधीच विद्यार्थ्यांच्या प्रकल्पाच्या पलीकडे गेला होता. विद्यार्थी मॉडेलनुसार प्रकल्पाच्या विकासातील मुख्य मर्यादित घटक म्हणजे सहभागींची प्रेरणा. विद्यार्थी शिकत असतानाच भाग घेतात आणि जेव्हा ते पदवीधर होतात तेव्हा वेगळी प्रेरणा मिळायला हवी. जर प्रेरणा दिसत नसेल, तर विद्यार्थी प्रकल्पात भाग घेणे थांबवतो. जर आपण हे लक्षात घेतले की विद्यार्थ्यांना प्रथम प्रशिक्षित करणे आवश्यक आहे, तर असे दिसून येते की ते पदवीधर होईपर्यंत चांगले विशेषज्ञ बनतात, परंतु अननुभवीपणामुळे प्रकल्पातील त्यांचे योगदान फार मोठे नाही.

सर्वसाधारणपणे, आम्ही सहजतेने मुख्य मुद्द्याकडे जातो जो आम्हाला एक ओपनसोर्स प्रकल्प तयार करण्याबद्दल बोलण्याची परवानगी देतो - एक उत्पादन तयार करणे जे त्याच्या वापरकर्त्यांच्या समस्या सोडवेल. मी वर स्पष्ट केल्याप्रमाणे, ओपनसोर्स प्रकल्पाची मुख्य मालमत्ता म्हणजे त्याचा समुदाय. शिवाय, समुदाय सदस्य प्रामुख्याने वापरकर्ते आहेत. पण वापरण्यासाठी काहीच नसताना ते येतात कुठून? त्यामुळे असे दिसून आले की, नॉन-ओपनसोर्स प्रकल्पाप्रमाणेच, तुम्हाला MVP (किमान व्यवहार्य उत्पादन) तयार करण्यावर लक्ष केंद्रित करणे आवश्यक आहे आणि जर ते वापरकर्त्यांना आवडले, तर प्रकल्पाच्या आसपास एक समुदाय दिसेल. जर तुम्ही फक्त कम्युनिटी PR द्वारे समुदाय तयार करण्यात गुंतले असाल, जगातील सर्व भाषांमध्ये विकी लिहित असाल किंवा gitub वर git वर्कफ्लो दुरुस्त करत असाल, तर प्रकल्पाच्या सुरुवातीच्या टप्प्यात याला काही फरक पडण्याची शक्यता नाही. अर्थात, योग्य टप्प्यावर या केवळ महत्त्वाच्याच नाहीत, तर आवश्यक गोष्टीही आहेत.

शेवटी मी सूचित करू इच्छितो भाष्य, माझ्या मते, ओपनसोर्स प्रकल्पाकडून वापरकर्त्याच्या अपेक्षा प्रतिबिंबित करणे:

मी या OS वर स्विच करण्याचा गंभीरपणे विचार करत आहे (किमान प्रयत्न करा. ते सक्रियपणे त्याचा पाठपुरावा करत आहेत आणि छान गोष्टी करत आहेत).

P.S. चालू टेकट्रेन आमच्याकडे तब्बल तीन अहवाल असतील. एक ओपन सोर्स बद्दल आणि दोन एम्बेडेड बद्दल (आणि एक व्यावहारिक आहे). स्टँडवर आम्ही प्रोग्रामिंग मायक्रोकंट्रोलर वापरून मास्टर क्लास आयोजित करू एम्बॉक्स. नेहमीप्रमाणे, आम्ही हार्डवेअर आणू आणि तुम्हाला ते प्रोग्राम करू द्या. शोध आणि इतर उपक्रम देखील असतील. उत्सवात या आणि आमचा स्टँड, मजा येईल.

स्त्रोत: www.habr.com