ProHoster > Blogs > Administrācija > Kā izveidot open source projektu

Kā izveidot open source projektu

Kā izveidot open source projektuÅ onedēļ Sanktpēterburgā norisināsies IT festivāls TechTrain. Viens no runātājiem bÅ«s Ričards Stollmans. Embox tāpat piedalās festivālā, un, protams, mēs nevarējām nepievērst uzmanÄ«bu atvērtā koda tēmai. Tādēļ viens no mÅ«su ziņojumiem ir nosaukts ā€œNo studenta varianta lÄ«dz opensource projektam. Embox pieredzeā€. Tas bÅ«s veltÄ«ts Embox kā atvērtā koda projekta attÄ«stÄ«bas vēsturei. Å ajā rakstā es vēlētos pastāstÄ«t par galvenajām idejām, kas, pēc manām domām, ietekmē atvērtā koda projektu attÄ«stÄ«bu. Raksts, tāpat kā ziņojums, balstÄ«ts uz personisko pieredzi.

Sāksim ar vienkārÅ”o, ar termina opensource definÄ«ciju. AcÄ«mredzami, ka atvērtā koda projekts ir projekts, kam ir viena no licenciām, kas ļauj piekļūt projekta avota kodam. Turklāt atvērts projekts nozÄ«mē, ka treÅ”ie izstrādātāji var veikt izmaiņas. Tātad, ja kāda uzņēmums vai izstrādātājs publicē sava produkta kodu, daļēji vai pilnÄ«bā, tas vēl nenozÄ«mē, ka Å”is produkts ir opensource projekts. Un visbeidzot, jebkurai projektā veiktai darbÄ«bai jānov leads pie kāda rezultāta, turklāt atvērtÄ«ba projekta nozÄ«mē, ka Å”o rezultātu izmanto ne tikai paÅ”i izstrādātāji.

Atvērtu licenci jautājumus neapskatÄ«sim. Tā ir pārāk liela un sarežģīta tēma, kas prasa dziļu izpratni. Å ajā tēmā ir uzrakstÄ«ti diezgan daudzi labi raksti un materiāli. Taču, tā kā es neesmu speciālists autortiesÄ«bu jomā, varu teikt tikai to, ka licencei jāatbilst projekta mērÄ·iem. Piemēram, Embox izvēle starp BSD un GPL licenci nebija nejauÅ”a.

Fakts, ka atvērtajam projektam jāsniedz iespēja veikt izmaiņas un ietekmēt atvērtā projekta attÄ«stÄ«bu, nozÄ«mē, ka projekts ir decentralizēts. To pārvaldÄ«t, saglabāt tā integritāti un darbspēju ir daudz grÅ«tāk salÄ«dzinājumā ar projektu, kam ir centralizēta pārvaldÄ«ba. Rodas pamatots jautājums ā€” kāpēc vispār veidot atvērtos projektus? Atbilde ir komerciālajā pamatotÄ«bā; noteiktai projektu klasei ieguvumi no Ŕāda pieejas pārsniedz izmaksas. Tas nenozÄ«mē, ka atvērtais pieejas modelis ir piemērots visiem projektiem. Piemēram, grÅ«ti iedomāties, ka elektrostacijas vai lidmaŔīnas vadÄ«bas sistēma varētu tikt izstrādāta, pamatojoties uz atvērtajiem principiem. Protams, Ŕādās sistēmās bÅ«tu jāpievieno moduļi, kas balstÄ«ti uz atvērtiem projektiem, jo tas sniegs virkni priekÅ”rocÄ«bu. Taču par gala produkta kvalitāti kādam jāatbild. Pat ja sistēma ir pilnÄ«bā balstÄ«ta uz atvērtos projektos esoÅ”o kodu, izstrādātājs, apkopojot visu vienā sistēmā un veicot konkrētus izstrādes un iestatÄ«Å”anas procesus, bÅ«tÄ«bā to slēdz. Kods var atrasties publiskajā pieejamÄ«bā.

