Vendor lock-in: ako si udržať kontrolu nad vlastným softvérom

Väčšina firiem nezistí, že má problém s vendor lock-inom, kým sa nepokúsi odísť. Roky to funguje bez trhliny: dodávateľ dodáva, systém beží, faktúry chodia. Potom príde moment — zmena cenníka, odchod kľúčového človeka na strane dodávateľa, spomalenie vývoja alebo len bežné výberové konanie — a firma zistí, že repozitár so zdrojovým kódom je na účte dodávateľa, doména je registrovaná na jeho IČO, produkcia beží pod jeho cloudovým účtom a jediný človek, ktorý vie, ako sa aplikácia nasadzuje, sedí na druhej strane. Softvér je zaplatený. Kontrola nad ním nie.

Píšeme to ako dodávateľ, čo je mierne nepohodlná pozícia — všetko, čo tu odporúčame, znižuje aj našu vlastnú vyjednávaciu silu. Robíme to preto, že rozdiel medzi klientom, ktorý má veci v poriadku, a klientom, ktorý ich nemá, sa neprejaví počas spolupráce, ale až pri jej konci. A vtedy už je neskoro čokoľvek dojednávať.

Nie každá závislosť na dodávateľovi je problém. Tím, ktorý s vami tri roky stavia interný systém, vie o vašich procesoch veci, ktoré nie sú a nikdy nebudú zapísané v žiadnej dokumentácii — prečo sa jeden typ objednávky schvaľuje inak, ktorý zákazník má výnimku, čo sa stalo pri migrácii pred dvoma rokmi. Táto znalosť je hodnota, za ktorú platíte, a preniesť ju inam bude drahé bez ohľadu na to, ako dobre máte podpísané zmluvy.

Vendor lock-in je niečo iné: umelo zvýšená cena odchodu, ktorá nevyplýva zo znalosti, ale z prístupov a artefaktov. Test je jednoduchý. Predstavte si, že spolupráca sa zajtra korektne končí, bez konfliktu. Koľko týždňov by iný kompetentný tím potreboval na to, aby nasadil do produkcie prvú netriviálnu zmenu?

Ak je odpoveď „týždne", máte zdravú závislosť. Ak je odpoveď „netušíme" alebo „museli by sme to prepísať", máte lock-in — a nezáleží na tom, aký dobrý je aktuálny vzťah.

Toto je jadro celej témy a zároveň jediná časť, ktorá sa dá vyriešiť za jedno popoludnie. Rozdiel medzi „dodávateľ nám sľúbil, že kód je náš" a „kód je v repozitári, kde som ja vlastníkom organizácie" je rozdiel medzi dôverou a kontrolou. Dôvera je dobrá vec, ale nie je to bezpečnostné opatrenie.

Najpodceňovanejšia položka je databázový export. „Zálohy robíme denne" je tvrdenie, nie dôkaz. Záloha, ktorú nikto nikdy neobnovil do čistého prostredia, je len súbor s neznámym obsahom. Otestované obnovenie je zároveň najlepší jednotlivý krok, ktorý zníži vašu závislosť — pretože dáta sú to jediné, čo sa naozaj nedá znovu vyrobiť.

Zmluva nenahradí prístupy, ale rieši to, čo sa nedá držať technicky. Pri výbere partnera sa oplatí prejsť si ich systematicky — patria do rovnakej kategórie otázok ako checklist na výber softvérového dodávateľa, len sa na ne zvykne prísť neskoro.

Prevod práv naviazaný na zaplatenie. Formulácia „poskytujeme licenciu na použitie diela" nie je to isté ako prevod majetkových práv. Prevod by sa mal vzťahovať aj na medziprodukty: dizajny, migračné skripty, infraštruktúrny kód, testy. Naviazanie na zaplatenie je férové voči obom stranám — dodávateľ nedáva práva k nezaplatenej práci, klient ich dostáva automaticky po úhrade, bez ďalšieho podpisovania.

