Aste honetan IT jaialdia ospatuko da San Petersburgon . Hizlarietako bat Richard Stallman izango da. jaialdian ere parte hartzen du, eta, noski, ezin genioke software librearen gaia alde batera utzi. Horregatik deitzen zaio gure txostenetako bati . Embox-en kode irekiko proiektu gisa garatzearen historiari eskainiko zaio. Artikulu honetan, nire ustez kode irekiko proiektuen garapenean eragina duten ideia nagusiei buruz hitz egin nahi dut. Artikulua, txostena bezala, esperientzia pertsonalean oinarritzen da.
Has gaitezen zerbait sinple batekin, opensource terminoaren definizioarekin. Jakina, kode irekiko proiektu bat proiektuaren iturburu-kodea atzitzea ahalbidetzen duen lizentzietako bat duen proiektua da. Gainera, proiektu ireki batek hirugarrenen garatzaileek aldaketak egin ditzaketela esan nahi du. Hau da, enpresa edo garatzaileren batek bere produktuaren kodea argitaratzen badu, partzialki edo guztiz, horrek ez du oraindik produktu hau kode irekiko proiektu bihurtzen. Eta, azkenik, edozein proiektu-jarduerak nolabaiteko emaitza ekarri behar du, eta proiektuaren irekierak esan nahi du emaitza hori garatzaileek ez ezik erabiltzen dutela.
Ez ditugu lizentzia irekien arazoak ukituko. Ikerkuntza sakona eskatzen duen gai handiegia eta konplexuegia da. Artikulu eta material on asko idatzi dira gai honi buruz. Baina ni neu egile eskubideen arloan aditua ez naizenez, lizentziak proiektuaren helburuak bete behar dituela esango dut soilik. Adibidez, Embotxek GPL lizentzia baino BSD aukeratzea ez zen ustekabean izan.
Kode irekiko proiektu batek aldaketak egiteko eta kode irekiko proiektuaren garapenean eragiteko gaitasuna eman behar izateak proiektua banatuta egotea dakar. Kudeatzea, osotasuna eta errendimendua mantentzea askoz zailagoa da kudeaketa zentralizatua duen proiektu batekin alderatuta. Arrazoizko galdera bat sortzen da: zergatik irekitzen dira proiektuak? Erantzuna bideragarritasun komertzialaren arloan dago; proiektu mota jakin baterako, ikuspegi honen onurak kostuak gainditzen ditu. Hau da, ez da egokia proiektu guztietarako eta ikuspegi irekia orokorrean onargarria da. Adibidez, zaila da printzipio ireki batean oinarritutako zentral elektriko baterako edo hegazkin baterako kontrol-sistema bat garatzea imajinatzea. Ez, noski, horrelako sistemek proiektu irekietan oinarritutako moduluak sartu beharko lituzkete, horrek abantaila ugari emango baititu. Baina norbaitek izan behar du azken produktuaren arduraduna. Nahiz eta sistema proiektu irekien kodean guztiz oinarritzen den, garatzaileak, dena sistema batean paketatu eta konfigurazio eta ezarpen zehatzak egin ondoren, funtsean itxi egiten du. Kodea publikoki eskuragarri egon daiteke.
Sistema hauentzat ere abantaila asko daude kode irekiko proiektuak sortzeak edo ekarpenak egiteak. Esan dudan bezala, amaierako sistemaren kodea publikoki eskuragarri egon daiteke. Zergatik, bistakoa baita nekez izango duela inork sistema probatzeko hegazkin bera edukitzea. Hori egia da, baina baliteke norbait izatea kodearen atal batzuk egiaztatu nahi dituena, edo, adibidez, norbaitek aurki dezake erabiltzen ari den liburutegia ez dagoela behar bezala konfiguratuta.
Are onura handiagoa agertzen da enpresak sistemaren oinarrizko zatiren bat proiektu bereizi batean esleitzen badu. Adibidez, liburutegi bat datuak trukatzeko protokolo motaren bat onartzen duena. Kasu honetan, nahiz eta protokoloa gai-arlo jakin bateko espezifikoa izan, sistemaren zati hori mantentzeko kostuak arlo horretako beste enpresekin parteka ditzakezu. Gainera, sistemaren zati hau jabari publikoan azter dezaketen espezialistek askoz denbora gutxiago behar dute eraginkortasunez erabiltzeko. Eta, azkenik, pieza bat hirugarrenen garatzaileek erabiltzen duten entitate independente batean bereizteak zati hau hobetzea ahalbidetzen digu, API eraginkorrak eskaini behar ditugulako, dokumentazioa sortu, eta ez naiz probaren estaldura hobetzeaz ere ari.
Enpresa batek abantaila komertzialak jaso ditzake kode irekiko proiekturik sortu gabe; nahikoa da bere espezialistek enpresan erabiltzen diren hirugarrenen proiektuetan parte hartzea. Azken finean, onura guztiak geratzen dira: langileek proiektua hobeto ezagutzen dute, beraz, modu eraginkorragoan erabiltzen dute, enpresak proiektuaren garapenaren norabidean eragin dezake, eta prest egindako kode depuratua erabiltzeak, jakina, enpresaren kostuak murrizten ditu.
Kode irekiko proiektuak sortzearen onurak ez dira hor amaitzen. Har dezagun marketina bezalako negozioaren osagai garrantzitsu bat. Haren ustez, oso ona da hare-kutxa, merkatuaren eskakizunak eraginkortasunez ebaluatzeko aukera ematen diona.
Eta, jakina, ez dugu ahaztu behar kode irekiko proiektu bat edozein espezializazioko eramaile gisa deklaratzeko modu eraginkorra dela. Zenbait kasutan, hori da merkatuan sartzeko modu bakarra. Adibidez, Embox RTOS bat sortzeko proiektu gisa hasi zen. Ziurrenik ez dago lehiakide asko daudela azaldu beharrik. Komunitate bat sortu gabe, besterik gabe, ez genuke baliabide nahikorik izango proiektua azken erabiltzaileari ekartzeko, hau da, hirugarrenen garatzaileek proiektua erabiltzen hasteko.
Komunitatea funtsezkoa da kode irekiko proiektu batean. Proiektuen kudeaketa kostuak nabarmen murrizteko, proiektua garatzeko eta laguntzeko aukera ematen du. Komunitaterik gabe ez dagoela inolako proiektu irekirik esan dezakegu.
Material asko idatzi da kode irekiko proiektuen komunitatea nola sortu eta kudeatu buruz. Dagoeneko ezagutzen diren gertakariak ez kontatzeko, Embox-en esperientzian zentratzen saiatuko naiz. Esaterako, komunitate bat sortzeko prozesua oso gai interesgarria da. Hau da, askok esaten dute lehendik dagoen komunitate bat nola kudeatu, baina bere sorrerako uneak alde batera uzten dira batzuetan, hori jakintzat hartuta.
Iturburu irekiko proiektu komunitate bat sortzeko arau nagusia araurik ez dagoela da. Esan nahi dut ez dagoela arau unibertsala, zilarrezko balarik ez dagoen bezala, proiektuak oso desberdinak direlako besterik ez bada ere. Nekez erabili ahal izango dituzu arau berdinak js logging liburutegi baterako komunitate bat sortzeko eta oso espezializatutako kontrolatzaile baterako. Gainera, proiektuaren garapen-fase ezberdinetan (eta, beraz, komunitatean), arauak aldatzen dira.
Embox ikasleen proiektu gisa hasi zen, sistemen programazio saileko ikasleak sarbidea zuelako. Izan ere, beste komunitate batean sartzen ari ginen. Komunitate honetako parte-hartzaileei, ikasleei, interesa genitzake beren espezialitateko industria praktika onetan, sistemaren programazioaren alorreko lan zientifikoan, ikastaroetan eta diplomak. Hau da, komunitate bat antolatzeko oinarrizko arauetako bat jarraitu genuen: komunitateko kideek zerbait jaso behar dute, eta prezio hori partaidearen ekarpenarekin bat etorri behar da.
Embox-en hurrengo etapa hirugarren erabiltzaileen bilaketa izan zen. Oso garrantzitsua da ulertzea erabiltzaileak kode irekiko komunitatean parte hartzaile osoak direla. Garatzaileak baino erabiltzaile gehiago egon ohi dira. Eta proiektu baten kolaboratzaile izan nahi izateko, lehendabizi, era batera edo bestera erabiltzen hasten dira.
Embox-en lehen erabiltzaileak Zibernetika Teoriko Saila izan ziren. Lego Mindstorm-erako firmware alternatibo bat sortzea proposatu dute. Eta hauek oraindik tokiko erabiltzaileak izan arren (beraiekin pertsonalki bildu eta nahi zutena eztabaidatu genezake). Baina, hala ere, oso esperientzia ona izan zen. Adibidez, besteei erakutsi ahal izateko demoak garatu genituen, robotak dibertigarriak direlako eta arreta erakartzen dutelako. Ondorioz, benetan hirugarrenen erabiltzaileak lortu ditugu, Embox zer den eta nola erabili galdetzen hasi zirenak.
Etapa honetan, dokumentazioan pentsatu behar izan dugu, erabiltzaileekin komunikatzeko bideei buruz. Ez, noski, aurretik pentsatu genuen gauza garrantzitsu horiei buruz, baina goiztiarra izan zen eta ez zuen eragin positiborik eman. Eragina nahiko negatiboa izan zen. Adibide pare bat jartzen dizkizut. Googlecode erabili dugu, zeinaren wikiak eleaniztasuna onartzen zuen. Hainbat hizkuntzatako orrialdeak sortu genituen, ingelesez eta errusieraz ez ezik, zeinetan nekez komunikatzen ginen, alemanez eta gaztelaniaz ere bai. Ondorioz, oso barregarria dirudi hizkuntza hauetan galdetzean, baina ezin dugu batere erantzun. Edo dokumentazioa idazteko eta iruzkintzeko arauak sartu zituzten, baina APIa sarritan eta nabarmen aldatzen zenez, gure dokumentazioa zaharkituta zegoela eta lagundu baino engainagarriagoa zela ikusi zen.
Ondorioz, gure ahalegin guztiek, okerrekoek ere, kanpoko erabiltzaileak agertzea ekarri zuten. Eta baita bere RTOS propioa berarentzat garatzea nahi zuen bezero komertzial bat ere agertu zen. Eta garatu dugu esperientzia eta oinarri batzuk ditugulako. Hemen momentu onez eta txarrez hitz egin behar duzu. txarretatik hasiko naiz. Garatzaile askok proiektu honetan oinarri komertzial batean parte hartu zutenez, komunitatea nahiko ezegonkorra eta zatituta zegoen jada, eta horrek, noski, ezin zuen proiektuaren garapenean eragin. Faktore gehigarri bat izan zen proiektuaren norabidea bezero komertzial batek ezarri zuela, eta bere helburua ez zen proiektua garatzea. Ez zen hori behintzat helburu nagusia.
Bestalde, alderdi positibo batzuk zeuden. Benetan hirugarrenen erabiltzaileak lortu ditugu. Bezeroa ez ezik, sistema hau zuzenduta zegoen hori ere izan zen. Proiektuan parte hartzeko motibazioa areagotu egin da. Azken finean, negozio interesgarri batekin ere dirua irabazten baduzu, beti da polita. Eta garrantzitsuena, bezeroengandik nahi bat entzun genuen, garai hartan zoroa iruditu zitzaigun, baina gaur egun Embbox-en ideia nagusia dena, hots, sisteman dagoeneko garatuta dagoen kodea erabiltzea. Orain Embbox-en ideia nagusia Linux softwarea Linux gabe erabiltzea da. Hau da, proiektua garatzen lagundu duen alderdi positibo nagusia proiektua hirugarren erabiltzaileek erabiltzen dutela konturatzea izan da, eta haien arazo batzuk konpondu beharko lituzke.
Garai hartan, Embox ikasleen proiektu baten esparrutik haratago joana zen jada. Ikasle ereduaren arabera proiektuaren garapenaren mugatzaile nagusia partaideen motibazioa da. Ikasleek ikasten duten bitartean parte hartzen dute, eta graduatu direnean, beste motibazio bat egon beharko litzateke. Motibazioa agertzen ez bada, ikasleak proiektuan parte hartzeari uzten dio besterik gabe. Lehenik eta behin ikasleak trebatu behar direla kontuan hartzen badugu, gradua amaitzen direnerako espezialista onak bihurtzen direla ematen du, baina proiektuari egiten dioten ekarpena, esperientzia faltagatik, ez da oso handia.
Oro har, leunki pasatzen gara kode irekiko proiektu bat sortzeaz hitz egiteko aukera ematen duen puntu nagusira: erabiltzaileen arazoak konponduko lituzkeen produktu bat sortzea. Goian azaldu dudan bezala, kode irekiko proiektu baten propietate nagusia komunitatea da. Gainera, komunitateko kideak erabiltzaileak dira nagusiki. Baina nondik datoz ezer erabiltzekorik ez dagoenean? Beraz, bihurtzen da, opensource ez den proiektu batekin bezala, MVP bat (gutxieneko produktu bideragarria) sortzera bideratu behar duzula, eta erabiltzaileei interesatzen bazaie, komunitate bat agertuko da proiektuaren inguruan. Komunitate bat sortzen ari bazara komunitateko PR bidez soilik, wiki bat munduko hizkuntza guztietan idazten edo github-en git lan-fluxua zuzentzen baduzu, litekeena da proiektuaren hasierako faseetan axola izango. Noski, egoki diren faseetan hauek garrantzitsuak ez ezik, beharrezkoak ere badira.
Bukatzeko adierazi nahi nuke , nire ustez, kode irekiko proiektu baten erabiltzaileen itxaropenak islatuz:
Serioski pentsatzen ari naiz sistema eragile honetara aldatzea (saia zaitez behintzat. Aktiboki bilatzen ari dira eta gauza politak egiten ari dira).
PS On Hiru txosten izango ditugu. Kode irekiari buruzko bat eta txertatuari buruzko bi (eta bat praktikoa da). Standean mikrokontrolagailuak erabiliz programatzeko klase magistral bat egingo dugu . Ohi bezala, hardwarea ekarriko dugu eta programatzen utziko dizugu. Bilaketa eta bestelako jarduerak ere izango dira. Zatoz jaialdira eta gure standera, dibertigarria izango da.
Iturria: www.habr.com