Onafhankelijk software laten bouwen

Je hebt een website of softwarepakket laten bouwen. Duizenden, tienduizenden of misschien nog meer geïnvesteerd in een product. Het werkt naar behoren en het rendeert. Maar kom jij ooit nog van je ontwikkelaar af? Heb jij vrijheid om te gaan en te staan of sta je volledig klem en kan je geen kant meer op?

Impact van afhankelijkheid

Afhankelijkheid van software en web ontwikkelaars speelt een grote rol bij veel bedrijven. De laatste jaren heb ik opgemerkt dat ondernemers hier (gelukkig) steeds vaker van bewust zijn. Steeds vaker krijg ik bijvoorbeeld van potentiële klanten de vraag wat zij kunnen doen zodra ik tegen de klassieke boom rijd. Toch zijn de gevolgen niet altijd te overzien en gebeurt het regelmatig dat er een hoop ellende op je afkomt als het gaat om het overstappen naar een andere ontwikkelaar.

Relatie met web / software ontwikkelaar

Een kink in de kabel, daar denk je waarschijnlijk meteen aan als we het hebben over het ontbinden van contracten of het beëindigen van een relatie tussen ondernemer en developer. Echter groei, capaciteit, faillissement, expertise, specialisme, doelstelling, visie en budgetteringen zijn zomaar wat redenen die ook een grote rol kunnen spelen bij een switch tussen web of software ontwikkelaars. De dienstverlening kan volledig naar wens zijn, maar het moet aansluiten op de manier waarop jij graag je business voert. De vrijheid om over te stappen naar een andere partij voor development is cruciaal. De reden is niet eens zozeer van belang, maar als ondernemer wil je niet klem komen te staan. Niet bij een relatief kleine investering voor een eenvoudige basiswebsite, maar zeker niet bij grote complexe softwareproducten waarvan jouw bedrijfsvoering en inkomstenbron afhankelijk is.

Code en framework

Het begint bij de basis. Een programmeur heeft vaak een eigen stijl en manier van ontwikkelen. Als iemand dat moet overnemen zonder documentatie en de juiste commentaren in de code, kan er enorm veel tijd verloren raken aan het inleven, het ‘eigen maken’ en het waar nodig aanpassen van code. Nog erger is wanneer er niet conform de basic principes wordt geprogrammeerd. Met name junior programmeurs bedenken nog wel eens een ‘omweg’ of kiezen voor de makkelijke cq snelle weg bij het bouwen van software. We zien nog vaak dat er slecht omgegaan wordt met frameworks (op manieren waar zo’n framework niet voor bedoeld is) of zelfs dat er überhaupt geen framework gebruikt wordt. Een softwarepakket als basis begint vaak in het klein bij bijvoorbeeld een stagiair die later binnen een organisatie zichzelf tot programmeur opschaalt. Als eigenaar van software zie je niet of de code of framework op orde is en dat maakt het juist zo lastig om te beoordelen of het goed in elkaar zit. Het kan geen kwaad om zo nu en dan een externe ervaren programmeur zijdelings te laten beoordelen. Zo weet je waar je staat en dek je jezelf in tegen de fout die het meest gemaakt wordt.

Juridische onafhankelijkheid

Software die jij laat maken is van jou, dat lijkt eenvoudig. Toch is een programmeur vaak in staat om software door te verkopen en hetgeen hij heeft ontwikkeld voor andere doeleinden te gebruiken. Dit is vaak niet wenselijk, hoewel het in bepaalde situaties ook voordelen voor jou kan hebben. Hergebruik betekent ook wel een efficiënte manier van programmeren. Wat al ‘op de schap’ ligt, kan ook voor jou toegepast worden. Wél wil je natuurlijk voorkomen dat je complete software op straat komt te liggen of doorverkocht wordt. Leg dit goed vast in een juridisch document. Zorg ook dat je een geheimhoudingsverklaring laat ondertekenen, want de ontwikkelaar van de software ziet alle data binnen je software omgeving. Dus ook zodra het in productie genomen wordt en de ontwikkelaar nog betrokken is bij het beheer.

Toegang tot je software

Software laten bouwen en vervolgens totaal niet op de hoogte zijn van de standplaats van het framework, dit moet herkenbaar zijn voor veel ondernemers die al ooit software hebben laten bouwen. Vaak hebben ontwikkelaars - terecht - de voorkeur om software zelf te hosten. Gezien er daardoor geen betrokkenheid wordt gecreëerd die jou op de hoogte brengt van de inrichting van de infrastructuur, heb je als ondernemer vaak geen toegang tot je eigen software. Mocht er dan iets misgaan, sta je mooi te kijken.

Zorg dat je toegang hebt tot - op zijn minst - de back-ups van de storage omgeving en database. Vraag ook altijd toegang tot de versiebeheer omgeving die je ontwikkelaar hanteert (Github / Gitlab etc). Deze stelt je in staat om wijzigingen in je software te monitoren, terug te draaien en je code altijd elders te deployen (onder te brengen). Als je deze gegevens paraat hebt, kan dat zonder tussenkomst van de ontwikkelaar.

Domeinhouder

Koop je domeinnaam elders of zorg dat de WHOIS gegevens (domeinhouder gegevens) op jouw bedrijf staan. Dit kan ik niet vaak genoeg zeggen, want vaak zet de ontwikkelaar uit gemak een domeinnaam op naam van het IT bedrijf. Je hebt dan geen juridische eigendomsrechten over je domeinnaam en dat is natuurlijk zeer gevoelig voor misbruik of conflicten. Op sites als sidn.nl (voor .nl domeinen) of whois.com vind je de eigendomgegevens van een domeinnaam.

Backend, en koppelingen

Regelmatig wordt er gebruik gemaakt van een centrale back-end of koppelingen met reeds ontwikkelde software bij ontwikkelaars. Het is de bedoeling dat jouw software los en onafhankelijk van andere softwarepakketten draait. Informeer en leg goed vast hoe afhankelijk jij bent van derde software (onderdelen) of externe koppelingen.

Backdoor

Tot slot hebben ontwikkelaars nog wel eens backdoors. Denk aan testaccounts die je als beheerder niet kan verwijderen of key’s en URL’s om op bepaalde manier toegang te krijgen. Meestal niet uit kwaadwil, maar eenvoud tijdens het ontwikkelen. Laat altijd goed controleren of je vorige ontwikkelaar nog toegang kan hebben, als je overstapt naar een andere partij.