Vendor lock-in vermijden: waarom eigenaarschap van code en data telt

In het kort

Vendor lock-in betekent dat je niet meer van een leverancier af kunt zonder onevenredig veel kosten, tijd of risico. Bij software sluipt het erin via code die je niet bezit, hosting op andermans account, licenties op een platform, data die je niet kunt exporteren en kennis die alleen bij de leverancier zit. Je vermijdt het niet door alle afhankelijkheid uit te bannen, want dat kan niet, maar door vooraf vast te leggen dat jij eigenaar bent van code en data, dat de software op jouw naam draait en dat een overdracht is beschreven. De toets is simpel: als de leverancier morgen stopt, kun jij dan verder?

Wat vendor lock-in is, en waarom het niet altijd erg is

Elke softwarekeuze maakt je ergens afhankelijk van. Kies je een boekhoudpakket, dan zit je administratie daar. Kies je een bouwer, dan kent die je systeem beter dan wie ook.

Afhankelijkheid op zichzelf is geen probleem; het is de prijs van niet alles zelf doen. Lock-in ontstaat wanneer die afhankelijkheid niet meer te beëindigen is tegen een redelijke inspanning, of wanneer de leverancier de voorwaarden eenzijdig kan veranderen zonder dat je een alternatief hebt.

Het onderscheid is belangrijk, omdat je anders de verkeerde dingen gaat vermijden. Een standaardpakket met een goede exportfunctie geeft weinig lock-in, ook al is het een abonnement. Maatwerk waarvan de code bij het bureau blijft, geeft veel lock-in, ook al heb je ervoor betaald.

De vraag is niet standaard of maatwerk, maar of je weg kunt als je dat wilt. In maatwerk of standaardpakket gaan we dieper in op die afweging.

De schade van lock-in zie je vaak pas jaren later: een leverancier die de voorwaarden verandert, een bureau dat stopt of overgenomen wordt, een platform dat een functie schrapt waar jij op bouwde, of gewoon een samenwerking die niet meer werkt. Op dat moment wil je een keuze hebben.

Waar lock-in in sluipt

Lock-in zit zelden op één plek. Dit zijn de zes plekken waar wij het het vaakst tegenkomen, met het signaal waaraan je het herkent.

Platforms verdienen extra aandacht

Automatiseringsplatforms zoals Zapier, Make en Power Automate en low-code-omgevingen zijn snel en nuttig voor kleine koppelingen. De lock-in ontstaat als je hele bedrijfsproces erin gaat zitten: tientallen flows die niemand meer overziet, die je niet kunt overzetten naar iets anders en waarvan de kosten meegroeien met je gebruik. Gebruik ze voor wat ze goed kunnen en zet kernprocessen in software die je bezit. Dat geldt ook voor koppelingen: een koppeling die je zelf hebt laten bouwen, kun je meenemen; een koppeling in een platform niet.

Hosting is de stille valkuil

Veel bureaus zetten uit gemak alles op hun eigen account: hosting, domeinregistratie, e-maildienst, certificaten. Dat werkt prima tot je uit elkaar gaat. Dan blijkt dat je domein niet van jou is en dat de database op een server staat waar je geen toegang toe hebt. Vraag daarom altijd om accounts op jouw naam, waarbij het bureau beheerdersrechten krijgt die je kunt intrekken.

Wat eigenaarschap van code in de praktijk betekent

Dat de code van jou is, is snel gezegd. In de praktijk betekent eigenaarschap vier concrete dingen.

1. De broncode staat in een repository op jouw naam. Het bureau werkt daarin, jij bent beheerder. Vanaf de eerste sprint, niet pas bij oplevering.
2. Het intellectueel eigendom is contractueel overgedragen. Zonder die bepaling blijft het auteursrecht in de regel bij de maker, ook als je alles betaald hebt. Laat dit door een jurist controleren; wij geven geen juridisch advies, maar we zien deze bepaling vaak ontbreken.
3. Je kunt de software zelf bouwen en uitrollen. Code zonder bouwscripts, configuratie en een beschrijving van de omgeving is een puzzel zonder doos. Een nieuwe bouwer moet de applicatie aan de hand van de repository kunnen draaien.
4. Onderdelen van derden zijn open source of vervangbaar. Elke applicatie gebruikt bibliotheken en diensten van anderen. Dat is normaal, zolang er geen onderdeel tussen zit dat alleen het bureau mag gebruiken of dat aan een licentie van het bureau hangt.

