Kuidas luua avatud lähtekoodiga projekti

Juba sel nädalal toimub Peterburis IT-festival TechTrain. Üheks esinejaks on Richard Stallman. Embox osalleb samuti festivalil, ja loomulikult ei saanud me tähelepanuta jätta avatud lähtekoodiga teemat. Seetõttu kannab üks meie ettekannetest pealkirja “Üliõpilase projektist avatud allika projektini. Emboxi kogemus”. See keskendub Emboxi arengule avatud lähtekoodiga projektina. Selles artiklis tahan rääkida peamistest ideedest, mis minu arvates mõjutavad avatud lähtekoodiga projektide arengut. Artikkel, nagu ka ettekande, põhineb isiklikul kogemusel.

Alustame lihtsast, avatud lähtekoodi mõiste määratlemisest. Ilmselgelt on avatud lähtekoodiga projekt projekt, millel on üks litsentsidest, mis võimaldab juurdepääsu projekti lähtekoodile. Lisaks tähendab avatud projekt, et kolmandad arendajad saavad teha muudatusi. Teisisõnu, kui mõni ettevõte või arendaja avaldab oma toote koodi osaliselt või täielikult, ei tähenda see veel, et see toode on avatud lähtekoodiga projekt. Lõpuks peab iga projekti tegevus viima mingi tulemuse saavutamiseni, ning projekti avatus tähendab, et seda tulemust kasutavad mitte ainult arendajad endid.

Avatud litsentside probleemide käsitlemisega ei hakka me tegelema. See on liiga suur ja keeruline teema, mis vajab süvitsi minekut. Selle teema kohta on kirjutatud palju häid artikleid ja materjale. Kuid kuna ma ei ole autoriõiguse valdkonna spetsialist, ütlen vaid, et litsents peab vastama projekti eesmärkidele. Näiteks ei olnud Emboxi valik BSD, mitte GPL litsentsi, juhuslik.

Tegurõigus, et avatud projekt peaks andma võimaluse muudatusi teha ja avatud projekti arengule mõju avaldada, eeldab, et projekt on jaotatud. Selle haldamine, terviklikkuse ja toimivuse säilitamine on palju keerulisem kui tsentraliseeritud juhtimisega projektide puhul. Tekib õigustatud küsimus, miks üldse avatud projekte teha. Vastus peitub äriotstarbes: teatud tüüpi projektide puhul ületavad sellise lähenemise kasud kulud. See tähendab, et mitte kõikidele projektidele sobib avatud lähenemine ja see on üldse lubatud. Näiteks on keeruline ette kujutada avatud põhimõttel põhineva elektrijaama või lennuki juhtimissüsteemi arendamist. Loomulikult tuleks sarnastes süsteemides kaasata mooduleid avatud projektide alusel, kuna see toob kaasa mitmeid eeliseid. Kuid lõpp-produkti eest peab keegi vastutama. Isegi kui süsteem põhineb täielikult avatud projektide koodil, sulgeb arendaja, kui ta kõik üheks süsteemiks paketib ja konkreetsed kogumid ja seaded loob, selle tegelikult. Kood võib samas olla avalikult kättesaadav.

Nende süsteemide jaoks on samuti palju eeliseid avatud projektide loomisel või nendes osalemisel. Nagu ma juba ütlesin, võib lõpp-süsteemi kood jääda avalikuks. Miks, sest on selge, et tõenäoliselt ei leia keegi sama lennukit süsteemi testimiseks. See on tõsi, kuid kindlasti võib leiduda keegi, kes soovib kontrollida teatud koodijuppe, või näiteks võib keegi avastada, et kasutatav teek ei ole täiesti korrektselt konfigureeritud.

Suurenev kasu ilmneb, kui ettevõte eraldab osa süsteemist eraldi projektiks. Näiteks andmevahetuse protokolli toe raamatukogu. Sellisel juhul, isegi kui protokoll on spetsiifiline konkreetse valdkonna jaoks, saab selle osa süsteemi säilitamise kulusid jagada teiste valdkonna ettevõtetega. Lisaks kulub spetsialistidele, kellel on võimalus tutvuda selle süsteemi osaga avatud juurdepääsu kaudu, tõhusaks kasutamiseks oluliselt vähem aega. Ja lõpuks, osa eraldamine iseseisvaks entiteediks, mida kasutavad kolmandad arendajad, võimaldab selle osa kvaliteeti parandada, kuna tuleb pakkuda tõhusaid API-sid, luua dokumentatsioon, ma ei mainigi testimise katvuse parandamist.

