Tento týždeň sa v Petrohrade uskutoční IT festival . Jedným z rečníkov bude Richard Stallman. sa festivalu zúčastňuje aj my a samozrejme sme nemohli ignorovať tému slobodného softvéru. Preto sa jedna z našich reportáží volá . Bude venovaný histórii vývoja Emboxu ako open source projektu. V tomto článku chcem hovoriť o hlavných myšlienkach, ktoré podľa môjho názoru ovplyvňujú vývoj opensource projektov. Článok, rovnako ako správa, je založený na osobnej skúsenosti.
Začnime niečím jednoduchým, definíciou pojmu opensource. Je zrejmé, že open source projekt je projekt, ktorý má jednu z licencií, ktorá umožňuje prístup k zdrojovému kódu projektu. Okrem toho otvorený projekt znamená, že vývojári tretích strán môžu vykonávať zmeny. To znamená, že ak nejaká spoločnosť alebo vývojár zverejní kód svojho produktu, čiastočne alebo úplne, ešte to nerobí z tohto produktu opensource projekt. A napokon, každá projektová aktivita musí viesť k nejakému výsledku a z otvorenosti projektu vyplýva, že tento výsledok využívajú nielen samotní vývojári.
Nebudeme sa dotýkať problémov otvorených licencií. Ide o príliš rozsiahlu a zložitú tému, ktorá si vyžaduje hĺbkové preskúmanie. Na túto tému bolo napísaných pomerne veľa dobrých článkov a materiálov. Ale keďže sám nie som odborník v oblasti autorských práv, poviem len toľko, že licencia musí spĺňať ciele projektu. Napríklad pre Embox výber BSD a nie licencie GPL nebol náhodný.
Skutočnosť, že projekt s otvoreným zdrojovým kódom by mal poskytovať možnosť vykonávať zmeny a ovplyvňovať vývoj projektu s otvoreným zdrojovým kódom, znamená, že projekt je distribuovaný. Jeho riadenie, udržiavanie integrity a výkonu je oveľa náročnejšie v porovnaní s projektom s centralizovaným riadením. Vzniká rozumná otázka: prečo sa vôbec otvárajú projekty? Odpoveď spočíva v oblasti komerčnej realizovateľnosti; pre určitú triedu projektov výhody tohto prístupu prevažujú nad nákladmi. To znamená, že nie je vhodný pre všetky projekty a otvorený prístup je všeobecne prijateľný. Napríklad je ťažké predstaviť si vývoj riadiaceho systému pre elektráreň alebo lietadlo na otvorenom princípe. Nie, samozrejme, takéto systémy by mali obsahovať moduly založené na otvorených projektoch, pretože to prinesie množstvo výhod. Niekto však musí byť zodpovedný za konečný produkt. Aj keď je systém úplne založený na kóde otvorených projektov, vývojár, ktorý všetko zabalil do jedného systému a urobil konkrétne zostavy a nastavenia, ho v podstate zatvorí. Kód môže byť verejne dostupný.
Existuje tiež veľa výhod pre tieto systémy z vytvárania alebo prispievania do projektov s otvoreným zdrojovým kódom. Ako som už povedal, kód koncového systému môže zostať verejne dostupný. Prečo, pretože je zrejmé, že je nepravdepodobné, že niekto bude mať rovnaké lietadlo na testovanie systému. To je pravda, ale môže sa nájsť niekto, kto bude chcieť skontrolovať určité časti kódu, alebo napríklad niekto zistí, že používaná knižnica nie je celkom správne nakonfigurovaná.
Ešte väčším prínosom je, ak spoločnosť vyčlení niektorú základnú časť systému do samostatného projektu. Napríklad knižnica na podporu nejakého druhu protokolu výmeny údajov. V tomto prípade, aj keď je protokol špecifický pre danú oblasť, môžete zdieľať náklady na údržbu tejto časti systému s inými spoločnosťami z tejto oblasti. Navyše, špecialisti, ktorí môžu študovať tento kus systému vo verejnej sfére, potrebujú oveľa menej času na jeho efektívne používanie. A nakoniec, oddelenie časti na nezávislú entitu, ktorú používajú vývojári tretích strán, nám umožňuje túto časť vylepšiť, pretože musíme ponúkať efektívne rozhrania API, vytvárať dokumentáciu a to ani nehovorím o zlepšení pokrytia testov.
Spoločnosť môže získať komerčné výhody bez vytvárania open source projektov, stačí, aby sa jej špecialisti podieľali na projektoch tretích strán používaných v spoločnosti. Všetky benefity napokon ostávajú: zamestnanci projekt lepšie poznajú, preto ho efektívnejšie využívajú, firma môže ovplyvniť smer vývoja projektu a použitie hotového, odladeného kódu samozrejme znižuje náklady firmy.
Tým výhody vytvárania opensource projektov nekončia. Zoberme si takú dôležitú zložku podnikania, akou je marketing. Pre neho je to veľmi dobrý sandbox, ktorý mu umožňuje efektívne vyhodnocovať požiadavky trhu.
A samozrejme nesmieme zabúdať, že opensource projekt je efektívny spôsob, ako sa deklarovať ako nositeľ akejkoľvek špecializácie. V niektorých prípadoch je to jediný spôsob, ako vstúpiť na trh. Napríklad Embox začal ako projekt na vytvorenie RTOS. To, že konkurentov je veľa, asi netreba vysvetľovať. Bez vytvorenia komunity by sme jednoducho nemali dostatok zdrojov na to, aby sme projekt priviedli ku koncovému používateľovi, teda na to, aby ho začali používať vývojári tretích strán.
Komunita je v opensource projekte kľúčová. Umožňuje výrazne znížiť náklady na riadenie projektu, rozvíjať a podporovať projekt. Môžeme povedať, že bez komunity neexistuje žiadny opensource projekt.
O tom, ako vytvoriť a spravovať komunitu projektov s otvoreným zdrojovým kódom, bolo napísaných veľa materiálov. Aby som neprerozprával už známe fakty, skúsim sa zamerať na zážitok z Emboxu. Veľmi zaujímavým problémom je napríklad proces vytvárania komunity. To znamená, že mnohí hovoria, ako spravovať existujúcu komunitu, ale momenty jej vzniku sú niekedy prehliadané, pretože to považujeme za samozrejmosť.
Hlavným pravidlom pri vytváraní komunity opensource projektov je, že neexistujú žiadne pravidlá. Myslím tým, že neexistujú žiadne univerzálne pravidlá, rovnako ako neexistuje žiadna strieborná guľka, už len preto, že projekty sú veľmi odlišné. Je nepravdepodobné, že môžete použiť rovnaké pravidlá pri vytváraní komunity pre knižnicu protokolovania js a nejaký vysoko špecializovaný ovládač. Navyše v rôznych fázach vývoja projektu (a teda komunity) sa pravidlá menia.
Embox začal ako študentský projekt, pretože mal prístup k študentom z oddelenia systémového programovania. V skutočnosti sme vstupovali do inej komunity. Účastníkov tejto komunity, študentov, v dobrej priemyselnej praxi by sme mohli zaujať ich špecializáciou, vedeckou prácou v oblasti systémového programovania, ročníkovými prácami a diplomami. To znamená, že sme dodržali jedno zo základných pravidiel organizácie komunity: členovia komunity musia niečo dostať a táto cena musí zodpovedať príspevku účastníka.
Ďalšou fázou pre Embox bolo vyhľadávanie používateľov tretích strán. Je veľmi dôležité pochopiť, že používatelia sú plnohodnotnými účastníkmi opensource komunity. Zvyčajne je viac používateľov ako vývojárov. A aby sa chceli stať prispievateľmi do projektu, najprv ho začnú tak či onak využívať.
Prvými používateľmi Emboxu bola Katedra teoretickej kybernetiky. Navrhli vytvorenie alternatívneho firmvéru pre Lego Mindstorm. A hoci to boli stále miestni používatelia (mohli sme sa s nimi osobne stretnúť a diskutovať o tom, čo chceli). Ale aj tak to bola veľmi dobrá skúsenosť. Vyvinuli sme napríklad ukážky, ktoré by sa mohli ukázať ostatným, pretože roboty sú zábavné a priťahujú pozornosť. V dôsledku toho sme získali skutočne používateľov tretích strán, ktorí sa začali pýtať, čo je Embox a ako ho používať.
V tejto fáze sme museli myslieť na dokumentáciu, na prostriedky komunikácie s užívateľmi. Nie, samozrejme, predtým sme o týchto dôležitých veciach uvažovali, ale bolo to predčasné a neprinieslo to pozitívny účinok. Účinok bol skôr negatívny. Dovoľte mi uviesť niekoľko príkladov. Použili sme googlecode, ktorého wiki podporovala viacjazyčnosť. Stránky sme vytvorili vo viacerých jazykoch, nielen v angličtine a ruštine, v ktorých sme sa takmer nedorozumeli, ale aj v nemčine a španielčine. V dôsledku toho to vyzerá veľmi smiešne, keď sa nás pýtajú v týchto jazykoch, ale nevieme odpovedať vôbec. Alebo zaviedli pravidlá o písaní dokumentácie a komentovaní, no keďže sa API dosť často a výrazne menilo, ukázalo sa, že naša dokumentácia bola zastaraná a viac zavádzala ako pomáhala.
V dôsledku toho všetko naše úsilie, dokonca aj nesprávne, viedlo k objaveniu sa externých používateľov. A dokonca sa objavil aj komerčný zákazník, ktorý chcel, aby bol pre neho vyvinutý vlastný RTOS. A vyvinuli sme to, pretože máme skúsenosti a nejaké základy. Tu musíte hovoriť o dobrých aj zlých chvíľach. Začnem tými zlými. Keďže do tohto projektu bolo zapojených veľa vývojárov na komerčnej báze, komunita už bola dosť nestabilná a rozdelená, čo samozrejme nemohlo ovplyvniť vývoj projektu. Ďalším faktorom bolo, že smerovanie projektu určil jeden komerčný zákazník a jeho cieľom nebol ďalší rozvoj projektu. Aspoň to nebol hlavný cieľ.
Na druhej strane tu bolo viacero pozitívnych stránok. Máme skutočne používateľov tretích strán. Nebol to len zákazník, ale aj tí, ktorým bol tento systém určený. Zvýšila sa motivácia zapojiť sa do projektu. Koniec koncov, ak môžete zarobiť peniaze aj na zaujímavom obchode, je to vždy príjemné. A čo je najdôležitejšie, od zákazníkov sme počuli jednu túžbu, ktorá sa nám v tom čase zdala šialená, ale ktorá je teraz hlavnou myšlienkou Emboxu, a to použiť už vyvinutý kód v systéme. Teraz je hlavnou myšlienkou Emboxu používať softvér Linux bez Linuxu. To znamená, že hlavným pozitívnym aspektom, ktorý prispel k ďalšiemu rozvoju projektu, bolo zistenie, že projekt využívajú používatelia tretích strán a mal by vyriešiť niektoré ich problémy.
Embox už vtedy presahoval rámec študentského projektu. Hlavným limitujúcim faktorom pri vypracovaní projektu podľa študentského modelu je motivácia účastníkov. Študenti sa zúčastňujú počas štúdia a keď zmaturujú, motivácia by mala byť iná. Ak sa motivácia nedostaví, študent jednoducho prestane participovať na projekte. Ak zoberieme do úvahy, že študentov treba najskôr zaškoliť, ukáže sa, že po ukončení štúdia sa z nich stanú dobrí špecialisti, no ich prínos do projektu z dôvodu neskúsenosti nie je príliš veľký.
Vo všeobecnosti plynulo prejdeme k hlavnému bodu, ktorý nám umožňuje hovoriť o vytvorení opensource projektu – vytvorenie produktu, ktorý by vyriešil problémy jeho používateľov. Ako som vysvetlil vyššie, hlavnou vlastnosťou opensource projektu je jeho komunita. Okrem toho sú členmi komunity predovšetkým používatelia. Ale odkiaľ sa berú, keď nie je čo použiť? Ukazuje sa teda, že rovnako ako pri projekte, ktorý nie je opensource, sa musíte zamerať na vytvorenie MVP (minimum životaschopného produktu) a ak to používateľov zaujme, potom sa okolo projektu objaví komunita. Ak sa venujete vytváraniu komunity iba prostredníctvom komunitného PR, písania wiki vo všetkých jazykoch sveta alebo správneho pracovného postupu git na githube, potom je nepravdepodobné, že by to malo význam v počiatočných fázach projektu. Samozrejme, vo vhodných fázach sú to nielen dôležité, ale aj nevyhnutné veci.
Na záver by som chcel podotknúť , podľa môjho názoru, čo odráža očakávania používateľov od projektu s otvoreným zdrojom:
Vážne uvažujem o prechode na tento OS (aspoň to skúste. Aktívne sa tomu venujú a robia skvelé veci).
PS zapnuté Budeme mať až tri správy. Jeden o otvorenom zdroji a dva o embedded (a jeden je praktický). V stánku uskutočníme majstrovský kurz o programovaní mikrokontrolérov pomocou . Ako obvykle, hardvér dovezieme a necháme vás naprogramovať. Nebude chýbať ani pátranie a iné aktivity. Príďte na festival a do nášho stánku, bude zábava.
Zdroj: hab.com