Eigenaarschap van data: export, toegang en back-ups

Data is voor de meeste bedrijven waardevoller dan de software eromheen. Toch wordt dit onderdeel het vaakst vergeten. Drie afspraken die je maakt:

• Een volledige export in een bruikbaar formaat. Niet alleen de tabellen, maar ook documenten, bijlagen en de relaties ertussen. Vraag om een proefexport voordat de software live gaat, en bekijk of je er zonder de leverancier iets mee kunt.
• Directe toegang tot de database en de bestandsopslag. Op jouw account, met jouw inloggegevens. Je hoeft er niet dagelijks in, maar je moet erbij kunnen.
• Back-ups op een plek die jij beheert. Een back-up die alleen de leverancier kan terugzetten, is een back-up van de leverancier, niet van jou.

Dit raakt ook aan de AVG: als je persoonsgegevens verwerkt, moet je kunnen aantonen waar ze staan, wie erbij kan en hoe je ze verwijdert. Een verwerkersovereenkomst met je bouwer en je hostingpartij is daarbij het minimum; bij twijfel over je verplichtingen raadpleeg je een privacyspecialist.

Bij standaardpakketten geldt hetzelfde principe. Kies je een boekhoud- of CRM-pakket, kijk dan vooraf naar de exportmogelijkheden en de API. Een pakket met een goede API-koppeling laat je je data naar je eigen software halen en houdt de keuze om te wisselen open.

Afspraken die je vooraf maakt

Alles hierboven regel je het makkelijkst vóór de eerste sprint. Daarna wordt het een onderhandeling. Dit is de lijst die je van elk bureau mag verwachten. Bij ons is het uitgangspunt dat de klant eigenaar is van code en data en dat de hosting in Nederland of de EU in eigen beheer staat; hoe dat in de praktijk gaat, lees je bij onze werkwijze.

• Het intellectueel eigendom van alle geschreven code gaat over naar de opdrachtgever, bij elke oplevering of betaling.
• De repository, hosting, het domein en overige accounts staan op naam van de opdrachtgever; het bureau krijgt beheerdersrechten.
• Documentatie hoort bij de oplevering: hoe de applicatie draait, welke onderdelen van derden erin zitten en hoe je een nieuwe omgeving opzet.
• Een beschrijving van de overdracht bij beëindiging: wat er wordt overgedragen, binnen welke termijn en tegen welke afspraak.
• Onderhoud is een aparte, opzegbare afspraak en geen voorwaarde om de software te mogen gebruiken.
• Bij gebruik van platforms of diensten van derden: welke, waarom en wat het alternatief is.

Zet dit niet alleen in het contract, maar controleer het ook. Log in de eerste maand zelf in op de repository en op het hostingaccount. Als dat niet lukt, klopt de afspraak op papier wel, maar in de praktijk niet. Meer vragen voor het eerste gesprek vind je in een softwarebureau kiezen: tien vragen.

De exit-test: zo controleer je je huidige situatie

Heb je al software draaien? Doe dan deze test. Stel je voor dat je leverancier vanaf morgen niet meer bereikbaar is, en beantwoord de vragen eerlijk.

1. Kun je vandaag inloggen op de repository met de broncode?
2. Kun je inloggen bij de hostingpartij, en staat het account op jouw naam?
3. Staan het domein en de certificaten op jouw naam?
4. Heb je ooit een volledige export van je data in handen gehad en geopend?
5. Is er documentatie waarmee een andere bouwer de applicatie kan draaien?
6. Staat in je overeenkomst dat het intellectueel eigendom bij jou ligt?
7. Weet je welke platforms en diensten van derden erin zitten en wat die kosten?
8. Kun je onderhoud opzeggen zonder de software te verliezen?

Elke vraag waarop het antwoord nee is, is een punt om nu te regelen, terwijl de relatie met je leverancier nog goed is. Meestal is het een kwestie van accounts overzetten, een aanvulling op de overeenkomst en een middag documentatie schrijven. Wacht je tot het misgaat, dan is dezelfde lijst een stuk duurder.

Begin je aan nieuwe maatwerksoftware? Neem deze acht vragen dan mee naar het eerste gesprek en vraag het bureau om ze vooraf te beantwoorden. De reactie zegt vaak genoeg.