Open Source Software v produkčním informačním systému organizace

Open Source Software v produkčním informačním systému organizace Miroslav Matuška Vysoká škola ekonomická v Praze

[email protected] Klíčová slova: Open Source Software, metodika MMDIS, IS/ICT podniku, informační manažer, vývoj IS, poskytování aplikačních služeb Abstrakt: Text se zabývá možnostmi využití otevřeného software - Open Source Software (OSS) - v informačních systémech podniků. Jde o řadu výhod nabízející trend, který může pomoci vedoucím informatiky ve firmách řešit některé problémy. V textu jsou uvedeny základní výhody otevřeného software, díky nimž podniky o OSS uvažují. Na příkladu životního cyklu metodiky MMDIS jsou uvedeny rozdíly mezi uzavřeným a otevřeným softwarem, dále jsou zmíněny změny a výzvy pro systémové integrátory, poskytovatele outsourcingu a aplikačních služeb. Závěr tvoří metodika pro konkrétní posuzování OSS a odpovědi na klíčové otázky týkající se celého fenoménu.

1. Otevřený software – dobrý sluha nebo zlý pán? Fenoménem posledních let v oblasti vývoje, distribuce a používání programového vybavení je tzv. Open Source Software (OSS). OSS vzniká jiným způsobem než klasický uzavřený software. Hlavním tvůrčím prvkem je tzv. komunita [7], což je neformální dobrovolné seskupení vývojářů, kteří mají zájem na vytvoření určité aplikace (nejčastěji proto, že ji sami potřebují). Kdokoli z komunity může dobrovolně napsat kus programového kódu a nabídnout jej ostatním. Sdílením výsledků práce všech vývoObr. č.1: Logo OSS operačního sysjářů a jejich poskytnutím dalším dochází tému Linux – tučňák “Tux” k úspoře práce a dalším pozitivním efektům. I přes značnou neformálnost vývoje s minimem projektového řízení (jde spíše o ideové vedení komunity) takto mohou vznikat i velmi komplexní projekty (např. webový server Apache, operační systém Linux – viz. obrázek č.1, a jiné). Výhodou otevřené práce v komunitě je sdílení duševních schopností širšího okruhu expertů, než je možné v rámci vývojářského týmu ve firmě. Svými zkušenostmi, komentáři a návrhy tak přispějí ke zlepšení vyvíjeného software. I méně zkušení vývojáři mohou prohlížet zdrojový kód a vylepšovat jej, například hledat bezpečnostní chyby. Úsilí komunity je pro jednu problémovou oblast koncentrováno k jednomu cíli a nevyvíjí se totéž vícekrát. Tím je vývoj v komunitě efektivnější než klasický přístup.

104

SYSTÉMOVÁ INTEGRACE 2/2004

Open Source Software v produkčním IS organizace

Jaké jsou motivace členů komunity? Proč se chovají tímto z pohledu ekonomie nevýhodným způsobem [6]? Již jsem zmínil řešení vlastních potřeb – nejsou spokojeni s programovým řešením určité oblasti a rádi by ho viděli jinak. Obětovaný čas a peníze (např. ušlý výdělek za dobu programování otevřeného software) jsou pro ně vynahrazeny fungující aplikací, která v komunitě vznikla. Dalším motivem tvorby OSS je snaha prezentovat své schopnosti mezi odborníky, upozornit na sebe a realizovat svou potřebu uznání u ostatních. I přes relativní tvůrčí svobodu je u větších OSS projektů potřeba koordinovat vývoj změn a směr dalšího rozvoje funkčnosti, což může být předmětem sporů v komunitě. Osoba dobrovolně akceptované autority (neformální „vůdce vývoje“) však pomáhá udržet jednotu ve vývoji. Jednotlivé přístupy k software s otevřeným zdrojovým kódem se liší podmínkami zpřístupnění zdrojového kódu a možností jeho nového použití stejně, jako se liší licenční podmínky užití software vyvíjeného klasicky (tzv. Closed Source Software, CSS). Souhrnně se otevřené přístupy označují jako Open Source Software (OSS) jako protiklad CSS. Lze se setkat i s příbuzným pojmem „Free software“. Slovo Free není v této souvislosti použito pouze jako „software zadarmo“ ([12], s nulovými pořizovacími náklady), ale jako programové vybavení s možností volby, bez závislosti na jediném dodavateli. Pojem „Open Source Software“ vedle dostupnosti zdarma akcentuje i otevřenost a svobodu změny, což pro laickou veřejnost vystihuje fenomén lépe. Otevřený přístup k vývoji software se ukazuje jako životaschopný v řadě oblastí a v posledních letech nachází své využití i v běžných činnostech typu výroba, služby a obchod. Právě použití v informačních systémech organizací, jeho výhodám, nevýhodám a trendům se věnuje tento text.

2. Otevřený software z hlediska informačního manažera podniku 2.1 Výhody OSS Nejvíce patrná výhoda – nulová nebo velmi nízká cena – není tou nejdůležitější. Při zvažování nákladů u dlouhodobých řešení nestačí srovnat jen pořizovací ceny, ale tzv. celkové náklady vlastnictví (TCO, Total Cost of Ownership) včetně provozních a dalších nákladů, které vzniknou. I přesto je nulová cena OSS výhodou, která snižuje náklady na vyzkoušení alternativního OSS řešení nebo náklady na změnu technologie. Mnohem důležitější výhodou je svoboda volby a nezávislost na dodavateli [12] při pozdějších rozhodováních. Rozdíl, který vyplyne až na konci období, za které se TCO počítá, může být nutnost pokračovat v nevýhodném (nákladově, funkčně) řešení, protože informační manažer (CIO) je determinován řešením předchozím. Existují tzv. náklady „na přepnutí“, které jsou běžně zahrnovány až do kalkulace nového řešení – a ty jsou díky otevřenosti u OSS minimální. Situace, kdy dodavatel uzavřeného software změní svou licenční politiku pro zákazníky nevýhodným způsobem [15], a ti přesto nemají možnost přejít k levnější či výhodnější alternativě, není neobvyklá.


105

Miroslav Matuška