Povinnosť odovzdania (exit klauzula). Bez nej je odovzdanie dobrá vôľa. Klauzula má definovať čo (zoznam artefaktov z tabuľky vyššie), do kedy (kalendárny počet dní od ukončenia), v akej forme (odovzdávací protokol, prístupy prevedené, nie preposlané heslá) a koľko hodín konzultácií je v cene.

Sadzby po odovzdaní. Dohodnite ich vtedy, keď máte vyjednávaciu silu — teda pri podpise, nie pri odchode. Aj korektný dodávateľ má po ukončení spolupráce iné priority a hodinovka bez predchádzajúcej dohody býva iná ako počas projektu.

Výpovedná lehota, symetricky. Ak má klient tri mesiace a dodávateľ tridsať dní, nie je to zmluva o partnerstve.

Escrow zdrojového kódu. Úschova kódu u tretej strany má zmysel pri krabicových produktoch, kde sa kód bežne nedodáva. Pri vývoji na mieru je vo väčšine prípadov zbytočná — repozitár priamo u klienta rieši to isté lacnejšie. A pozor: escrow bez otestovaného postupu buildu je ilúzia bezpečia. Uložený archív, z ktorého nikto nevie zostaviť bežiacu aplikáciu, nie je poistka.

Subdodávatelia a komerčné licencie. Ak projekt používa platenú knižnicu, komponent alebo šablónu kúpenú na meno dodávateľa, licencia sa s vami nepresťahuje. Chcete zoznam všetkých takýchto položiek a v ideálnom prípade nákup na vaše IČO.

Zmluva nezabráni tomu, aby dodávateľ odišiel. Zabráni len tomu, aby ste spolu s ním prišli aj o softvér.

Časť lock-inu vzniká už pri návrhu, dávno pred akýmkoľvek konfliktom, a nikto ju nemyslí zle.

Bežný stack namiesto exotického. Nejde o módu, ide o trh práce. Aplikácia postavená na rozšírených technológiách má stovky ľudí, ktorí ju vedia prevziať; aplikácia na okrajovom frameworku má desiatky, z toho polovicu u pôvodného dodávateľa. Toto je jeden z tichých argumentov pri voľbe medzi softvérom na mieru a hotovým SaaS riešením — u SaaS je lock-in vlastne súčasťou produktu, len sa volá inak.

Dokumentovaná architektúra na úrovni „nový vývojár si to spustí lokálne za pol dňa". Nemusí to byť rozsiahly dokument. Stačí README s krokmi na spustenie, diagram toku dát a stránka s tým, kam sa aplikácia nasadzuje a čo sa deje pri nasadení.

Žiadna nezdokumentovaná proprietárna vrstva. Interné knižnice a generátory dodávateľa sú legitímne — zrýchľujú prácu a klient z toho profituje. Problém nastáva, keď nie sú súčasťou prevodu práv alebo keď nemajú dokumentáciu. Pýtajte sa priamo: „Ktoré časti systému sú vaše interné komponenty a čo sa s nimi stane, keď skončíme?"

Infraštruktúra ako kód a oddelenie dát od aplikácie. Prostredie, ktoré sa dá znovu vytvoriť zo súboru v repozitári, je prenosné. Prostredie, ktoré niekto pred rokmi naklikal v konzole, nie je. Rovnako platí, že štandardná relačná databáza s exportovateľnou schémou drží dvere otvorené, zatiaľ čo dáta uzavreté v proprietárnom formáte konkrétnej služby ich zatvárajú.

Automatizované testy ako forma dokumentácie. Sada testov je pre preberajúci tím často cennejšia než text — hovorí, čo systém má robiť, a dá sa spustiť.

