Tento týden se v Petrohradě bude konat IT festival . Jedním z řečníků bude Richard Stallman. se festivalu také účastní a samozřejmě jsme nemohli opomenout téma svobodného softwaru. Proto se jedna z našich zpráv jmenuje . Bude věnován historii vývoje Emboxu jako open source projektu. V tomto článku chci mluvit o hlavních myšlenkách, které podle mého názoru ovlivňují vývoj opensource projektů. Článek, stejně jako reportáž, vychází z osobní zkušenosti.
Začněme něčím jednoduchým, definicí pojmu opensource. Je zřejmé, že open source projekt je projekt, který má jednu z licencí, která umožňuje přístup ke zdrojovému kódu projektu. Otevřený projekt navíc znamená, že vývojáři třetích stran mohou provádět změny. To znamená, že pokud nějaká společnost nebo vývojář zveřejní kód svého produktu, částečně nebo úplně, ještě to z tohoto produktu nedělá opensource projekt. A konečně jakákoli projektová činnost musí vést k nějakému výsledku a z otevřenosti projektu vyplývá, že tento výsledek využívají nejen samotní vývojáři.
Nebudeme se dotýkat problémů otevřených licencí. Toto je příliš rozsáhlé a složité téma, které vyžaduje důkladné prozkoumání. Na toto téma bylo napsáno poměrně dost dobrých článků a materiálů. Protože ale sám nejsem odborník v oblasti autorských práv, řeknu pouze to, že licence musí splňovat cíle projektu. Například pro Embox nebyla volba BSD spíše než licence GPL náhodná.
Skutečnost, že projekt s otevřeným zdrojovým kódem by měl poskytovat možnost provádět změny a ovlivňovat vývoj projektu s otevřeným zdrojovým kódem, znamená, že je projekt distribuován. Jeho správa, udržování integrity a výkonu je mnohem obtížnější ve srovnání s projektem s centralizovanou správou. Nabízí se rozumná otázka: proč vůbec otevírat projekty? Odpověď leží v oblasti komerční proveditelnosti, u určité třídy projektů výhody tohoto přístupu převažují nad náklady. To znamená, že není vhodný pro všechny projekty a otevřený přístup je obecně přijatelný. Například je těžké si představit vývoj řídicího systému pro elektrárnu nebo letadlo na otevřeném principu. Ne, takové systémy by samozřejmě měly obsahovat moduly založené na otevřených projektech, protože to poskytne řadu výhod. Ale někdo musí být zodpovědný za konečný produkt. I když je systém zcela založen na kódu otevřených projektů, vývojář, který vše zabalil do jednoho systému a provedl konkrétní sestavení a nastavení, jej v podstatě uzavře. Kód může být veřejně dostupný.
Existuje také mnoho výhod pro tyto systémy z vytváření nebo přispívání do open source projektů. Jak jsem již řekl, koncový systémový kód může zůstat veřejně dostupný. Proč, protože je zřejmé, že je nepravděpodobné, že někdo bude mít stejné letadlo na testování systému. To je pravda, ale může se najít někdo, kdo bude chtít zkontrolovat určité části kódu, nebo například někdo zjistí, že používaná knihovna není nakonfigurována zcela správně.
Ještě větší přínos se jeví, pokud společnost alokuje některou základní část systému do samostatného projektu. Například knihovna na podporu nějakého protokolu pro výměnu dat. V tomto případě, i když je protokol specifický pro danou oblast, můžete sdílet náklady na údržbu této části systému s jinými společnostmi z této oblasti. Kromě toho specialisté, kteří mohou studovat tento kus systému ve veřejné doméně, potřebují mnohem méně času na jeho efektivní použití. A konečně, oddělení kusu do nezávislé entity, kterou používají vývojáři třetích stran, nám umožňuje tuto část vylepšit, protože musíme nabízet efektivní API, vytvářet dokumentaci, a to ani nemluvím o zlepšení pokrytí testů.
Společnost může získat komerční výhody bez vytváření open source projektů, stačí, aby se její specialisté podíleli na projektech třetích stran používaných ve společnosti. Všechny výhody ostatně zůstávají: zaměstnanci projekt lépe znají, proto jej efektivněji využívají, firma může ovlivnit směr vývoje projektu a použití hotového odladěného kódu samozřejmě snižuje náklady firmy.
Tím výhody vytváření opensource projektů nekončí. Vezměme si tak důležitou složku podnikání, jako je marketing. Pro něj je to velmi dobrý sandbox, který mu umožňuje efektivně vyhodnocovat požadavky trhu.
A samozřejmě nesmíme zapomínat, že opensource projekt je efektivní způsob, jak se prohlásit za nositele jakékoli specializace. V některých případech je to jediný způsob, jak vstoupit na trh. Například Embox začal jako projekt na vytvoření RTOS. Že je soutěžících hodně, asi není potřeba vysvětlovat. Bez vytvoření komunity bychom jednoduše neměli dostatek zdrojů na to, abychom projekt přinesli koncovému uživateli, tedy aby projekt začali používat vývojáři třetích stran.
Komunita je v opensource projektu klíčová. Umožňuje výrazně snížit náklady na řízení projektu, rozvíjet a podporovat projekt. Můžeme říci, že bez komunity neexistuje žádný opensource projekt.
O tom, jak vytvořit a spravovat komunitu projektů s otevřeným zdrojovým kódem, bylo napsáno mnoho materiálů. Abych nepřevyprávěl již známá fakta, zkusím se zaměřit na zážitek z Emboxu. Velmi zajímavou záležitostí je například proces vytváření komunity. To znamená, že mnozí říkají, jak spravovat existující komunitu, ale okamžiky jejího vzniku jsou někdy přehlíženy, protože to je samozřejmé.
Hlavním pravidlem při vytváření komunity opensource projektů je, že neexistují žádná pravidla. Myslím tím, že neexistují žádná univerzální pravidla, stejně jako neexistuje žádná stříbrná kulka, už jen proto, že projekty jsou velmi odlišné. Je nepravděpodobné, že můžete použít stejná pravidla při vytváření komunity pro knihovnu protokolování js a nějaký vysoce specializovaný ovladač. Navíc v různých fázích vývoje projektu (a potažmo komunity) se pravidla mění.
Embox začal jako studentský projekt, protože měl přístup ke studentům z oddělení systémového programování. Ve skutečnosti jsme vstupovali do nějaké jiné komunity. Mohli bychom účastníky této komunity, studenty, v dobré průmyslové praxi zajímat o jejich specializaci, vědeckou práci v oblasti systémového programování, ročníkové práce a diplomy. To znamená, že jsme dodrželi jedno ze základních pravidel organizace komunity: členové komunity musí něco dostat a tato cena musí odpovídat příspěvku účastníka.
Další fází pro Embox bylo hledání uživatelů třetích stran. Je velmi důležité pochopit, že uživatelé jsou plnohodnotnými účastníky opensource komunity. Obvykle je více uživatelů než vývojářů. A aby se chtěli stát přispěvateli do projektu, začnou jej nejprve tak či onak využívat.
Prvními uživateli Emboxu byla katedra teoretické kybernetiky. Navrhli vytvořit alternativní firmware pro Lego Mindstorm. A ačkoli to byli stále místní uživatelé (mohli jsme se s nimi osobně setkat a probrat, co chtěli). Ale i tak to byla velmi dobrá zkušenost. Vyvinuli jsme například dema, která by se mohla ukázat ostatním, protože roboti jsou zábavní a přitahují pozornost. Výsledkem bylo, že jsme získali skutečně uživatele třetích stran, kteří se začali ptát, co je Embox a jak jej používat.
V této fázi jsme museli přemýšlet o dokumentaci, o prostředcích komunikace s uživateli. Ne, samozřejmě jsme o těchto důležitých věcech přemýšleli dříve, ale bylo to předčasné a nepřineslo to pozitivní efekt. Efekt byl spíše negativní. Dovolte mi uvést několik příkladů. Použili jsme googlecode, jehož wiki podporovala vícejazyčnost. Vytvořili jsme stránky v několika jazycích, nejen v angličtině a ruštině, ve kterých jsme se téměř nedomluvili, ale také v němčině a španělštině. Ve výsledku to na dotaz v těchto jazycích vypadá velmi směšně, ale neumíme vůbec odpovědět. Nebo zavedli pravidla o psaní dokumentace a komentování, ale jelikož se API měnilo poměrně často a výrazně, ukázalo se, že naše dokumentace byla zastaralá a byla spíše zavádějící, než pomáhala.
V důsledku toho všechny naše snahy, i ty nesprávné, vedly k tomu, že se objevili externí uživatelé. A dokonce se objevil i komerční zákazník, který chtěl, aby pro něj byl vyvinut jeho vlastní RTOS. A vyvinuli jsme to, protože máme zkušenosti a nějaké základy. Zde je třeba mluvit o dobrých i špatných okamžicích. Začnu těmi špatnými. Vzhledem k tomu, že do tohoto projektu bylo zapojeno mnoho vývojářů na komerční bázi, byla komunita již značně nestabilní a rozdělená, což samozřejmě nemohlo ovlivnit vývoj projektu. Dalším faktorem bylo, že směřování projektu udával jeden komerční zákazník a jeho cílem nebyl další rozvoj projektu. Alespoň to nebyl hlavní cíl.
Na druhou stranu tu byla řada pozitivních aspektů. Máme skutečně uživatele třetích stran. Nebyl to jen zákazník, ale i ti, pro které byl tento systém určen. Zvýšila se motivace k účasti na projektu. Koneckonců, pokud můžete také vydělat peníze zajímavým obchodem, je to vždy příjemné. A hlavně jsme slyšeli od zákazníků jednu touhu, která nám v té době připadala šílená, ale která je nyní hlavní myšlenkou Emboxu, totiž použít v systému již vyvinutý kód. Nyní je hlavní myšlenkou Emboxu používat Linuxový software bez Linuxu. To znamená, že hlavním pozitivem přispívajícím k dalšímu rozvoji projektu bylo zjištění, že projekt využívají uživatelé třetích stran a měl by vyřešit některé jejich problémy.
Embox v té době již přesahoval rámec studentského projektu. Hlavním limitujícím faktorem při vývoji projektu podle studentského modelu je motivace účastníků. Studenti se účastní při studiu, a když absolvují, měla by být jiná motivace. Pokud se motivace nedostaví, student se prostě přestane projektu účastnit. Vezmeme-li v úvahu, že je potřeba studenty nejprve zaškolit, ukáže se, že se z nich stávají dobří specialisté v době, kdy dostudují, ale jejich přínos pro projekt díky nezkušenosti není příliš velký.
Obecně plynule přejdeme k hlavnímu bodu, který nám umožňuje hovořit o vytvoření opensource projektu – vytvoření produktu, který by řešil problémy jeho uživatelů. Jak jsem vysvětlil výše, hlavní vlastností opensource projektu je jeho komunita. Členové komunity jsou navíc především uživatelé. Ale odkud se berou, když není co použít? Ukazuje se tedy, že stejně jako u neopensource projektu se musíte zaměřit na vytvoření MVP (minimum životaschopného produktu), a pokud to uživatele zaujme, pak se kolem projektu objeví komunita. Pokud se zabýváte vytvářením komunity pouze prostřednictvím komunitního PR, psaním wiki ve všech jazycích světa nebo správným git workflow na githubu, pak je nepravděpodobné, že by na tom v raných fázích projektu záleželo. Samozřejmě, že ve vhodných fázích jsou to nejen důležité, ale také nezbytné věci.
Závěrem bych chtěl podotknout , podle mého názoru odrážející očekávání uživatelů od opensource projektu:
Vážně uvažuji o přechodu na tento OS (alespoň to zkus. Aktivně to provádějí a dělají skvělé věci).
PS zapnuto Budeme mít až tři zprávy. Jeden o open source a dva o embedded (a jeden je praktický). Na stánku provedeme master class o programování pomocí mikrokontrolérů . Jako obvykle přivezeme hardware a necháme vás naprogramovat. Nebude chybět ani hledání a další aktivity. Přijďte na festival a náš stánek, bude zábava.
Zdroj: www.habr.com