Tamasha la IT litafanyika St. Petersburg wiki hii . Mmoja wa wazungumzaji atakuwa Richard Stallman. pia inashiriki katika tamasha, na bila shaka hatukuweza kupuuza mada ya programu ya bure. Ndio maana moja ya ripoti zetu inaitwa . Itawekwa kwa ajili ya historia ya ukuzaji wa Embox kama mradi wa chanzo huria. Katika makala hii nataka kuzungumza juu ya mawazo makuu ambayo, kwa maoni yangu, yanaathiri maendeleo ya miradi ya opensource. Nakala, kama ripoti, inategemea uzoefu wa kibinafsi.
Wacha tuanze na kitu rahisi, na ufafanuzi wa neno opensource. Ni wazi, mradi wa chanzo huria ni mradi ambao una moja ya leseni zinazoruhusu ufikiaji wa msimbo wa chanzo wa mradi. Kwa kuongeza, mradi wa wazi unamaanisha kuwa watengenezaji wa tatu wanaweza kufanya mabadiliko. Hiyo ni, ikiwa kampuni fulani au msanidi programu atachapisha msimbo wa bidhaa yake, kwa kiasi au kabisa, hii haifanyi bidhaa hii kuwa mradi huria. Na hatimaye, shughuli yoyote ya mradi lazima iongoze kwa aina fulani ya matokeo, na uwazi wa mradi unamaanisha kuwa matokeo haya hayatumiwi tu na watengenezaji wenyewe.
Hatutagusa matatizo ya leseni wazi. Hii ni mada kubwa na changamano inayohitaji uchunguzi wa kina. Nakala nyingi nzuri na nyenzo zimeandikwa juu ya mada hii. Lakini kwa kuwa mimi mwenyewe si mtaalam katika uwanja wa hakimiliki, nitasema tu kwamba leseni inapaswa kufikia malengo ya mradi huo. Kwa mfano, kwa Embox uchaguzi wa BSD badala ya leseni ya GPL haukuwa wa bahati mbaya.
Ukweli kwamba mradi wa chanzo huria unapaswa kutoa uwezo wa kufanya mabadiliko na kushawishi maendeleo ya mradi wa chanzo huria ina maana kwamba mradi huo unasambazwa. Kusimamia, kudumisha uadilifu na utendaji ni vigumu zaidi ikilinganishwa na mradi wenye usimamizi wa kati. Swali la busara linatokea: kwa nini hufungua miradi wakati wote? Jibu liko katika eneo la uwezekano wa kibiashara; kwa darasa fulani la miradi, faida za mbinu hii ni kubwa kuliko gharama. Hiyo ni, haifai kwa miradi yote na njia ya wazi inakubalika kwa ujumla. Kwa mfano, ni vigumu kufikiria kuendeleza mfumo wa udhibiti wa kiwanda cha nguvu au ndege kulingana na kanuni iliyo wazi. Hapana, bila shaka, mifumo hiyo inapaswa kujumuisha modules kulingana na miradi ya wazi, kwa sababu hii itatoa idadi ya faida. Lakini mtu lazima awajibike kwa bidhaa ya mwisho. Hata kama mfumo unategemea kabisa kanuni za miradi iliyo wazi, msanidi programu, akiwa ameweka kila kitu kwenye mfumo mmoja na kufanya miundo na mipangilio maalum, kimsingi huifunga. Msimbo unaweza kupatikana kwa umma.
Pia kuna manufaa mengi kwa mifumo hii kutokana na kuunda au kuchangia miradi huria. Kama nilivyosema tayari, msimbo wa mfumo wa mwisho unaweza kubaki unapatikana kwa umma. Kwa nini, kwa sababu ni dhahiri kwamba hakuna uwezekano kwamba mtu yeyote atakuwa na ndege sawa ili kupima mfumo. Hii ni kweli, lakini kunaweza kuwa na mtu ambaye anataka kuangalia sehemu fulani za msimbo, au, kwa mfano, mtu anaweza kugundua kuwa maktaba inayotumiwa haijasanidiwa ipasavyo.
Faida kubwa zaidi inaonekana ikiwa kampuni itatenga sehemu ya msingi ya mfumo katika mradi tofauti. Kwa mfano, maktaba ya kusaidia aina fulani ya itifaki ya kubadilishana data. Katika kesi hii, hata kama itifaki ni maalum kwa eneo fulani la somo, unaweza kushiriki gharama za kudumisha kipande hiki cha mfumo na makampuni mengine kutoka eneo hili. Kwa kuongezea, wataalamu ambao wanaweza kusoma sehemu hii ya mfumo katika kikoa cha umma wanahitaji muda mfupi sana wa kuitumia kwa ufanisi. Na hatimaye, kutenganisha kipande katika huluki huru ambayo wasanidi programu wengine hutumia huturuhusu kuboresha sehemu hii, kwa sababu tunahitaji kutoa API zinazofaa, kuunda hati, na hata sizungumzii kuhusu kuboresha huduma ya majaribio.
Kampuni inaweza kupokea faida za kibiashara bila kuunda miradi ya chanzo huria; inatosha kwa wataalamu wake kushiriki katika miradi ya wahusika wengine inayotumiwa katika kampuni. Baada ya yote, manufaa yote yanabaki: wafanyakazi wanajua mradi bora zaidi, kwa hiyo wanaitumia kwa ufanisi zaidi, kampuni inaweza kuathiri mwelekeo wa maendeleo ya mradi huo, na matumizi ya msimbo tayari, uliotatuliwa kwa hakika hupunguza gharama za kampuni.
Faida za kuunda miradi ya opensource haziishii hapo. Wacha tuchukue sehemu muhimu ya biashara kama uuzaji. Kwa ajili yake, hii ni sandbox nzuri sana ambayo inamruhusu kutathmini kwa ufanisi mahitaji ya soko.
Na kwa kweli, hatupaswi kusahau kuwa mradi wa opensource ni njia bora ya kujitangaza kama mtoaji wa utaalam wowote. Katika baadhi ya matukio, hii ndiyo njia pekee ya kuingia kwenye soko. Kwa mfano, Embox ilianza kama mradi wa kuunda RTOS. Pengine hakuna haja ya kueleza kuwa kuna washindani wengi. Bila kuunda jumuiya, tusingekuwa na rasilimali za kutosha kuleta mradi kwa mtumiaji wa mwisho, yaani, kwa watengenezaji wa vyama vya tatu kuanza kutumia mradi huo.
Jumuiya ni muhimu katika mradi huria. Inakuruhusu kupunguza kwa kiasi kikubwa gharama za usimamizi wa mradi, kukuza na kusaidia mradi. Tunaweza kusema kwamba bila jumuiya hakuna mradi wa opensource hata kidogo.
Nyenzo nyingi zimeandikwa kuhusu jinsi ya kuunda na kudhibiti jumuiya ya mradi huria. Ili nisiseme tena ukweli unaojulikana, nitajaribu kuzingatia uzoefu wa Embox. Kwa mfano, mchakato wa kuunda jumuiya ni suala la kuvutia sana. Hiyo ni, wengi husema jinsi ya kusimamia jumuiya iliyopo, lakini wakati wa kuundwa kwake wakati mwingine hupuuzwa, kwa kuzingatia hili.
Kanuni kuu wakati wa kuunda jumuiya ya mradi wa opensource ni kwamba hakuna sheria. Ninamaanisha kuwa hakuna sheria za ulimwengu wote, kama vile hakuna risasi ya fedha, ikiwa tu kwa sababu miradi ni tofauti sana. Haiwezekani kwamba unaweza kutumia sheria sawa wakati wa kuunda jumuia ya maktaba ya ukataji miti ya js na dereva fulani aliyebobea sana. Aidha, katika hatua tofauti za maendeleo ya mradi (na kwa hiyo jamii), sheria hubadilika.
Embox ilianza kama mradi wa wanafunzi kwa sababu ilikuwa na ufikiaji wa wanafunzi kutoka idara ya programu ya mifumo. Kwa kweli, tulikuwa tunaingia kwenye jumuiya nyingine. Tunaweza kuwavutia washiriki wa jumuiya hii, wanafunzi, katika mazoezi mazuri ya viwanda katika taaluma zao, kazi ya kisayansi katika uwanja wa programu za mfumo, kozi na diploma. Hiyo ni, tulifuata mojawapo ya kanuni za msingi za kuandaa jumuiya: wanajamii lazima wapokee kitu, na bei hii lazima ilingane na mchango wa mshiriki.
Hatua iliyofuata ya Embox ilikuwa utafutaji wa watumiaji wengine. Ni muhimu sana kuelewa kwamba watumiaji ni washiriki kamili katika jumuiya ya opensource. Kawaida kuna watumiaji wengi kuliko watengenezaji. Na ili kutaka kuwa mchangiaji wa mradi, wanaanza kuutumia kwa njia moja au nyingine.
Watumiaji wa kwanza wa Embox walikuwa Idara ya Nadharia ya Cybernetics. Walipendekeza kuunda programu mbadala ya Lego Mindstorm. Na ingawa hawa walikuwa bado watumiaji wa ndani (tunaweza kukutana nao ana kwa ana na kujadili walichotaka). Lakini bado ilikuwa uzoefu mzuri sana. Kwa mfano, tulitengeneza onyesho ambazo zinaweza kuonyeshwa kwa wengine, kwa sababu roboti ni za kufurahisha na kuvutia umakini. Kwa hivyo, tulipata watumiaji wa wahusika wengine ambao walianza kuuliza Embox ni nini na jinsi ya kuitumia.
Katika hatua hii, tulipaswa kufikiria juu ya nyaraka, kuhusu njia za mawasiliano na watumiaji. Hapana, bila shaka, tulifikiri juu ya mambo haya muhimu kabla, lakini ilikuwa mapema na haikutoa athari nzuri. athari ilikuwa badala hasi. Ngoja nikupe mifano michache. Tulitumia googlecode, ambayo wiki iliauni lugha nyingi. Tuliunda kurasa katika lugha kadhaa, sio tu Kiingereza na Kirusi, ambayo hatukuweza kuwasiliana, lakini pia Kijerumani na Kihispania. Kwa sababu hiyo, inaonekana ni ujinga sana unapoulizwa katika lugha hizi, lakini hatuwezi kujibu hata kidogo. Au walianzisha sheria kuhusu kuandika hati na kutoa maoni, lakini kwa kuwa API ilibadilika mara nyingi na kwa kiasi kikubwa, ikawa kwamba hati zetu zilikuwa za zamani na zilikuwa za kupotosha zaidi kuliko ilivyosaidia.
Matokeo yake, jitihada zetu zote, hata zile mbaya, zilisababisha kuonekana kwa watumiaji wa nje. Na hata mteja wa kibiashara alionekana ambaye alitaka RTOS yake mwenyewe itengenezwe kwa ajili yake. Na tuliikuza kwa sababu tuna uzoefu na msingi fulani. Hapa unahitaji kuzungumza juu ya wakati mzuri na mbaya. Nitaanza na wabaya. Kwa kuwa watengenezaji wengi walihusika katika mradi huu kwa misingi ya kibiashara, jumuiya ilikuwa tayari haijatulia na imegawanyika, ambayo bila shaka haikuweza lakini kuathiri maendeleo ya mradi huo. Jambo la ziada lilikuwa kwamba mwelekeo wa mradi uliwekwa na mteja mmoja wa kibiashara, na lengo lake halikuwa maendeleo zaidi ya mradi huo. Angalau hili halikuwa lengo kuu.
Kwa upande mwingine, kulikuwa na idadi ya vipengele vyema. Tulipata watumiaji wa wahusika wengine. Haikuwa mteja tu, bali pia wale ambao mfumo huu ulikusudiwa. Hamasa ya kushiriki katika mradi huo imeongezeka. Baada ya yote, ikiwa unaweza pia kupata pesa kutoka kwa biashara ya kuvutia, daima ni nzuri. Na muhimu zaidi, tulisikia hamu moja kutoka kwa wateja, ambayo wakati huo ilionekana kuwa wazimu kwetu, lakini ambayo sasa ni wazo kuu la Embox, yaani, kutumia nambari iliyotengenezwa tayari kwenye mfumo. Sasa wazo kuu la Embox ni kutumia programu ya Linux bila Linux. Hiyo ni, kipengele kikuu chanya kilichochangia maendeleo zaidi ya mradi huo ni kutambua kwamba mradi hutumiwa na watumiaji wa tatu, na inapaswa kutatua baadhi ya matatizo yao.
Wakati huo, Embox tayari ilikuwa imevuka upeo wa mradi wa wanafunzi. Sababu kuu ya kizuizi katika maendeleo ya mradi kulingana na mfano wa mwanafunzi ni motisha ya washiriki. Wanafunzi hushiriki wanapokuwa wanasoma, na wanapohitimu, kuwe na motisha tofauti. Ikiwa motisha haionekani, mwanafunzi ataacha tu kushiriki katika mradi huo. Ikiwa tunazingatia kwamba wanafunzi kwanza wanahitaji kufundishwa, zinageuka kuwa wanakuwa wataalam wazuri wakati wa kuhitimu, lakini mchango wao katika mradi huo, kutokana na uzoefu, sio mkubwa sana.
Kwa ujumla, tunaendelea vizuri kwenye hatua kuu ambayo inaruhusu sisi kuzungumza juu ya kuunda mradi wa opensource - kuunda bidhaa ambayo inaweza kutatua matatizo ya watumiaji wake. Kama nilivyoeleza hapo juu, mali kuu ya mradi huria ni jumuiya yake. Zaidi ya hayo, wanajamii kimsingi ni watumiaji. Lakini wanatoka wapi wakati hakuna kitu cha kutumia? Kwa hivyo inabadilika kuwa, kama vile mradi usio wa rasilimali huria, unahitaji kuzingatia kuunda MVP (bidhaa ya chini inayowezekana), na ikiwa inawavutia watumiaji, basi jumuiya itaonekana karibu na mradi huo. Ikiwa unajishughulisha na kuunda jumuiya tu kupitia PR ya jumuiya, kuandika wiki katika lugha zote za dunia, au sahihisha mtiririko wa kazi wa git kwenye github, basi hii haiwezekani kuwa muhimu katika hatua za mwanzo za mradi. Bila shaka, katika hatua zinazofaa haya sio muhimu tu, bali pia mambo muhimu.
Kwa kumalizia ningependa kubainisha , kwa maoni yangu, inayoonyesha matarajio ya watumiaji kutoka kwa mradi wa opensource:
Ninafikiria sana kubadili mfumo huu wa uendeshaji (angalau jaribu. Wanaifuatilia kwa bidii na kufanya mambo mazuri).
P.S. Imewashwa Tutakuwa na ripoti nyingi kama tatu. Moja kuhusu chanzo wazi na mbili kuhusu iliyopachikwa (na moja ni ya vitendo). Katika msimamo tutafanya darasa la bwana juu ya vidhibiti vidogo vya programu kwa kutumia . Kama kawaida, tutaleta maunzi na kukuruhusu uipange. Pia kutakuwa na jitihada na shughuli nyingine. Njoo kwenye tamasha na msimamo wetu, itakuwa ya kufurahisha.
Chanzo: mapenzi.com