Closed source is niet heiligmakend

Verstokte voorstanders van closed source software beweren vaak dat dergelijke software beter wordt getest en dat problemen bij klanten ook sneller worden opgelost. Dat is niet onze ervaring!

Filip Vervloesem

In onze carrière als Linux sysadmin komen we nog geregeld in contact met closed source software. Het is erg onwaarschijnlijk om een bedrijfsomgeving voor de volle 100% op open source software te draaien, al was het maar omdat je voor out-of-band management bij servers vasthangt aan de closed source oplossing van de fabrikant. In grotere bedrijven heb je als Linux sysadmin ook niet altijd de vrijheid om voor elke toepassing een open source oplossing te kiezen. Dat zie je bijvoorbeeld geregeld als er in andere teams al een closed source pakket gebruikt wordt voor dezelfde toepassing. Heeft het Windows-team al VMWare gekozen voor servervirtualisatie? Dan ziet de IT-manager natuurlijk liever niet dat jij voor de Linux-systemen Red Hat Virtualization gaat implementeren. Hoe minder verschillende oplossingen, hoe minder complex de omgeving en hoe kleiner de kans op fouten. Volumekortingen op licenties en onderhoudscontracten spelen natuurlijk ook een belangrijke rol.

Betaalde ondersteuning

Bij de meeste commerciële pakketten betalen bedrijven jaarlijks een niet onaardige som voor ondersteuning vanuit de fabrikant. Jammer genoeg is dat geen garantie op een snelle afhandeling van fouten. Het meest frappante voorbeeld uit onze ervaring betreft de ILO remote console voor servers van HP. Via de ILO webinterface kun je op afstand toegang krijgen tot het beeldscherm, de muis en het toetsenbord van de server. Die is onmisbaar om servers te installeren, BIOS-instellingen aan te passen of problemen te troubleshooten als de server niet meer bereikbaar is via het netwerk. Aangezien we in België nog steeds met een AZERTY-toetsenbordlay-out werken (dank u, Frankrijk!), is het altijd in spanning afwachten of het toetsenbord van de remote console wel correct werkt. Gelukkig stond onze Belgische toetsenbordlay-out in de lijst van ondersteunde indelingen van de ILO console.

Ellenlange wachttijd

Voor nieuwere servers met de laatste ILO-versie liep het enkele jaren geleden echter grondig mis. Als we de toetsenbordlay-out in de remote console op AZERTY instelden, gaf de z-toets een ‘w’ terug (alsof die nog in QWERTY stond), maar ook de w-toets gaf een ‘w’ terug. Kortom: met die AWERTY-layout konden we onmogelijk een ‘z’ invoeren! Je wil niet weten hoeveel tijd en moeite het heeft gekost om die fout recht te zetten! We hebben letterlijk uren aan de lijn gehangen met Indische support-medewerkers (niet de meest aangename bezigheid) om hen simpelweg duidelijk te maken wat precies ons probleem was. Het hielp natuurlijk niet dat we een vrij obscure toetsenbordlay-out gebruikten én dat het probleem zich enkel voordeed in een browser op een Linux-client (onder Windows werkte het wel correct). Uiteindelijk heeft het meer dan zes maanden geduurd voordat we bij iemand terechtkwamen die toegang had tot de broncode. Die persoon gaf meteen toe dat het schandalig lang geduurd had voordat die fout bij hem terechtkwam.

Tikfout

Het was immers helemaal geen ingewikkelde fout: het volstond om één letter te wijzigen in de broncode (een ‘w’ in een ‘z’) en de code te her-compileren om ons probleem op te lossen. Inderdaad: het was gewoon een domme tikfout. Zou de ILO open source software geweest zijn, dan hadden we die fout gewoon zélf kunnen rechtzetten en was ons probleem wellicht na een halve dag al opgelost. Zo zie je maar: dure closed source software is echt niet per se beter dan open source software!