Proces přizpůsobování software (např. ASW) na míru potřebám organizace je většinou časově náročná a nákladná část implementace nového řešení. V době výběru vhodného software není celkový rozsah těchto úprav znám – a ty jsou pak řešeny později ad-hoc konzultacemi, což zvyšuje původně uvažované náklady řešení (jev častý zejména u implementací velkých ERP systémů). U OSS může změny provést de facto kdokoliv a podnik si může najmout experty z větší skupiny odborníků, což vede i ke snížení ceny přizpůsobení. Výhodami OSS jsou také časem prověřený výkon a stabilita u déle existujících projektů. Z mnoha důvodů není možné při vývoji klasickým způsobem dosáhnout stavu, kdy je software bezvadně odladěný z hlediska chyb i maximálního výkonu (omezená skupina vývojářů a testerů, nutnost ukončit vývoj do určitého termínu). Vývojáři OSS mají naopak snahu, aby software fungoval bezchybně a rychle (protože ho většinou budou sami používat) a věnují vývoji a opravám kódu větší úsilí. To se násobí tím, jak kód optimalizují další členové komunity. Na řadě úloh je tak OSS stabilnější a odolnější vůči vnějším vlivům než klasicky vyvíjený a používaný software.

2.2 Faktory přispívající k popularitě trendu 2.2.1 Informační manažeři se orientují na levnější a operativnější řešení Pro informačního manažera podniku (CIO) je důležité volit pro implementaci taková řešení, která splní požadavky globální a informační strategie při minimálních nákladech [4], uvažovaných jako TCO. Celkové vyčíslení těchto nákladů však může vyžadovat informace, které nejsou v době rozhodnutí známé. OSS se díky stále se rozvíjejícím možnostem dostává do hledáčku informačních manažerů jako alternativní řešení. V poslední době dochází ke snižování rozhodovacího rizika a nejistoty u OSS a je na něm možno začít stavět některé obchodní služby. Důležitými faktory, které udávají směr trendu, je rostoucí funkční bohatost OSS, již určitým časem prověřená stabilita, vznikající podpora malých i velkých poskytovatelů služeb a rostoucí penetrace OSS spojená s pozitivní zpětnou vazbou.

2.2.2

Software jako komodita

Zajímavou skutečností je tzv. „komoditizace“ software ([3], [6]). V určitých oblastech (například webový server, kancelářský balík a další) došlo u programového vybavení ke konvergenci k víceméně ideální podobě funkčnosti. Tuto jasně definovanou funkčnost požaduje většina uživatelů a není důvod v těchto produktech implementovat odlišnosti. Při výběru komoditizovaných produktů je hlavním kritériem cena, což usnadňuje rozhodování. V procesu komoditizace nachází OSS uplatnění hned ze dvou důvodů: díky otevřenému zdrojovému kódu a koncentraci sil dochází k efektivnímu využití úsilí vývojářů (neopakuje se programování téhož) a díky nulové nebo nízké ceně je otevřený produkt velmi konkurenceschopný.

106



2.2.3

Vznik komerční podpory otevřených systémů

U klasicky vyvíjeného software je podpora jeho fungování garantována (např. smluvně) přímo výrobcem nebo jeho partnery. Z tohoto důvodu bylo OSS dlouho chápáno jako sice funkční a spolehlivý prostředek, který se ovšem z důvodu absence garantované podpory nehodí pro pokrytí životně důležitých záležitostí organizace. Riziko informační „nepodpory“ hlavních činností organizace není akceptovatelné a firmy nemohou založit chod svých systémů na neformální podpoře OSS produktů v komunitě (a to i přesto, že řeší připomínky a žádosti o pomoc velmi rychle). Zlom v této situaci znamenalo ohlášení podpory Open Source Software velkými výrobci hardware a software (mj. IBM – viz obrázek č.2, dále společnosti Sun, Intel, Oracle a další [13]). Ti nabízí pro svá řešení integrovaná s vybranými OSS produkty stejné garance, jako pro běžný komerční software. Přínosem nejsou jen záruky funkčnosti a nabídka technické podpory, ale i zvýšení důvěryhodnosti OSS jako takového a dále i finanční a právní záruky ohledně otázek, které mohou spolu s používáním OSS vyvstat. Vznikají také firmy specializované na poskytování konzultací a podpory k OSS projektům na komerční bázi.

Obr. č.2: Z reklamní kampaně společnosti IBM: „Peace, Love & Linux”

2.3 Položení otázek pro posouzení trendu Vzhledem k současně panující přímé konkurenci mezi oběma způsoby vývoje software je potřeba brát argumenty obou stran s rezervou a posoudit je na základě konkrétní situace. Pro zaujmutí stanoviska k použití OSS v podnikových informačních systémech je potřeba odpovědět alespoň na tyto otázky: Je proces tvorby OSS konzistentní a efektivní jako u klasického software? Je (případně v dohledné době bude) OSS natolik kvalitní, že je možné jej nasadit na životně důležité podnikové aplikace? Je podpora a nabízené služby u OSS na úrovni, kterou informační manažeři v podnicích pro své systémy požadují [4]? Jak OSS ovlivní práci systémového integrátora, outsourcingové organizace a poskytovatele aplikačních služeb (ASP)? Jak vypadá (bude vypadat) dlouhodobá ekonomická existence OSS a služeb na něm postavených, jaký bude obchodní model? Kdy je a kdy není vhodné nasadit OSS v IS organizace ? SYSTÉMOVÁ INTEGRACE 2/2004

107

Miroslav Matuška

3. Rozdíl mezi běžným a otevřeným přístupem k software ve vazbě na metodiku MMDIS Pro ilustrování odlišností v životním cyklu otevřeného a uzavřeného software jsem zvolil metodiku MMDIS, která cyklus rozděluje do sedmi fází [1], viz obrázek č.3. Rozdíly mezi OSS a CSS jsem uvedl jak z pohledu uživatelské organizace (např. výrobní neinformatický podnik), tak z pohledu dodavatele informačního systému (např. systémového integrátora nebo poskytovatele aplikačních služeb).

Provoz a údržba (PU)

Globální strategie (GST)

Informační strategie (IST)

Implementace (IM)

Úvodní studie (US)

Detailní analýza a návrh (DAN)

Globální analýza a návrh (GAN)

Obr. č.3: Schéma fází životního cyklu dle metodiky MMDIS

3.1 Vlivy OSS na úvodní fáze životního cyklu IS (GST, zejména IST, US, GAN) Globální (GST) a informační (IST) strategie [1] reprezentují strategickou úroveň řízení podniku, resp. jeho informačního systému. Podnik musí mít jasno, ke kterému cíli směřuje a jak se tam chce dostat. Tyto cíle a cesty má mít podporované informačními procesy specifikovanými v IST. Jak OSS změní již tyto úvodní fáze strategického řízení IS?

