Një festival IT do të mbahet në Shën Petersburg këtë javë . Një nga folësit do të jetë Richard Stallman. merr pjesë edhe në festival, dhe natyrisht nuk mund të anashkalohej edhe tema e softuerit të lirë. Kjo është arsyeja pse një nga raportet tona quhet . Ai do t'i kushtohet historisë së zhvillimit të Embox si një projekt me kod të hapur. Në këtë artikull dua të flas për idetë kryesore që, për mendimin tim, ndikojnë në zhvillimin e projekteve me burim të hapur. Artikulli, ashtu si raporti, bazohet në përvojën personale.
Le të fillojmë me diçka të thjeshtë, me përkufizimin e termit opensource. Natyrisht, një projekt me burim të hapur është një projekt që ka një nga licencat që lejon aksesin në kodin burimor të projektit. Përveç kësaj, një projekt i hapur do të thotë që zhvilluesit e palëve të treta mund të bëjnë ndryshime. Kjo do të thotë, nëse një kompani ose zhvillues publikon kodin e produktit të saj, pjesërisht ose plotësisht, kjo nuk e bën ende këtë produkt një projekt me burim të hapur. Dhe së fundi, çdo aktivitet projekti duhet të çojë në një lloj rezultati, dhe hapja e projektit nënkupton që ky rezultat të përdoret jo vetëm nga vetë zhvilluesit.
Ne nuk do të prekim problemet e licencave të hapura. Kjo është një temë shumë e madhe dhe komplekse që kërkon hetim të thelluar. Për këtë temë janë shkruar mjaft artikuj dhe materiale të mira. Por duke qenë se unë vetë nuk jam ekspert në fushën e të drejtave të autorit, do të them vetëm se licenca duhet të përmbushë qëllimet e projektit. Për shembull, për Embox zgjedhja e një BSD në vend të një licence GPL nuk ishte e rastësishme.
Fakti që një projekt me kod të hapur duhet të ofrojë aftësinë për të bërë ndryshime dhe për të ndikuar në zhvillimin e projektit me burim të hapur nënkupton që projekti është i shpërndarë. Menaxhimi i tij, ruajtja e integritetit dhe performancës është shumë më e vështirë në krahasim me një projekt me menaxhim të centralizuar. Lind një pyetje e arsyeshme: pse hapen fare projektet? Përgjigja qëndron në fushën e fizibilitetit komercial; për një klasë të caktuar projektesh, përfitimet e kësaj qasjeje tejkalojnë kostot. Kjo do të thotë, nuk është i përshtatshëm për të gjitha projektet dhe një qasje e hapur është përgjithësisht e pranueshme. Për shembull, është e vështirë të imagjinohet zhvillimi i një sistemi kontrolli për një termocentral ose një avion bazuar në një parim të hapur. Jo, sigurisht, sisteme të tilla duhet të përfshijnë module të bazuara në projekte të hapura, sepse kjo do të sigurojë një sërë avantazhesh. Por dikush duhet të jetë përgjegjës për produktin përfundimtar. Edhe nëse sistemi bazohet plotësisht në kodin e projekteve të hapura, zhvilluesi, pasi ka paketuar gjithçka në një sistem dhe ka bërë ndërtime dhe cilësime specifike, në thelb e mbyll atë. Kodi mund të jetë i disponueshëm publikisht.
Ka gjithashtu shumë përfitime për këto sisteme nga krijimi ose kontributi në projekte me burim të hapur. Siç thashë tashmë, kodi i sistemit përfundimtar mund të mbetet i disponueshëm publikisht. Pse, sepse është e qartë se nuk ka gjasa që dikush të ketë të njëjtin avion për të testuar sistemin. Kjo është e vërtetë, por mund të ketë dikush që dëshiron të kontrollojë disa seksione të kodit, ose, për shembull, dikush mund të zbulojë se biblioteka që përdoret nuk është konfiguruar mjaft saktë.
Një përfitim edhe më i madh shfaqet nëse kompania alokon një pjesë bazë të sistemit në një projekt të veçantë. Për shembull, një bibliotekë për të mbështetur një lloj protokolli të shkëmbimit të të dhënave. Në këtë rast, edhe nëse protokolli është specifik për një fushë të caktuar lëndore, ju mund të ndani kostot e mirëmbajtjes së kësaj pjese të sistemit me kompani të tjera nga kjo fushë. Përveç kësaj, specialistët që mund ta studiojnë këtë pjesë të sistemit në domenin publik kërkojnë shumë më pak kohë për ta përdorur atë në mënyrë efektive. Dhe së fundi, ndarja e një pjese në një entitet të pavarur që përdorin zhvilluesit e palëve të treta na lejon ta përmirësojmë këtë pjesë, sepse ne duhet të ofrojmë API efektive, të krijojmë dokumentacion dhe nuk po flas as për përmirësimin e mbulimit të testeve.
Një kompani mund të marrë përfitime tregtare pa krijuar projekte me burim të hapur; mjafton që specialistët e saj të marrin pjesë në projekte të palëve të treta të përdorura në kompani. Në fund të fundit, të gjitha përfitimet mbeten: punonjësit e njohin më mirë projektin, prandaj e përdorin atë në mënyrë më efektive, kompania mund të ndikojë në drejtimin e zhvillimit të projektit, dhe përdorimi i kodit të gatshëm, të korrigjuar padyshim zvogëlon kostot e kompanisë.
Përfitimet e krijimit të projekteve me burim të hapur nuk mbarojnë këtu. Le të marrim një komponent kaq të rëndësishëm të biznesit si marketingu. Për të, kjo është një sandbox shumë i mirë që i lejon atij të vlerësojë në mënyrë efektive kërkesat e tregut.
Dhe sigurisht, nuk duhet të harrojmë se një projekt me burim të hapur është një mënyrë efektive për të deklaruar veten si bartës të çdo specializimi. Në disa raste, kjo është mënyra e vetme për të hyrë në treg. Për shembull, Embox filloi si një projekt për të krijuar një RTOS. Ndoshta nuk ka nevojë të shpjegohet se ka shumë konkurrentë. Pa krijuar një komunitet, ne thjesht nuk do të kishim burime të mjaftueshme për ta sjellë projektin te përdoruesi përfundimtar, domethënë që zhvilluesit e palëve të treta të fillonin ta përdorin projektin.
Komuniteti është kyç në një projekt me burim të hapur. Kjo ju lejon të reduktoni ndjeshëm kostot e menaxhimit të projektit, të zhvilloni dhe mbështesni projektin. Mund të themi se pa një komunitet nuk ka fare projekt opensource.
Shumë materiale janë shkruar për mënyrën e krijimit dhe menaxhimit të një komuniteti projekti me burim të hapur. Për të mos ritreguar fakte tashmë të njohura, do të përpiqem të përqendrohem në përvojën e Embox. Për shembull, procesi i krijimit të një komuniteti është një çështje shumë interesante. Kjo do të thotë, shumë thonë se si të menaxhohet një komunitet ekzistues, por momentet e krijimit të tij ndonjëherë anashkalohen, duke e konsideruar këtë si të dhënë.
Rregulli kryesor kur krijoni një komunitet të projektit me burim të hapur është se nuk ka rregulla. Dua të them që nuk ka rregulla universale, ashtu si nuk ka asnjë plumb argjendi, qoftë edhe sepse projektet janë shumë të ndryshme. Nuk ka gjasa që të mund të përdorni të njëjtat rregulla kur krijoni një komunitet për një bibliotekë js logging dhe ndonjë drejtues shumë të specializuar. Për më tepër, në faza të ndryshme të zhvillimit të projektit (dhe për rrjedhojë të komunitetit), rregullat ndryshojnë.
Embox filloi si një projekt studentor sepse kishte akses për studentët nga departamenti i programimit të sistemeve. Në fakt, ne po hynim në një komunitet tjetër. Ne mund të interesonim pjesëmarrësit e këtij komuniteti, studentë, për praktikën e mirë industriale në specialitetin e tyre, punën shkencore në fushën e programimit të sistemit, lëndëve dhe diplomave. Kjo do të thotë, ne kemi ndjekur një nga rregullat themelore të organizimit të një komuniteti: anëtarët e komunitetit duhet të marrin diçka dhe ky çmim duhet të korrespondojë me kontributin e pjesëmarrësit.
Faza tjetër për Embox ishte kërkimi i përdoruesve të palëve të treta. Është shumë e rëndësishme të kuptohet se përdoruesit janë pjesëmarrës të plotë në komunitetin me burim të hapur. Zakonisht ka më shumë përdorues sesa zhvillues. Dhe në mënyrë që të duan të bëhen kontribues në një projekt, ata fillimisht fillojnë ta përdorin atë në një mënyrë ose në një tjetër.
Përdoruesit e parë të Embox ishin Departamenti i Kibernetikës Teorike. Ata sugjeruan krijimin e një firmueri alternativ për Lego Mindstorm. Dhe megjithëse këta ishin ende përdorues lokalë (ne mund të takoheshim personalisht me ta dhe të diskutonim atë që dëshironin). Por gjithsesi ishte një përvojë shumë e mirë. Për shembull, ne zhvilluam demonstrime që mund t'u shfaqen të tjerëve, sepse robotët janë argëtues dhe tërheqin vëmendjen. Si rezultat, morëm përdorues të vërtetë të palëve të treta që filluan të pyesin se çfarë është Embox dhe si ta përdorin atë.
Në këtë fazë duhej të mendonim për dokumentacionin, për mjetet e komunikimit me përdoruesit. Jo, sigurisht, i kemi menduar më parë këto gjëra të rëndësishme, por ka qenë e parakohshme dhe nuk ka dhënë efekt pozitiv. Efekti ishte mjaft negativ. Më lejoni t'ju jap disa shembuj. Ne përdorëm googlecode, wiki i të cilit mbështeti shumëgjuhësinë. Kemi krijuar faqe në disa gjuhë, jo vetëm anglisht dhe rusisht, në të cilat mezi komunikonim, por edhe gjermanisht dhe spanjisht. Si rezultat, duket shumë qesharake kur pyetet në këto gjuhë, por ne nuk mund të përgjigjemi fare. Ose ata futën rregulla për shkrimin e dokumentacionit dhe komentimin, por meqenëse API ndryshonte mjaft shpesh dhe në mënyrë të konsiderueshme, doli që dokumentacioni ynë ishte i vjetëruar dhe ishte më mashtrues sesa ndihmoi.
Si rezultat, të gjitha përpjekjet tona, madje edhe ato të gabuara, çuan në shfaqjen e përdoruesve të jashtëm. Dhe madje u shfaq një klient komercial i cili donte që RTOS-i i tij të zhvillohej për të. Dhe e kemi zhvilluar sepse kemi përvojë dhe disa baza. Këtu duhet të flisni si për momentet e mira ashtu edhe për ato të këqija. Do të filloj me të këqijat. Meqenëse shumë zhvillues u përfshinë në këtë projekt mbi baza komerciale, komuniteti tashmë ishte mjaft i paqëndrueshëm dhe i ndarë, gjë që natyrisht nuk mund të mos ndikonte në zhvillimin e projektit. Një faktor shtesë ishte se drejtimi i projektit ishte vendosur nga një klient komercial dhe qëllimi i tij nuk ishte zhvillimi i mëtejshëm i projektit. Të paktën ky nuk ishte qëllimi kryesor.
Nga ana tjetër, kishte një sërë aspektesh pozitive. Kemi përdorues vërtet të palëve të treta. Nuk ishte vetëm klienti, por edhe ata për të cilët ishte menduar ky sistem. Motivimi për të marrë pjesë në projekt është rritur. Në fund të fundit, nëse mund të fitoni para edhe nga një biznes interesant, është gjithmonë mirë. Dhe më e rëndësishmja, ne dëgjuam një dëshirë nga klientët, e cila në atë kohë na dukej e çmendur, por që tani është ideja kryesore e Embox, domethënë, përdorimi i kodit të zhvilluar tashmë në sistem. Tani ideja kryesore e Embox është përdorimi i softuerit Linux pa Linux. Kjo do të thotë, aspekti kryesor pozitiv që kontribuoi në zhvillimin e mëtejshëm të projektit ishte realizimi se projekti përdoret nga përdoruesit e palëve të treta, dhe ai duhet të zgjidhë disa nga problemet e tyre.
Në atë kohë, Embox kishte shkuar përtej qëllimit të një projekti studentor. Faktori kryesor kufizues në zhvillimin e projektit sipas modelit të studentit është motivimi i pjesëmarrësve. Studentët marrin pjesë gjatë kohës që studiojnë dhe kur diplomohen, duhet të ketë një motivim tjetër. Nëse motivimi nuk shfaqet, studenti thjesht ndalon pjesëmarrjen në projekt. Po të kemi parasysh që studentët fillimisht duhet të trajnohen, rezulton se ata bëhen specialistë të mirë në momentin që diplomohen, por kontributi i tyre në projekt, për shkak të mungesës së përvojës, nuk është shumë i madh.
Në përgjithësi, ne kalojmë pa probleme në pikën kryesore që na lejon të flasim për krijimin e një projekti me burim të hapur - krijimin e një produkti që do të zgjidhte problemet e përdoruesve të tij. Siç e shpjegova më lart, vetia kryesore e një projekti me burim të hapur është komuniteti i tij. Për më tepër, anëtarët e komunitetit janë kryesisht përdorues. Por nga vijnë ato kur nuk ka asgjë për t'u përdorur? Pra, rezulton se, ashtu si me një projekt pa burim të hapur, ju duhet të përqendroheni në krijimin e një MVP (produkti minimal i zbatueshëm), dhe nëse ai intereson përdoruesit, atëherë një komunitet do të shfaqet rreth projektit. Nëse jeni të angazhuar në krijimin e një komuniteti vetëm përmes PR të komunitetit, duke shkruar një wiki në të gjitha gjuhët e botës ose rrjedhën e saktë të punës git në github, atëherë kjo nuk ka gjasa të ketë rëndësi në fazat e hershme të projektit. Sigurisht, në fazat e duhura këto nuk janë vetëm gjëra të rëndësishme, por edhe të nevojshme.
Si përfundim do të doja të theksoja , për mendimin tim, duke reflektuar pritjet e përdoruesve nga një projekt me burim të hapur:
Unë jam duke menduar seriozisht për kalimin në këtë OS (të paktën provoni. Ata po e ndjekin në mënyrë aktive dhe po bëjnë gjëra fantastike).
PS Aktivizohet Do të kemi deri në tre raporte. Një për burim të hapur dhe dy për të integruar (dhe një është praktik). Në stendë do të zhvillojmë një klasë master mbi programimin e mikrokontrolluesve duke përdorur . Si zakonisht, ne do të sjellim harduerin dhe do t'ju lejojmë ta programoni atë. Do të ketë gjithashtu një kërkim dhe aktivitete të tjera. Ejani në festival dhe në stendën tonë, do të jetë argëtuese.
Burimi: www.habr.com