Šonedēļ Sanktpēterburgā notiks IT festivāls . Viens no runātājiem uzstāsies Ričards Stallmans. arī piedalās festivālā, un, protams, nevarējām ignorēt bezmaksas programmatūras tēmu. Tāpēc viens no mūsu ziņojumiem tiek saukts . Tas būs veltīts Embox kā atvērtā pirmkoda projekta attīstības vēsturei. Šajā rakstā vēlos runāt par galvenajām idejām, kas, manuprāt, ietekmē atvērtā koda projektu attīstību. Raksts, tāpat kā ziņojums, ir balstīts uz personīgo pieredzi.
Sāksim ar kaut ko vienkāršu, ar termina opensource definīciju. Acīmredzot atvērtā koda projekts ir projekts, kuram ir viena no licencēm, kas ļauj piekļūt projekta pirmkodam. Turklāt atvērts projekts nozīmē, ka trešās puses izstrādātāji var veikt izmaiņas. Tas ir, ja kāds uzņēmums vai izstrādātājs daļēji vai pilnībā publicē sava produkta kodu, tas vēl nepadara šo produktu par atvērtā koda projektu. Un visbeidzot, jebkurai projekta darbībai ir jānoved pie sava veida rezultāta, un projekta atklātība nozīmē, ka šo rezultātu izmanto ne tikai paši izstrādātāji.
Atvērto licenču problēmas neskarsim. Šī ir pārāk liela un sarežģīta tēma, kas prasa padziļinātu izpēti. Par šo tēmu ir uzrakstīts diezgan daudz labu rakstu un materiālu. Bet, tā kā es pats neesmu eksperts autortiesību jomā, teikšu tikai to, ka licencei ir jāatbilst projekta mērķiem. Piemēram, Embox BSD, nevis GPL licences izvēle nebija nejauša.
Fakts, ka atvērtā koda projektam ir jānodrošina iespēja veikt izmaiņas un ietekmēt atvērtā koda projekta attīstību, nozīmē, ka projekts tiek izplatīts. To pārvaldīt, saglabāt integritāti un veiktspēju ir daudz grūtāk, salīdzinot ar projektu ar centralizētu pārvaldību. Rodas pamatots jautājums: kāpēc vispār tiek atvērti projekti? Atbilde ir komerciālās iespējamības jomā; noteiktai projektu klasei šīs pieejas priekšrocības pārsniedz izmaksas. Tas ir, tas nav piemērots visiem projektiem, un atvērta pieeja kopumā ir pieņemama. Piemēram, ir grūti iedomāties vadības sistēmas izstrādi spēkstacijai vai lidmašīnai, pamatojoties uz atvērtu principu. Nē, protams, šādās sistēmās būtu jāiekļauj moduļi, kuru pamatā ir atvērti projekti, jo tas sniegs vairākas priekšrocības. Bet kādam ir jāatbild par galaproduktu. Pat ja sistēma ir pilnībā balstīta uz atvērto projektu kodu, izstrādātājs, visu sapakojis vienā sistēmā un veicis konkrētus būvējumus un iestatījumus, to būtībā aizver. Kods var būt publiski pieejams.
Šīm sistēmām ir arī daudz priekšrocību, veidojot atvērtā pirmkoda projektus vai sniedzot ieguldījumu tajos. Kā jau teicu, beigu sistēmas kods var palikt publiski pieejams. Kāpēc, jo ir acīmredzams, ka diez vai kādam būs tāda pati lidmašīna, lai pārbaudītu sistēmu. Tā ir taisnība, taču var būt kāds, kurš vēlas pārbaudīt noteiktas koda sadaļas, vai, piemēram, kāds var atklāt, ka izmantotā bibliotēka nav konfigurēta gluži pareizi.
Vēl lielāks ieguvums parādās, ja uzņēmums iedala kādu sistēmas pamata daļu atsevišķā projektā. Piemēram, bibliotēka, lai atbalstītu kādu datu apmaiņas protokolu. Tādā gadījumā, pat ja protokols ir raksturīgs konkrētai tēmai, šīs sistēmas daļas uzturēšanas izmaksas varat dalīt ar citiem uzņēmumiem no šīs jomas. Turklāt speciālistiem, kuri var izpētīt šo sistēmas daļu publiskajā telpā, ir nepieciešams daudz mazāk laika, lai to efektīvi izmantotu. Un visbeidzot, daļas atdalīšana neatkarīgā vienībā, ko izmanto trešo pušu izstrādātāji, ļauj mums uzlabot šo daļu, jo mums ir jāpiedāvā efektīvas API, jāizveido dokumentācija, un es pat nerunāju par testa pārklājuma uzlabošanu.
Uzņēmums var saņemt komerciālus ieguvumus, neveidojot atvērtā koda projektus, pietiek ar tā speciālistu dalību uzņēmumā izmantotajos trešo personu projektos. Galu galā visi ieguvumi paliek: darbinieki labāk pārzina projektu, tāpēc izmanto to efektīvāk, uzņēmums var ietekmēt projekta attīstības virzienu, un gatavā, atkļūdota koda izmantošana acīmredzami samazina uzņēmuma izmaksas.
Atvērtā pirmkoda projektu izveides priekšrocības ar to nebeidzas. Ņemsim tik svarīgu biznesa sastāvdaļu kā mārketings. Viņam šī ir ļoti laba smilšu kaste, kas ļauj efektīvi izvērtēt tirgus prasības.
Un, protams, mēs nedrīkstam aizmirst, ka atvērtā pirmkoda projekts ir efektīvs veids, kā pasludināt sevi par jebkuras specializācijas nesēju. Dažos gadījumos tas ir vienīgais veids, kā iekļūt tirgū. Piemēram, Embox sākās kā projekts, lai izveidotu RTOS. Droši vien nav jāskaidro, ka konkurentu ir daudz. Bez kopienas izveides mums vienkārši nebūtu bijis pietiekami daudz resursu, lai projektu nodotu gala lietotājam, tas ir, lai trešo pušu izstrādātāji varētu sākt izmantot projektu.
Kopienai ir galvenā loma atvērtā pirmkoda projektā. Tas ļauj būtiski samazināt projekta vadības izmaksas, attīstīt un atbalstīt projektu. Mēs varam teikt, ka bez kopienas vispār nav atvērtā koda projekta.
Ir uzrakstīts daudz materiālu par to, kā izveidot un pārvaldīt atvērtā koda projektu kopienu. Lai nepārstāstītu jau zināmus faktus, centīšos pievērsties Embox pieredzei. Piemēram, kopienas izveides process ir ļoti interesants jautājums. Tas ir, daudzi stāsta, kā pārvaldīt esošu kopienu, taču tās izveides brīži dažkārt tiek ignorēti, uzskatot to par pašsaprotamu.
Galvenais noteikums, veidojot atvērtā koda projektu kopienu, ir tas, ka nav noteikumu. Es domāju, ka nav universālu noteikumu, tāpat kā nav sudraba lodes, kaut vai tāpēc, ka projekti ir ļoti atšķirīgi. Maz ticams, ka varat izmantot tos pašus noteikumus, veidojot kopienu js reģistrēšanas bibliotēkai un kādam ļoti specializētam draiverim. Turklāt dažādos projekta (un līdz ar to arī kopienas) attīstības posmos noteikumi mainās.
Embox sākās kā studentu projekts, jo tam bija piekļuve studentiem no sistēmu programmēšanas nodaļas. Patiesībā mēs iekļuvām kādā citā kopienā. Mēs varētu ieinteresēt šīs kopienas dalībniekus, studentus, par labu rūpniecisko praksi savā specialitātē, zinātnisko darbu sistēmu programmēšanas jomā, kursa darbus un diplomus. Tas ir, mēs ievērojām vienu no kopienas organizēšanas pamatnoteikumiem: kopienas dalībniekiem kaut kas jāsaņem, un šai cenai jāatbilst dalībnieka ieguldījumam.
Nākamais Embox posms bija trešo pušu lietotāju meklēšana. Ir ļoti svarīgi saprast, ka lietotāji ir pilntiesīgi atvērtā pirmkoda kopienas dalībnieki. Parasti lietotāju ir vairāk nekā izstrādātāju. Un, lai viņi vēlētos kļūt par projekta līdzstrādniekiem, viņi vispirms sāk to izmantot vienā vai otrā veidā.
Pirmie Embox lietotāji bija Teorētiskās kibernētikas katedra. Viņi ieteica izveidot alternatīvu programmaparatūru Lego Mindstorm. Un, lai gan tie joprojām bija vietējie lietotāji (varējām ar viņiem tikties klātienē un apspriest, ko viņi vēlas). Bet tā joprojām bija ļoti laba pieredze. Piemēram, mēs izstrādājām demonstrācijas, kuras varētu parādīt citiem, jo roboti ir jautri un piesaista uzmanību. Rezultātā mēs saņēmām patiesi trešo pušu lietotājus, kuri sāka jautāt, kas ir Embox un kā to izmantot.
Šajā posmā bija jādomā par dokumentāciju, par saziņas līdzekļiem ar lietotājiem. Nē, par šīm svarīgajām lietām mēs jau iepriekš domājām, bet tas bija pāragri un nedeva pozitīvu efektu. Ietekme bija diezgan negatīva. Ļaujiet man sniegt jums pāris piemērus. Mēs izmantojām googlecode, kura wiki atbalstīja daudzvalodību. Mēs veidojām lapas vairākās valodās, ne tikai angļu un krievu valodās, kurās gandrīz nevarējām sazināties, bet arī vācu un spāņu. Rezultātā tas izskatās ļoti smieklīgi, kad jautā šajās valodās, bet mēs nevaram atbildēt vispār. Vai arī viņi ieviesa noteikumus par dokumentācijas rakstīšanu un komentēšanu, taču, tā kā API mainījās diezgan bieži un būtiski, izrādījās, ka mūsu dokumentācija ir novecojusi un vairāk maldinoša, nekā palīdzēja.
Rezultātā visas mūsu pūles, pat nepareizās, noveda pie ārēju lietotāju parādīšanās. Un pat parādījās komerciāls klients, kurš vēlējās, lai viņam tiktu izstrādāts savs RTOS. Un mēs to izstrādājām, jo mums ir pieredze un zināms pamats. Šeit jums jārunā gan par labajiem, gan sliktajiem brīžiem. Sākšu ar sliktajiem. Tā kā daudzi izstrādātāji šajā projektā bija iesaistīti uz komerciāliem pamatiem, sabiedrība jau bija diezgan nestabila un sašķelta, kas, protams, nevarēja neietekmēt projekta attīstību. Papildu faktors bija tas, ka projekta virzienu noteica viens komercpasūtītājs, un viņa mērķis nebija projekta tālāka attīstība. Tas vismaz nebija galvenais mērķis.
No otras puses, bija vairāki pozitīvi aspekti. Mums ir patiesi trešo pušu lietotāji. Tas bija ne tikai klients, bet arī tie, kam šī sistēma bija paredzēta. Ir pieaugusi motivācija piedalīties projektā. Galu galā, ja jūs varat arī nopelnīt naudu no interesanta biznesa, tas vienmēr ir jauki. Un pats galvenais, no klientiem dzirdējām vienu vēlmi, kas tobrīd mums šķita traka, bet tagad ir Embox galvenā ideja, proti, sistēmā izmantot jau izstrādātu kodu. Tagad Embox galvenā ideja ir izmantot Linux programmatūru bez Linux. Proti, galvenais pozitīvais aspekts, kas veicināja projekta turpmāko attīstību, bija apziņa, ka projektu izmanto trešo pušu lietotāji, un tam vajadzētu atrisināt dažas viņu problēmas.
Tajā laikā Embox jau bija izgājis ārpus studentu projekta robežām. Galvenais ierobežojošais faktors projekta izstrādē pēc studenta modeļa ir dalībnieku motivācija. Studenti piedalās, kamēr viņi mācās, un, kad viņi absolvē, jābūt citai motivācijai. Ja motivācija neparādās, skolēns vienkārši pārtrauc dalību projektā. Ja ņem vērā, ka skolēni vispirms ir jāapmāca, izrādās, ka līdz studiju beigšanai viņi kļūst par labiem speciālistiem, taču viņu pienesums projektā pieredzes trūkuma dēļ nav īpaši liels.
Kopumā raiti pārejam pie galvenā, kas ļauj runāt par atvērtā koda projekta izveidi – tāda produkta radīšanu, kas atrisinātu tā lietotāju problēmas. Kā jau paskaidroju iepriekš, atvērtā pirmkoda projekta galvenais īpašums ir tā kopiena. Turklāt kopienas locekļi galvenokārt ir lietotāji. Bet no kurienes tie rodas, ja nav ko izmantot? Tātad izrādās, ka, tāpat kā ar atvērtā koda projektu, jums ir jākoncentrējas uz MVP (minimālā dzīvotspējas produkta) izveidi, un, ja tas interesē lietotājus, tad ap projektu radīsies kopiena. Ja esat iesaistījies kopienas veidošanā, tikai izmantojot kopienas PR, rakstot wiki visās pasaules valodās vai koriģējot git darbplūsmu vietnē github, maz ticams, ka tam būs nozīme projekta sākumposmā. Protams, atbilstošos posmos tās ir ne tikai svarīgas, bet arī nepieciešamas lietas.
Nobeigumā vēlos norādīt , manuprāt, atspoguļojot lietotāju cerības no atvērtā pirmkoda projekta:
Es nopietni domāju par pāreju uz šo OS (vismaz pamēģini. Viņi aktīvi tiecas pēc tā un dara foršas lietas).
PS ieslēgts Mums būs trīs ziņojumi. Viens par atvērto avotu un divi par iegulto (un viens ir praktisks). Stendā vadīsim meistarklasi par mikrokontrolleru programmēšanu, izmantojot . Kā parasti, mēs atvedīsim aparatūru un ļausim to programmēt. Būs arī kvests un citas aktivitātes. Nāciet uz festivālu un mūsu stendu, būs jautri.
Avots: www.habr.com