Këtë javë do të zhvillohet një festival IT në Shën Petersburg. . Një nga folësit do të jetë Richard Stallman. po ashtu do të marrë pjesë në festival, dhe natyrisht që nuk mund të kalojmë përpara temës të Softuerit me Kod të Hapshëm. Prandaj, një nga leksionet tona quhet . Ai do të jetë i dedikuar historisë së zhvillimit të Embox si një projekt me kod të hapur. Në këtë artikull dua të flas për idetë kryesore që, sipas mendimit tim, ndikojnë në zhvillimin e projekteve opensource. Artikulli, ashtu si dhe leksioni, është i bazuar në përvojën personale.
Le të fillojmë me të thjeshtën, me përcaktimin e termit opensource. Qartë është se një projekt me kod të hapur është një projekt që ka një nga licencat që lejojnë qasjen në kodin burimor të projektit. Për më tepër, një projekt i hapur nënkupton mundësinë e bërë ndryshimesh nga zhvillues të tjerë. Pra, nëse një kompani ose zhvillues publikojnë kodin e produktit të tyre, pjesërisht ose në mënyrë të plotë, kjo nuk e bën automatikisht atë produkt një projekt opensource. Dhe së fundmi, çdo veprimtari projektuale duhet të çojë në aparitjen e një rezultati, dhe hapësira e projektit nënkupton që ky rezultat të përdoret jo vetëm nga vetë zhvilluesit.
Nuk do të prekemi nga problemet e licencave të hapura. Kjo është një temë shumë e madhe dhe e nd komplikuar që kërkon një shqyrtim të thellë. Është shkruar shumë për këtë temë në artikuj dhe materiale të mira. Por për shkak se unë vetë nuk jam specialist në fushën e të drejtës së autorit, do të them vetëm se licenca duhet të përmbushë qëllimet e projektit. Për shembull, për Embox, zgjedhja e licencës BSD, në vend të GPL, nuk ishte rastësi.
Fakti që një projekt i hapur duhet të ofrojë mundësinë për të bërë ndryshime dhe të ndikojë në zhvillimin e projektit të hapur, nënkupton se projekti është i shpërndarë. Të menaxhosh atë, të ruash integritetin dhe funksionalitetin është shumë më e vështirë krahasuar me një projekt që ka menaxhim qendror. Lind një pyetje e arsyeshme: përse të bësh projekte të hapura në radhë të parë? Përgjigjja është në fushën e arsyeshmërisë komerciale; për një klasë të caktuar projektesh, përfitimi nga ky qasje e tejkalon kostot. Kështu, nuk për të gjitha projektet ky qasje është e përshtatshme dhe e pranueshme. Për shembull, është e vështirë të imagjinosh zhvillimin e një sistemi menaxhimi për një central elektrik ose një aeroplan, bazuar në një princip të hapur. Jo, natyrisht, është e rëndësishme të përfshihen module bazuar në projekte të hapura, sepse kjo do të sjellë një sërë përfitimesh. Por për produktin përfundimtar duhet të ketë dikush që merr përgjegjësinë. Edhe nëse sistemi është krejtësisht i bazuar në kodin e projekteve të hapura, zhvilluesi, duke e paketuar gjithçka në një sistem dhe duke bërë ndarje dhe konfigurations të caktuara, në thelb e mbyll atë. Kodi në këtë rast mund të jetë në qasje publike.
Për këto sisteme gjithashtu ka shumë përfitime nga krijimi i projekteve të hapura ose pjesëmarrja në to. Siç e thashë, kodi i sistemit përfundimtar mund të mbetet në qasje publike. Pse, sepse është e qartë se e vështirë se dikush ka një aeroplan të tillë për të testuar sistemin. Kjo është e vërtetë, por mund të ndodhë që ndonjë dëshiron të verifikoje pjesë të ndryshme të kodit, ose për shembull, ndokush mund të zbulojë se biblioteka që po përdoret nuk është e konfiguruar krejtësisht siç duhet.
Një përfitim edhe më i madh shfaqet kur një kompani ndan një pjesë themelore të sistemit në një projekt të veçantë. Për shembull, një bibliotekë për të mbështetur ndonjë protokoll për shkëmbim të të dhënave. Në këtë rast, edhe nëse protokolli është specifik për këtë fushë, mund të ndahen kostot për mbështetje të këtij segmenti me kompani të tjera në këtë fushë. Për më tepër, specialistët që mund të studiojnë këtë segment të sistemit në qasje publike, kanë nevojë për shumë më pak kohë për ta përdorur atë me efikasitet. Dhe përfundimisht, ndarja e një segmenti në një entitet të pavarur, që përdoret nga zhvillues të tjerë, lejon që kjo pjesë të bëhet më cilësore, sepse duhet të ofrohet API efikas, të bëhet dokumentacion, madje as nuk po flas për përmirësimin e mbulimit të testeve.
Përfitimin komercial një kompani mund ta marrë edhe pa krijuar projekte të hapura; është e mjaftueshme që specialistët e saj të marrin pjesë në projekte të tjera, që përdoren brenda kompanisë. Sepse të gjitha përfitimet mbeten: punonjësit e njohin më mirë projektin, kështu që e përdorin atë më efektivisht, kompania mund të ndikojë në drejtimin e zhvillimit të projektit, dhe përvetësimi i kodit të gatshëm të përfunduar, padyshim që e ul kostot e kompanisë.
Përfitimet nga krijimi i projekteve opensource nuk përfundojnë këtu. Të marrim si shembull një komponent të rëndësishëm të biznesit siç është marketingu. Për të, kjo është një arenë shumë e mirë që lejon të vlerësojmë kërkesat e tregut në mënyrë efektive.
Dhe natyrisht, nuk duhet harruar se projekti opensource është një mënyrë efektive për të shpallur veten si një mbajtës i një specializimi. Në disa raste, kjo është ndoshta e vetmja mënyrë për t'u futur në treg. Për shembull, Embox filloi si një projekt për krijimin e OSRV. Ndoshta nuk ka nevojë të shpjegoj se ka shumë konkurrentë. Pa krijimin e një komuniteti, thjesht nuk do të kishim burimet për ta çuar projektin te përdoruesit përfundimtarë, që do të thotë që projekti të përdorej nga zhvillues të jashtëm.
Komuniteti është çelësi në një projekt opensource. Ai lejon të reduktojë ndjeshëm kostot e menaxhimit të projektit, zhvillon dhe mbështet projektin. Mund të thuhet se pa komunitet nuk ka as një projekt opensource.
Ka shumë materiale për mënyrën se si të krijoni dhe menaxhoni një komunitet për një projekt me kod të hapur. Unë, që të mos përsëris fakte tashmë të njohura, do të mundohem të theksoj përvojën e Embox. Për shembull, një çështje shumë interesante është processi i krijimit të një komuniteti. Shumë flasin për menaxhimin e një komuniteti ekzistues, por ndonjëherë harrojnë momentet e krijimit të tij, duke e marrë këtë si një të dhënë.
Rregulli kryesor gjatë krijimit të një komuniteti për një projekt opensource është se nuk ka asnjë rregull. Dua të them, nuk ekzistojnë rregulla universale, ashtu siç nuk ka një plumb të argjendtë, për shkak se projektet janë shumë të ndryshme. Padyshim, është e vështirë të përdoren të njëjtat rregulla për të krijuar një komunitet për një bibliotekë logimi në js dhe për një drejtues të specializuar. Për më tepër, në faza të ndryshme të zhvillimit të projektit (dhe për pasojë të komunitetit), rregullat ndryshojnë.
Embox filloi si një projekt studentor, sepse kishte qasje te studentët e katedrës së programimit sistemik. Në thelb, ne hynim në një komunitet tjetër. Anëtarët e këtij shteti, studentët, ne mund të ishim të interesuar për praktikën e mirë industriale në fushën e tyre, punimet shkencore në fushën e programimit sistemik, projektet e kursit dhe diplomave. Kështu, ne përmbushnim një nga rregullat kryesore për organizimin e një komuniteti, anëtarët e komunitetit duhet të marrin diçka, dhe kjo çmim duhet të korrespondonte me kontributin e anëtarit.
Faza tjetër për Embox ishte kërkimi i përdoruesve të jashtëm. Është shumë e rëndësishme të kuptoni se përdoruesit janë pjesëmarrës të plota në komunitetin opensource. Përdoruesit zakonisht janë më të shumtë se zhvilluesit. Dhe që të duan të bëhen kontribues të projektit, fillimisht ata duhet ta përdorin atë siç duan.
Përdoruesit e parë për Embox ishin katedra e Kibernetikës Teorike. Ata propozuan krijimin e një firmware alternative për Lego Mindstorm. Dhe megjithëse ata ishin akoma përdorues lokalë (ne mund të takoheshim me ta dhe të diskutojmë se çfarë donin). Megjithatë, kjo ishte një përvojë shumë e mirë. Për shembull, ne zhvilluam demo që mund të shiheshin nga të tjerët, sepse robotët janë të këndshëm dhe tërheqin vëmendjen. Në fund, ne kishim vërtet përdorues të jashtëm që filluan të pyesnin se çfarë ishte Embox dhe si mund ta përdornin atë.
Në këtë fazë, na duhej të mendojmë për dokumentacionin, për mjetet e komunikimit me përdoruesit. Natyrisht, ne kishim menduar për këto gjëra të rëndësishme para kësaj, por ishte tepër herët dhe nuk kishte një efekt pozitiv. E efektit ishte më shumë negativ. Të jap një ose dy shembuj. Ne përdornim googlecode, wiki e së cilës mbështeste shumëgjuhësinë. Ne krijuam faqe në disa gjuhë, përfshirë anglishten dhe rusishten, me të cilat mund të komunikonim me vështirësi, por gjithashtu gjermanishten dhe spanjishten. Si rezultat, dukej shumë absurd kur pyesnin në këto gjuhë dhe ne nuk mund të përgjigjeshim. Ose vendosëm rregulla për shkrimin e dokumentacionit dhe komenteve, por pasi API ndryshonte mjaft shpesh dhe në mënyrë të rëndësishme, rezultatet ishin që dokumentacioni ynë bëhej i vjetër dhe më shumë përgatiste konfuzion sesa ndihmonte.
Si përfundim, të gjitha përpjekjet tona, madje edhe ato të gabuara, çuan në shfaqjen e përdoruesve të jashtëm. Madje u shfaq edhe një klient komercial që dëshironte që ne të zhvillonim një OSRV për të. Dhe ne e zhvilluam, pasi kishim përvojë dhe disa zhvillime. Këtu duhet të flasim si për momentet pozitive, ashtu edhe për ato negative. Do të filloj me të këqijat. Meqë shumë zhvillues u angazhuan në këtë projekt në mënyrë komerciale, komuniteti u bë mjaft i paqëndrueshëm dhe u ndanë, çka natyrisht ndikoi në zhvillimin e projektit. Një faktor shtesë ishte fakti se drejtimi i projektit ishte përcaktuar nga një klient komercial, i cili qëllimin e tij nuk e kishte zhvillimin e mëtejshëm të projektit. Të paktën kjo qëllim nuk ishte kryesorja.
Nga ana tjetër, kishte disa momente pozitive. Ne morëm përdorues të vërtetë të jashtëm. Kjo ishte jo vetëm klienti, por edhe ata për të cilët ishte e destinuar kjo sistem. Motivimi për të marrë pjesë në projekt u rrit. Sepse nëse mund të fitosh para nga një punë interesante, është gjithmonë e këndshme. Dhe më e rëndësishmja, ne dëgjuam një dëshirë nga klientët që në atë kohë dukej si një ide e çmendur, por që tani është ideja kryesore e Embox, dmth, të përdorim kodin e zhvilluar tashmë në sistem. Tani ideja kryesore e Embox është përdorimi i softuerit Linux pa Linux. Domethënë, momenti kryesor pozitiv që ndihmoi në zhvillimin e mëtejshëm të projektit ishte kuptimi se projekti po përdoret nga përdorues të jashtëm dhe se ai duhet të zgjidhë disa nga problemet e tyre.
Në atë kohë, Embox kishte dalë përtej kornizave të një projekti studentor. Faktori kryesor që pengonte zhvillimin e projektit sipas modelit studentor ishte motivimi i pjesëmarrësve. Studentët marrin pjesë përsa kohë studiojnë, dhe kur ata diplomojnë, duhet të shfaqet një motivim tjetër. Nëse motivimi nuk shfaqet, studenti thjesht ndalon së marrë pjesë në projekt. Nëse marrim parasysh se studentët fillimisht duhen mësuar, rezulton se ata bëhen specialistë të mirë në momentin e diplomimit, por kontributi në projekt, për shkak të papërvojës, nuk është shumë i madh.
Në përgjithësi, ne kalojmë ngadalë në momentin kryesor që na lejon të flasim për krijimin e një projekti opensource, — krijimin e një produkti që do t'i zgjidhte problemet përdoruesve të tij. Siç e shpjegova më lart, karakteristika kryesore e një projekti opensource është komuniteti i tij. Pjesëmarrësit e komunitetit janë para së gjithash përdoruesit. Por nga do të vijë kjo, derisa nuk ka asgjë për të përdorur? Kështu që ndodh, se si me një projekt jo opensource, duhet të përqendrohemi në krijimin e një MVP (produkti minimalisht funksional), dhe nëse ai intereson përdoruesit, atëherë rreth projektit do të shfaqet një komunitet. Nëse merret me krijimin e komunitetit vetëm përmes PR-së, shkrimit të wiki në të gjitha gjuhët e botës, ose një git workflow të saktë në github, atëherë është e vështirë të ketë ndikim në fazat e hershme të projektit. Sigurisht, në fazat përkatëse, këto janë jo vetëm të rëndësishme, por edhe të nevojshme.
Në përfundim, dua të përmend , sipas mendimit tim, një reflektim të pritshmërive të përdoruesit nga një projekt opensource:
Mendoj seriozisht të kaloj në këtë OS (të paktën, ta provoj. Po e zhvillojnë me shumë intensitet dhe bëjnë gjëra të shkëlqyera).
P. S. Në do të kemi tre referate. Një për open source dhe dy për embedded (madje një praktik). Në stand do të organizojmë një master klas për programimin e mikro kontrollorëve me ndihmën e . Tradicionalisht do të sjellim pajisje dhe do t'i japim atyre të programohen. Do ketë gjithashtu një kërkesë dhe aktivitete të tjera. Ejani në festival dhe në standin tonë, do të jetë argëtuese.
Burimi: habr.com