Ettevõte võib kaubanduslikku kasu saada, luues mitte avatud projekte; piisab, kui tema spetsialistid osalevad ettevõttes rakendatavates kolmanda osapoole projektides. Nimelt jäävad kõik eelised alles: töötajad tunnevad projekti paremini, seega kasutavad nad seda tõhusamalt, ettevõte saab mõjutada projekti arendamise suundi ning valmis ja testitud koodi kasutamine vähendab selgelt ettevõtte kulusid.

Avatud lähtekoodiga projektide loomise eelised ei piirdu sellega. Vaatame sellist olulist ärikomponenti nagu turundus. Selle jaoks on see väga hea mänguväljak, mis võimaldab tõhusalt hinnata turu nõudmisi.

Ja muidugi, ei tohi unustada, et avatud lähtekoodiga projekt on tõhus viis end spetsialiseerumise kandjana tutvustada. Mõnel juhul on see ainus viis turule pääsemiseks. Näiteks alustas Embox operatsioonisüsteemi loomise projektina. Ilmselt pole vajalik selgitada, et konkurente on hulganisti. Ilma kogukonna loomata ei oleks meil lihtsalt piisavalt ressursse projekti lõpptarbijani viimiseks, st et projekti hakkaksid kasutama kolmandad arendajad.

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

Avatud koodiga projekti kogukonna loomise ja haldamise kohta on kirjutatud palju materjale. Et mitte korduda juba tuntud faktidega, püüan keskenduda Emboxi kogemusele. Näiteks on selle protsessi loomine väga huvitav teema. Paljud räägivad, kuidas hallata juba olemasolevat kogukonda, kuid selle loomise hetked jäävad sageli tähelepanuta, kuna neid peetakse enesestmõistetavaks.

Peamine reegel avatud lähtekoodiga projekti kogukonna loomisel on see, et mingeid reegleid ei ole. Tõesed universaalsed reeglid puuduvad, just nagu hõbedast kuul. Põhjuseks on see, et projektid on väga erinevad. On ebatõenäoline, et saab kasutada samu reegleid kogukonna loomisel näiteks JavaScripti logimisraamatukogu ja kitsalt spetsialiseeritud draiveri puhul. Veelgi enam, projekti (ja seega ka kogukonna) erinevatel arenguetappidel reeglid muutuvad.

Embox alustas üliõpilasprojektina, kuna olid juurdepääsud süsteemse programmeerimise osakonna üliõpilastele. Sisuliselt astusime me teise kogukonda. Selle kogukonna liikmeid, üliõpilasi, suutsime me huvitada korraliku tööstusliku praktikaga vastava eriala järgi, teaduslike tööde ja kursuste ning diplomitega süsteemse programmeerimise alal. See tähendab, et täitsime ühte olulisemat reeglit kogukonna korraldamisel: kogukonna liikmed peavad midagi saama, ning see hind peab vastama osaluse sisule.

Järgmine etapp Emboxi jaoks oli välistarbijate otsimine. On väga oluline mõista, et kasutajad on avatud lähtekoodiga kogukonna täielikud liikmed. Kasutajaid on tavaliselt rohkem kui arendajaid. Ja et soovida saada projekti kaasautoriks, tuleb seda esmalt kuidagi kasutada.

Emboxi esimesed kasutajad olid Teoreetilise Küberneetika osakond. Nad pakkusid välja luua alternatiivse tarkvaraversiooni Lego Mindstormile. Ja kuigi need olid ikka veel kohalikud kasutajad (me võisime nendega isiklikult kohtuda ja arutada, mida nad soovivad), oli see siiski väga hea kogemus. Näiteks töötasime välja demo, mida saime teistele näidata, kuna robotid on lõbusad ja köidavad tähelepanu. Lõppkokkuvõttes tekkisid meil tõeliselt välist kasutajad, kes hakkasid küsima, mis on Embox ja kuidas seda kasutada.

Selles etapis pidime mõtlema dokumentatsioonile ja suhtlemisvahenditele kasutajatega. Jah, me olime neid olulisi asju mõelnud varem, kuid see oli liiga vara ja ei andnud positiivset mõju. Efekt oli pigem negatiivne. Toome välja paar näidet. Kasutasime Googlecode'i, mille wikit toetas mitmekeelsus. Meie lehed olid mitmes keeles, sealhulgas mitte ainult inglise ja vene, millega suudaksime kuidagi suhelda, vaid ka saksa ja hispaania keeles. Tulemuseks nägi see väga naljakas välja, kui küsiti nendes keeltes, aga me ei suutnud üldse vastata. Või kehtestasime reegleid dokumentatsioonide kirjutamiseks ja kommentaaride jaoks, kuid kuna API muutus üsna sageli ja oluliselt, selgus, et meie dokumentatsioon oli aegunud ja segadusse ajav rohkem kui abistav.