3.1.1

Pohled uživatelské organizace (fáze GST, IST, US)

Globální strategie ještě nebude otevřený software zmiňovat – ta se týká především hlavní činnosti podniku. V oblasti podpůrného zajištění hlavní činnosti však může zmiňovat obecnou orientaci na efektivní a úsporné kroky. V informační strategii podniku pak jako její důsledek bude zaměření na otevřená řešení reflektující dostupný ASW na trhu a současné trendy IS/IT. Jedním z těchto trendů je i OSS a možnost jej s výhodou použít pro informatickou podporu některých činností (zpočátku třeba jen okrajových). 108



Podnik, který s otevřeným softwarem dosud nemá zkušenost, může k tomuto trendu přistupovat opatrně a konzervativně – to by mu však nemělo bránit v dalším kole aktualizace IST reflektovat zkušenosti s OSS z jeho okolí nebo jeho vlastních zkušebních projektů. Do budoucna by největší překážka implementace OSS – náročnost na zajištění lidskými zdroji – měla klesat v souvislosti s rostoucí penetrací znalosti OSS systémů mezi kvalifikovanými IS/ICT pracovníky (mladí lidé o něm mají povědomí z univerzit, vlastních pokusů aj.). Stejně tak bude růst nabídka komerční podpory otevřeného software od dodavatelů různých informatických služeb [12]. Úvodní studie (US, [2]) odpoví na otázku proveditelnosti informační strategie přesněji. Detailní posouzení nákladů a jiných požadavků na implementaci OSS řešení pomůže zvážit jeho vhodnost pro konkrétní organizaci. To, co může v globálním pohledu vypadat jako zajímavý trend, se při uvažování zdrojů dostupných dané situaci v US může ukázat jako nevýhodné nebo neproveditelné – pak je nutno zvolit jinou variantu zavádění OSS nebo tento krok odložit. Na druhou stranu se může okrajová OSS aplikace ukázat jako klíčová pro úspěch, což by úvodní studie měla zachytit. Pokud je implementace OSS řešení příliš náročná, je možné ji zde rozdělit do několika sub-projektů (například implementace do vnitřních a vnějších IS zvlášť, pilotní realizace v obchodně nekritických částech IS, oddálení vlastního vývoje OSS aplikací a podobně).

3.1.2

Pohled dodavatele IS (fáze GST, IST, US)

V případě poskytovatele aplikačních služeb nebo systémového integrátora může GST vypadat velmi podobně, přičemž ze specifikovaného cíle poskytování diferencovaných služeb pro každého zákazníka vyplyne velmi široký záběr poskytovaných řešení – včetně OSS. SWOT analýza [1] by měla explicitně reflektovat tento trend jako výzvu a navazujícím faktorem úspěchu by měla být úspěšná integrace OSS řešení do nabídky služeb poskytovatele a její personální zajištění. Orientace na hodnoty, kterými OSS disponuje, jako například na sdílené znalosti, otevřené standardy, snadnou integraci, možnost ad-hoc změny, nezávislost na jednom výrobci [12], svobodnou licenční politiku a efektivní používaná řešení, by měla být u ASP explicitně zmíněna již v globální strategii (nebo přímo v poslání firmy). To se nevylučuje s poskytováním, vývojem nebo provozem proprietárních služeb a uzavřeného software tam, kde to je výhodnější, nebo kde si to zákazníci přejí. Nicméně existuje mnoho oblastí, kde se výše zmíněné hodnoty uplatní lépe. V návrzích všech architektur informační strategie (která na výše zmíněnou GST navazuje) se pak ideová volba OSS řešení objeví jako důsledek vznikajícího IS/ICT trendu a analýzy dostupného software. Součástí tohoto kroku bude též zvážení míry použití OSS (pouze testovací implementace, pilotní projekty, plnohodnotná část produktového portfolia, převažující realizace) a z toho plynoucí zajištění OSS zdroji. Jak konkrétně může OSS proměnit informační strategii poskytovatele aplikačních služeb nebo systémového integrátora? Výchozí stav nabízených služeb bude mít nejspíše některé nedostatky plynoucí z vlastností uzavřeného software (malá flexibilita a cenová náročnost řešení, obtížná integrace jednotlivých produktů mezi sebou, závislost na podpoře jediného výrobce aj.), které by bylo vhodné nějakým SYSTÉMOVÁ INTEGRACE 2/2004

109

Miroslav Matuška

způsobem změnit. Dle konceptuálního modelu IST to může vycházet z požadavků uživatelů nebo analýzy konkurence. Analýza trendů a dostupného software pak může nabídnout alternativní řešení – OSS. Jeho nasazení si ale vynutí změny ve vlastním IS/IT organizace (tzv. reengineering, [1]). Otevřený software nejvíce ovlivní technologickou a softwarovou architekturu (v obou případech zejména silnější vazbou na obecně dodržované standardy), dále aspekty právní (licenční otázky a problém copyrightu [7], [16], [17]) a pracovní (zajištění kvalifikovanými zaměstnanci). Tu nejvýraznější změnu IST a navazující úvodní studie (US) však podstoupí v okamžiku, kdy se poskytovatel informatických služeb rozhodne používat ne pouze již hotová OSS řešení, ale sám k nim přispívat a vyvíjet nová. V rámci IST to znamená změnit některé principy řízení vývoje a provozu IS/ICT. Není samozřejmě možné ponechat vývojovým a provozním zaměstnancům tvůrčí svobodu podobnou té, kterou mají k dispozici v komunitě. Nicméně je možné využít všech výhod sdílení znalostí s jinými vývojáři - při zachování citlivých zákaznických údajů uvnitř firmy. Může být tedy oslaben podíl jednání s dodavateli a klasického projektového řízení, nicméně vedení vývoje, termíny dokončování a odpovědnost musí stále existovat.

3.1.3

Společný pohled (GAN)

Globální analýza a návrh se při OSS přístupu nebude od klasického příliš lišit, protože se jedná o implementačně nezávislou analýzu funkčních a datových požadavků na vyvíjený systém nebo aplikaci. Tu je potřeba provést vždy, bez ohledu na nakonec vybrané řešení. Specifika OSS budou jistě zachycena ve školícím plánu pro vývojáře a uživatele, protože jde o zatím málo známou technologii. Analýza současného stavu informatiky také ukáže, které technologie bude nutno přidat nebo nahradit a případně navrhne realizaci zkušební Open Source Software laboratoře/pracoviště. Tím se už dostáváme k volbě konkrétních implementačních řešení, což je obsahem další fáze.

