Këtë javë do të zhvillohet një festival IT në Shën Petersburg . Një nga folësit do të jetë Richard Stallman. edhe ai merr pjesë në festival, dhe sigurisht që nuk mund të lëmë pa përmendur temën e softuerit me burim të hapur. Prandaj, një nga referatet tona quhet . Ky referat do t'i kushtohet historisë së zhvillimit të Embox si një projekt me kod të hapur. Në këtë artikull, do të doja të flas për idetë kryesore që, sipas mendimit tim, ndikojnë në zhvillimin e projekteve opensource. Artikulli, ashtu si referati, bazohet në eksperiencën time personale.
Le të fillojmë me të thjeshtën, me definimin e termit opensource. Është e qartë që një projekt me kod të hapur është një projekt që ka një nga licencat që lejon aksesin në kodin burimor të projektit. Për më tepër, një projekt i hapur nënkupton mundësinë e bërit ndryshime nga zhvillues të tjerë. Pra, nëse ndonjë kompani ose zhvillues publikojnë kodin e produktit të tyre, pjesërisht ose plotësisht, kjo nuk e bën automatikisht atë produkt një projekt opensource. Dhe në fund, çdo aktivitet projekt duhet të çojë në krijimin e një rezultati, dhe hapësira e projektit nënkupton që ky rezultat të përdoret jo vetëm nga zhvilluesit vetë.
Nuk do të prekim problemet e licencave të hapura. Kjo është një temë shumë e madhe dhe e komplikuar që kërkon një hetim të thellë. Për këtë temë janë shkruar shumë artikuj dhe materiale të mira. Por, duke qenë 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ërputhet me qëllimet e projektit. Për shembull, për Embox zgjedhja e licencës BSD, dhe jo GPL, nuk ishte rastësi.
Fakti që një projekt i hapur duhet të ofrojë mundësinë për të bërë ndryshime dhe për të ndikuar në zhvillimin e projektit të hapur, nënkupton që projekti është i shpërndarë. Të menaxhosh atë, të ruash integritetin dhe funksionalitetin është shumë më e vështirë në krahasim me një projekt që ka menaxhim të centralizuar. Lind një pyetje e arsyeshme: përse duhet të bëjnë projekte të hapura? Pjesa e përgjigjes është në fushën e arsyeshmërisë ekonomike; për një klasë të caktuar projektesh, përfitimi nga ky qasje tejkalon shpenzimet. Pra, jo të gjitha projektet janë të përshtatshme dhe nuk është gjithashtu e pranueshme të aderohet tek qasja e hapur. Për shembull, është e vështirë të imagjinohet zhvillimi i një sistemi menaxhimi për një central elektrik ose një aeroplan, të bazuar në parimin e hapur. Ndoshta, për në këto sisteme duhet të përfshihen module të bazuara në projekte të hapura, pasi kjo do të ofronte një sërë përfitimesh. Por dikush duhet të marrë përgjegjësinë për produktin përfundimtar. Edhe nëse sistemi është plotësisht i bazuar në kodin e projekteve të hapura, zhvilluesi, duke ambalazhuar gjithçka në një sistem dhe duke bërë ndërlikime dhe konfigurime të caktuara, në thelb e mbyll atë. Kodi në këtë rast mund të jetë në dispozitë publike.
Për këto sisteme ka po ashtu 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ë dispozitë publike. Pse, kur është e qartë se vështirë se ndokush do të ketë një aeroplan të ngjashëm për të testuar sistemin. Kjo është e vërtetë, por mund të dalë dikush që dëshiron të kontrollojë ecuritë e caktuara të kodit, apo ndoshta, dikush mund të zbulojë se biblioteka e përdorur nuk është konfiguruar krejtësisht saktë.
Një përfitim edhe më i madh paraqitet nëse kompania dedikon një pjesë të caktuar themelore të sistemit në një projekt të veçantë. Për shembull, një bibliotekë për mbështetje të një protokolli të caktuar të shkëmbimit të të dhënave. Në këtë rast, edhe nëse protokolli është specifik për këtë fushë, mund të ndahen shpenzimet për mbështetje të këtij elementi të sistemit me kompani të tjera nga kjo fushë. Përveç kësaj, specialistët që mund të studiojnë këtë pjesë të sistemit në mënyrë të hapur, kërkojnë shumë më pak kohë për ta përdorur atë në mënyrë efikase. Dhe së fundmi, ndarja e një pjese në një entitet të pavarur, të cilin e përdorin zhvilluesit e jashtëm, lejon që kjo pjesë të bëhet më e cilësisë, pasi duhet të ofrohen API efikas, të bëhet dokumentacioni, dhe nuk po flas për përmirësimin e mbulimit të testeve.
Kompania mund të përfitojë ekonomikisht edhe pa krijuar projekte të hapura, mjafton që specialistët e saj të marrin pjesë në projekte të jashtme, që aplikuar në kompaninë e saj. Të gjitha përfitimet mbeten: punonjësit njohin më mirë projektin, prandaj e përdorin atë më efektivisht, kompania mund të ndikojë në drejtimin e zhvillimit të projektit, dhe përdorimi i kodit të gatshëm dhe të testuar, sigurisht, redukton shpenzimet e kompanisë.
Edhe këtu përfitimet nga krijimi i projekteve opensource nuk mbarojnë. Të marrim pjesën më të rëndësishme të biznesit siç është marketingu. Kjo është një sandbox shumë e mirë që lejon të vlerësohet në mënyrë efikase kërkesa e tregut.
Dhe natyrisht, nuk duhet harruar se një projekt opensource është një mënyrë efektive për të shpallur veten si mbajtës të një specializimi të caktuar. Në disa raste, kjo është e vetmja rrugë për t'u prezantuar në treg. Për shembull, Embox filloi si një projekt për krijimin e OSRV. Ndoshta nuk është e nevojshme të shpjegohet se ekzistojnë shumë konkurrentë. Pa krijimin e një komuniteti, thjesht nuk do të kishim burime të mjaftueshme për të çuar projektin te përdoruesi përfundimtar, pra, që projekti të përdorej nga zhvillues të jashtëm.
Komuniteti është thelbësor në një projekt opensource. Ai lejon ndjeshëm që të reduktohen shpenzimet për menaxhimin e projektit, për të zhvilluar dhe mbështetur projektin. Mund të thuhet se pa komunitet, në të vërtetë nuk ka projekt opensource.
Ka shumë materiale të shkruara për mënyrën se si të krijoni dhe menaxhoni një komunitet për një projekt me kod të hapur. Unë, për të mos përsëritur fakte tashmë të njohura, do të përqendrohem në përvojën e Embox. Për shembull, një çështje mjaft interesante është procesi i krijimit të komunitetit. Domethënë, shumë flasin për menaxhimin e një komuniteti ekzistues, por momentet e krijimit të tij shpesh kalojnë pa u vënë re, duke e konsideruar këtë si një të dhënë.
Rregulli kryesor gjatë krijimit të një komuniteti për një projekt opensource është se nuk ka rregulla të përshtatshme. Kam parasysh që nuk ekzistojnë rregulla universale, ashtu siç nuk ka një plumb të argjendtë, ndoshta për shkak se projektet janë shumë të ndryshme. Ë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 ndonjë driver 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, pasi patëm qasje te studentët e departamentit të programimit sistemor. Në thelb, ne hyjmë në një komunitet tjetër. Anëtarët e këtij komuniteti, studentët, mund të ishin të interesuar për praktikën e mirë industriale në specialitetin e tyre, punimet shkencore në fushën e programimit sistemor, punimet e kursit dhe diplomën. Domethënë, ne përmbushëm një nga rregullat kryesore të organizimit të një komuniteti, anëtarët e komunitetit duhet të marrin diçka, dhe ky çmim duhet të korrespondojë 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ë kuptohet se përdoruesit janë pjesëmarrës të plotë në komunitetin opensource. Përdoruesit zakonisht janë më të shumtë se zhvilluesit. Dhe që të dëshirojnë të bëhen kontributorë të projektit, së pari ata e fillojnë atë në një farë mënyre në përdorim.
Përdoruesit e parë të Embox ishin Departamenti i Kibernetikës Teorike. Ata propozuan krijimin e një sistemi alternativ për Lego Mindstorm. Edhe pse ata ishin ende përdorues lokalë (ne mund të takoheshim personalisht me ta dhe të diskutojmë se çfarë dëshironin), kjo ishte një eksperiencë shumë e mirë. Për shembull, ne zhvilluam demo që mund të tregohej për të tjerët, pasi robotët janë argëtues dhe tërheqin vëmendjen. Si pasojë, morëm përdorues vërtet të jashtëm, të cilët filluan të pyesin se çfarë është Embox dhe si të përdoret.
Në këtë fazë, duhet të mendonim për dokumentacionin dhe mjetet e komunikimit me përdoruesit. Sigurisht, ne e kishim menduar këtë çështje të rëndësishme edhe më parë, por ishte parakohe dhe nuk jepte efekt të pozitiv. Efekti ishte më shumë negativ. Do të jap disa shembuj. Ne përdorëm googlecode, wiki që mbështeste shumë gjuhësi. Krijuam faqe në disa gjuhë, përfshirë jo vetëm anglisht dhe rusisht, ku mund të komunikonim ashtu si ashtu, por edhe gjermanisht dhe spanjisht. Si pasojë, dukej shumë e çuditshme kur pyesnin në këto gjuhë dhe ne nuk mund të përgjigjeshim. Ose vendosëm rregulla për shkruanin e dokumentacionit dhe komenteve, por për shkak se API ndryshonte shpesh dhe ndjeshëm, ndodhte që dokumentacioni ynë të plaket dhe të krijonte konfuzion më shumë se sa të ndihmonte.
Në fund, të gjitha përpjekjet tona, madje edhe ato të gabuara, çuan në daljen e përdoruesve të jashtëm. Madje u shfaq një klient komercial që dëshiroi që të krijonim për të një OSRV të vetën. Dhe ne e zhvilluam pasi kishim përvojë dhe disa përgatitje. Këtë duhet ta tregoj për momentet e mira dhe të këqija. Do të filloj me të këqijat. Duke qenë se shumë zhvillues ishin angazhuar në këtë projekt në mënyrë komerciale, community-në e kemi pasur më të paqëndrueshme dhe ajo u nda, gjë që natyrisht nuk mund të ndikonte në zhvillimin e projektit. Një faktor shtesë ishte fakti se drejtimi i projektit përcaktohej nga një klient komercial, i cili qëllimi i tij nuk ishte zhvillimi i mëtejshëm i projektit. Të paktën ky qëllim nuk ishte kryesor.
Nga ana tjetër, kishte disa momente pozitive. Ne morëm përdorues të vërtetë të jashtëm. Ajo nuk ishte vetëm një klient, por edhe ata për të cilët ishte krijuar 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ë kënaqësi. Dhe më e rëndësishmja, ne dëgjuam një dëshirë nga klientët, e cila në atë kohë na dukej si një ide e çmendur, por që tani është ideja kryesore e Embox, do të thotë, përdorimi i kodit të zhvilluar tashmë në sistem. Tani ideja kryesore e Embox është përdorimi i softuerit Linux pa Linux. Pra, momenti kryesor pozitiv që ndihmon në zhvillimin e mëtejshëm të projektit ishte që ne kuptuam se projekti po përdoret nga përdoruesit e jashtëm dhe ai duhet të zgjidhë disa nga problemet e tyre.
Në atë kohë, Embox tashmë kishte dalë jashtë kornizave të një projekti studentor. Factori kryesor që e pengonte zhvillimin e projektit në modelin studentor ishte motivimi i pjesëmarrësve. Studentët marrin pjesë derisa studiojnë, dhe kur ata diplomohen, duhet të shfaqet një motivim tjetër. Nëse motivimi nuk shfaqet, studenti thjesht ndalon së marrë pjesë në projekt. Nëse merret parasysh se studentët së pari duhet të trajnohen, atëherë del se ata bëhen specialistë të mirë në momentin e diplomimit, por kontributi i tyre në projekt, për shkak të paekspertizës, nuk është shumë i madh.
Në përgjithësi, ne kalojmë ngadalë në momentin kryesor që lejon të flasim për krijimin e një projekti opensource, — krijimin e një produkti që do të zgjidhte problemet e përdoruesve të tij. Siç shpjegova më sipër, vetia kryesore e një projekti opensource është bashkësia e tij. Dhe, pjesëmarrësit e bashkësisë janë para së gjithash përdoruesit. Por si mund të shfaqen ata nëse nuk kanë çfarë të përdorin? Pra, siç ndodh me një projekt që nuk është opensource, është e nevojshme të përqendrohemi në krijimin e një MVP (produkti minimal të jetueshëm), dhe nëse ai do të tërheqë përdoruesit, atëherë rreth projektit do të shfaqet një bashkësi. Nëse merremi me krijimin e bashkësisë vetëm përmes PR-së, shkruarjes së wiki në të gjitha gjuhët e botës, ose një workflow të saktë git në github, atëherë me siguri kjo nuk do të ketë rëndësi 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, dëshiroj të citoj , sipas mendimit tim pasqyron pritshmëritë e përdoruesve nga projekti opensource:
Po mendoj seriozisht të kaloj në këtë OS (të paktën për ta provuar. Sa shumë po e përmirësojnë dhe po bëjnë gjëra të shkëlqyera).
P. S. Në do të kemi madje tri referate. Një për open source dhe dy për embedded (ndërsa një është praktik). Në stend do të organizojmë një master klas për programimin e mikrocontroller-ëve me anë të . Tradicionalisht do të sjellim pajisje dhe do t’i japim mundësinë të programohen. Do të ketë gjithashtu një kërkesë dhe aktivitete të tjera. Ejani në festival dhe në stendin tonë, do të jetë e këndshme.
Burimi: habr.com
