Sel nädalal peetakse Peterburis IT-festivali . Üks esinejatest on Richard Stallman. osaleb ka festivalil ning loomulikult ei saanud mainimata jätta ka vaba tarkvara teemat. Sellepärast nimetatakse ühte meie aruannetest . See on pühendatud Emboxi kui avatud lähtekoodiga projekti arengu ajaloole. Selles artiklis tahan rääkida peamistest ideedest, mis minu arvates avatud lähtekoodiga projektide arengut mõjutavad. Artikkel, nagu ka aruanne, põhineb isiklikul kogemusel.
Alustame millestki lihtsast, mõiste avatud lähtekoodi definitsioonist. 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 kolmandatest osapooltest arendajad saavad muudatusi teha. See tähendab, et kui mõni ettevõte või arendaja avaldab oma toote koodi osaliselt või täielikult, ei muuda see seda toodet veel avatud lähtekoodiga projektiks. Ja lõpuks, iga projektitegevus peab viima mingisuguse tulemuseni ja projekti avatus eeldab, et seda tulemust ei kasuta mitte ainult arendajad ise.
Avatud litsentside probleeme me ei puuduta. See on liiga mahukas ja keeruline teema, mis nõuab põhjalikku uurimist. Sellel teemal on kirjutatud päris palju häid artikleid ja materjale. Aga kuna ma ise ei ole autoriõiguste alal ekspert, siis ütlen vaid, et litsents peab vastama projekti eesmärkidele. Näiteks Emboxi puhul ei olnud GPL-i litsentsi asemel BSD valik juhuslik.
Asjaolu, et avatud lähtekoodiga projekt peaks võimaldama teha muudatusi ja mõjutada avatud lähtekoodiga projekti arengut, tähendab, et projekti levitatakse. Selle haldamine, terviklikkuse ja jõudluse säilitamine on palju keerulisem võrreldes tsentraliseeritud haldusega projektiga. Tekib mõistlik küsimus: miks üldse projekte avatakse? Vastus peitub ärilise teostatavuse valdkonnas; teatud tüüpi projektide puhul kaaluvad selle lähenemisviisi eelised üles kulud. See tähendab, et see ei sobi kõigi projektide jaoks ja avatud lähenemine on üldiselt aktsepteeritav. Näiteks on raske ette kujutada elektrijaama või lennuki juhtimissüsteemi arendamist avatud põhimõttel. Ei, muidugi peaksid sellised süsteemid sisaldama avatud projektidel põhinevaid mooduleid, sest see annab mitmeid eeliseid. Kuid keegi peab vastutama lõpptoote eest. Isegi kui süsteem põhineb täielikult avatud projektide koodil, siis arendaja, olles pakkinud kõik ühte süsteemi ning teinud konkreetsed buildid ja seadistused, sisuliselt sulgeb selle. Kood võib olla avalikult kättesaadav.
Samuti on nende süsteemide jaoks palju kasu avatud lähtekoodiga projektide loomisest või nendesse panustamisest. Nagu ma juba ütlesin, võib lõppsüsteemi kood jääda avalikult kättesaadavaks. Miks, sest on ilmselge, et on ebatõenäoline, et kellelgi on samasugune lennuk süsteemi testimiseks. See on tõsi, kuid võib juhtuda, et leidub keegi, kes soovib koodi teatud jaotisi kontrollida, või näiteks võib keegi avastada, et kasutatav teek pole päris õigesti konfigureeritud.
Veelgi suurem kasu ilmneb siis, kui ettevõte eraldab mõne süsteemi põhiosa eraldi projekti. Näiteks raamatukogu, mis toetab mingit andmevahetusprotokolli. Sel juhul, isegi kui protokoll on konkreetsele ainevaldkonnale omane, saate selle süsteemiosa ülalpidamiskulusid jagada teiste selle valdkonna ettevõtetega. Lisaks vajavad spetsialistid, kes saavad seda süsteemi osa avalikult uurida, selle tõhusaks kasutamiseks palju vähem aega. Ja lõpuks, tüki eraldamine sõltumatuks üksuseks, mida kolmandate osapoolte arendajad kasutavad, võimaldab meil seda osa paremaks muuta, sest peame pakkuma tõhusaid API-sid, looma dokumentatsiooni ja ma ei räägi isegi testide katvuse parandamisest.
Ettevõte saab ärilisi hüvesid ilma avatud lähtekoodiga projekte loomata, piisab, kui tema spetsialistid osalevad ettevõttes kasutatavates kolmandate osapoolte projektides. Kõik hüved jäävad ju alles: töötajad tunnevad projekti paremini, seetõttu kasutavad nad seda efektiivsemalt, ettevõte saab mõjutada projekti arengu suunda ning valmis silutud koodi kasutamine vähendab ilmselgelt ettevõtte kulusid.
Avatud lähtekoodiga projektide loomise eelised ei piirdu sellega. Võtame nii olulise ärikomponendi nagu turundus. Tema jaoks on see väga hea liivakast, mis võimaldab turu nõudeid tõhusalt hinnata.
Ja loomulikult ei tohi me unustada, et avatud lähtekoodiga projekt on tõhus viis kuulutada end mis tahes eriala kandjaks. Mõnel juhul on see ainus viis turule sisenemiseks. Näiteks Embox sai alguse RTOS-i loomise projektist. Ilmselt pole vaja seletada, et konkurente on palju. Ilma kommuuni loomiseta poleks meil lihtsalt olnud piisavalt ressursse, et viia projekt lõppkasutajani ehk et kolmandatest osapooltest arendajad saaksid projekti kasutama hakata.
Kogukond on avatud lähtekoodiga projektis võtmetähtsusega. See võimaldab oluliselt vähendada projektijuhtimise kulusid, projekti arendada ja toetada. Võime öelda, et ilma kogukonnata pole avatud lähtekoodiga projekti üldse.
Avatud lähtekoodiga projektikogukonna loomise ja haldamise kohta on kirjutatud palju materjale. Et mitte juba teadaolevaid fakte ümber jutustada, püüan keskenduda Emboxi kogemusele. Näiteks kogukonna loomise protsess on väga huvitav teema. See tähendab, et paljud räägivad, kuidas olemasolevat kogukonda hallata, kuid selle loomise hetked jäetakse mõnikord kahe silma vahele, pidades seda iseenesestmõistetavaks.
Peamine reegel avatud lähtekoodiga projektikogukonna loomisel on reeglite puudumine. Ma mõtlen, et universaalseid reegleid pole olemas, nagu ka hõbekuuli, kasvõi sellepärast, et projektid on väga erinevad. On ebatõenäoline, et saate samu reegleid kasutada kommuuni loomisel js-i logimise teegi ja mõne väga spetsiifilise draiveri jaoks. Veelgi enam, projekti (ja seega ka kogukonna) arendamise erinevatel etappidel reeglid muutuvad.
Embox sai alguse üliõpilasprojektina, kuna sellel oli juurdepääs süsteemiprogrammeerimise osakonna õpilastele. Tegelikult olime sisenemas mõnda teise kogukonda. Võiksime selles kogukonnas osalejaid, tudengeid, huvitada oma eriala heast tööstustavast, teaduslikust tööst süsteemi programmeerimise vallas, kursuste ja diplomitega. See tähendab, et lähtusime kogukonna korraldamise ühest põhireeglist: kogukonna liikmed peavad midagi saama ja see hind peab vastama osaleja panusele.
Emboxi järgmine etapp oli kolmandate osapoolte kasutajate otsimine. On väga oluline mõista, et kasutajad on avatud lähtekoodiga kogukonnas täieõiguslikud osalejad. Tavaliselt on kasutajaid rohkem kui arendajaid. Ja selleks, et sooviksid saada projekti panustajaks, hakkavad nad seda kõigepealt ühel või teisel viisil kasutama.
Emboxi esimesed kasutajad olid teoreetilise küberneetika osakond. Nad soovitasid luua Lego Mindstormi jaoks alternatiivse püsivara. Ja kuigi need olid ikkagi kohalikud kasutajad (saime nendega isiklikult kohtuda ja arutada, mida nad tahavad). Aga see oli ikkagi väga hea kogemus. Näiteks töötasime välja demosid, mida saaks teistele näidata, sest robotid on lõbusad ja tõmbavad tähelepanu. Selle tulemusena saime tõeliselt kolmanda osapoole kasutajaid, kes hakkasid küsima, mis on Embox ja kuidas seda kasutada.
Selles etapis pidime mõtlema dokumentatsioonile, kasutajatega suhtlemisvahenditele. Ei, me muidugi mõtlesime nendele olulistele asjadele varem, aga see oli ennatlik ega andnud positiivset mõju. Mõju oli pigem negatiivne. Toon paar näidet. Kasutasime googlecode'i, mille wiki toetas mitmekeelsust. Tegime lehti mitmes keeles, mitte ainult inglise ja vene keeles, milles me peaaegu ei saanud suhelda, vaid ka saksa ja hispaania keeles. Seetõttu tundub see nendes keeltes küsides väga naeruväärne, kuid me ei saa üldse vastata. Või kehtestati dokumentatsiooni kirjutamise ja kommenteerimise reeglid, kuid kuna API muutus üsna sageli ja oluliselt, siis selgus, et meie dokumentatsioon oli aegunud ja oli pigem eksitav, kui aitas.
Selle tulemusena viisid kõik meie jõupingutused, isegi valed, väliste kasutajate ilmumiseni. Ja ilmus isegi kommertsklient, kes soovis, et tema jaoks töötataks välja oma RTOS. Ja me arendasime seda, sest meil on kogemusi ja mõningane eeltöö. Siin tuleb rääkida nii headest kui ka halbadest hetkedest. Alustan halbadest. Kuna paljud arendajad olid sellesse projekti kaasatud ärilistel alustel, oli kogukond juba üsna ebastabiilne ja lõhestunud, mis muidugi ei saanud mõjutada projekti arengut. Lisafaktoriks oli ka see, et projekti suuna määras üks kommertsklient ning tema eesmärgiks ei olnud projekti edasiarendus. Vähemalt see ei olnud peamine eesmärk.
Teisest küljest oli mitmeid positiivseid külgi. Meil on tõeliselt kolmandatest osapooltest kasutajad. See ei olnud ainult klient, vaid ka need, kellele see süsteem mõeldud oli. Suurenenud on motivatsioon projektis osaleda. Lõppude lõpuks, kui saate ka huvitava äriga raha teenida, on see alati tore. Ja mis kõige tähtsam, kuulsime klientidelt üht soovi, mis tollal tundus meile hullumeelne, kuid mis on nüüd Emboxi põhiidee, nimelt kasutada süsteemis juba väljatöötatud koodi. Nüüd on Emboxi põhiidee kasutada Linuxi tarkvara ilma Linuxita. See tähendab, et peamine positiivne aspekt, mis projekti edasisele arengule kaasa aitas, oli tõdemus, et projekti kasutavad kolmandatest osapooltest kasutajad ja see peaks lahendama osa nende probleemidest.
Embox oli selleks ajaks juba üliõpilasprojekti raamest väljunud. Peamine piirav tegur projekti arendamisel õpilasmudeli järgi on osalejate motivatsioon. Õpilased osalevad õppimise ajal ja kui nad lõpetavad, peaks motivatsioon olema erinev. Kui motivatsiooni ei ilmu, lõpetab õpilane lihtsalt projektis osalemise. Kui võtta arvesse, et tudengeid tuleb esmalt koolitada, siis selgub, et nendest saavad kooli lõpetamise ajaks head spetsialistid, kuid nende panus projekti ei ole kogenematuse tõttu kuigi suur.
Üldiselt liigume sujuvalt edasi põhipunkti juurde, mis võimaldab rääkida avatud lähtekoodiga projekti loomisest – toote loomisest, mis lahendaks selle kasutajate probleemid. Nagu eespool selgitasin, on avatud lähtekoodiga projekti peamine omadus selle kogukond. Lisaks on kogukonna liikmed peamiselt kasutajad. Aga kust need tulevad, kui pole midagi kasutada? Nii selgub, et nii nagu mitteavatud lähtekoodiga projekti puhul, tuleb keskenduda MVP (minimaalselt elujõulise toote) loomisele ja kui see huvitab kasutajaid, siis tekib projekti ümber kogukond. Kui tegelete kogukonna loomisega ainult kogukonna suhtekorralduse kaudu, kirjutate wiki kõigis maailma keeltes või parandate Githi töövoogu githubis, pole sellel projekti algfaasis tõenäoliselt tähtsust. Loomulikult ei ole need asjakohastel etappidel mitte ainult olulised, vaid ka vajalikud asjad.
Kokkuvõtteks tahaksin märkida , minu arvates peegeldades kasutajate ootusi avatud lähtekoodiga projektist:
Ma mõtlen tõsiselt sellele OS-ile ülemineku üle (vähemalt proovige. Nad tegelevad sellega aktiivselt ja teevad lahedaid asju).
PS Sees Meil on koguni kolm aruannet. Üks avatud lähtekoodiga ja kaks manustatud (ja üks on praktiline). Stendil viime läbi mikrokontrollerite programmeerimise meistriklassi . Nagu tavaliselt, viime riistvara kaasa ja laseme selle programmeerida. Toimub ka quest ja muud tegevused. Tulge festivalile ja meie stendile, see saab olema lõbus.
Allikas: www.habr.com