3.2 Vlivy OSS na pozdější fáze životního cyklu IS (DAN, IM, PU) Ve fázi detailní analýzy a návrhu (DAN, [2]) se může objevit potřeba změnit původně uvažované řešení jedním či druhým směrem. Například původně uvažovaná OSS aplikace může být funkčně nedostatečná a je nutno ji upravit nebo nahradit proprietární realizací – nebo naopak stejnou datovou základnu a funkční bohatost může být výhodnější realizovat pomocí OSS. Odlišnosti OSS se nejvíce projeví v případě, pokud se v rámci projektu vytváří nový ASW. Stejně jako v klasickém přístupu je potřeba dokončit procesní, datovou a funkční architekturu. S uvažováním OSS máme výhodu v možnosti importu již hotových otevřených architektur, které se osvědčily v jiných podobných použitích (a to zejména v případě dat a funkcí). Nové firemní postupy, procesy a organizační struktury však bude nutné s výjimkou izolovaných oblastí navrhnout a zkonzultovat klasickou cestou. OSS nabízí velký přínos v technologické oblasti, nicméně do ucelenosti a komplexnosti celých procesních postupů mu ještě mnoho schází. Příkladem těchto izolovaných oblastí mohou být intranetové/extranetové aplikace (například elektronický obchod), kde spolu s nasazením OSS získá podnik i některé postupy, jak tyto činnosti řešit. Určité zkušenosti a postupy sdílené

110



v komunitě existují, ale konkrétní řešení podnikové činnosti zůstává na každé organizaci zvlášť a patří k chráněným konkurenčním výhodám každé z nich. Hlavním polem dnešní působnosti OSS tak zůstávají komoditizované funkční oblasti, přičemž konkrétní odlišnosti si každá organizace dořeší a doimplementuje sama (za menšího úsilí než při klasickém přístupu). Ve fázi implementace OSS je velmi důležité rozhodnutí o konkrétní právní podobě řešení. Je možné volit z mnoha otevřených licencí [10], [18], např. GNU GPL, LGPL, BSD, MIT licence, případně si vytvořit licenci vlastní, kde budou specifikovány podmínky dalšího využití kódu (stane-li se součástí veřejného OSS kódu nebo zůstanou-li proprietární extenze uzavřené v rámci podniku). Česky psaný rozbor jednotlivých vlastností je možné nalézt například v [11], str. 63 – 72. Rychleji by také mohl probíhat proces testování a ladění nedostatků systému – jakákoliv analýza fungování kódu je Obr. .4: Logo sdružení GNU, publiv otevřeném prostředí vždy efektivnější. kujícího otevřenou GNU GPL licenci Zavádění již hotového systému musí projít stejnými postupy v obou případech. U správně navrženého systému jeho uživatelé ani nemusí vědět, jak byl konkrétně zrealizován – pokud budou zachována obecná pravidla o uživatelských rozhraních, příjemnosti používání, smysluplnosti funkcí, nebude ve školící a informační části pro uživatele mezi OSS a uzavřeným programovým systémem žádný rozdíl. Dokumentace k OSS bude mít v souladu s kódem, který komentuje, otevřenější charakter. Odlišnosti v provozu a údržbě budou spočívat v jiné periodě instalace bezpečnostních úprav a funkčních změnách – u OSS budou častější a menšího rozsahu, v případě uzavřeného řešení budou změny méně časté a ve větších celcích. Tato skutečnost vyplývá z okamžité možnosti v otevřeném přístupu funkční kód změnit, případně se vrátit k předchozímu stavu. Zajímavým fenoménem u OSS kódu je prolínání rolí programátora systému a jeho správce do jediné, kde drobné změny v otevřeném software provádí i provozní správce (a stejně tak bývá programátor prvním uživatelem a správcem jím vyvinutého systému). Nicméně hlavní specializace pracovníka (provozní nebo vývojový) zůstává zachována.

3.3 Vliv na práci systémového integrátora Na každou oblast podnikové činnosti existuje samostatné informatické řešení a u větších firem se nepřehlédnutelnou činností stává jejich vzájemná integrace do jednoho fungujícího celku (tzv. užší pojetí systémové integrace [1], bude popisováno i dále). Systémový integrátor má k dispozici určitá řešení od dodavatelů za různorodých podmínek pořízení a možností spolupráce. Na výsledné řešení musí systémový integrátor také poskytnout určitou záruku na fungování jako celku, protože se typicky jedná o kritickou součást podnikové existence. To z jeho strany SYSTÉMOVÁ INTEGRACE 2/2004

111

Miroslav Matuška

vyžaduje zajištění buď vlastními zkušenými pracovníky nebo externí konzultační firmou. Existence OSS není pro systémové integrátory hotovým ideálním řešením, ale může velmi významnou měrou snížit náklady a úsilí při integraci. Použitím standardizovaného softwaru dojde k širším možnostem zapojování dalších součástí podnikového informačního systému, bez vynucených proprietárních omezení. Možnost zasáhnout do zdrojového kódu a upravit si aplikaci je pro systémového integrátora velmi důležitá, pokud chce zajistit řešení skutečně podniku na míru [16] a nebýt závislý na předpřipravených balících s menší možností variability. V současné době není možné všechny komponenty podnikového informačního systému realizovat pomocí OSS. Téměř neprozkoumanou oblastí jsou pro OSS komplexní systémy typu ERP, CRM, jejichž klasický OSS vývoj prostřednictvím dobrovolného úsilí komunity je málo pravděpodobný [8]. Nicméně i zde existují snahy o komoditizaci a tvorbu zatím jednoduchých aplikací, které řeší problémy malých firem (např. projekt Compiere [9]). Tvůrci rekrutující se především z řad správců podnikových systémů těchto malých firem postupně dotváří moduly řešící jednoduché úkoly a jejich skládáním vznikají systémy složitější.

4. Existence OSS versus ekonomická realita Může OSS dlouhodobě existovat i bez odpovídající ekonomické vazby („odměny“) ke svým tvůrcům [6]? Zdá se, že ano – výhody, které přináší komunitě tvůrců a uživatelů, jsou tak významné, že klasicky chápaná peněžní odměna za tvůrčí práci nemusí být přítomna. Je ale možné realizovat i výdělečné ekonomické aktivity nad otevřeným softwarem ?

