Opensource-drama bij enterprise- en overheidsorganisaties

Opensource-CMS-en zoals Drupal, Wordpress en Joomla bieden veel voordelen. Denk aan; het is gratis, ze bieden nagenoeg eindeloze functionaliteiten dankzij de uitbreidingen via modules of plug-ins, je kunt bij de meeste systemen zelf custom modules of plug-ins ontwikkelen en daarmee de functionaliteiten nog verder uitbreiden, code wordt gratis onderhouden door een community van ontwikkelaars die bugs en veiligheidslekken opsporen en verhelpen. 

Alternatief?

Je kunt iets 'from scratch' laten ontwikkelen door een team van developers, maar dan ben je vaak al door je budget heen met het maken van alleen nog maar de basisfunctionaliteiten. Terwijl die bij de meeste opensource-systemen zo op de plank liggen. Of je kunt kiezen voor een bestaande oplossing die iemand verhuurt onder een licentie. Denk aan systemen als Jira of Mailchimp. Zij bieden specifieke oplossingen en rekenen daar een x bedrag per maand voor. Maar zelf iets aanpassen aan deze 'closed source'-systemen is geen optie en even je data oppakken en verhuizen naar een ander systeem zit er vaak niet in.

Drempels

Ok, dus open source moet het wel worden. Het is in veel gevallen de meest logische keuze. Je vraagt een aantal offertes op, die passen allemaal mooi binnen budget. Maar bij het akkoord krijgen van de offerte beginnen diverse afdelingen vragen te stellen, waarbij het soms lastig is een antwoord te geven waarmee je je collega’s geruststelt.

Soms weten collega's niet precies hoe open source werkt of krijg je het lastig uitgelegd aan een jurist of privacyfunctionaris. Hieronder heb ik een aantal drempels beschreven waar onze opdrachtgevers vanuit overheidsorganisaties of grotere bedrijven tegenaan lopen en geef ik tips hoe je hiermee om kunt gaan.

Garantie en open source

Je kunt opensource-software gratis gebruiken en de code is van iedereen. Maar er gaat geen organisatie achter schuil bij wie je een claim kunt neerleggen wanneer de opensource-software niet werkt zoals je wilt dat het werkt.

Deels wordt dit probleem door de community achter een opensource-systeem zelf opgelost. Afhankelijk van hoe actief en professioneel een community is, worden bugs en securityfixes snel uitgebracht en wordt je systeem gratis voorzien van verbeteringen.

Anderzijds kun je een specialist inhuren die ervaring heeft met het opensource-systeem om problemen op te lossen. Denk hierbij aan kleine euvels die in de praktijk vervelend kunnen zijn, maar die relatief makkelijk op te lossen zijn voor een ervaren specialist. Zie ook het stukje over Service Level Agreements hieronder.

Daarnaast leert de praktijk dat een bug in een gesloten systeem van een leverancier bij wie je wel kunt aankloppen ook niet altijd oplosbaar is. Een bug in Windows kun je natuurlijk melden bij Microsoft, maar je hoeft niet te verwachten dat er direct een team van developers klaarstaat om eraan te werken.

Wel kun je garantie krijgen op de onderdelen die je eventueel op maat laat ontwikkelen. Denk aan een design, een theme of een op maat gemaakte module of koppeling. Maar op de open source code of werking daarvan is geen garantie. 

Doorontwikkeling en open source

De ontwikkeling met open source heeft een paar haken en ogen. Organisaties die net afstappen van een closedsource-systeem worden vaak gretig en willen van alles laten ontwikkelen. Gevolg is soms een opensource-systeem dat enorm veel eigen code bevat. Eigen code is code die geschreven wordt door een ingehuurde ontwikkelaar en die niet gedeeld wordt met en door de community. Je kunt jezelf dan de vraag stellen of het nog wel een opensource-project is. Een van de voordelen van open source is het niet vastzitten aan één leverancier, maar met heel veel eigen code is dat niet meer erg realistisch.

Als opdrachtgever ben je hier grotendeels zelf verantwoordelijk voor, maar een goede partner moet ook op de rem durven trappen.

Een truc is om vooraf een handrem af te spreken met je partner. Zo kun je aangeven (en ook opnemen in offertes en contracten) dat de doelstelling is om zoveel mogelijk opensource-techniek te gebruiken voordat er eventueel gegrepen wordt naar een op maat gemaakte oplossing waarbij het ontwikkelen van eigen code noodzakelijk is.

