De vraag viel weer tijdens een recente vergadering bij een klant: Moeten we open source software (oss) inzetten of niet? Voor veel organisaties een lastige vraag om te beantwoorden. Uiteraard is het er wel een die beantwoord moet worden. Het is echter jammer dat er niet altijd zakelijke criteria en argumenten gebruikt worden.
Sommige voorstanders van Oosshebben zeer idealistische redenen. Zij vinden dat leveranciers van niet-oss te commercieel zijn. Anderen propageren oss om een monopoliepositie van een leverancier te doorbreken. En er zijn er die het gewoon hip vinden.
Uiteindelijk zullen we allemaal oss in huis hebben. De software die tegenwoordig ontwikkeld moet worden is zo complex en bestaat uit zoveel regels code, dat de meeste klassieke leveranciers zelf oss gebruiken. Dus als u van een klassieke leverancier commerciële software koopt, dan is de kans groot dat daar oss in verwerkt zit. IBM, SAP, allemaal gebruiken ze open source modules in hun eigen software.
Software dient niet aangeschaft te worden puur en alleen omdat het open source is. Criteria die gehanteerd moeten worden zijn prijs, prestatie, functionaliteit, ondersteuning, toekomsttransparantie en compleetheid van de leveranciersportfolio. De eerste vier spreken voor zich. De laatste twee vereisen enige toelichting.
Met toekomsttransparantie wordt bedoeld hoe duidelijk de leverancier de toekomstplannen van haar software bekendmaakt. Laat ik een voorbeeld geven. Momenteel ben ik twee boeken aan het schrijven, een over IBM’s DB2 en een ander over MySQL. Bij het schrijven loop ik tegen bugs aan en kom ik onduidelijkheden betreffende de implementatie tegen (waarom werkt iets zoals het werkt). Tevens moet ik bepalen voor welke versies ik die boeken ga schrijven.
Als er een probleem of onduidelijkheid is met DB2, dan heb ik binnen enkele dagen een duidelijk antwoord op mijn email en weet ik precies waar ik aan toe ben. IBM kan ook precies aangeven of in een nieuwe versie bepaalde functionaliteit opgenomen zal worden.
Bij MySQL is dat een heel ander verhaal. Als ik daar een bug tegenkom, deze rapporteer en vervolgens vraag wanneer dat gerepareerd wordt, dan is het antwoord steevast: we weten niet precies wanneer iemand dat probleem oppakt. Als ik wil weten of een bepaalde SQL-extensie al dan niet in de nieuwe versie opgenomen zal worden, is het antwoord: we weten niet of we er aan toekomen. Misschien wel, misschien niet. Dan is er voor de buitenstaander weinig toekomsttransparantie.
Nu ben ik slechts een schrijver van een boek. Voor een klant die nieuwe applicaties op MySQL wil bouwen kan dat frustrerend zijn. Klanten dienen duidelijkheid en helderheid te hebben wat betreft de software die zij inzetten. Dit kunnen oss-leveranciers vanwege de wijze van ontwikkeling zelden bieden.
Steeds meer klanten hebben geen zin meer om zelf verschillende softwarecomponenten te integreren om een applicatie te kunnen bouwen. Steeds vaker wordt van een leverancier verwacht dat hij een complete portfolio van software heeft. Als klant willen we bij één leverancier de meeste software kunnen aanschaffen en we mogen aannemen dat die samenwerken. Hier hebben bedrijven als IBM, Microsoft, Oracle en SAP voor een deel hun succes aan te danken. Maar dit kunnen oss-leveranciers momenteel niet bieden. De meeste richten zich op één of enkele softwarecomponenten. Hierdoor komt de integratieproblematiek volledig bij de klant te liggen.
Dat organisaties over oss nadenken, lijkt me prima en terecht. Dat er teveel niet-zakelijke argumenten gehanteerd worden, daar heb ik een probleem mee. De consequenties van het kiezen van software zijn groot en werken door op lange termijn. Daarom dienen we naar de gebruikelijke criteria te kijken, inclusief de genoemde toekomsttransparantie en de compleetheid van de portfolio.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
