Kuidas luua avatud lähtekoodiga projekti

Juba sel nädalal toimub Peterburis IT-festival TechTrain. Üheks esinejaks on Richard Stallman. Embox osalevad samuti festivalil ning loomulikult ei saanud me mööda vaadata avatud lähtekoodiga tarkvara teemast. Seetõttu kannab üks meie ettekannetest nime “Üliõpilasprojektist avatud lähtekoodiga projektina. Emboksi kogemus”. See keskendub Emboxi arengu ajaloole avatud lähtekoodiga projektina. Käesolevas artiklis tahan ma rääkida peaideedest, mis minu arvates mõjutavad avatud lähtekoodiga projektide arengut. Artikkel, nagu ka ettekande, põhineb isiklikul kogemusel.

Alustame lihtsast: avatud lähtekoodiga projekti mõistest. On ilmselge, et avatud lähtekoodiga projekt on projekt, mis on varustatud ühe sellise litsentsiga, mis võimaldab juurdepääsu projekti allikale. Lisaks tähendab avatud projekt, et kolmandad arendajad saavad teha muudatusi. Seega, kui mõni ettevõte või arendaja avaldab oma toote koodi osaliselt või täielikult, ei muuda see veel seda toodet avatud lähtekoodiga projektiks. Ja lõpuks, iga projekti tegevus peaks tooma mingisuguse tulemuse ning projekti avatus tähendab, et seda tulemust kasutavad mitte ainult arendajad.

Avatud litsentside probleeme ei puuduta. See on liiga suur ja keeruline teema, mis nõuab sügavat arusaamist. Selle teema kohta on kirjutatud üsna palju häid artikleid ja materjale. Kuna ma ei ole õiguste spetsialist, ütlen ainult, et litsents peab vastama projekti eesmärkidele. Näiteks ei olnud Emboxi puhul BSD litsentsi valik juhuslik, mitte GPL litsents.

Tõsiasi, et avatud projekt peab võimaldama muudatusi ja mõjutama avatud projekti arengut, eeldab, et projekt on jaotatud. Selle haldamine, terviklikkuse ja töökindluse säilitamine on palju keerulisem võrreldes keskjuhtimisega projektiga. Tekib mõistlik küsimus, miks üldse teha avatud projekte. Vastus peitub ärilises otstarbekuses: teatud klassi projektide puhul kaaluvad eelised sellisest lähenemisest üles kulud. See tähendab, et mitte kõikide projektide jaoks ei sobi avatud lähenemine ja see pole alati lubatud. Näiteks on keeruline ette kujutada avatud põhimõttel põhineva elektrijaama või lennuki juhtimissüsteemi arendamist. Jah, sellistesse süsteemidesse tuleks lisada mooduleid avatud projektide baasil, kuna see toob kaasa mitmeid eeliseid. Kuid keegi peab vastutama lõpprodukti eest. Isegi kui süsteem põhineb täielikult avatud projektide koodil, sulgeb arendaja, pakkides kõik ühte süsteemi ja tehes konkreetsed kogumid ja seadistused, selle sisuliselt. Kood võib samas olla avalikus juurdepääsus.

Nende süsteemide puhul on hulgaliselt eeliseid avatud projektide loomisest või neis osalemisest. Nagu ma juba mainisin, võib lõpp-süsteemi kood jääda avalikuks. Miks, kuna on ilmselge, et pigem on raske leida kedagi, kellel oleks sama lennuk, et süsteemi testida. See on tõsi, kuid keegi võib siiski soovida kontrollida üksikuid koodijuppe, või näiteks võib keegi avastada, et kasutatav teek ei ole päris õigesti konfigureeritud.

Veel suurem kasu tuleb siis, kui ettevõte eraldab süsteemi teatud põhisektor eraldi projektiks. Näiteks andmevahetuse protokolli toetava teegi. Sellisel juhul, isegi kui protokoll on konkreetse valdkonna jaoks spetsiifiline, saab sellel süsteemi osal jagada kulusid teiste selle valdkonna ettevõtetega. Lisaks vajavad spetsialistid, kes saavad avatud juurdepääsu kaudu uurida selle süsteemi osa, selle tõhusaks kasutamiseks oluliselt vähem aega. Lõpuks, osa eraldamine iseseisvaks üksuseks, mida kasutavad kolmandad arendajad, võimaldab selle osa kvaliteeti parandada, kuna on vajadus pakkuda tõhusat API-d, koostada dokumentatsioon ning ma ei hakka isegi rääkima testimise katte suurendamisest.

