Scheermesjes worden vaak ontworpen om alleen compatibel te zijn met mesjes van hetzelfde merk. De scheermeshouder is gunstig geprijsd, terwijl de vervangende mesjes tegen een premium worden verkocht. Patenten zorgen ervoor dat scheermesjes niet door andere partijen kunnen worden verkocht.
Inktjetprinters idem. Spotgoedkoop in de aanschaf, kostbaar op de lange termijn door de cartridges waar een patent op rust. Daarbovenop voert de printerfabrikant firmwareupdates uit die het onmogelijk maken om cartridges, die de belangrijkste inkomstenbron voor de fabrikant vormen, van een andere aanbieder te gebruiken.
Twee eenvoudige voorbeelden van vendor lock-in: een (te) grote afhankelijkheid van een leverancier die niet eenvoudig op te heffen is. Overstappen naar een andere oplossing is te duur of ingewikkeld. Bij een echte vendor lock-in is er tevens sprake van een beter alternatief waar je als afnemer op over zou willen stappen.
Vendor lock-in in de software-industrie
De wereld van inktjetprinters en scheermesjes laat zien dat bedrijven sluwe methoden ontwikkelen om de concurrent te benadelen en klanten aan zich te binden.
Ook software kan, bewust of onbewust, zo worden ontwikkeld dat jij als afnemer niet zonder aanzienlijke moeite en kosten kan overstappen op een alternatief. Dat een softwarepartner te goeder trouw is en geen bewuste vendor lock-in strategieën toepast, betekent niet dat het risico op lock-in minder groot is.
Gelukkig zijn er manieren om die afhankelijkheid een stuk beheersbaarder te maken. Hier zijn vijf thema’s om scherp in het vizier te houden, om zo te voorkomen dat vendor lock-in jou ten deel valt.
- Gekozen programmeertaal en technologieën
Jouw ontwikkelaar is misschien een groot fan van Elixir of Elm, maar is het the right tool for the job?
Obscure technologieën maken het lastig om je software mee te nemen en door een ander te laten doorontwikkelen. Developers vinden is lastig, je software opschalen verloopt problematisch, of investeerders of overnemende partijen haken zelfs af.
Kies een beproefde tech stack met een grote en actieve community. Populaire talen hebben meestal een overvloed aan open source frameworks en andere tools die helpen om software makkelijk overdraagbaar te maken. - Gebrek aan standaarden
In het verlengde daarvan: elke ontwikkelaar die ooit een softwareproject heeft georven waarin zelfbedachte database-, bestands- of communicatieprotocollen zijn verwerkt, weet wat voor kwelling het is om er mee te werken. De onderliggende gedachtegangen van die zelfgesmede oplossingen zit opgesloten in de hoofden van de oorspronkelijke ontwikkelaars. De, in het slechtste geval, ongedocumenteerde code biedt slechts een blik door het sleutelgat.
Het gebruik van open standaarden en breed gedragen technische normen is cruciaal voor software die ook door anderen begrepen en doorontwikkeld moet kunnen worden. Deze best practices zijn het resultaat van jarenlange collectieve ervaring, onderzoek en expertise, en zorgen voor degelijke, goed overdraagbare softwareprojecten. - Toegang tot je digitale assets
Je ontwikkelaar heeft plotseling een burn-out, of er onstaat een conflict met je software agency. Je kunt niet bij je code. De ontwikkeling staat stil, de continuïteit van jouw business komt in het gedrang. En nu?
Als je risico loopt op het wegvallen van zo’n single point of failure, dan wil je zelf bij je digitale assets kunnen. Heeft iemand in jouw organisatie toegang tot de broncode? Beschik je over de actuele technische documentatie en back-ups die je kunt overhandigen aan een andere ontwikkelaar? Heb je alle relevante wachtwoorden en sleutels? - Kwaliteit
Eén van de moeilijkste zaken voor een opdrachtgever om vast te stellen: hoe weet ik of de kwaliteit van de opgeleverde software naar behoren is? Is de juiste architectuur gekozen en zijn er voldoende unit tests? Kan een andere ontwikkelaar er ook mee overweg, of is de applicatie zo complex opgezet dat herbouwen het enige alternatief is?
Ten eerste is er een hoop te zien aan de buitenkant. Voldoet de opgeleverde software aan de vooraf gestelde specificaties en vereisten? Zijn alle functionaliteiten correct geïmplementeerd? Bevat de software bugs? Door functioneel te testen krijg je een degelijk beeld van de algehele deugdelijkheid van je softwareproduct. Betrek gebruikers hierbij – zij geven echte feedback over de bruikbaarheid en gebruikerservaring van de software.
Een andere manier om kwaliteit te beoordelen is door het uit laten voeren van een software audit. Dat kan je door een ander software agency laten doen, maar ook door een expert uit je netwerk die zonder vooringenomenheid code reviews uitvoert. Deze objectieve kwaliteitsbewaker voorziet je van een oordeel over de technische staat van je software. - Intellectueel eigendom
Ookal beschik je over de broncode, op papier kan de vork anders in de steel steken. Met andere woorden, wie is de eigenaar van de software? Het ligt voor de hand om te denken dat de eigendomsrechten bij jou, de opdrachtgever, liggen. Echter is de ontwikkelaar automatisch de auteur en eigenaar van de software, tenzij er anders is overeengekomen. Laat dus expliciet vastleggen dat het intellectuele eigendom van jouw software bij jou ligt.
Om risico’s zoals inbreuk op auteursrechten of licentiegeschillen af te dekken, is het daarnaast belangrijk dat ontwikkelaars geen proprietary software opnemen in jouw code, of open source componenten die commercieel hergebruik of aanpassingen niet toestaan.
Blijven of herbouwen?
Kom je tot de conclusie dat je ten prooi bent gevallen aan vendor lock-in? Dan blijven er vaak maximaal twee opties over: bij je huidige softwarepartner blijven of herbouwen.
Beide alternatieven zijn kostbaar, dus hou daarom een vinger aan de pols. Blijf kritisch naar je ontwikkelaar en vraag om een duidelijke verantwoording van bovenstaande thema’s.
Ook als je niet van plan bent om te breken met je ontwikkelaar, is het altijd wijs om een exitstrategie in het achterhoofd te houden. Zo voorkom je niet alleen een vendor lock-in, maar leg je als opdrachtgever ook de basis voor robuuste software die toekomstproof is.
