Vendor lock-in: jak si udržet kontrolu nad vlastním softwarem

Většina firem nezjistí, že má problém s vendor lock-inem, dokud se nepokusí odejít. Roky to funguje bez zádrhelu: dodavatel dodává, systém běží, faktury chodí. Pak přijde okamžik — změna ceníku, odchod klíčového člověka na straně dodavatele, zpomalení vývoje nebo jen běžné výběrové řízení — a firma zjistí, že repozitář se zdrojovým kódem je na účtu dodavatele, doména je registrovaná na jeho IČO, produkce běží pod jeho cloudovým účtem a jediný člověk, který ví, jak se aplikace nasazuje, sedí na druhé straně. Software je zaplacený. Kontrola nad ním ne.

Píšeme to jako dodavatel, což je mírně nepohodlná pozice — všechno, co tu doporučujeme, snižuje i naši vlastní vyjednávací sílu. Děláme to proto, že rozdíl mezi klientem, který má věci v pořádku, a klientem, který je nemá, se neprojeví během spolupráce, ale až při jejím konci. A tehdy už je pozdě cokoli domlouvat.

Ne každá závislost na dodavateli je problém. Tým, který s vámi tři roky staví interní systém, ví o vašich procesech věci, které nejsou a nikdy nebudou zapsané v žádné dokumentaci — proč se jeden typ objednávky schvaluje jinak, který zákazník má výjimku, co se stalo při migraci před dvěma lety. Tahle znalost je hodnota, za kterou platíte, a přenést ji jinam bude drahé bez ohledu na to, jak dobře máte podepsané smlouvy.

Vendor lock-in je něco jiného: uměle zvýšená cena odchodu, která nevyplývá ze znalosti, ale z přístupů a artefaktů. Test je jednoduchý. Představte si, že spolupráce zítra korektně končí, bez konfliktu. Kolik týdnů by jiný kompetentní tým potřeboval na to, aby nasadil do produkce první netriviální změnu?

Pokud je odpověď „týdny", máte zdravou závislost. Pokud je odpověď „netušíme" nebo „museli bychom to přepsat", máte lock-in — a nezáleží na tom, jak dobrý je aktuální vztah.

Tohle je jádro celého tématu a zároveň jediná část, která se dá vyřešit za jedno odpoledne. Rozdíl mezi „dodavatel nám slíbil, že kód je náš" a „kód je v repozitáři, kde jsem já vlastníkem organizace" je rozdíl mezi důvěrou a kontrolou. Důvěra je dobrá věc, ale není to bezpečnostní opatření.

Nejpodceňovanější položkou je databázový export. „Zálohy děláme denně" je tvrzení, ne důkaz. Záloha, kterou nikdo nikdy neobnovil do čistého prostředí, je jen soubor s neznámým obsahem. Otestovaná obnova je zároveň nejlepší jednotlivý krok, který sníží vaši závislost — protože data jsou to jediné, co se opravdu nedá vyrobit znovu.

Smlouva nenahradí přístupy, ale řeší to, co se nedá držet technicky. Při výběru partnera se vyplatí projít si je systematicky — patří do stejné kategorie otázek jako checklist pro výběr softwarového dodavatele, jen se na ně obvykle přijde pozdě.

Převod práv navázaný na zaplacení. Formulace „poskytujeme licenci k užití díla" není totéž co převod majetkových práv. Převod by se měl vztahovat i na meziprodukty: designy, migrační skripty, infrastrukturní kód, testy. Navázání na zaplacení je férové vůči oběma stranám — dodavatel nedává práva k nezaplacené práci, klient je dostává automaticky po úhradě, bez dalšího podepisování.

Povinnost předání (exit klauzule). Bez ní je předání dobrá vůle. Klauzule má definovat co (seznam artefaktů z tabulky výše), do kdy (kalendářní počet dní od ukončení), v jaké formě (předávací protokol, přístupy převedené, ne přeposlaná hesla) a kolik hodin konzultací je v ceně.

Sazby po předání. Domluvte je tehdy, kdy máte vyjednávací sílu — tedy při podpisu, ne při odchodu. I korektní dodavatel má po ukončení spolupráce jiné priority a hodinovka bez předchozí dohody bývá jiná než během projektu.

Výpovědní lhůta, symetricky. Pokud má klient tři měsíce a dodavatel třicet dní, není to smlouva o partnerství.

Escrow zdrojového kódu. Úschova kódu u třetí strany dává smysl u krabicových produktů, kde se kód běžně nedodává. U vývoje na míru je ve většině případů zbytečná — repozitář přímo u klienta řeší totéž levněji. A pozor: escrow bez otestovaného postupu buildu je iluze bezpečí. Uložený archiv, ze kterého nikdo neumí sestavit běžící aplikaci, není pojistka.

Subdodavatelé a komerční licence. Pokud projekt používá placenou knihovnu, komponentu nebo šablonu koupenou na jméno dodavatele, licence se s vámi nepřestěhuje. Chcete seznam všech takových položek a v ideálním případě nákup na vaše IČO.

Smlouva nezabrání tomu, aby dodavatel odešel. Zabrání jen tomu, abyste spolu s ním přišli i o software.

Část lock-inu vzniká už při návrhu, dávno před jakýmkoli konfliktem, a nikdo to nemyslí zle.

