Ta teden bo v Sankt Peterburgu potekal IT festival . Eden od govornikov bo Richard Stallman. sodeluje tudi na festivalu, seveda pa nismo mogli mimo teme brezplačnega programja. Zato se eno od naših poročil imenuje . Posvečen bo zgodovini razvoja Emboxa kot odprtokodnega projekta. V tem članku želim govoriti o glavnih idejah, ki po mojem mnenju vplivajo na razvoj odprtokodnih projektov. Članek, tako kot poročilo, temelji na osebnih izkušnjah.
Začnimo z nečim preprostim, z definicijo pojma odprtokodni vir. Očitno je odprtokodni projekt projekt, ki ima eno od licenc, ki omogoča dostop do izvorne kode projekta. Poleg tega odprt projekt pomeni, da lahko razvijalci tretjih oseb izvajajo spremembe. Se pravi, če neko podjetje ali razvijalec objavi kodo svojega izdelka, delno ali v celoti, to še ne pomeni, da je ta izdelek odprtokodni projekt. In končno, vsaka projektna dejavnost mora voditi do nekega rezultata, odprtost projekta pa pomeni, da tega rezultata ne uporabljajo samo razvijalci sami.
Ne bomo se dotikali problemov odprtih licenc. To je prevelika in zapletena tema, ki zahteva poglobljeno raziskavo. Na to temo je bilo napisanih kar nekaj dobrih člankov in materialov. Ker pa sam nisem strokovnjak na področju avtorskih pravic, bom rekel le to, da mora licenca ustrezati ciljem projekta. Na primer, za Embox izbira licence BSD namesto GPL ni bila naključna.
Dejstvo, da mora odprtokodni projekt zagotavljati možnost spreminjanja in vplivanja na razvoj odprtokodnega projekta, pomeni, da je projekt distribuiran. Upravljanje, ohranjanje integritete in učinkovitosti je veliko težje v primerjavi s projektom s centraliziranim upravljanjem. Postavlja se razumno vprašanje: zakaj sploh odpirati projekte? Odgovor je na področju komercialne izvedljivosti; za določen razred projektov so koristi tega pristopa večje od stroškov. To pomeni, da ni primeren za vse projekte in je odprt pristop na splošno sprejemljiv. Na primer, težko si je predstavljati razvoj krmilnega sistema za elektrarno ali letalo, ki temelji na odprtem principu. Ne, seveda bi morali takšni sistemi vključevati module, ki temeljijo na odprtih projektih, saj bo to zagotovilo številne prednosti. Nekdo pa mora odgovarjati za končni izdelek. Tudi če sistem v celoti temelji na kodi odprtih projektov, ga razvijalec, potem ko je vse zapakiral v en sistem in naredil posebne gradnje in nastavitve, v bistvu zapre. Koda je lahko javno dostopna.
Prav tako imajo ti sistemi veliko koristi od ustvarjanja ali prispevanja k odprtokodnim projektom. Kot sem že rekel, lahko končna sistemska koda ostane javno dostopna. Zakaj, saj je očitno, da je malo verjetno, da bo kdo imel isto letalo za testiranje sistema. To je res, a morda bo kdo želel preveriti določene dele kode ali pa bo na primer nekdo ugotovil, da knjižnica, ki se uporablja, ni povsem pravilno konfigurirana.
Še večja korist se pokaže, če podjetje nek osnovni del sistema dodeli v ločen projekt. Na primer knjižnica za podporo neke vrste protokola za izmenjavo podatkov. V tem primeru, tudi če je protokol specifičen za določeno predmetno področje, lahko stroške vzdrževanja tega dela sistema delite z drugimi podjetji s tega področja. Poleg tega strokovnjaki, ki lahko preučujejo ta del sistema v javni domeni, potrebujejo veliko manj časa za njegovo učinkovito uporabo. In končno, ločitev dela v neodvisno entiteto, ki jo uporabljajo razvijalci tretjih oseb, nam omogoča, da izboljšamo ta del, ker moramo ponuditi učinkovite API-je, ustvariti dokumentacijo in da o izboljšanju pokritosti testov niti ne govorim.
Podjetje lahko prejme komercialne koristi brez ustvarjanja odprtokodnih projektov; dovolj je, da njegovi strokovnjaki sodelujejo v projektih tretjih oseb, ki se uporabljajo v podjetju. Konec koncev ostajajo vse prednosti: zaposleni bolje poznajo projekt, zato ga učinkoviteje uporabljajo, podjetje lahko vpliva na smer razvoja projekta, uporaba že pripravljene, razhroščene kode pa očitno zmanjša stroške podjetja.
Prednosti ustvarjanja odprtokodnih projektov se tu ne končajo. Vzemimo tako pomembno komponento poslovanja, kot je trženje. Zanj je to zelo dober peskovnik, ki mu omogoča učinkovito ovrednotenje zahtev trga.
In seveda ne smemo pozabiti, da je odprtokodni projekt učinkovit način, da se razglasite za nosilca katere koli specializacije. V nekaterih primerih je to edini način za vstop na trg. Na primer, Embox se je začel kot projekt za ustvarjanje RTOS. Verjetno ni treba posebej razlagati, da je tekmovalcev veliko. Brez oblikovanja skupnosti enostavno ne bi imeli dovolj sredstev, da bi projekt pripeljali do končnega uporabnika, torej da bi projekt začeli uporabljati zunanji razvijalci.
Skupnost je ključna pri odprtokodnem projektu. Omogoča vam znatno zmanjšanje stroškov vodenja projekta, razvoj in podporo projekta. Lahko rečemo, da brez skupnosti odprtokodnega projekta sploh ni.
O tem, kako ustvariti in upravljati odprtokodno projektno skupnost, je bilo napisanega veliko gradiva. Da ne bom ponavljal že znanih dejstev, se bom poskušal osredotočiti na izkušnjo Emboxa. Na primer, proces ustvarjanja skupnosti je zelo zanimivo vprašanje. To pomeni, da mnogi govorijo, kako upravljati obstoječo skupnost, vendar so trenutki njenega nastanka včasih spregledani, saj menijo, da je to dano.
Glavno pravilo pri ustvarjanju odprtokodne projektne skupnosti je, da ni pravil. Hočem reči, da ni univerzalnih pravil, tako kot ni srebrne krogle, že zato, ker so projekti zelo različni. Malo verjetno je, da lahko uporabite ista pravila pri ustvarjanju skupnosti za knjižnico beleženja js in kakšen visoko specializiran gonilnik. Poleg tega se pravila spreminjajo na različnih stopnjah razvoja projekta (in s tem skupnosti).
Embox se je začel kot študentski projekt, ker je imel dostop do študentov iz oddelka za sistemsko programiranje. Pravzaprav smo vstopali v neko drugo skupnost. Udeležence te skupnosti, študente, bi lahko zanimali za dobro industrijsko prakso v njihovi specialnosti, znanstveno delo na področju sistemskega programiranja, tečajne naloge in diplome. Se pravi, sledili smo enemu od osnovnih pravil organiziranja skupnosti: člani skupnosti morajo nekaj prejeti in ta cena mora ustrezati prispevku udeleženca.
Naslednja faza za Embox je bilo iskanje uporabnikov tretjih oseb. Zelo pomembno je razumeti, da so uporabniki polnopravni udeleženci odprtokodne skupnosti. Ponavadi je več uporabnikov kot razvijalcev. In da bi želeli postati sodelujoči pri projektu, ga najprej začnejo tako ali drugače uporabljati.
Prvi uporabniki Emboxa so bili Oddelek za teoretično kibernetiko. Predlagali so ustvarjanje alternativne vdelane programske opreme za Lego Mindstorm. Pa čeprav so bili to še vedno lokalni uporabniki (lahko smo se osebno srečali z njimi in se pogovorili, kaj so želeli). A vseeno je bila zelo dobra izkušnja. Razvili smo na primer predstavitve, ki bi jih lahko pokazali drugim, saj so roboti zabavni in pritegnejo pozornost. Kot rezultat smo dobili resnično tretje uporabnike, ki so začeli spraševati, kaj je Embox in kako ga uporabljati.
V tej fazi smo morali razmišljati o dokumentaciji, o načinih komunikacije z uporabniki. Ne, seveda smo o teh pomembnih stvareh razmišljali že prej, vendar je bilo prezgodaj in ni dalo pozitivnega učinka. Učinek je bil precej negativen. Naj vam navedem nekaj primerov. Uporabili smo googlecode, katerega wiki je podpiral večjezičnost. Ustvarili smo strani v več jezikih, ne le v angleščini in ruščini, v katerih se komaj sporazumevamo, ampak tudi v nemščini in španščini. Posledično je videti zelo smešno, ko ga vprašamo v teh jezikih, vendar sploh ne moremo odgovoriti. Ali pa so uvedli pravila o pisanju dokumentacije in komentiranju, a ker se je API precej pogosto in bistveno spreminjal, se je izkazalo, da je naša dokumentacija zastarela in je bolj zavajala kot pomagala.
Posledično so vsa naša prizadevanja, tudi napačna, pripeljala do pojava zunanjih uporabnikov. In pojavil se je celo komercialni kupec, ki je želel, da se zanj razvije lasten RTOS. In razvili smo ga, ker imamo izkušnje in nekaj podlage. Tukaj se morate pogovarjati tako o dobrih kot o slabih trenutkih. Začel bom s slabimi. Ker je bilo veliko razvijalcev komercialno vključenih v ta projekt, je bila skupnost že precej nestabilna in razdeljena, kar seveda ni moglo ne vplivati na razvoj projekta. Dodaten dejavnik je bil, da je smer projekta zastavil en komercialni naročnik, njegov cilj pa ni bil nadaljnji razvoj projekta. Vsaj to ni bil glavni cilj.
Po drugi strani pa je bilo nekaj pozitivnih vidikov. Dobili smo resnično tretje osebe. Ni šlo samo za stranko, ampak tudi za tiste, ki jim je bil ta sistem namenjen. Motivacija za sodelovanje v projektu se je povečala. Konec koncev, če lahko zaslužiš tudi z zanimivim poslom, je vedno lepo. In kar je najpomembneje, od strank smo slišali eno željo, ki se nam je takrat zdela nora, zdaj pa je glavna ideja Emboxa, in sicer, da bi v sistemu uporabili že razvito kodo. Zdaj je glavna ideja Emboxa uporaba programske opreme Linux brez Linuxa. To pomeni, da je bil glavni pozitivni vidik, ki je prispeval k nadaljnjemu razvoju projekta, spoznanje, da projekt uporabljajo tretji uporabniki in naj bi rešil nekatere njihove težave.
Takrat je Embox že presegel okvire študentskega projekta. Glavni omejitveni dejavnik pri razvoju projekta po študentskem modelu je motivacija udeležencev. Študenti sodelujejo med študijem, ko diplomirajo, pa bi morala biti drugačna motivacija. Če se motivacija ne pojavi, študent preprosto preneha sodelovati pri projektu. Če upoštevamo, da je študente najprej treba usposobiti, se izkaže, da z diplomo postanejo dobri strokovnjaki, njihov prispevek k projektu pa zaradi neizkušenosti ni zelo velik.
Na splošno gladko preidemo na glavno točko, ki nam omogoča govoriti o ustvarjanju odprtokodnega projekta - ustvariti izdelek, ki bi rešil težave svojih uporabnikov. Kot sem pojasnil zgoraj, je glavna lastnost odprtokodnega projekta njegova skupnost. Poleg tega so člani skupnosti predvsem uporabniki. Toda od kod prihajajo, ko ni ničesar za uporabiti? Izkazalo se je, da se morate tako kot pri projektu, ki ni odprtokoden, osredotočiti na ustvarjanje MVP (minimum viable product) in če bo to zanimalo uporabnike, se bo okoli projekta pojavila skupnost. Če se ukvarjate z ustvarjanjem skupnosti samo prek PR skupnosti, pisanja wikija v vseh jezikih sveta ali pravilnega poteka dela git na githubu, potem to verjetno ne bo pomembno v zgodnjih fazah projekta. Seveda v ustreznih fazah to niso samo pomembne, ampak tudi nujne stvari.
Na koncu bi rad poudaril , po mojem mnenju odraža pričakovanja uporabnikov od odprtokodnega projekta:
Resno razmišljam, da bi prešel na ta OS (vsaj poskusi. Tega se aktivno ukvarjajo in delajo kul stvari).
PS Vklopljeno Imeli bomo kar tri poročila. Ena o odprtokodnosti in dve o vdelanih (in ena je praktična). Na stojnici bomo izvedli mojstrski tečaj o programiranju mikrokrmilnikov z uporabo . Kot običajno vam bomo prinesli strojno opremo in jo programirali. Potekale bodo tudi quest in druge aktivnosti. Pridite na festival in našo stojnico, zabavno bo.
Vir: www.habr.com