Nog een methode om binnen budget te blijven, is om te werken met vaste release cycles waarbij het budget vooraf bekend is. Vanuit de SCRUM-werkmethode worden dit ook wel sprints genoemd.

Veel van de budgetproblemen binnen de ICT ontstaan doordat opdrachtgevers met vaste projectprijzen willen werken. Er moeten hierdoor inschattingen gemaakt worden in een te vroeg stadium. Later blijkt in de praktijk dat een project veel complexer is dan gedacht of dat de wensen en eisen die aan het project gesteld werden niet kloppen.

Door te werken met een vast budget per periode kan het ontwikkelteam een realistischer inschatting maken en onderzoek doen. Ze kunnen bijvoorbeeld aangeven dat bepaalde functionaliteiten niet mogelijk zijn in deze release, maar wel in de volgende. Eventueel kun je teleurgesteld zijn dat de functie die je graag dit jaar nog wilde pas volgend jaar ontwikkeld wordt, maar je overschrijdt nooit je budget.

Service Level Agreements en open source

Binnen een SLA bepaal je een reeks van minimale eisen waaraan een leverancier moet voldoen. Je stelt ook vast wanneer iets 'extra' is of hoe een beslisstructuur eruitziet voor wanneer er een probleem is en hoe snel er gereageerd kan worden. 

Over het algemeen heb je het bij SLA's over bedrijfskritische systemen waarbij een SLA afgesloten wordt om de continuïteit van de systemen te waarborgen. Omdat deze bedrijfskritische systemen meer en meer op opensource-techniek gebaseerd worden zijn er dus ook SLA’s gewenst voor opensource-systemen.

Zoals ik al aangaf is het lastige daarbij dat er geen directe leverancier is van de opensource-techniek die de verantwoording draagt of kan dragen over de fouten die in de opensource-code zit. Wel kun je afspreken in een SLA op welke manier je opensource-partner hierin optreedt. Zo stellen wij in onze SLA's dat als zich een probleem voordoet binnen de Drupalcore of een van de Drupalmodules, we dit probleem onderzoeken en een alternatief of oplossing voorstellen.

Eigendom en open source

De meeste organisaties willen eigenaar zijn van wat ze laten maken. Dit ontstaat meestal niet vanuit de wens om het gemaakte te verkopen of te verhuren, maar uit angst dat zich later een partij meldt die een rekening presenteert. Alleen bestaat er een verschil tussen het recht van gebruik en het recht van eigendom, en dat laatste is lastig te claimen.

In het geval van opensource-techniek zijn de gebruiksrechten en beperkingen vaak goed vastgelegd. Dat gebeurt namelijk in een zogenaamde GNU General Public License. Drupal valt hier bijvoorbeeld onder.

In een General Public License (GPL) staat beschreven dat de opensource-software gratis te gebruiken is voor iedereen en wat er wel en niet mag. Zo mag je de software onder deze licentie altijd gratis gebruiken en aanpassen naar je eigen behoefte. Geld rekenen of een patent aanvragen op de techniek is niet toegestaan.

Naast de opensource-techniek is er vaak ook een component binnen een website of applicatie die 'op maat' wordt ontwikkeld. Denk aan een op maat gemaakte module, een koppeling of een webdesign. Deze onderdelen zijn uniek en alleen voor jouw organisatie. Maar ze zijn wel door iemand gemaakt die het auteursrecht bezit van dit stukje werk. Dit overdragen is vaak lastig omdat de maker nu eenmaal de maker is. 

Wel kun je duidelijke afspraken maken binnen SLA's, offertes of andere contracten, die het gebruiksrecht duidelijk beschrijven. Zo kan jouw organisatie altijd gebruik blijven maken van dat stukje dat speciaal voor jou op maat gemaakt is.

Privacy en open source

Het is vaak de inrichting van een systeem en de omgang met persoonsgegevens die ervoor zorgen dat iets ‘AVG-proof’ is. In de praktijk kan elk systeem AVG-proof zijn, maar zodra er een exportfunctie wordt gebouwd die alle persoonsgegevens exporteert naar een Excelbestand ontstaan er al snel problemen. Niet direct natuurlijk, maar pas achteraf wanneer de Excelfile op een usb-stick in een trein wordt gevonden.