Běžný stack místo exotického. Nejde o módu, jde o trh práce. Aplikace postavená na rozšířených technologiích má stovky lidí, kteří ji umí převzít; aplikace na okrajovém frameworku má desítky, z toho polovinu u původního dodavatele. To je jeden z tichých argumentů při volbě mezi softwarem na míru a hotovým SaaS řešením — u SaaS je lock-in vlastně součástí produktu, jen se jmenuje jinak.

Zdokumentovaná architektura na úrovni „nový vývojář si to spustí lokálně za půl dne". Nemusí to být rozsáhlý dokument. Stačí README s kroky pro spuštění, diagram toku dat a stránka s tím, kam se aplikace nasazuje a co se při nasazení děje.

Žádná nezdokumentovaná proprietární vrstva. Interní knihovny a generátory dodavatele jsou legitimní — zrychlují práci a klient z toho profituje. Problém nastává, když nejsou součástí převodu práv nebo když nemají dokumentaci. Ptejte se přímo: „Které části systému jsou vaše interní komponenty a co se s nimi stane, až skončíme?"

Infrastruktura jako kód a oddělení dat od aplikace. Prostředí, které se dá znovu vytvořit ze souboru v repozitáři, je přenositelné. Prostředí, které někdo před lety naklikal v konzoli, není. Totéž platí o datech: standardní relační databáze s exportovatelným schématem drží dveře otevřené, zatímco data uzavřená v proprietárním formátu konkrétní služby je zavírají.

Automatizované testy jako forma dokumentace. Sada testů je pro přebírající tým často cennější než text — říká, co má systém dělat, a dá se spustit.

Tady je čestný protiargument, který se v článcích na tohle téma většinou nezmiňuje. Každá vrstva přidaná „kvůli přenositelnosti" něco stojí. Databázově agnostická abstrakce znamená, že se vzdáte poloviny možností konkrétní databáze. Architektura připravená na tři cloudy se v praxi píše na nejnižší společný jmenovatel všech tří. Software, který je záměrně navržený tak, aby se dal snadno vyměnit, bývá obecnější, nudnější a hůř přizpůsobený tomu, co vaše firma opravdu dělá — a přesně kvůli přizpůsobení jste si ho nechali dělat na míru.

Platí to i o vztahu. Dodavatel, který ví, že ho kdykoli vyměníte, se chová jako dodavatel komodity: dělá přesně to, co je v zadání, a nepřinese návrh, který by vám ušetřil tři měsíce vývoje. Část hodnoty dlouhodobé spolupráce vzniká právě z toho, že obě strany investují nad rámec aktuální objednávky. To se nedá mít zadarmo.

Cílem tedy není nulová cena za výměnu dodavatele. Cílem je cena, kterou znáte předem a umíte ji zaplatit. Rozdíl mezi „výměna nás bude stát zhruba dva až tři měsíce překrytí a nějakou ztrátu tempa" a „nemáme představu, jestli je to vůbec možné" je celý rozdíl mezi rozhodnutím a rukojmím.

Pokud už systém běží roky, nemusíte hned měnit smlouvu. Stačí udělat poctivou inventuru — klidně jako společné cvičení s dodavatelem, korektní partner s tím nebude mít problém.

1. Projděte tabulku artefaktů a u každého řádku napište konkrétní jméno účtu a vlastníka, ne „máme".
2. Nechte si předvést nasazení změny do produkce a zapište, co všechno se při něm děje.
3. Vyžádejte si obnovu poslední zálohy do prázdného prostředí a ověřte počty záznamů.
4. Dejte jednomu nezávislému vývojáři dva dny na to, aby projekt spustil lokálně podle dokumentace. To, co mu bude chybět, je váš skutečný lock-in.
5. Výsledky promítněte do dodatku smlouvy a do plánu údržby a rozvoje softwaru po spuštění, aby se stav znovu nerozpadl.

Pokud inventura ukáže, že systém je technologicky na konci životnosti, otázka lock-inu splyne s otázkou obnovy — tehdy se vyplatí číst to spolu s postupem při migraci legacy systému na moderní platformu, protože migrace je zároveň nejlepší příležitost dát vlastnictví do pořádku.

Vendor lock-in není otázka důvěry a málokdy vzniká ze špatného úmyslu. Vzniká z drobných rozhodnutí, která v den, kdy se dělají, dávají smysl: dodavatel založí repozitář, protože je to rychlejší, doména se zaregistruje na jeho účet, protože to trvá pět minut, produkce běží tam, kde už má přístupy. Po třech letech je z toho stav, který se nedá odmotat za týden.

Držte artefakty, ne sliby. Ošetřete smluvně to, co se technicky držet nedá. Vybírejte technologie, které umí převzít i někdo jiný. A zároveň to nepřehánějte — určitá míra provázanosti s dobrým partnerem je cena za software, který opravdu sedí vašim procesům, a je to cena, kterou se vyplatí platit vědomě. V INTERFASE považujeme za normální, že klient je vlastníkem repozitáře i infrastruktury od prvního dne; je to jediný způsob, jak může být spolupráce dobrovolná na obou stranách. Pokud si chcete projít inventuru vlastnictví na existujícím projektu nebo nastavit vývoj softwaru na míru tak, abyste od začátku drželi vše podstatné, ozvěte se nám a projdeme si to bod po bodu.