Tu je čestný protiargument, ktorý sa v článkoch na túto tému väčšinou nespomína. Každá vrstva pridaná „kvôli prenositeľnosti" niečo stojí. Databázovo agnostická abstrakcia znamená, že sa vzdáte polovice možností konkrétnej databázy. Architektúra pripravená na tri cloudy sa v praxi píše na najnižší spoločný menovateľ všetkých troch. Softvér, ktorý je zámerne navrhnutý tak, aby sa dal ľahko vymeniť, býva všeobecnejší, nudnejší a horšie prispôsobený tomu, čo vaša firma naozaj robí — a presne kvôli prispôsobeniu ste si ho dali robiť na mieru.

Platí to aj o vzťahu. Dodávateľ, ktorý vie, že ho hocikedy vymeníte, sa správa ako dodávateľ komodity: robí presne to, čo je v zadaní, a neprinesie návrh, ktorý by vám ušetril tri mesiace vývoja. Časť hodnoty dlhodobej spolupráce vzniká práve z toho, že obe strany investujú nad rámec aktuálnej objednávky. To sa nedá mať zadarmo.

Cieľom teda nie je nulová cena za výmenu dodávateľa. Cieľom je cena, ktorú poznáte vopred a viete ju zaplatiť. Rozdiel medzi „výmena nás bude stáť približne dva až tri mesiace prekrytia a nejakú stratu tempa" a „nemáme predstavu, či je to vôbec možné" je celý rozdiel medzi rozhodnutím a rukojemníctvom.

Ak už systém beží roky, nemusíte hneď meniť zmluvu. Stačí urobiť poctivú inventúru — pokojne ako spoločné cvičenie s dodávateľom, korektný partner s tým nebude mať problém.

1. Prejdite tabuľku artefaktov a pri každom riadku napíšte konkrétne meno účtu a vlastníka, nie „máme".
2. Nechajte si predviesť nasadenie zmeny do produkcie a zapíšte, čo všetko sa pri ňom deje.
3. Vyžiadajte obnovu poslednej zálohy do prázdneho prostredia a overte počty záznamov.
4. Dajte jednému nezávislému vývojárovi dva dni na to, aby projekt spustil lokálne podľa dokumentácie. To, čo mu bude chýbať, je váš skutočný lock-in.
5. Výsledky premietnite do dodatku zmluvy a do plánu údržby a rozvoja softvéru po spustení, aby sa stav znovu nerozpadol.

Ak inventúra ukáže, že systém je technologicky na konci životnosti, otázka lock-inu splynie s otázkou obnovy — vtedy sa oplatí čítať to spolu s postupom pri migrácii legacy systému na modernú platformu, pretože migrácia je zároveň najlepšia príležitosť dať vlastníctvo do poriadku.

Vendor lock-in nie je otázka dôvery a málokedy vzniká zo zlého úmyslu. Vzniká z drobných rozhodnutí, ktoré v deň, keď sa robia, dávajú zmysel: dodávateľ založí repozitár, lebo je rýchlejšie, doména sa zaregistruje na jeho účet, lebo to trvá päť minút, produkcia beží tam, kde už má prístupy. Po troch rokoch je z toho stav, ktorý sa nedá odmotať za týždeň.

Držte artefakty, nie sľuby. Ošetrite zmluvne to, čo sa technicky držať nedá. Vyberajte technológie, ktoré vie prevziať aj niekto iný. A zároveň nepreháňajte to — určitá miera zviazanosti s dobrým partnerom je cena za softvér, ktorý naozaj sedí vašim procesom, a je to cena, ktorú sa oplatí platiť vedome. V INTERFASE považujeme za normálne, že klient je vlastníkom repozitára aj infraštruktúry od prvého dňa; je to jediný spôsob, ako môže byť spolupráca dobrovoľná na oboch stranách. Ak si chcete prejsť inventúru vlastníctva na existujúcom projekte alebo nastaviť vývoj softvéru na mieru tak, aby ste od začiatku držali všetko podstatné, ozvite sa nám a prejdeme si to bod po bode.