Net als bij elke leverancier of partner die toegang heeft tot de persoonsgegevens is het zaak om een bewerkersovereenkomst af te sluiten. Als opdrachtgever ben je hier zelf verantwoordelijk voor. Een bewerkersovereenkomst is een relatief simpel document waarin staat dat de partij die bij de persoonsgegevens kan, dat op een zorgvuldige en veilige manier doet. 

Daarnaast kun je ook kritisch kijken naar welke partners je kiest als het gaat om privacy. Welke tools gebruiken ze zelf? Hoe gaan ze om met privacygevoelige kwesties? Wij hebben dit soort zaken beschreven in een Privacy Beleidsplan waar we binnen onze SLA's naar verwijzen zodat iedereen weet hoe we hiermee omgaan. Andere specialisten zullen dit misschien anders oplossen, maar het is in ieder geval belangrijk erover na te denken, het te bespreken met de partij waarmee je samen gaat werken en daar iets over op papier te zetten. 

Exitstrategie en open source

Een van de voordelen van open source is dat je niet vastzit aan een bepaalde partij. Je kunt zolang je de doorontwikkeling goed hebt ingericht switchen naar een andere specialist, maar dan is het wel verstandig daar het een en ander over vast te leggen.

Hoe ga je precies uit elkaar? Wat verwacht je van de partij die je opensource-systeem heeft opgezet en beheerd? En mag de partij daar kosten voor in rekening brengen?

Misschien heb je een vrij complex systeem en wil je dat er technische documentatie wordt bijgehouden die bij een exit wordt geüpdatet en met een toelichting wordt overgedragen aan de nieuwe partner. Dit zijn suggesties die een overgang kunnen versoepelen, maar ook kostbaar kunnen zijn. 

Security en open source

Een vraag die we vaak krijgen: is open source veilig? En het antwoord na meer dan 20 jaar ervaring is: ja. Zolang je bijtijds security-updates doorvoert en zaken als hosting goed op orde hebt zijn er weinig gevallen bekend waarbij een website of webapplicatie gehackt is. In de gevallen waarbij dat wel is gebeurd, lees je meestal dat het ging om een minder sterk beveiligd CMS zoals Joomla of Wordpress waarbij óf de hosting niet op orde was, óf het CMS niet onderhouden/up-to-date was.

Wat kun je doen om je opensource-website of -webapplicatie nog veiliger te maken? Denk bijvoorbeeld aan two-step authentication, waarbij de inloggende bezoeker naast het bekende wachtwoord een extra code nodig heeft. Het is als enterprise- of overheidsorganisatie ook aan te raden om met regelmaat de systemen te laten 'penetrationtesten', ook wel 'pentesten' genoemd.

Met een pentest wordt gekeken of een systeem zwakke plekken heeft en doet de pentester aanbevelingen om de beveiliging te verbeteren. Of de oplossingen die nodig zijn voor het doorvoeren van deze aanbevelingen beschikbaar zijn binnen jouw opensource-systeem hangt af van de keuze van het systeem.

Binnen contentmanagement-systemen zien we dat Drupal vaak gebruikt wordt in een enterprisesetting. Daarom worden dus vaker pentests op Drupal uitgevoerd, wat weer resulteert in meer beschikbare oplossingen om de beveiliging op te schroeven. 

Praktische tips:

• Leg binnen je organisatie uit wat open source is. Hoe het werkt, wie eraan werkt, van wie het is. Onbekend is onbemind, en wanneer je achterban beter begrijpt wat de voordelen zijn en hoe open source tot stand komt, kom je vaak al een stuk verder.

https://youtu.be/Tyd0FO0tko8

• Zoek een partner die je situatie begrijpt. Die meegaat in het tegemoetkomen van wensen, maar ook tegengas durft te geven. Onrealistische beloften lijken soms fijn om een project er doorheen te krijgen, maar op lange termijn kan het voor problemen zorgen.
   
• Spreek een aantal zaken schriftelijk af met je opensource-partner. Dat kan in een SLA, een offerte of in een aanvullend contract. Denk aan gebruiksrecht, exitstrategie en omgang met persoonsgegevens. 
   
• Neem security serieus en maak hier een terugkerend proces van. Bijvoorbeeld een jaarlijkse pentest waarna het systeem verbeterd wordt op basis van de aanbevelingen.