Tento týden se v Petrohradu koná IT festival . Jedním z řečníků bude Richard Stallman. také se účastní festivalu, a samozřejmě jsme nemohli pominout téma otevřeného softwaru. Proto jeden z našich příspěvků nese název . Bude se věnovat historii vývoje Embox jako otevřeného projektu. V tomto článku chci vyprávět o hlavních myšlenkách, které, podle mého názoru, ovlivňují vývoj opensource projektů. Článek, stejně jako příspěvek, je založen na osobních zkušenostech.
Začněme jednoduše, s definicí pojmu opensource. Je zřejmé, že projekt s otevřeným zdrojovým kódem je projekt, který má jednu z licencí, které umožňují přístup k zdrojovému kódu projektu. Kromě toho otevřený projekt předpokládá možnost provádění změn třetími vývojáři. To znamená, že pokud nějaká společnost nebo vývojář zveřejní kód svého produktu, částečně nebo úplně, nečiní to automaticky tento produkt opensource projektem. A konečně, jakákoli projektová činnost by měla vést k vzniku nějakého výsledku, přičemž otevřenost projektu předpokládá, že tento výsledek používají nejen sami vývojáři.
Problematiku otevřených licencí se dotýkat nebudeme. To je příliš velké a složité téma, které vyžaduje hluboké prozkoumání. Na toto téma bylo napsáno poměrně hodně dobrých článků a materiálů. Ale protože sám nejsem odborníkem v oblasti autorského práva, řeknu jen to, že licence by měla odpovídat cílům projektu. Například pro Embox bylo zvolení licence BSD namísto GPL náhodné.
Skutečnost, že otevřený projekt musí umožnit provádění změn a ovlivňování vývoje otevřeného projektu, předpokládá, že projekt je distribuovaný. Řídit ho, zachovat jeho integritu a funkčnost je mnohem obtížnější ve srovnání s projektem, který má centralizované řízení. Objevuje se rozumná otázka, proč vůbec vytvářet otevřené projekty. Odpověď leží v oblasti obchodní efektivity; pro určitou třídu projektů převažuje přínos takového přístupu nad náklady. To znamená, že ne pro všechny projekty se otevřený přístup hodí a je vůbec přijatelný. Například je obtížné si představit vývoj systému řízení elektrárny nebo letadla založeného na otevřeném principu. Ne, samozřejmě že do takových systémů by měly být zahrnuty moduly na základě otevřených projektů, protože to přinese řadu výhod. Ale za konečný produkt by měl někdo nést odpovědnost. I když je systém zcela založen na kódu otevřených projektů, vývojář, který vše zabalí do jednoho systému a vytvoří konkrétní sestavení a nastavení, tímto způsobem de facto uzavírá jeho. Kód přitom může být veřejně dostupný.
Pro tyto systémy rovněž existuje celá řada výhod z vytváření otevřených projektů nebo účasti na nich. Jak jsem již řekl, kód konečného systému může zůstat ve veřejném přístupu. Proč, když je zřejmé, že jen těžko někdo najde stejné letadlo, aby otestoval systém? To je pravda, ale může se najít někdo, kdo si chce ověřit jednotlivé části kódu, nebo například může někdo zjistit, že používaná knihovna není zcela správně nakonfigurována.
Ještě větší výhoda se objevuje, pokud společnost vyčlení určitou základní část systému do samostatného projektu. Například knihovnu pro podporu nějakého protokolu pro výměnu dat. V tomto případě, i když je protokol specifický pro danou oblast, lze rozdělit náklady na údržbu této části systému mezi další společnosti z této oblasti. Navíc specialistům, kteří mohou tento kus systému studovat v otevřeném přístupu, potřebuje mnohem méně času na jeho efektivní využití. A nakonec, vyčlenění části do samostatné entity, kterou používají externí vývojáři, umožňuje tuto část zlepšit, protože je třeba nabídnout efektivní API, vypracovat dokumentaci, a to nemluvím o zlepšení testovací pokrytí.
Kompletní finanční výhody může společnost získat i bez vytváření otevřených projektů, stačí, aby její specialisté se zapojili do externích projektů, které jsou využívány ve firmě. Vždyť všechny výhody zůstávají: zaměstnanci lépe znají projekt, a tím efektivněji ho využívají, společnost může ovlivnit směr rozvoje projektu, a použití již hotového a odladěného kódu zjevně snižuje náklady společnosti.
Tímto výhody vytváření opensource projektů nekončí. Vezměme si takovou důležitou součást podnikání jako marketing. Pro něj je to velmi dobrý pískoviště, které umožňuje efektivně ocenit požadavky trhu.
A samozřejmě nelze zapomenout, že opensource projekt je efektivní způsob, jak se prezentovat jako nositel nějaké specializace. V některých případech to vůbec je jediný způsob, jak se dostat na trh. Například, Embox začínal jako projekt na vytvoření OSRV. Asi není třeba vysvětlovat, že existuje spousta konkurentů. Bez vytvoření komunity bychom jednoduše neměli zdroje k tomu, abychom projekt dostali k koncovému uživateli, tedy, aby projekt používali externí vývojáři.
Komunita je klíčová v opensource projektu. Umožňuje podstatně snížit náklady na správu projektu, vyvíjí a udržuje projekt. Dalo by se říci, že bez komunity vlastně není opensource projektu.
O tom, jak vytvořit a spravovat komunitu otevřeného zdroje, bylo napsáno mnoho materiálů. Abych nepřevyprávěl již známé skutečnosti, pokusím se zaměřit na zkušenosti Emboxu. Například velmi zajímavou otázkou je proces vytváření komunity. Mnozí hovoří o tom, jak spravovat existující komunitu, ale momenty jejího vzniku mnohdy opomíjejí, považujíce to za danost.
Hlavní pravidlo při zakládání komunity opensource projektu je — žádná pravidla. Mám na mysli, že univerzální pravidla neexistují, stejně jako stříbrná kulka, alespoň proto, že projekty jsou velmi odlišné. Těžko lze používat stejné pravidla při zakládání komunity pro knihovnu logování na js a pro nějaký specializovaný ovladač. Navíc se během různých fází vývoje projektu (a tedy i komunity) pravidla mění.
Embox začínal jako studentský projekt, protože jsme měli přístup ke studentům katedry systémového programování. V podstatě jsme vstupovali do nějaké jiné komunity. Členy této komunity, studenty, jsme mohli zaujmout zajímavou průmyslovou praxí odpovídající jejich specializaci, vědeckými pracemi v oblasti systémového programování, bakalářskými a diplomovými pracemi. To znamená, že jsme splnili jedno z hlavních pravidel organizace komunity, účastníci komunity by měli něco získat, přičemž tato cena by měla odpovídat příspěvku účastníka.
Další fází pro Embox bylo hledání externích uživatelů. Je velmi důležité chápat, že uživatelé jsou plnohodnotnými účastníky opensource komunity. Uživatelů je obvykle více než vývojářů. A aby se stali přispěvateli projektu, začnou ho nejprve tak či onak používat.
Prvními uživateli pro Embox byla katedra Teoretické Kybernetiky. Navrhli vytvořit alternativní firmware pro Lego Mindstorm. I když to byli stále místní uživatelé (s kterými jsme se mohli osobně setkat a prodiskutovat, co chtějí), byl to velmi dobrý zážitek. Například jsme vyvinuli ukázky, které bylo možné předvést ostatním, protože roboti jsou zábavní a přitahují pozornost. Nakonec jsme měli opravdu externí uživatele, kteří se začali ptát, co je Embox a jak to používat.
V této fázi jsme museli přemýšlet o dokumentaci a o prostředcích komunikace s uživateli. Samozřejmě, že jsme o těchto důležitých věcech přemýšleli i dříve, ale bylo to předčasné a nemělo to pozitivní efekt. Efekt byl spíše negativní. Uvedu pár příkladů. Používali jsme googlecode, jehož wiki podporovalo vícejazyčnost. Vytvořili jsme stránky v několika jazycích, přičemž to nebylo jen angličtina a ruština, v nichž jsme se s obtížemi mohli domlouvat, ale i němčina a španělština. Výsledkem bylo velmi trapné, když se někdo zeptal v těchto jazycích, ale my jsme vůbec nemohli odpovědět. Nebo jsme zavedli pravidla pro psaní dokumentace a komentování, ale protože se API měnilo poměrně často a zásadně, naše dokumentace se stala zastaralou a zaváděla spíše do omylu než aby pomáhala.
Nakonec všechny naše snahy, i když ne vždy správné, vedly k tomu, že se objevili externí uživatelé. Dokonce se objevil komerční zákazník, který chtěl, abychom pro něj vyvinuli vlastní OSRV. A my jsme to vyvinuli, protože máme zkušenosti a nějaké know-how. Musím zmínit i dobré a špatné momenty. Začnu s těmi špatnými. Jelikož byli mnozí vývojáři zapojeni do tohoto projektu na komerční bázi, komunitu, která byla již tak dost nestabilní, to rozdělovalo, což samozřejmě mělo dopad na rozvoj projektu. Dalším faktorem bylo, že směr projektu určoval jeden komerční zákazník, jehož cílem nebylo další rozvíjení projektu. Minimálně tento cíl nebyl hlavní.
Na druhé straně bylo několik pozitivních aspektů. Skutečně jsme získali externí uživatele. Nebyli to pouze zákazníci, ale i ti, pro které byl tento systém určen. Motivace účastnit se projektu vzrostla. Vždyť pokud můžete na zajímavé činnosti také vydělat, je to vždy příjemné. A hlavně, slyšeli jsme jedno přání zákazníků, které se nám tehdy zdálo absurdní, ale nyní je hlavní myšlenkou Emboxu, a to využít již vyvinutý kód v systému. Hlavní myšlenka Emboxu nyní spočívá ve využívání softwaru Linux bez Linuxu. Tedy hlavním pozitivním faktorem podporujícím další rozvoj projektu bylo uvědomění, že projekt využívají externí uživatelé a měl by řešit nějaké jejich problémy.
V té době už Embox překročil hranice studentského projektu. Hlavním omezujícím faktorem rozvoje projektu podle studentského modelu je motivace účastníků. Studenti se účastní, dokud se učí, a když absolvují, měla by se objevit jiná motivace. Pokud motivace не vznikne, student z projektu jednoduše odstoupí. Když vezmeme v úvahu, že se studenty nejprve musíme školit, dostáváme se k tomu, že dobří specialisté se stávají až při absolvování, ale jejich přínos k projektu, kvůli nezkušenosti, nebývá příliš velký.
Obecně hladce přecházíme k hlavnímu bodu, který nám umožňuje mluvit o vytvoření opensource projektu - k vytvoření produktu, který by řešil problémy svých uživatelů. Jak jsem již vysvětlil výše, hlavní vlastností opensource projektu je jeho komunita. A to, že účastníci komunity jsou především uživatelé. Ale odkud se mají vzít, když není čím se zabývat? Takže se ukazuje, že stejně jako u ne-opensource projektu, je třeba se soustředit na vytvoření MVP (minimálně životaschopného produktu), a pokud zaujme uživatele, kolem projektu vznikne komunita. Pokud se však budeme zabývat vytvářením komunity pouze prostřednictvím PR, psaním wiki ve všech jazycích světa, nebo správným git workflow na githubu, pravděpodobně to nebude mít smysl v raných fázích projektu. Samozřejmě, v odpovídajících fázích jsou to nejen důležité, ale také nezbytné věci.
Na závěr bych rád uvedl , podle mého názoru odrážející očekávání uživatelské komunity od opensource projektu:
Vážně uvažuji o přechodu na tento operační systém (alespoň to zkusit. Opravdu se na něm pilně pracuje a dělají se skvělé věci).
P. S. Na budeme mít hned tři přednášky. Jedna o open source a dvě o embedded (přičemž jedna bude praktická). Na stánku uspořádáme workshop na programování mikrokontrolérů s pomocí . Tradičně přivezeme hardware a dáme lidem příležitost programovat. Budou také úkoly a další aktivity. Přijďte na festival a k našemu stánku, bude to zábavné.
Zdroj: habr.com