4.1 Obchodní modely postavené na OSS Je-li stabilita, robustnost a uživatelská přívětivost OSS produktu podobná nebo lepší ve srovnání s uzavřeným produktem, firmy se nemusí bránit využití OSS i v každodenních činnostech [3], například na místě kancelářského balíku. Pro běžné používání OSS při realizaci podnikových procesů je však hlavní podmínkou komerčně zajištěná podpora k nasazenému software. Podnik (resp. jeho CIO) bude pravděpodobně [4] potřebovat: • garanci fungování systému, • opravu chyb a bezpečnostních nedostatků, • vývoj a doplňování nových funkcí systému na míru chodu podniku. Tyto nekomoditizované úlohy může komunita poskytnout podniku jen v omezené míře (opravy chyb) nebo vůbec (úpravy na míru). Řešení originálních a nových problémů bude vždy vyžadovat velké úsilí tvůrců pro svou jedinečnost a tedy i významné náklady na toto konkrétní první řešení. To je také prostor pro ekonomickou aktivitu navázanou na OSS. V tomto obchodním modelu pak bude tvůrce a konzultant vydělávat na tom, co je originální, nové, unikátní, připravené na míru – bude vydělávat na jím přidané hodnotě. S trochou zjednodušení můžeme říci, že programátorské úsilí se přesune z opakovaného řešení obvyklých oblastí znovu a znovu do pozice přidávání nového 112



nebo přizpůsobování [16]. Originální rozšíření funkčnosti, která se posléze stanou součástí původního zdrojového kódu (a budou k dispozici komunitě) bude zpoplatněno – nicméně pouze jednou, v čase tvorby. V této souvislosti se nabízí otázka, proč by někdo uvolňoval otevřenou formou kód vyvinutý za velkého úsilí, o který je zájem, takže by za něj v uzavřeném licenčním schématu mohl získat velký ekonomický prospěch. To nevylučuji a dá se předpokládat, že by toto chování bylo obvyklé. Pokud by se však jednalo o aplikaci funkčně směrující ke komoditizaci, pak by o její vytvoření kvůli mnoha výhodám usilovala i komunita samotná, což by tak či tak vedlo k otevření kódu. Dá se proto očekávat, že vedle sebe budou koexistovat jak otevřená, tak uzavřená forma software. Představují pro sebe konkurenci a doplněk zároveň.

4.2 Tržní podíl OSS a licenční politika uzavřeného software Problémem pro vykazování přehledu používání OSS je měření tržního podílu druhů software jako finančního objemu prodaných kusů licencí. To není z podstaty OSS přesné. S novými obchodními modely založenými na jiných principech ([13], služby, proprietární extenze, apod.) by bylo dobré zachytit i tyto ekonomické vazby – například situaci, kdy podnik místo proprietárního software používá OSS. Přesnější čísla by mohla být získána sledováním charakteristik jako náklady na podporu a konzultace k nasazenému software, náklady na školení uživatelů, počet používaných instancí (ne počet zakoupených licencí) nebo podíl otevřeného a uzavřeného software (například jako v obrázku č.5).

Podíl serverových operačních systémů (2000)

Linux 25%

Netware 19%

Jiné 3%

Windows NT 38% Unix 15%

Obr. č. 5: Zdroj: „The Future of Linux“, CNet 2000, IDC V poslední době řada velkých výrobců změnila svou licenční politiku pro své zákazníky nevýhodným způsobem. Jde například o zkrácení intervalů, kdy musí zákazníci povinně pořídit k produktu upgrade, jinak na něj ztrácejí nárok (Microsoft Licensing 6.0, [15]). Tento interval je kratší, než CIO nutně potřebují a de facto je nutí k nákladům, které nejsou aktuálně nutné (starší verze splňuje všechny požadavky). Jiným případem je změna platebního kritéria – například z platby za rychlost procesoru na platbu za počet procesorů bez ohledu na rychlost (Oracle). Vzhledem k proprietárnosti jednotlivých produktů však není v takové situaci snadná možnost volby přejít na jiné řešení, náklady přechodu by byly příliš veliké. Software


113

Miroslav Matuška

na bázi OSS vrací možnost volby zpět do rukou informačních manažerů. CIO mohou zkusit alternativní řešení, které se nabízí s nižšími náklady.

4.2.1

OSS a poskytování informačních služeb

Poskytovatelé aplikačních a outsourcingových služeb mohou s výhodou využít OSS pro snížení jejich nákladů na zajištění služby, přičemž rozkládají nutné úvodní břemeno znalostí potřebných ke zvládnutí OSS mezi řadu zákazníků. Nepotřebují tak platit za licenci za každý nasazený produkt a zároveň efektivně využívají pracovní sílu, která se o provoz, rozvoj a úpravy OSS stará. Zároveň tím získají již zmíněné nefinanční výhody otevřeného software. Výhody sdílení se zde projeví ještě výrazněji – jakoukoliv novou funkčnost je možné díky otevřenosti přenést a zahrnout do poskytovaných služeb jinde (pokud k tomu dá zákazník souhlas). Vedle prostého sdílení nákladů na kvalifikovanou údržbu dochází i ke sdílení nákladů na samotnou tvorbu kódu. Možné je i sdílení procesních postupů ve firmách, přičemž se dá očekávat, že opakovaně implementovat se budou ty efektivnější a úspěšnější. Nasazení u poskytovatelů outsourcingu a ASP je možná tím nejvhodnějším začátkem pro komerční využívání OSS vůbec. Podniku jako koncovému zákazníku bude ve většině případů jedno, jakým způsobem je služba zajištěna (jestli pomocí proprietárního nebo otevřeného software), protože dostane od provozovatele záruky bez ohledu na interní realizaci služby. Tím zároveň OSS osvědčí své schopnosti být nasazen v běžné neinformatické uživatelské organizaci.