Å Ä«m sistēmām pastāv arÄ« daudzi ieguvumi no atvērtu projektu veidoÅ”anas vai dalÄ«bas tajos. Kā jau teicu, gala sistēmas kods var palikt publiskajā pieejamÄ«bā. Kāpēc tas ir vajadzÄ«gs, ja ir acÄ«mredzams, ka grÅ«ti atrast kādu citu lidmaÅ”inu, lai pārbaudÄ«tu sistēmu? Tas ir patiesi, taču var arÄ« atrasties kāds, kas vēlētos pārbaudÄ«t konkrētas koda daļas, vai piemēram, kāds var atklāt, ka izmantotā bibliotēka nav pilnÄ«bā pareizi konfigurēta.

Vēl lielāka izdevÄ«ba rodas, ja uzņēmums atvēl kādu pamata sistēmas daļu atseviŔķam projektam. Piemēram, bibliotēkai datu apmaiņas protokola atbalstam. Å ajā gadÄ«jumā, pat ja protokols ir specifisks konkrētajai jomai, izmaksas Ŕīs sistēmas daļas uzturÄ“Å”anai var dalÄ«t ar citiem uzņēmumiem, kas darbojas Å”ajā nozarē. Turklāt speciālistiem, kuri var izpētÄ«t Å”o sistēmas daļu atklātā piekļuvē, ir nepiecieÅ”ams ievērojami mazāk laika efektÄ«vai tās izmantoÅ”anai. Un visbeidzot, atseviŔķas daļas izdalÄ«Å”ana par paÅ”pietiekamu vienÄ«bu, ko izmanto treÅ”o personu izstrādātāji, ļauj Å”o daļu padarÄ«t kvalitatÄ«vāku, jo jānodroÅ”ina efektÄ«vi API, jāizveido dokumentācija, nemaz nerunājot par testÄ“Å”anas seguma uzlaboÅ”anu.

KomercizdevÄ«bu uzņēmums var gÅ«t arÄ« nelatvējot atvērtos projektus, pietiek, lai viņu speciālisti piedalÄ«tos treÅ”o puÅ”u projektos, kas tiek izmantoti uzņēmumā. Galu galā visus ieguvumus saglabā: darbinieki labāk izprot projektu, lÄ«dz ar to efektÄ«vāk to izmanto, uzņēmums var ietekmēt projekta attÄ«stÄ«bu, un gatavā, rÅ«pÄ«gi izstrādātā koda izmantoÅ”ana acÄ«mredzami samazina uzņēmuma izdevumus.

Tomēr priekÅ”rocÄ«bas no atvērtā pirmkoda projektu izveides nebeidzas Å”eit. ApskatÄ«sim tādu bÅ«tisku uzņēmuma sastāvdaļu kā mārketings. Tas ir ļoti laba izmēģinājuma vide, kas ļauj efektÄ«vi novērtēt tirgus prasÄ«bas.

Un, protams, nedrÄ«kst aizmirst, ka atvērtā pirmkoda projekts ir efektÄ«vs veids, kā paziņot par sevi kā kāda specializācija nesēju. Dažos gadÄ«jumos tas ir pat vienÄ«gais ceļŔ uz tirgu. Piemēram, Embox sāka kā operētājsistēmas projektu. DroÅ”i vien nav jāskaidro, ka ir daudz konkurentu. Bez kopienas izveides mums vienkārÅ”i nepietiktu resursu projekta pabeigÅ”anai, proti, lai projektu sāktu izmantot treÅ”o puÅ”u izstrādātāji.

Kopiena ir būtiska atvērtā pirmkoda projektā. Tā būtiski samazina izdevumus projekta vadībā, attīsta un uztur projektu. Var teikt, ka bez kopienas vispār nav atvērtā pirmkoda projekta.

Par to, kā izveidot un vadÄ«t atvērtā koda projekta kopienu, ir uzrakstÄ«ti daudzi materiāli. Es, lai nepārstāstÄ«tu jau zināmos faktus, centÄ«Å”os pievērst uzmanÄ«bu Embox pieredzei. Piemēram, ļoti interesants jautājums ir kopienas izveides process. Tas ir, daudzi stāsta, kā vadÄ«t esoÅ”u kopienu, taču brīžiem tās izveides aspekti tiek aizmirsti, uzskatot to par paÅ”saprotamu.