Äriettevõte võib teenida kasu ka ilma avatud projektide loomata, piisab, kui tema spetsialistid osalevad ettevõttes rakendatavates kolmandate osapoolte projektides. Lõppude lõpuks jäävad kõik eelised alles: töötajad tunnevad paremini projekti, mis tähendab, et nad kasutavad seda tõhusamalt, ettevõte saab mõjutada projekti arengusuunda, ja valmis testitud koodi kasutamine vähendab ilmselgelt ettevõtte kulusid.

Avatud lähtekoodiga projektide loomise eelised ei piirdu sellega. Võtame näiteks sellise olulise äriosa nagu turundus. See on väga hea liivakast, mis võimaldab tõhusalt hinnata turu nõudmisi.

Ja loomulikult ei tohi unustada, et avatud lähtekoodiga projekt on tõhus viis enda erialasuse propageerimiseks. Mõnel juhul on see isegi ainus võimalus turule pääseda. Näiteks alustas Embox operatsioonisüsteemi projekti loomisega. Ilmselt ei pea ma selgitama, et konkurente on küllaga. Ilma kogukonna loomata ei oleks meil lihtsalt ressursse projekti lõpuks kasutajani viimiseks, st et projektist hakkaksid kasu saama välised arendajad.

Kogukond on avatud lähtekoodiga projekti võtmetähtsusega. See võimaldab oluliselt vähendada projekti haldamise kulusid, arendab ja toetab projekti. Võib öelda, et ilma kogukonnata ei eksisteeri avatud lähtekoodiga projekti üldse.

Kuidas luua ja hallata avatud lähtekoodiga projekti kogukonda on kirjutatud palju materjale. Et mitte korduda juba tuntud faktidega, püüan keskenduda Emboxi kogemusele. Näiteks on väga huvitav küsimus kogukonna loomise protsess. Paljud räägivad, kuidas olemasolevat kogukonda hallata, kuid selle loomise hetked jäetakse tihti tähelepanuta, kuna neid peetakse iseenesestmõistetavaks.

Peamine reegel avatud lähtekoodiga projekti kogukonna loomisel on see, et reegleid pole. Ma mõtlen, et universaalseid reegleid ei eksisteeri, just nagu ei ole ka hõbedast kuuli, vähemalt seetõttu, et projektid on äärmiselt erinevad. Tõenäoliselt ei saa sama reeglit kasutada nii näiteks JavaScripti logimisraamatukogu kogukonna loomisel kui ka kitsalt spetsialiseeritud draiveri loomisel. Veelgi enam, projekti (ja seega ka kogukonna) arengu erinevatel etappidel muutuvad reeglid.

Embox algas üliõpilasprojektina, kuna meil oli juurdepääs süsteemse programmeerimise osakonna üliõpilastele. Tegelikult astusime me mingisse teise kogukonda. Me suutisime huvitada selle kogukonna liikmeid, üliõpilasi, hea tööstushariduse ja teaduslike töödega süsteemses programmeerimises, kursuste ja lõputöödega. Teisisõnu järgime me üht kogukonna korraldamise põhireeglit: kogukonna liikmed peavad saama midagi, samas peab see hind vastama liikme panusele.

Emboxi järgmine etapp oli kolmandate osaliste kasutajate otsimine. On väga oluline mõista, et kasutajad on täieõiguslikud avatud lähtekoodiga kogukonna liikmed. Kasutajaid on tavaliselt rohkem kui arendajaid. Ja et soovida muutuda projekti kaasautoriks, tuleb esmalt mingil moel hakata seda kasutama.

Esimeste kasutajatena said Emboxi jaoks Teoreetilise Küberneetika osakond. Nad pakkusid välja luua alternatiivse tarkvara Lego Mindstormile. Ja kuigi need olid ikka veel kohalikud kasutajad (me saime nendega isiklikult kohtuda ja arutada, mida nad soovivad). See oli siiski väga hea kogemus. Näiteks arendasime demo, mida saime teistele näidata, sest robotid on lõbusad ja köidavad tähelepanu. Lõpuks meil olid tõeliselt kolmandate osaliste kasutajad, kes hakkasid küsima, mis on Embox ja kuidas seda kasutada.

Selles etapis pidime mõtlema dokumentatsioonile ja kommunikatsioonivahenditele kasutajatega. Jah, me muidugi mõtlesime nendele olulistele asjadele ka varem, kuid see tundus toona enneaegne ja ei andnud positiivset efekti. Tulemuseks oli pigem negatiivne. Toon mõned näited. Kasutasime googlecode'i, mille wiki toetas mitmekeelsust. Looime lehti mitmes keeles, mitte ainult inglise ja vene keeles, millega suutsime enam-vähem suhelda, vaid ka saksa ja hispaania keeles. Tulemuseks oli väga kohatu olukord, kui keegi küsis nendes keeltes, aga meie ei saanud üldse vastata. Või kehtestasime reeglid, kuidas dokumentatsiooni kirjutada ja kommenteerida, kuid kuna API muutus sageli ja oluliselt, siis osutus, et meie dokumentatsioon muutus vananenuks ja eksitas rohkem kui aitas.