5. Metriky hodnocení použitelnosti OSS v organizaci V současné době neexistuje mnoho obecně použitelných metodik, které by popsaly rozhodovací proces při zavádění OSS do informačního systému organizace. Jednou z výjimek je například [11] nebo materiál „A Business Case Study of Open Source Software“ společnosti MITRE [5]. Základní kostra postupu dle [5] vypadá po zjednodušení takto: 1. Zhodnocení a výběr vývojářské komunity (resp. produktu). Optimální je komunita s jednotným ideovým vedením s řadou velmi schopných vývojářů, kteří produkt neustále udržují, rozvíjejí a uživatelům jsou k dispozici se základní podporou. Je možné zjišťovat referenční instalace a historii používání produktu – časem prověřená aplikace je dobrým kandidátem. 2. Průzkum trhu, zdali se zvyšuje se poptávka po tomto typu produktů a dá-li se očekávat, že bude vznikat/růst komerční podpora těchto systémů. 3. Provedení analýzy výhod a rizik OSS vzhledem ke konkrétní situaci. Studie MITRE [5] zmiňuje soubor kritérií, kterými je možno porovnávat různé kandidáty OSS software. Tato kritéria jsou podrobněji rozepsána v následující sekci. 4. Porovnání dlouhodobých nákladů pro variantu otevřeného a uzavřeného software. Pojem „celkové náklady“ může mít rozličný výklad, členění dle studie MITRE je uvedeno taktéž v následující sekci. 5. Závěrečný výběr strategie – informace získané v předchozích bodech by měly pomoci zvolit optimální podíl OSS, nakupovaného uzavřeného a proprietárně ad-hoc vyvíjeného software pro konkrétní použití. 114



Rozhodováním mezi nákupem aplikačního software a jeho vlastním vývojem je analogické u uzavřené i otevřené varianty. Nákupu uzavřeného ASW odpovídá použití nemodifikovaného (tedy dostatečně komoditizovaného) OSS. Jeho protipól – vlastní vývoj ASW – pak odpovídá nasazení OSS s mnoha zásadními úpravami, případně čistý vývoj celého ASW pod některou z open source licencí. Skutečná situace při reálném nasazení není žádný z těchto extrémů, ale poloha někde mezi, podle aktuální potřeby. Jde o kombinaci následujících charakteristik, další je možné najít například v [1]. Nákup (resp. nemodifikovaný OSS)

Vlastní vývoj (OSS nebo CSS)

Lacinější na pořízení

Dražší na pořízení

Potřeba zhodnotit, jestli funkčně odpovídá potřebám

Funkce odpovídají požadavkům

Nutno dodržet licenční omezení autora (dodavatele)

Nemusí být tak odladěný jako standardní produkt

Může vyžadovat pozdější nákladné úpravy

Vyžaduje více pracovní síly

Interval nových verzí a funkčnost určuje Obtížnější podpora vzhledem dodavatel (resp. autoři) k unikátnosti řešení Produkt bude více zkoumán z hlediska bezpečnostních nedostatků Údržbu a vývoj má pod kontrolou dodavatel (resp. autoři)

5.1 Kritéria pro posouzení vhodnosti nasazení OSS Taxonomie nákladů spojených s pořízením a provozem IS dle případové studie MITRE [5]. Ve třetím sloupci je doplněn příklad jeho hodnoty pro modelový OSS produkt. Přímé náklady – HW a SW

Položka

OSS – typický případ

Software

Pořizovací cena

Typicky zdarma

Aktualizace, upgrady, dodatky

Není poplatek za funkčnost navíc

Licenční poplatky (duševní vlastnictví)

Není poplatek za funkčnost ani uživatele navíc

Hardware

Pořizovací cena

Funguje na lacinějším HW

Upgrady, dodatky

Typicky není potřeba

V druhé tabulce, kde pokračuje výčet nákladových položek dle MITRE [5], je uveden jako příklad dostupnost těchto činností/služeb pro modelový uzavřený produkt.


115

Miroslav Matuška

Přímé náklady – podpora

Položka

Uzavřený software – typický případ

Interní

Instalace a nastavení

Dostupné

Externí

Údržba a provoz

Částečně dostupné

Řešení potíží

Typicky není možné zajistit

Podpůrné nástroje (knihy aj.)

Dostupné

Instalace a nastavení

Dostupné

Údržba a provoz

Dostupné

Řešení potíží

Dostupné

Dle výsledku studie MITRE [5] druh Přímé náklady – zaměstnanci použitého software (OSS nebo uzavřený) Projektový management náklady na zaměstnance v tabulce vlevo neurčuje. Určujícím faktorem je spíše Vývojáři, systémoví analytici konkrétní charakter projektu (zdali bude Administrátoři systému nový systém spíše vyvíjen nebo spíše Nákup, jednání s dodavateli nakoupen). Školení Poslední složkou nákladů, které je při rozhodování nutno brát v úvahu, jsou skryté Nespecifikované vlivy, které může být obtížné přímo zachytit. Odinstalace a likvidace Nepředstavují náklady navíc, ale ztrátu produktivity – zaměstnanci by se mohli věnovat produktivní práci, pokud by nemuseli provádět níže uvedené činnosti. Nepřímé náklady Položka

Příklad položky

Podpora mezi kolegy

Neformální pomoc mezi kolegy na pracovišti mezi sebou bez zásahu IT helpdesku

Neformální vzdělávání

Samovzdělávání zaměstnanců pro vyřešení aktuálního úkolu namísto formálního školení

Formální školení

Náklady na kurs, cestovné a ztráta z neúčasti pracovníka ve firmě

Rozvoj aplikace

Čas strávený psaním požadavků a testováním nových verzí systému

Faktor „Futz“

Čas, kdy pracovník zkoumá a využívá IT vybavení společnosti ze svých osobních (nepracovních) důvodů

Výpadky

Snížená produktivita z důvodu nefunkčnosti systému (plánovaná i neplánovaná), + přímé náklady na obnovu fungování

Druhým rozdělením, které je ve studii MITRE [5] uvedeno, je členění výhod a rizik OSS do určitých skupin. Tyto skupiny pak můžeme považovat za kritéria, podle kterých lze porovnat otevřené a uzavřené produkty, případně produkty z těchto skupin mezi sebou. 116



Název

Popis

Hodnocení

Schopnost přizpůsobení na míru

Možnost si SW upravit – omezení nepotřebných funkcí, přidání unikátních možností. Modularita a flexibilita použití pro různé účely

++

Dostupnost a spolehlivost

Podíl času, kdy je služba (systém) dostupná (vychází z vnitřní struktury kódu a možnosti testování mezi uživateli)

+

Interoperabilita

Spolupráce s jinými systémy, možnost existence v heterogenním prostředí, podpora výměny dat a otevřených protokolů

++

Škálovatelnost

Schopnost systému zvládnout nárůst uživatelů resp. funkčnosti bez nutnosti vyměnit podstatné součásti

+

Životnost

Délka existence systému v budoucnu, souvisí s délkou vývoje a „oficiální“ podpory

++

Výkon

Schopnost využívat výpočetní zdroje efektivně, záleží na pečlivosti programátorské práce

+

Kvalita navazujících služeb a podpory

Zejména cenová úroveň podpory a její dostupnost v pravý čas

+

Bezpečnost

Schopnost systému poskytovat funkce a data pouze určeným osobám, závisí na architektuře aplikace a pečlivosti provedení jak implementace, tak samotného provozu systému

0

Úroveň náročnosti správy a řízení

„Přátelskost“, intuitivnost pro obsluhu, logické seskupení souvisejících funkcí, možnost vzdálené administrace

0

Riziko fragmentace vývoje SW

Ucelenost koncepce vývoje software, jednotnost vedení

-

Dostupnost aplikací

Možnost realizovat požadované funkce pomocí již hotového software

- (až - -)

Hodnotící stupnice může vypadat například takto (je použita i v tabulce výše, z pohledu OSS oproti CSS): • ++ je vždy výraznou výhodou oproti alternativě • + typicky má výhodu oproti alternativě • 0 není možné jednoznačně určit výhody a nevýhody, záleží na konkrétní situaci • - typicky má nevýhodu oproti alternativě • - - má vždy výraznou nevýhodu oproti alternativě U komplikovanějších systémů a rozhodnutí je možno volit kritéria i složitěji a hodnotit je podle přidělených vah [1], odpovídajících důležitosti charakteristiky. SYSTÉMOVÁ INTEGRACE 2/2004

117

Miroslav Matuška

Použití OSS má pozitivní vliv na zlepšení celkové životnosti nasazovaného systému. Větší svoboda změn v kódu v porovnání s uzavřeným software umožní lépe přizpůsobovat existující systém novým situacím, čímž podniku déle vydrží bez zásadnější výměny. Existující podniková data a funkce nebude nutno kvůli proprietárnosti jejich vyjádření opustit a realizovat znovu. Díky tomu lze zpomalit nutný inovační cyklus a šetřit nepřímo náklady. Z hlediska bezpečnosti nabízí i dobře navržený, ale ledabyle administrovaný systém neautorizovaným útočníkům řadu možností k průniku [14]. Uzavřenost kódu je v tomto případě výhodou jen relativní – „černá skříňka“ se sice hůře analyzuje, ale zase nemohla být stabilita jejího návrhu a realizace ověřena řadou lidí tak, jako u otevřené varianty, která má výhodu v možnosti rychlé opravy chyby. Detailnější analýza bezpečnosti kódu je například v [11], str. 80-90. Překážkou nasazování OSS může být obava z toho, že se komunita rozhodne vývoj a podporu některého produktu ukončit. Další případ, který v OSS může nastat, je tzv. fragmentace kódu, kde z jednoho produktu vznikne více vývojových řad s lehce rozdílnou funkčností. Fragmentovaný kód tříští vývojové a podpůrné síly komunity a celkově uvádí uživatele do nejistoty.

6. Závěr 6.1 Shrnutí odpovědí na dříve položené otázky Je proces tvorby OSS konzistentní a efektivní jako u klasického software? Proces vývoje OSS je efektivní ve smyslu opakovaného používání již hotového díla a přidávání pouze nových vlastností. Je využit volný (=nepracovní) čas programátora, je vytvořeno něco, co někdo opravdu potřebuje. V malém rozsahu vývoje se snadněji zachová konzistentní funkční obsah, ve velkých projektech potřebnou konzistenci zajistí neformálně uznávaný vůdce komunity. Obrovskou výhodou OSS je pak okamžité testování a zpětná vazba od řádově většího počtu uživatelů, než by bylo možné při uzavřeném vývoji. Pokud by si nechal podnik upravit nějaký OSS na zakázku, bude zřejmě stanoven projekt a programátoři budou placeni, takže dojde ke kombinaci výhod obou přístupů – možnost sdílení kódu a zároveň jistota časového rozložení projektu. Je (případně v dohledné době bude) OSS natolik kvalitní, že je možné jej nasadit na životně důležité podnikové aplikace? OSS je dostatečně kvalitní i pro životně důležité podnikové aplikace již dnes, bohužel však jen pro určitý výsek podnikových činností (neexistuje komplexní řešení). Je možné realizovat například e-commerce extenze ke stávajícímu podnikání, elektronické obchody [3], některé části podpory zákazníků a podobně. Problémem OSS není nedostatečná kvalita, ale šíře záběru aplikací. I částečná implementace OSS do podnikového informačního systému již dnes přinese řadu výhod (zejména svobodu volby řešení) v budoucnu. Je podpora a nabízené služby u OSS na úrovni, kterou CIO v podnicích pro své systémy požadují [4]? Donedávna byla podpora k OSS dostupná pouze neformálně v rámci komunity vývojářů a uživatelů. Nyní však nabízí smluvně zajištěnou podporu 118