Galvenais noteikums, veidojot opensource projekta kopienu, ir tas, ka nav nekādu noteikumu. Es domāju, ka universālu noteikumu nav, tāpat kā sudraba lodes, vismaz tāpēc, ka projekti ir ļoti atŔķirÄ«gi. GrÅ«ti vienos un tajos paÅ”os noteikumos vadÄ«t kopienu bibliotēkai, kas reÄ£istrē datus uz js, un kādam Å”auram specializētam draiverim. Vēl jo vairāk, dažādās projekta attÄ«stÄ«bas fāzēs (un attiecÄ«gi arÄ« kopienas) noteikumi mainās.

Embox sākās kā studentu projekts, jo bija pieejami studenti no sistēmu programmÄ“Å”anas katedras. PatiesÄ«bā mēs ienācām kādā citā kopienā. Å Ä«s kopienas dalÄ«bniekiem, studentiem, mēs varējām piedāvāt labu rÅ«pniecisko praksi viņu specialitātē, zinātniskos darbus sistēmu programmÄ“Å”anas jomā, kā arÄ« kursa un diplomdarbus. Tas ir, mēs izpildÄ«jām vienu no galvenajiem noteikumiem kopienas organizÄ“Å”anā, dalÄ«bniekiem jāsaņem kaut kas, un Å”ai cenai jāatbilst dalÄ«bnieka ieguldÄ«jumam.

Nākamais posms Embox bija meklēt ārējos lietotājus. Ļoti svarīgi saprast, ka lietotāji ir pilnvērtīgi atvērtā koda kopienas dalībnieki. Lietotāju parasti ir vairāk nekā izstrādātāju. Un, lai vēlētos kļūt par projekta līdzautoru, vispirms viņi kādā mērā sāk to lietot.

Pirmaji lietotāju grupa Embox bija Teorētiskās Kibernētikas katedra. Viņi piedāvāja izveidot alternatīvu programmatūru Lego Mindstorm. Un, lai gan tie joprojām bija vietējie lietotāji (mēs varējām tikties ar viņiem personīgi un apspriest, ko viņi vēlas). Tomēr tas bija ļoti labs pieredze. Piemēram, mēs izstrādājām demonstrācijas, kuras varējām parādīt citiem, jo roboti ir jautri un piesaista uzmanību. Beigās mums bija patiesi ārēji lietotāji, kas sāka jautāt, kas ir Embox un kā to lietot.

Å ajā posmā mums bija jādomā par dokumentāciju, par komunikācijas lÄ«dzekļiem ar lietotājiem. Protams, mēs par Ŕīm svarÄ«gajām lietām domājām arÄ« iepriekÅ”, taču tas bija pāragri, un tas nesniedza pozitÄ«vu efektu. Efekts bija drÄ«zāk negatÄ«vs. Sniedzu pāris piemērus. Mēs izmantojām googlecode, kura wiki atbalstÄ«ja daudzvalodÄ«bu. Mēs izveidojām lapas vairākās valodās, tostarp ne tikai angļu un krievu, ar kurām kaut kā varējām sazināties, bet arÄ« vācu un spāņu. Rezultātā bija ļoti smieklÄ«gi, kad kāds jautāja Å”ajās valodās, bet mēs vispār nevarējām atbildēt. Vai arÄ« mēs ievieÅ”am noteikumus par dokumentācijas rakstÄ«Å”anu un komentÄ“Å”anu, taču, ņemot vērā, ka API mainÄ«jās diezgan bieži un bÅ«tiski, izrādÄ«jās, ka mÅ«su dokumentācija novecoja un vairāk maldināja nekā palÄ«dzēja.

Galu galā visi mÅ«su centieni, pat nepareizie, noveda pie tā, ka parādÄ«jās ārējie lietotāji. Un pat radās komerciāls klients, kurÅ” vēlējās, lai viņam izstrādā savu OSRV. Mēs to izstrādājām, jo mums ir pieredze un daži iepriekŔējie darbi. Å eit jāstāsta gan par labajām, gan sliktajām lietām. Sāksim ar sliktajām. Tā kā daudzi izstrādātāji tika piesaistÄ«ti Å”im projektam uz komerciāla pamata, kopiena un tāpat jau diezgan nestabila, sadalÄ«jās, kas, protams, nevarēja neietekmēt projekta attÄ«stÄ«bu. Papildu faktors bija tas, ka projekta virzÄ«ba tika noteikta no viena komerciāla pasÅ«tÄ«tāja, un tā mērÄ·is nebija projekta turpmākā attÄ«stÄ«ba. Vismaz Å”is mērÄ·is nebija galvenais.

