Tématu open source se v poslední době věnujeme čím dál více. Trend se objevuje v oblasti software i hardware a hodně se o něm mluví mezi vývojáři i distributory. Většinou se zmiňují výhody, jako je snadná dostupnost, široký výběr zdrojů, přístup a licence zdarma. To je běžný rys pro všechny věci, které chce někdo prodat. I když to může svádět k dojmu, že volně dostupný zdroj je ideální volbou pro urychlení vývoje a snížení nákladů, má to svá ale. Řada stinných stránek se vyskytuje v obecné rovině, ať jde o aplikační software, různé embedded RTOS nebo hardwarové produkty.
Bezpečnost na prvním místě
Vezmeme-li důsledně v úvahu požadavky a regulace bezpečnosti IT a informační infrastruktury a všechna doporučení Secure by design, můžeme otevřené zdroje téměř vyloučit u systémů, kde potřebujeme mít stoprocentní kontrolu nad firmware, aplikačními i osobními daty. Je téměř nemožné garantovat bezpečnost něčeho, nad čím nemáme žádnou kontrolu. Kdo zaručí, že knihovna verze 1.22.44.128 bude mít stejné bezpečnostní vlastnosti jako verze 1.22.44.129? Nikdo. Jak dlouho bude nutné čekat na záplatu bezpečnostní díry? Nevíme. Ručí někdo, že se skrz komunitu nedostane do zdroje nějaký kritický kód? Nikoli.
Vzhledem k tomu, že vrstva aplikace, která využívá otevřený sw a hw zdroje ovlivňuje funkčnost celého systému nad ní, představuje otevřenost neakceptovatelné riziko pro aplikaci i uživatelská data. Tato otázka není kritická pro serverové aplikace, kde se o bezpečnost postarají dva nebo tři redundantní bezpečnostní systémy, u IoT aplikací a embedded systémů, kde se počítá každý bit a spotřebovaný mA z baterie, jde o hodně.
Funkčnost není 100%, ale to se nějak udělá
Před zahájením vývoje s využitím open source je vhodné provést důkladnou analýzu zadání a vhodnosti daného systému. Ve chvíli, kdy volně dostupný zdroj splní sotva 60% funkčních požadavků, je lepší poohlédnout se po jiné cestě. Různé nadstavby a můstky, které musí překlenout nedostatky, vedou k prodloužení vývoje a opět přinášejí riziko kompatibility. Ladění takto poslepovaného produktu není nikdy jednoduché a znamená ztrátu cenných člověkoměsíců.
Otevřené zdroje jsou také často „neprofesionální“, protože přímočaře řeší funkčnost bez kontroly, zabezpečení a ochrany před chybami. Většinou tak není ošetřeno zabezpečení dat, kontroly zápisů do pamětí, opakované čtení a další věci, které se u profesionálního návrhu očekávají. Dobře to vystihuje rčení „Nerozbije se to způsobem, který autor nezamýšlel“. Do open source zdrojů se dostávají i funkce, které fungují jen při dodržení určitých podmínek. Když se stane cokoli jiného, fungovat to přestane. Vstup do zdrojů za účelem ošetření všech rizikových stavů je v podstatě nemožný.
Zde se do hry dostává také dostupnost a kvalita dokumentace. U open source lze s jistotou konstatovat, že dokumentace je také komunitní záležitostí. Tomu odpovídá její obsah, struktura i verzování. Pod označením komunitní záležitost si lze představit cokoli, od hodně veselých večírků v oblacích kouře doprovázených skelnými pohledy aktérů a na druhé straně tichého samotáře, který právě objevil, jak ovládat GPIO. V případě pochybností nebo chyb je velmi složité cokoli najít a téměř nemožné cokoli s jistotou ověřit, protože u open source neexistuje žádný standard ani minimální požadavky.
Stejně zbytečné je v případě open source také spoléhat na podporu. Plnohodnotná a garantovaná podpora neexistuje. Samozřejmě přichází v úvahu oblíbená cesta diskuzních fór a sociálních sítí. Jak potvrzují zkušenosti, výsledkem je, že tazatel se dozví, že je to tak jednoduché, že to není třeba řešit. Variantou je, že se nedozví nic, protože si nikdo neví rady nebo proto, že problém nikoho nezajímá. V českém prostředí se často dozví obě věci najednou.
Životní cyklus zdroje vs. životní cyklus produktu
Stejně jako „velkého“ software se embedded systémů týká otázka životnosti otevřených zdrojů. O tom, jak dlouho bude použitelná stávající verze hw nebo sw, rozhoduje mnoho faktorů. Zájmy komunity, zpravidla podpořené zájmy silných komerčních hráčů, se ne vždy shodují s tím, co využívá jeden projekt. Často se tedy stává, že nutná změna verze open source zdroje vyvolá potřebu změn navazujících částí hardwarových modulů nebo programového kódu. To v praxi znamená zopakovat celý vývoj i v době, kdy by jinak navržený produkt mohl v klidu dožít bez jakéhokoli zásahu.
Situace, kdy je firma nucena opakovat vývoj z důvodu nedostupnosti součástek, operačních systémů nebo knihoven patří k nejhorším. Obvykle se o tom dozvíme ze zkušeností: Kdybychom to věděli, napsali jsme si to od začátku sami. K tomu může dojít, i když je do systému potřeba implementovat další funkce, na které původně vybraný a dostupný otevřený zdroj nestačí. Na rozdíl od korporátního vývoje, kde je funkce produktu pečlivě definována a implementována ve 100% rozsahu a později se se změnou nepočítá, vývoj v malém, včetně startupů, postupuje jinak. Dobrý produkt je potřeba neustále zdokonalovat a přidávat další funkce, služby a vychytávky.
Duševní vlastnictví
Zajímavá otázka, která se znovu váže také s bezpečností. Při použití open source je nutné důkladně ověřit licenční podmínky.
Mnoho systémů vychází z filozofie, že cokoli, postavené s jejich využitím, podléhá stejným licenčním podmínkám. Jednoduše řečeno, pokud máte free/open RTOS, je celá vaše aplikace free a celá komunita ji má mít k dispozici. To si u profesionálního projektu přeje málokdo. Je sice možné to nedodržet, ale je nemožné se jakkoli bránit v případě, kdy dojde k jakémukoli prolomení aplikace.
Tuto premisu po nebo tvrzují i komerční projekty, které se k open source hlásí. Většinou jde o polotovary nebo kity, které cílí právě na komunity a samy o sobě nejsou určeny pro vestavbu do cílové aplikace. Často mezi nimi najdeme modulární stavebnice, na kterých lze postavit demo senzorového nebo robotického řešení, ale pro profesionální návrh jim chybí buď robustnost, nebo nesplňují další kritéria bezpečnosti, komunikace nebo optimalizace hardware z hlediska zatížení a spotřeby.
V případě, že je váš nápad geniální a má ambice stát se celosvětovým prodejním hitem, zapomeňte na open source také. Pro jakékoli patentové řízení je využití jakékoli volné technologie a duševního vlastnictví dalších stran problematické a znamená minimálně dlouhé zdržení a vysoké právní náklady.
Uzavřené systémy
Většinu rizik eliminují softwarové platformy, nabízené v rámci ekosystémů jednotlivých výrobců. Dnes se stalo standardem, že na úrovni vývoje s konkrétními čipovými sadami a kity jsou k dispozici zdarma a jejich funkčnost je plně garantována po dobu dostupnosti čipů. Ta je také jasně deklarována. Systémy tak poskytují maximální kompatibilitu programu s čipem, chybové stavy se vyskytují pouze výjimečně a dostupné knihovny jsou často lepší, než u open source projektů. Samozřejmostí je dokumentace, podpora a dostupnost nápadů v rámci globálních komunit.
Když vezmeme průměrný ekosostém výrobce, snaží se dnes v oblasti IoT aplikací připravit vývojové kity a příklady kódů pro většinu aplikací, pro které chce svůj čipset prodat. Pro vývoj mají tyto kuchařky podobný účel, jako open source knihovny, tedy funkční vzorek podobného řešení. U proprietárních systémů je to ale s jistotou, že to na daném čipu bude chodit. V těchto ohledech výhody jednoznačně převažují.
Při posouzení nákladů je rozdíl mimimální. SDK a knihovny jsou u výrobců obvykle dostupné zdarma a cena je rozprostřena do ceny čipů. To je vlastně výhoda, protože korporátní zákazníci, kteří integrují desítky tisíc čipů, tak přispívají malým vývojářům.
Ve srovnání s open source je zde ještě jeden významný rozdíl. Nikoho nenapadne vzít sample kód z příkladu a použít ho jako základ své aplikace.
Technickým, bezpečnostním i vlastnickým problémům lze předejít pouze důsledným zvážením všech možných situací. Stále platí, že open source je nenahraditelný pro rychlé prototypování s vývoj funkčních vzorků pro ověření nápadu i sběru dat. Pro integraci do sériového produktu je nutné vzít v úvahu jeho limity a rizika. Čí dál víc ale platí, že vlastní vývoj znamená přidanou hodnotu pro zákazníka i pro vývojáře, protože od začátku do konce přináší detailní znalost vlastního produktu. A zákazník pozná, když firma svému produktu věří.
Komentáře
Poněkud tendenční
Tento článek mi přijde poněkud tendenční. Minimálně musím uvést na pravou míru to s licencováním FreeRTOS. Není pravda, že musíte vystavit kód. Cituji ze stránek freertos:
The FreeRTOS open source MIT license does not require you to expose your proprietary IP.
Co se týče záruk za běh systému, tak není moc dodavatelů, kteří dají za svůj produkt ruku do ohně. I ten Microsoft dodává software bez záruky. Ti, co za něj ručí si to nechají sakra zaplatit.
Schválně si přečtěte článek, jakou mají výrobci podporu u softwaru za stovky tisíc Kč: https://www.lupa.cz/clanky/nestrilejte-specialisty-aneb-co-zpusobilo-roz...
Nemyslím si, že je Opensource lepší, ale taky nemyslím, že je o tolik horší.
A nakonec by mě zajímalo, kolik z těch zaklínačů opensource, používají fatfs od ChaN.