Co je problém
Proč bohužel ? Ono je sice na krásně hezké, že jsou rychle nalezeny chyby. Díky tomu je také bývá pravidlem, že chyby jsou velmi rychle i opraveny. A protože víc programátorů více naprogramuje, vývoj Open Source projektů je velmi rychlý. To je příjemné zejména pokud se objeví díra v softwarovém trhu, která může být velmi rychle zaplněna. A díky otevřeným licencím a komunitě, je rychlost vývoje opravdu velká.
Jenže, pod hlavičkou Open Source nevznikají jen výsledné programy a softwarové nástroje, ale také i samotné knihovny a rozhraní pro tvorbu takových nástrojů. A tady je kámen úrazu. Pokud je knihovna vyvíjena příliš rychle, resp. její aktualizace vycházejí velmi často, vzniká problém.
Nové knihovny, ať se jejich vývojáři snaží sebe lépe, prostě někdy neumí dodržet zpětně kompatibilní API, nebo ABI. Pokud pomineme, že v nových verzích jsou funkce a metody rychlejší a efektnější, často toho také více umějí. No a pak se stává, že jsou staré funkce nahrazeny novými. Konec konců nevyvíjí se jen knihovna, ale celá její struktura. Za slovo knihovna můžeme samozřejmě dosadit celou škálu jiných typů projektů. Například programovací jazyk (resp. jeho implementace), systémové nástroje, rozhraní jádra systému, atd.
Proč je to problém
Někteří z Vás mě jistě začnou v duchu (nebo nahlas :)) oponovat, že rychlý vývoj přeci není a nemůže být na překážku. Ale právě stabilita prostředí je velmi klíčová pro jeho použití. Díky tomuto problému bývá na různých verzích systémů instalováno různé množství verzí knihoven a interpretů. Jako příklad může posloužit třeba jazyk Python.
Protože díky nekompatibilitě (i kdyby jen malinké) není možné provozovat aplikace na nových verzích systému, je obtížné vybrat tu správnou podporovanou verzi. Mějme aplikaci, která používá knihovnu. V jedné době si autoři aplikace nainstalovali novou běžně se vyskytující verzi knihovny a použili jí ve své aplikaci. Jak se knihovna vyvíjela, automaticky se mezi uživateli začala šířit i nová verze knihovny.
Jenže pokud v nějakém časovém bodě přestane být knihovna zpětně kompatibilní, musí autoři aplikace řešit celou škálu otázek. Věnovat část svého času na úpravu aplikace tak, aby používala novou knihovnu, nebo aby používala jen to část API, které je stále zpětně kompatibilní ? Je pro život aplikace nutné aby byla provozovatelná se starou verzí knihovny ? Jak dlouho bude trvat než se objeví nová verze knihovny, na kterou bude nutné migrovat ? Co vlastně obnáší migrace, resp. jak moc je únosné udělat rychlé hacky do aplikace ? Pokud není šířena aplikace formou zdrojových kódů, bude se někdo starat o kompilaci pro různé verze prostředí kvůli nekompatibilnímu ABI?
Je třeba si uvědomit, že životnost některých IT prostředí je v řádech i několika desítek let. Během této doby někteří uživatelé nemají potřebu aktualizovat své systémy, protože za prvé stávající systém funguje, za druhé aktualizace stojí energii, čas případně peníze. Pokud bych převedl tento IT svět analogicky do světa telefonů, otázka zní, jaká je průměrná doba používání jednoho telefonu.
To že guru, geek, nerd, specialista, technokrat či jiný IT magor aktualizuje ob 14 dní ještě neznamená že to dělá většina ostatních. Pro autory aplikací a systémů je tedy velmi důležité si dvakrát rozmyslet s jakou verzí prostředí budou pracovat. Díky tomu také některé firmy drží několikaletou podporu jedné verze systému, a této verzi se po danou dobu věnují. Neaktualizují knihovny ani nástroje, nemění funkčnost prostředí, pouze opravují bezpečností chyby. A to tak, aby zachovali jak API tak ABI pokud možno beze změny a když už, tak zpětně kompatibilní změny. Takové prostředí je pak nejen bezpečné, časem prověřené, ale také velmi stabilní.
Dopad na uživatele
Na konci celého maratonu vývoje aplikace je uživatel. Ten který v nějakém prostředí výsledný projekt provozuje, používá. Ten který buď platí za několikaletou podporu staršího prostředí, nebo je nucen aktualizovat své prostředí aby držel krok s projektem, nebo v konečné fázi prostě utře.
S ohledem na titulek tohoto článku je zřejmé kam mířím. Problém Androidu je ten, že jeho verze vychází častěji, než měním svůj telefon. Nemluvě o tom, že čím kvalitnější telefon mám, tím měně koukám po jiném, novějším a je tedy předpoklad, že ho budu déle používat. Dalo by se namítnout že na kvalitnější telefon budu moci instalovat celkem dlouho nové verze Androidu. Ale budou neoficiální, a nemusí v nich fungovat to, to a to. Nekoupil sem si telefon abych co půl roku aktualizoval jeho systém svépomocí jen proto, že vývojáři mých aplikací už z nějakého důvodu nepodporují starší verzi.
Se stářím systému samozřejmě stárnou i aplikace, ale pokud již dnes koupím nový telefon, který je v době koupě zastaralý, je to špatně. Nakonec si rozhodně nechci kupovat nový telefon, jen proto, že na mém telefonu zestárl systém. Pokud se přesunu k desktopu, k distribucím Linuxu, přirovnal bych Android k verzi Debianu Sid, nebo k Ubuntu, a jiným distribucím, které co půlrok (pokud ne průběžně) aktualizují obrovské množství knihoven. Je hezké mít stále aktuální systém, ale vyžaduje to jeho neustálou údržbu a řešení problémů s kompatibilitou.
Nechci tím tvrdit, že neustálý rychlý vývoj je špatný, ale čím dál více se v některých IT profesích musí uplatňovat ono české „Dvakrát měř, jednou řež”. Aby nevznikali knihovny, které se za 2 měsíce začnou přepisovat protože jeden dvakrát nemyslel, ale rovnou začal programovat.