No otras puses, bija virkne pozitÄ«vu momentu. Mēs saņēmām patiesi treÅ”o personu lietotājus. Tas nebija tikai klients, bet arÄ« tie, kam Ŕī sistēma bija paredzēta. Motivācija piedalÄ«ties projektā palielinājās. Jo, ja uz interesanta darba var arÄ« nopelnÄ«t, tas vienmēr ir patÄ«kami. Un galvenais, mēs dzirdējām vienu klientu vēlmi, kas tajā brÄ«dÄ« mums Ŕķita nereāla, taču tagad tā ir galvenā ideja Embox ā€” proti, izmantot sistēmā jau izstrādāto kodu. Tagad galvenā ideja Embox ir Linux programmatÅ«ras izmantoÅ”ana bez Linux. Tas ir, galvenais pozitÄ«vais moments, kas veicina projekta turpmāku attÄ«stÄ«bu, bija apzināŔanās, ka projektu izmanto treÅ”o personu lietotāji, un tam jārisina kādas viņu problēmas.

Tajā brÄ«dÄ« Embox jau bija iznācis no studentu projekta robežām. Galvenais attÄ«stÄ«bas ierobežojoÅ”ais faktors studentu modeļa ietvaros ir dalÄ«bnieku motivācija. Studentu dalÄ«ba turpinās, kamēr viņi mācās, bet pēc izlaiduma ir jārod cita motivācija. Ja motivācija neparādās, students vienkārÅ”i pārtrauc dalÄ«bu projektā. Ja ņem vērā, ka studentus vispirms ir jāmāca, iznāk, ka par labiem speciālistiem viņi kļūst izlaiduma brÄ«dÄ«, taču ieguldÄ«jums projektā, jaunas pieredzes dēļ, nav ļoti liels.

Kopumā mēs pakāpeniski pārejam pie galvenā momenta, kas ļauj runāt par opensource projekta izveidi, ā€” produkta izveidoÅ”anu, kas risinātu tā lietotāju problēmas. Kā jau iepriekÅ” minēju, galvenā opensource projekta iezÄ«me ir tā kopiena. Turklāt kopienas dalÄ«bnieki ir vispirms lietotāji. Bet no kurienes viņi var rasties, ja nav ko izmantot? Tā tas sanāk, ka tāpat kā ar ne-opensource projektu, ir nepiecieÅ”ams koncentrēties uz MVP (minimālais dzÄ«votspējÄ«gais produkts) izveidi, un, ja tas ieinteresē lietotājus, ap projektu veidosies kopiena. Ja tikai centÄ«sies izveidot kopienu caur sabiedrisko attiecÄ«bu, wiki rakstÄ«Å”anu visās pasaules valodās vai pareizu git darba plÅ«smu github, tad grÅ«ti teikt, cik nozÄ«mÄ«gi tas bÅ«s projekta agrÄ«najos posmos. Protams, atbilstoÅ”ajos posmos tas ir ne tikai svarÄ«gi, bet arÄ« nepiecieÅ”ami.

Noslēgumā vēlos izcelt komentārs, manā skatījumā atspoguļo lietotāju cerības attiecībā uz opensource projektu:

Es nopietni domāju par pāreju uz Å”o OS (vismaz izmēģināt. To ļoti aktÄ«vi attÄ«sta un veido lieliskas lietas).

P. S. Uz TechTrain mums bÅ«s pat trÄ«s ziņojumi. Viens par open source un divi par embedded (turklāt viens bÅ«s praktisks). Stendā rÄ«kosim meistarklasi par mikrokontrolieru programmÄ“Å”anu ar Embox. Tradicionāli atvedÄ«sim aparatÅ«ru un ļausim to programmēt. BÅ«s arÄ« kustÄ«ba un citas aktivitātes. Nāciet uz festivālu un uz mÅ«su stendu, bÅ«s jautri.

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster