Isang IT festival ang gaganapin sa St. Petersburg ngayong linggo . Isa sa mga magsasalita ay si Richard Stallman. nakikilahok din sa pagdiriwang, at siyempre hindi namin maaaring balewalain ang paksa ng libreng software. Kaya naman tinawag ang isa sa aming mga ulat . Ito ay nakatuon sa kasaysayan ng pag-unlad ng Embox bilang isang open source na proyekto. Sa artikulong ito gusto kong pag-usapan ang mga pangunahing ideya na, sa aking palagay, ay nakakaimpluwensya sa pagbuo ng mga proyektong opensource. Ang artikulo, tulad ng ulat, ay batay sa personal na karanasan.
Magsimula tayo sa isang bagay na simple, kasama ang kahulugan ng terminong opensource. Malinaw, ang isang open source na proyekto ay isang proyekto na may isa sa mga lisensya na nagbibigay-daan sa pag-access sa source code ng proyekto. Bilang karagdagan, ang isang bukas na proyekto ay nangangahulugan na ang mga third-party na developer ay maaaring gumawa ng mga pagbabago. Ibig sabihin, kung ang ilang kumpanya o developer ay nag-publish ng code ng produkto nito, bahagyang o ganap, hindi pa nito ginagawang opensource na proyekto ang produktong ito. At sa wakas, ang anumang aktibidad ng proyekto ay dapat humantong sa ilang uri ng resulta, at ang pagiging bukas ng proyekto ay nagpapahiwatig na ang resulta na ito ay ginagamit hindi lamang ng mga developer mismo.
Hindi namin hawakan ang mga problema ng bukas na mga lisensya. Ito ay masyadong malaki at kumplikadong paksa na nangangailangan ng malalim na pagsisiyasat. Napakaraming magagandang artikulo at materyales ang naisulat sa paksang ito. Ngunit dahil ako mismo ay hindi isang dalubhasa sa larangan ng copyright, sasabihin ko lamang na ang lisensya ay dapat matugunan ang mga layunin ng proyekto. Halimbawa, para sa Embox ang pagpili ng isang BSD sa halip na isang lisensya ng GPL ay hindi sinasadya.
Ang katotohanan na ang isang open source na proyekto ay dapat magbigay ng kakayahang gumawa ng mga pagbabago at maimpluwensyahan ang pagbuo ng open source na proyekto ay nagpapahiwatig na ang proyekto ay ipinamamahagi. Ang pamamahala nito, pagpapanatili ng integridad at pagganap ay mas mahirap kumpara sa isang proyektong may sentralisadong pamamahala. Ang isang makatwirang tanong ay lumitaw: bakit bukas ang mga proyekto sa lahat? Ang sagot ay nasa lugar ng pagiging posible sa komersyo; para sa isang tiyak na klase ng mga proyekto, ang mga benepisyo ng diskarteng ito ay mas malaki kaysa sa mga gastos. Iyon ay, hindi ito angkop para sa lahat ng mga proyekto at ang isang bukas na diskarte ay karaniwang katanggap-tanggap. Halimbawa, mahirap isipin ang pagbuo ng isang control system para sa isang planta ng kuryente o isang sasakyang panghimpapawid batay sa isang bukas na prinsipyo. Hindi, siyempre, ang mga naturang sistema ay dapat magsama ng mga module batay sa mga bukas na proyekto, dahil ito ay magbibigay ng isang bilang ng mga pakinabang. Ngunit ang isang tao ay dapat na responsable para sa huling produkto. Kahit na ang system ay ganap na nakabatay sa code ng mga bukas na proyekto, ang developer, na naka-package ang lahat sa isang system at gumawa ng mga partikular na build at setting, ay talagang isinasara ito. Maaaring available sa publiko ang code.
Marami ring benepisyo para sa mga system na ito mula sa paglikha o pag-aambag sa mga open source na proyekto. Gaya ng sinabi ko na, maaaring manatiling available sa publiko ang end system code. Bakit, dahil maliwanag na hindi malamang na sinuman ang magkakaroon ng parehong sasakyang panghimpapawid upang subukan ang system. Totoo ito, ngunit maaaring mayroong isang tao na gustong suriin ang ilang mga seksyon ng code, o, halimbawa, maaaring matuklasan ng isang tao na ang library na ginagamit ay hindi na-configure nang tama.
Ang isang mas malaking benepisyo ay lilitaw kung ang kumpanya ay naglalaan ng ilang pangunahing bahagi ng system sa isang hiwalay na proyekto. Halimbawa, isang library upang suportahan ang ilang uri ng data exchange protocol. Sa kasong ito, kahit na ang protocol ay partikular sa isang partikular na paksa, maaari mong ibahagi ang mga gastos sa pagpapanatili ng bahaging ito ng system sa ibang mga kumpanya mula sa lugar na ito. Bilang karagdagan, ang mga espesyalista na maaaring pag-aralan ang bahaging ito ng system sa pampublikong domain ay nangangailangan ng mas kaunting oras upang magamit ito nang epektibo. At sa wakas, ang paghihiwalay ng isang piraso sa isang independiyenteng entity na ginagamit ng mga third-party na developer ay nagbibigay-daan sa amin na gawing mas mahusay ang bahaging ito, dahil kailangan naming mag-alok ng mga epektibong API, gumawa ng dokumentasyon, at hindi ko man lang pinag-uusapan ang tungkol sa pagpapabuti ng saklaw ng pagsubok.
Ang isang kumpanya ay maaaring makatanggap ng mga komersyal na benepisyo nang hindi gumagawa ng mga open-source na proyekto; sapat na para sa mga espesyalista nito na lumahok sa mga third-party na proyekto na ginagamit sa kumpanya. Pagkatapos ng lahat, ang lahat ng mga benepisyo ay nananatili: mas alam ng mga empleyado ang proyekto, samakatuwid ginagamit nila ito nang mas epektibo, maaaring maimpluwensyahan ng kumpanya ang direksyon ng pag-unlad ng proyekto, at ang paggamit ng handa, na-debug na code ay malinaw na binabawasan ang mga gastos ng kumpanya.
Ang mga benepisyo ng paglikha ng mga proyektong opensource ay hindi nagtatapos doon. Kunin natin ang isang mahalagang bahagi ng negosyo bilang marketing. Para sa kanya, ito ay isang napakahusay na sandbox na nagbibigay-daan sa kanya upang epektibong suriin ang mga kinakailangan sa merkado.
At siyempre, hindi natin dapat kalimutan na ang isang opensource na proyekto ay isang epektibong paraan upang ideklara ang iyong sarili bilang carrier ng anumang espesyalisasyon. Sa ilang mga kaso, ito ang tanging paraan upang makapasok sa merkado. Halimbawa, nagsimula ang Embox bilang isang proyekto upang lumikha ng isang RTOS. Marahil ay hindi na kailangang ipaliwanag na mayroong maraming mga kakumpitensya. Kung wala ang paglikha ng isang komunidad, hindi kami magkakaroon ng sapat na mapagkukunan upang dalhin ang proyekto sa end user, iyon ay, para sa mga third-party na developer upang simulan ang paggamit ng proyekto.
Ang komunidad ay susi sa isang opensource na proyekto. Pinapayagan ka nitong makabuluhang bawasan ang mga gastos sa pamamahala ng proyekto, bumuo at suportahan ang proyekto. Masasabi natin na kung walang komunidad ay walang proyektong opensource.
Maraming materyal ang naisulat tungkol sa kung paano lumikha at mamahala ng isang open source na komunidad ng proyekto. Upang hindi na maisalaysay muli ang mga alam na katotohanan, susubukan kong tumuon sa karanasan ng Embox. Halimbawa, ang proseso ng paglikha ng isang komunidad ay isang napaka-interesante na isyu. Iyon ay, marami ang nagsasabi kung paano pamahalaan ang isang umiiral na komunidad, ngunit ang mga sandali ng paglikha nito ay minsan ay hindi pinapansin, kung isasaalang-alang na ito ay ibinigay.
Ang pangunahing panuntunan kapag lumilikha ng isang komunidad ng opensource na proyekto ay walang mga panuntunan. I mean walang universal rules, parang walang silver bullet, if only because the projects are very different. Ito ay malamang na hindi mo magagamit ang parehong mga patakaran kapag lumilikha ng isang komunidad para sa isang js logging library at ilang lubos na dalubhasang driver. Bukod dito, sa iba't ibang yugto ng pag-unlad ng proyekto (at samakatuwid ay ang komunidad), nagbabago ang mga patakaran.
Nagsimula ang Embox bilang isang proyekto ng mag-aaral dahil mayroon itong access sa mga mag-aaral mula sa departamento ng programming ng system. Sa katunayan, pumapasok kami sa ibang komunidad. Maaari naming interesante ang mga kalahok ng komunidad na ito, mga mag-aaral, sa mahusay na kasanayan sa industriya sa kanilang espesyalidad, gawaing siyentipiko sa larangan ng system programming, coursework at diploma. Ibig sabihin, sinunod namin ang isa sa mga pangunahing alituntunin ng pag-oorganisa ng isang komunidad: ang mga miyembro ng komunidad ay dapat tumanggap ng isang bagay, at ang presyong ito ay dapat na tumutugma sa kontribusyon ng kalahok.
Ang susunod na yugto para sa Embox ay ang paghahanap para sa mga user ng third-party. Napakahalagang maunawaan na ang mga user ay ganap na kalahok sa opensource na komunidad. Karaniwang mas maraming user kaysa sa mga developer. At upang nais na maging isang kontribyutor sa isang proyekto, sinimulan muna nilang gamitin ito sa isang paraan o iba pa.
Ang mga unang gumagamit ng Embox ay ang Department of Theoretical Cybernetics. Iminungkahi nila ang paglikha ng alternatibong firmware para sa Lego Mindstorm. At bagaman ang mga ito ay mga lokal na user pa rin (maaari naming makipagkita sa kanila nang personal at talakayin kung ano ang gusto nila). Ngunit ito ay isang napakagandang karanasan pa rin. Halimbawa, gumawa kami ng mga demo na maaaring ipakita sa iba, dahil ang mga robot ay masaya at nakakaakit ng pansin. Bilang resulta, nakakuha kami ng mga tunay na user ng third-party na nagsimulang magtanong kung ano ang Embox at kung paano ito gamitin.
Sa yugtong ito, kailangan naming mag-isip tungkol sa dokumentasyon, tungkol sa paraan ng komunikasyon sa mga gumagamit. Hindi, siyempre, naisip namin ang mga mahahalagang bagay na ito noon, ngunit ito ay napaaga at hindi nagbigay ng positibong epekto. Ang epekto ay medyo negatibo. Hayaan akong magbigay sa iyo ng ilang mga halimbawa. Gumamit kami ng googlecode, na sinuportahan ng wiki ang multilingualism. Gumawa kami ng mga pahina sa maraming wika, hindi lamang Ingles at Ruso, kung saan halos hindi kami makapag-usap, kundi pati na rin sa Aleman at Espanyol. Bilang resulta, mukhang napaka-katawa-tawa kapag tinanong sa mga wikang ito, ngunit hindi namin masagot ang lahat. O nagpakilala sila ng mga panuntunan tungkol sa pagsusulat ng dokumentasyon at pagkomento, ngunit dahil medyo madalas at malaki ang pagbabago ng API, lumalabas na ang aming dokumentasyon ay luma na at mas nakakapanlinlang kaysa nakatulong ito.
Bilang resulta, ang lahat ng aming mga pagsisikap, kahit na ang mga mali, ay humantong sa hitsura ng mga panlabas na gumagamit. At kahit isang komersyal na customer ay lumitaw na nais na ang kanyang sariling RTOS ay mabuo para sa kanya. At binuo namin ito dahil mayroon kaming karanasan at ilang batayan. Dito kailangan mong pag-usapan ang parehong magagandang sandali at ang masama. Magsisimula ako sa mga masama. Dahil maraming mga developer ang kasangkot sa proyektong ito sa isang komersyal na batayan, ang komunidad ay medyo hindi matatag at nahahati, na siyempre ay hindi makakaapekto sa pagbuo ng proyekto. Ang isang karagdagang kadahilanan ay ang direksyon ng proyekto ay itinakda ng isang komersyal na customer, at ang kanyang layunin ay hindi ang karagdagang pag-unlad ng proyekto. Hindi bababa sa hindi ito ang pangunahing layunin.
Sa kabilang banda, mayroong isang bilang ng mga positibong aspeto. Mayroon kaming tunay na mga third-party na user. Ito ay hindi lamang ang customer, kundi pati na rin ang para kanino ang sistemang ito ay inilaan. Nadagdagan ang motibasyon na lumahok sa proyekto. Pagkatapos ng lahat, kung maaari ka ring kumita ng pera mula sa isang kawili-wiling negosyo, ito ay palaging maganda. At ang pinakamahalaga, narinig namin ang isang pagnanais mula sa mga customer, na sa oras na iyon ay tila nabaliw sa amin, ngunit ngayon ang pangunahing ideya ng Embox, ibig sabihin, ang paggamit ng nabuo na code sa system. Ngayon ang pangunahing ideya ng Embox ay ang paggamit ng Linux software nang walang Linux. Iyon ay, ang pangunahing positibong aspeto na nag-aambag sa karagdagang pag-unlad ng proyekto ay ang pagsasakatuparan na ang proyekto ay ginagamit ng mga user ng third-party, at dapat nitong lutasin ang ilan sa kanilang mga problema.
Sa oras na iyon, ang Embox ay lumampas na sa saklaw ng isang proyekto ng mag-aaral. Ang pangunahing salik na naglilimita sa pagbuo ng proyekto ayon sa modelo ng mag-aaral ay ang pagganyak ng mga kalahok. Ang mga mag-aaral ay nakikilahok habang sila ay nag-aaral, at kapag sila ay nagtapos, dapat magkaroon ng ibang motibasyon. Kung ang pagganyak ay hindi lilitaw, ang mag-aaral ay hihinto lamang sa pakikilahok sa proyekto. Kung ating isasaalang-alang na ang mga mag-aaral ay kailangan munang sanayin, lumalabas na sila ay nagiging mahusay na mga espesyalista sa oras na sila ay nagtapos, ngunit ang kanilang kontribusyon sa proyekto, dahil sa kawalan ng karanasan, ay hindi masyadong malaki.
Sa pangkalahatan, maayos kaming lumipat sa pangunahing punto na nagpapahintulot sa amin na pag-usapan ang tungkol sa paglikha ng isang opensource na proyekto - ang paglikha ng isang produkto na malulutas ang mga problema ng mga gumagamit nito. Tulad ng ipinaliwanag ko sa itaas, ang pangunahing pag-aari ng isang opensource na proyekto ay ang komunidad nito. Bukod dito, ang mga miyembro ng komunidad ay pangunahing mga gumagamit. Ngunit saan sila nanggaling kung walang magagamit? Kaya lumalabas na, tulad ng sa isang hindi opensource na proyekto, kailangan mong tumuon sa paglikha ng isang MVP (minimum na mabubuhay na produkto), at kung interesado ito sa mga user, lilitaw ang isang komunidad sa paligid ng proyekto. Kung ikaw ay nakikibahagi sa paglikha ng isang komunidad sa pamamagitan lamang ng community PR, pagsusulat ng wiki sa lahat ng mga wika sa mundo, o tamang git workflow sa github, malamang na hindi ito mahalaga sa mga unang yugto ng proyekto. Siyempre, sa naaangkop na mga yugto ang mga ito ay hindi lamang mahalaga, kundi pati na rin ang mga kinakailangang bagay.
Sa konklusyon nais kong ituro , sa aking opinyon, na sumasalamin sa mga inaasahan ng user mula sa isang opensource na proyekto:
Seryoso akong nag-iisip tungkol sa paglipat sa OS na ito (at least subukan. Aktibo nilang hinahabol ito at gumagawa ng mga cool na bagay).
Naka-on ang PS Magkakaroon tayo ng hanggang tatlong ulat. Isa tungkol sa open source at dalawa tungkol sa naka-embed (at isa ay praktikal). Sa stand ay magsasagawa kami ng master class sa programming microcontrollers gamit . Gaya ng dati, dadalhin namin ang hardware at hahayaan kang mag-program nito. Magkakaroon din ng quest at iba pang aktibidad. Halika sa pagdiriwang at sa aming stand, ito ay magiging masaya.
Pinagmulan: www.habr.com