Kokkuvõttes tõid kõik meie pingutused, isegi need, mis ei olnud õiged, kaasa väliste kasutajate tekkimise. Ilmus isegi ärikliendiks hakkaja, kes soovis, et me arendaksime talle oma OSRVi. Me arendasime, kuna meil on kogemus ja mingid arengud. Siin tuleb rääkida nii headest kui halbade asjadest. Alustan halbadega. Kuna paljusid arendajaid kaasati sellesse projekti ärilistel alustel, oli kogukond üsna ebastabiilne, jagunedes, mis mõjutamata ei saanud projekt arengu käiku. Täiendavaks faktoriks oli see, et projekti suuna määras üks äriline klient, kelle eesmärk ei olnud projekti edasine arendamine. Kõige vähem oli see eesmärk peamine.

Teiselt poolt oli mitmeid positiivseid aspekte. Saime tõeliselt väliseid kasutajaid. Need ei olnud mitte ainult tellijad, vaid ka need, kelle jaoks see süsteem oli mõeldud. Motivatsioon osaleda projektis kasvas. Lõppude lõpuks on alati tore, kui huvitava tegevuse juures on ka võimalus teenida. Ja mis peamine, kuulsime ühte tellijate soovi, mis tookord tundus meile absurdne, kuid mis nüüd on Emboxi peamine idee, nimelt kasutada süsteemis juba arendatud koodi. Praegu on Emboxi peamine idee kasutada Linuxi tarkvara ilma Linuxita. Seega oli peamine positiivne aspekt, mis toetas projekti edasist arengut, teadlikkus, et projekti kasutavad välised kasutajad ja see peab lahendama nende probleeme.

Sel hetkel oli Embox juba ületanud tudengite projekti piirid. Projekti arengu peamine takistus tudengimudeli järgi on osalejate motivatsioon. Tudengid osalevad seni, kuni nad õpivad, ja kui nad lõpetavad, peab tulema uus motivatsioon. Kui motivatsiooni ei teki, lõpetab tudeng lihtsalt projekti eest koosolekutele tuleku. Kui arvestada, et tudengeid tuleb esmalt koolitada, selgub, et nad saavad headeks spetsialistideks lõpetamise ajaks, kuid nende panus projekti on alguses, tänu kogemuste puudumisele, üsna väike.

Üldiselt liigume sujuvalt põhiteema juurde, mis võimaldab rääkida avatud lähtekoodiga projekti loomisest — toote loomine, mis lahendab kasutajate probleeme. Nagu ma juba eespool selgitasin, on avatud lähtekoodiga projekti peamine omadus selle kogukond. Samuti on kogukonna liikmed eelkõige kasutajad. Kuid kust nad tulevad, kui pole midagi kasutamiseks? Nii ongi, et nagu mitte-avatud lähtekoodiga projektiga, tuleb keskenduda MVP (minimaalselt elujõulise toote) loomisele, ja kui see huvitab kasutajaid, siis tekib projekti ümber kogukond. Kui aga tegeleda kogukonna loomisega ainult läbi PR-i, kirjutades vikipeediat kõikides maailma keeltes või õigesti korraldades git töövoogu GitHubis, siis on see varajastes etappides tõenäoliselt mõttetu. Loomulikult on hilisematel etappidel need asjad mitte ainult olulised, vaid ka vajalikud.

Kokkuvõtteks tahan tuua kommentaar, minu arvates peegeldab kasutaja ootusi avatud lähtekoodiga projekti suhtes:

Mõtlen tõsiselt selle operatsioonisüsteemi peale üleminekule (vähemalt proovima. Nad töötavad selle kallal tõeliselt aktiivselt ja teevad ägedaid asju).

P. S. Sa TechTrain Meil on lausa kolm ettekannet. Üks avatud allikast ja kaks sisseehitatud teemadest (sealjuures üks praktiline). Messil korraldame mikroprotsessorite programmeerimise töötoa Embox. Traditsiooniliselt toome kaasa riistvara ja laseme seda programmeerida. Ootame veel ka mängu ja muid tegevusi. Tulge festivalile ja meie stendile, kindlasti läheb lõbusaks.

Allikas: habr.com