Lõppkokkuvõttes viisid kõik meie jõupingutused, isegi mitte õiged, selle tulemuseni, et tekkisid välist kasutajad. Ja isegi tekkis kommertstootja, kes soovis, et temale arendataks kohandatud OSRVi. Me arendasime seda, kuna meil oli kogemusi ja teatud eelteadmisi. Siin tuleb rääkida nii headest kui halbadest momentidest. Alustan halbadest. Kuna paljusid arendajaid kaasati sellesse projekti äri alusel, oli juba niigi ebastabiilne kogukond jagunenud, mis ei saanud kindlasti olla edasise projekti arengu jaoks kasulik. Täiendavaks teguriks oli see, et projekti suunda määras üks kommertstootja, kelle eesmärk ei olnud projekti edasine arendamine. Vähemalt see eesmärk ei olnud peamine.

Teisest küljest oli mitmeid positiivseid aspekte. Saime tõeliselt kolmandaid kasutajaid. Need ei olnud ainult kliendid, vaid ka need, kellele see süsteem oli mõeldud. Osalemismotivatsioon projektis kasvas. Kui huvitava tegevuse juures on ka võimalik teenida, on see alati meeldiv. Ja mis peamine, kuulasime üht kliendi soov, mis tookord tundus meile jaburana, kuid mis on nüüd Emboxi peamine idee, nimelt kasutada süsteemis juba välja töötatud koodi. Täna on Emboxi põhiteema Linuxi tarkvara kasutamine ilma Linuxita. Siis oli peamine positiivne aspekt, mis aitas projekti edasist arengut, arusaamine, et projekti kasutavad kolmandad kasutajad ja see peab lahendama nende probleeme.

Tollal oli Embox juba ületanud üliõpilasprojekti piire. Projekti arengu peamine pidurdustegur üliõpilasmudeli kohaselt on osalejate motivatsioon. Üliõpilased osalevad seni, kuni nad õpivad, ja kui nad lõpetavad, peab tekkima uus motivatsioon. Kui motivatsiooni ei teki, lõpetab üliõpilane lihtsalt projekti osalemise. Kui arvestada, et üliõpilasi tuleb esmalt koolitada, siis selgub, et nad saavad headeks spetsialistideks lõpetamise ajaks, kuid nende panus projekti, tänu kogemuse puudumisele, pole kuigi suur.

Kokkuvõttes liigume sujuvalt põhiteema juurde, mis võimaldab rääkida avatud koodiga projekti loomisest — toote loomine, mis lahendab selle kasutajate probleeme. Nagu ma juba eelnevalt selgitasin, on avatud koodiga projekti peamine omadus selle kogukond. Ja kogukonna liikmed on kõigepealt kasutajad. Aga kust nad tulevad, kui neil pole millegagi kasutada? Nii on nagu mitte-avatud koodiga projektiga — tuleb keskenduda MVP (minimaalne elujõuline toode) loomisele, ja kui see huvitab kasutajaid, siis tekib projekti ümber kogukond. Kui aga tegeleda kogukonna loomisega ainult läbi kogukonna reklaami, kirjutades vikipeedia igas maailma keeles või õigesti git workflow'ga githubis, siis kahtlemata ei oma see projekte algfaasis suurt tähtsust. Muidugi, vastavatel etappidel on need mitte ainult olulised, vaid ka vajalikud asjad.

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

Mõtlen tõsiselt selle operatsioonisüsteemi kasutusele võtmisest (vähemalt proovida. Seda arendatakse väga aktiivselt ja sellel on palju lahedaid funktsioone).

P. S. Meil TechTrain on lausa kolm ettekannet. Üks avatud lähtekoodiga ja kaks sisseehitatud (lisaks üks praktiline). Meie stendil viime läbi mikrocontrolleride programmeerimise meistriklassi, kasutades Embox. Traditsiooniliselt toome kaasa riistvara ja anname neid proovida programmeerida. Olemas on ka mäng ja teised tegevused. Tulge festivalile ja meie stendile, seal on lõbus.

Allikas: habr.com