k nejobvyklejším OSS produktům i velké firmy jako IBM, Sun, Oracle a další, které umožňují koexistovat jejich produktům s otevřeným softwarem. Existuje řada menších konzultačních a outsourcingových firem, které nabízí podporu srovnatelnou s komerční podporou uzavřeného software. Tato podpora však obvykle není k dispozici pro málo používané, málo komoditizované a úzce orientované aplikace - nebo je výrazně dražší. Jak OSS ovlivní práci systémového integrátora, outsourcingové organizace, případně ASP? Systémový integrátor nebo poskytovatel outsourcingu by podle všeho měl být jedním z těch, kterým větší nasazování OSS usnadní práci. Zejména v komoditizované oblasti je OSS svým striktním dodržováním otevřených standardů ideálním prostředkem pro zrychlení a zlevnění integrace systému bez závislostí na jednom výrobci/dodavateli. Celkové integrované řešení pak může být díky svobodě úprav více na míru přizpůsobené konkrétní firmě. Podmínkou je samozřejmě personální zajištění ze strany systémového integrátora. Díky sdílení nákladů mezi mnoha zákazníky by to však neměla být velká překážka. Stejně tak outsoucingové organizace a ASP mohou pomocí OSS snižovat své náklady a nabízet zákazníkům výhodnější ceny díky sdílení lidské síly spravující (a případně i vyvíjející) OSS. Zákazník si objednává službu bez ohledu na její realizaci, takže její poskytovatel může zvolit tu nejlevnější pro daný účel. Zákazník nemusí řešit personální zajištění a smluvní záruky na fungování OSS, protože ty mu zajistí poskytovatel. Jak vypadá (bude vypadat) dlouhodobá ekonomická existence OSS a služeb na něm postavených, jaký bude obchodní model? Za samotný software se typicky neplatí, je však možné získat zaplaceno za konzultační a jiné služby nad tímto OSS realizovanými. Ty mají jedinečný charakter, protože jsou aplikovány na jednu konkrétní situaci jednoho konkrétního podniku a není možné je opakovat. Podobnou ideu sleduje i myšlenka vývoje funkčního jádra OSS aplikace zdarma a k ní komerční vývoj a prodej doplňkových proprietárních extenzí (například kvalitního uživatelské rozhraní, [13]). Kdy je a kdy není vhodné nasadit OSS do IS organizace ? K aplikaci by měla existovat široká komunita vývojářů a uživatelů a také podpora fungující na komerční bázi. Ostatní charakteristiky (zejména výkonnostní a standardizační) bývají u OSS většinou vyhovující, je však možnost využít pomocnou metodiku [5] a pomocí různých kritérií různé varianty srovnat mezi sebou. Druhou důležitou úvahou je pak uvažování budoucích nákladů v případě jednoho či druhého řešení, včetně nákladů nepřímých. Je dobré uvažovat i fakt, že díky svobodě řešení může OSS ušetřit náklady v budoucnu. Výsledky analýzy vlastností a nákladů už by poté měly pomoci informačnímu manažerovi ve volbě strategie používání otevřeného software v jeho společnosti. V zásadě platí: rozšířeně využívané (a komoditizované) OSS aplikaci, která řeší potřebné podnikové funkce, se není třeba vyhýbat [3]. Její integrace do existujícího systému bude menší problém, než u uzavřeného software. Naopak velkou opatrnost by měl CIO mít, pokud jde o „niche“ alternativní řešení s malou uživatelskou základnou.


119

Miroslav Matuška

6.2 Podmínky a faktory pro úspěšné rozvinutí trendu Do budoucna je možné počítat s tím, že se podíl otevřeného software v podnicích bude postupně zvyšovat. První podmínkou pro to je růst používání takového druhu software, které má tendenci ke komoditizaci. Čím více společných vlastností u nějakého druhu software bude, tím více se komunitě vyplatí investovat své dobrovolné úsilí do převodu této funkčnosti do otevřené formy. Další podmínkou je růst poptávky i po komoditizaci klasických podnikových záležitostí jako ERP a CRM [3][8] a fakt, že budou otevřenou formou Logo OSS Initiative vyvíjeny i tyto komponenty. Čím větší poptávka (www.opensource.org) firem bude, tím větší pozdější výhody z OSS budou mít. Informační manažeři v podnicích by se proto měli zajímat i o alternativní řešení svého IS. Faktorem přispívajícím k úspěšnému rozvinutí trendu bude i rozvoj outsourcingu a ASP služeb, protože tito poskytovatelé budou na snížení nákladů za poskytované služby velmi motivováni. Zároveň se tak OSS nepřímo dostane i do firem, kde existují jiné překážky jeho zavedení. Ke zvýšení podílu OSS ve firmách v budoucnosti přispěje i příchod mladých pracovníků, kteří mají s OSS větší zkušenosti ze škol nebo vlastních pokusů [12] díky jeho velké dostupnosti. Nástup OSS do firem bude nejspíš pozvolný – nejdříve se bude nasazovat do jasně ohraničených oblastí, kde náklady ušetří rychle a výhody budou znatelné. Celkové řešení informačního systému podniku na bázi OSS je ještě daleko, ale výhody z něj je možno ve firmách čerpat již nyní.

7. Literatura: 1. 2. 3. 4. 5.

6.

7. 8. 9. 120

Voříšek J.: Strategické řízení informačního systému a systémová integrace, Management Press Praha, 1997, ISBN:8085943409 Dohnal J., Pour J.: Architektury informačních systémů v průmyslových a obchodních podnicích, Ekopress Praha, 1997, ISBN:8086119025 Koch. C: Your Opensource Plan, CIO Magazine, březen 2003, ISSN: 0894-9301 Open Source Gains Momentum, CIO Research Survey (průzkum), prosinec 2003, http://www2.cio.com/research/surveyreport.cfm?id=48 Kenwood C.A: A Business Case Study of Open Source Software, Mitre, http://www.mitre.org/work/tech_papers/tech_papers_01/kenwood_softwar e/kenwood_software.pdf Prasad G: Open Source-onomics: Examining some pseudo-economic arguments about Open Source, Linux Today, http://linuxtoday.com/infrastructure/2001041200620OPBZCY-Poe. T: A Successful Linux/Open-Source Business Model, Linux Journal, 16. červen 2002, ISSN: 1075-3583 Linux Business Solutions Project & Linux Enterprise Computing, http://linas.org/linux/web-project.html The Compiere Project, http://www.compiere.com SYSTÉMOVÁ INTEGRACE 2/2004


10. GNU: Various licenses and comments, http://www.gnu.org/philosophy/license-list.html 11. Bukovjan M.: Analýza specifických dimenzí open source software a jejich dopadu na metodiku výběrového řízení, disertační práce KIT VŠE v Praze, červen 2004 12. Kalin S.: Free Lunch, Anyone? - Darwin Magazine, prosinec 2000 13. Evers J., McMillan R.: Making Open Source Pay – A Developer's Dilemma - CIO Magazine březen 2003, ISSN: 0894-9301 14. James G.: Nobody is perfect - CIO Magazine leden 2003, ISSN: 0894-9301 15. Koch C., Showdown at the 6.0 Corral - CIO Magazine březen 2003, ISSN: 0894-9301 16. Wheatley M.: The Myths of Open Source - CIO Magazine březen 2004, ISSN: 0894-9301 17. Parkinson J.: The End Of Idealism - CIO Magazine červenec 2003, ISSN: 0894-9301 18. Open Source Licensing, http://www.opensource.org/licenses/


121

Miroslav Matuška

122


Open Source Software v produkčním informačním systému organizace

Recommend Documents