Op dagelijkse basis kiezen bedrijven en organisaties software pakketten. Deze keuze is een rationeel proces of een “uitgemaakte zaak”. Indien het een “uitgemaakte zaak” betreft, staat de keuze al vast. Veelal was er dan sprake van een emotioneel proces. Dit white paper beschrijft hoofdzakelijk het rationele keuze proces.

Rationeel proces

Als software pakket keuze rationeel tot stand komt spelen er een viertal factoren een rol. Eerst wordt er naar functionele zaken gekeken. Het software pakket moet immers een functioneel business vraagstuk oplossen en als het dat niet doet heeft het geen nut. Voldoet de software aan de functionele aspecten, dan zijn er drie aspecten die daarna overwogen worden, te weten, kosten en kwaliteit. Als laatste is risico een aspect dat de overige drie beïnvloedt.

Bij het keuze proces kunnen ook juist emoties een rol spelen. 
Zo kan er om verschillende redenen een sterkte voorkeur 
(of juist afkeur) zijn van bijvoorbeeld een product of leverancier. 
Zo kan het voorkomen dat men per se open source software wil - 
ongeacht de rationele aspecten. Mogelijk heeft de persoon 
die de keuze moet maken relaties bij een betreffende 
leverancier en is er daarom een voorkeur.

De keuze tussen emotioneel proces of rationeel proces 
wordt niet alleen in het begin gemaakt. Dit kan ook later 
in het proces. Zo kan bijvoorbeeld gestart worden met een 
rationeel proces maar toch halverwege op emotionele 
gronden een keuze gemaakt worden. Misschien heeft men 
een hekel gekregen aan de account manager waarmee men 
contact heeft.

 

 

 

 

Het functionele aspect

Als eerste wordt software beoordeeld op functionaliteit. Functionaliteit wordt hier breed gedefinieerd, als alle kenmerken waaraan het moet voldoen zoals, pakket functionaliteit, minimale performance, het moet aansluiten bij de (toekomstige) overige ICT infrastructuur enz. Ook hebben bedrijven en organisaties soms bestaand ICT beleid dat de keuze beïnvloedt.

In de meest eenvoudige vorm wordt een lijst van functionele specificaties opgesteld waarop een aantal software pakketten beoordeeld worden. Echter, dit gaat uit van het idee dat alle functionele aspecten even “zwaar wegen”. In de praktijk is dat niet het geval. Aan de functionele specificaties kan dus een wegingsfactor worden toegekend. Een factor kan bijvoorbeeld twee keer zo “zwaar wegen” als een andere. De onderstaande figuur is een voorbeeld van een dergelijk afweging.

Er is te zien dat Functionele eis 4 (F4) het “zwaarste weegt” (met een factor 10) en dat uiteindelijk pakket 2 (S2) als hoogste scoort.

Wat in de figuur nog mist is dat sommige functionele vereisten een “knock out” criterium kunnen zijn. Heeft een software pakket deze vereiste(n) niet, dan valt het geheel af, ongeacht andere aspecten. Een “knock out” criterium kan op verschillende manieren in een keuze matrix worden verwerkt.

 

Het kosten aspect

Van het totaal aantal software pakketten dat beoordeeld is op functionaliteit zullen er enkele afgevallen zijn en ongetwijfeld een aantal over gebleven zijn. In een rationeel proces zal daarna echter ook gekeken worden naar de kosten. Deze kosten bestaan uit:

• licentiekosten,
• supportkosten (subscripties bij commerciële open source software),
• implementatiekosten,
• migratiekosten,
• kosten voor beheer,
• kosten voor hardware, housing, stroom en koeling,
• exitkosten,
• enz.

Kortom, we spreken hier snel over Total Cost of Ownership (TCO). Dat zijn alle kosten die gemaakt worden om software over een bepaalde periode te kunnen gebruiken.

Overwogen kan worden om een business case te schrijven. In de meeste gevallen worden in de business case alle aspecten meegenomen zoals in dit artikel zijn beschreven, alhoewel de kosten vaak het meest nadrukkelijk aan bod komen.

Het kwaliteitsaspect

De software pakketten die door de kosten afweging komen (en dus nog niet zijn afgevallen) kunnen hierna beoordeeld worden op kwaliteit. Zo kan het voorkomen dat alle pakketten die nog in “de race” zijn het performance criterium hebben gehaald, maar dat bij gelijke kosten toch de voorkeur uitgaat naar het pakket met de hoogste performance. Dit is een argument als verwacht wordt dat performance in de toekomst een rol gaat spelen.

Een ander kwaliteitsaspect is het data format in software pakketten. Voor een goede toegankelijkheid van data en lage (toekomstige) exit kosten kan de voorkeur uit gaan naar een open format zoals dat gegarandeerd in open source software gebruikt wordt.

De volgorde tussen kosten en kwaliteit staat niet vast. 
Soms is het kwaliteitsaspect belangrijker dan het kosten
aspect. In zo'n geval zal eerst naar kwaliteit worden gekeken 
en daarna pas naar kosten.

 

Risico

Als laatste speelt er het risico. Het beïnvloedt de drie overige keuze aspecten. Zo kan na de implementatie blijken dat de functionaliteit niet blijkt overeen te komen met het onderzoek en vergelijk dat daarnaar is uitgevoerd. Ook kan de kwaliteit lager blijken dan gedacht. De software is bijvoorbeeld niet zo stabiel als verwacht. Er kunnen ook risico’s zijn die de kosten beïnvloeden. De project kan uitlopen en er is dan bijvoorbeeld sprake van hogere implementatiekosten en een langere Time To Market. Ook kan blijken dat er meer specialistische hulp nodig is tijdens de implementatie of dat er meer opleidingskosten blijken te zijn. Als laatste kan hier worden genoemd – en die wordt vaak vergeten – dat de exit kosten hoger uitvallen dan begroot. De exit kosten “vallen” vaak jaren later en worden nog wel eens ten onrechte aan de implementatie van een nieuw pakket toe gewezen. Uiteindelijk kunnen alle risico’s in kosten worden uitgedrukt.

Rationeel versus emotioneel

Zoals eerder genoemd kan een rationeel keuze proces halverwege veranderen in een emotioneel keuzeproces. In veel business beslissingen speelt emotie mee. De vraag is waar een organisatie of bedrijf het beste mee geholpen is. Vanuit de stroming van het “scientific management” zal de voorkeur naar het rationele beslissingsproces uitgaan. De moeilijkheid in de discussie rond rationeel versus emotioneel is dat we het vaak niet weten hoe het precies zit. Het keuze proces kan alle schijn hebben dat het een rationeel proces is, maar in werkelijkheid is de keuze (emotioneel) allang gemaakt. Het begeleiden van dergelijke keuze processen is daarom erg lastig en een potentieel “mijnenveld”.

Hoe verhoudt OSS zich hiertoe?

In de discussie rond de keuze van software pakketten kan men zich afvragen wat de relatie is met  open source software.

Juist bij OSS speelt emotie vaak een rol. Zo kan men overtuigd zijn dat OSS de betere keuze is. Er zijn bedrijven die een policy hanteren waarin OSS de voorkeur geniet. Hier loert het risico van een “geloofsdiscussie”. Omgekeerd kan natuurlijk ook. Tegenstanders van OSS zullen bijvoorbeeld stellen dat software van Microsoft de voorkeur geniet. Men is dan mogelijk van mening dat open source software hobbyisme is. Zodra emoties een rol spelen in het keuze proces zijn de feiten ver te zoeken.

OSS en functionele aspecten

Of software voldoet aan de functionele vereisten hangt sterk af van de exacte vraag die ingevuld moet worden. In het algemeen is het beeld hierbij dat hoe generieker de functionaliteit, hoe groter de kans dat dit goed met OSS ingevuld kan worden. De uitersten hierbij zijn bijvoorbeeld een operating systeem (Linux) dat door heel veel mensen gebruikt wordt. Mede hierom, maar ook omdat het technische functionaliteit betreft (en daarvoor interesseren veel software ontwikkelaars zich), heeft zich hieromheen een omvangrijke community gevormd. Deze community bestaat inmiddels – mede – uit veel grote ICT bedrijven zoals IBM, Red Hat, HP, Novell enz. Aan het andere eind van het spectrum zit bijvoorbeeld de “vrachtwagendraaicirkel applicatie. Dit is een applicatie die door gemeenten gebruikt wordt om bochten in wegen te berekenen zodat vrachtwagens die zonder problemen kunnen berijden. De markt hiervoor is betrekkelijk klein en niet erg interessant voor software developpers. Er zal daarom geen community rond ontstaan en de kans dat dergelijke functionaliteit met OSS ingevuld kan worden is buitengewoon klein.

OSS en kosten

Een interessante discussie rond OSS is of hiermee kosten bespaard kunnen worden. Dit hangt natuurlijk af van de TCO berekening. Het is wel belangrijk dat hierbij de subscriptiekosten vergeleken worden met de kosten van support en niet met de licentiekosten. Immers, licentiekosten geven recht op gebruik van de software en bij OSS heeft men al recht op gebruik. De subscriptiekosten geven recht op support, media en toegang tot supportfora en beheer software (zoals Red Hat network).

Hoewel de uitkomst hiervan sterk afhangt van de TCO berekening laten sommige business cases een duidelijk voordeel voor OSS zien. Dit is ook niet heel moeilijk te begrijpen, want de licentiekosten zijn bij OSS afwezig, dus dat is als eerste “gewonnen”.

In een goede TCO berekening worden alle keuzes en aannames beschreven (met onderbouwing) en wordt gewaakt om niet “appels met peren” te vergelijken.

OSS en kwaliteit

Als closed source software concurreert met OSS, dan is dat meestal op grond van features. In het algemeen kan gesteld worden dat closed sources software meer features kent dan OSS. Het is hierbij dus de vraag of dit essentiële features betreft. Bedrijven en organisaties die hiermee ervaring hebben opgedaan merken dat OSS vaak wel alle essentiële features heeft.

De technische kwaliteit van OSS is vaak goed. Hiervoor zijn meerdere redenen te noemen. Ten eerste willen OSS developers trots kunnen zijn op hun werk. Het gevolg hiervan is dat bugs snel verholpen worden. Nog een groot voordeel van het development model van OSS is dat er geen marketing is. Er is geen marketing directeur die bepaalt wat er wel of niet in de software komt. Zo was bijvoorbeeld de eerste firewall code in de Linux kernel ipfwadm. Deze werd vervangen door ipchains en binnen een of twee jaar door iptables. Dit zou voor een marketing afdeling een angstdroom zijn. Hoe vertellen we onze klanten dat we de systematiek van firewalls maken weer veranderd hebben, dat ze opnieuw moeten migreren en opnieuw moeten opleiden? In OSS projecten* is dit geen probleem. Marketing en verkoop speelt geen enkele rol, die zijn er niet. De beste code wint het lijkt daarmee op een soort “survival of the fittest”. Vanuit het OSS development model mag verwacht worden dat snel superieure code geproduceerd wordt. Bedrijven die voor (technische) kwaliteit gaan doen er verstandig aan OSS in de keuze te betrekken.

* bij commerciële OSS projecten ligt dit wat genuanceerder…

OSS en risico

Ondanks grote verschillen tussen closed source software en OSS, blijft het in beide gevallen “gewoon” software met alle risico’s die daarbij komen kijken. Het risico van uitloopt van projecten, tegenvallende functionaliteit of gebrek aan kwaliteit zijn bij beiden aanwezig. Maar er zijn ook verschillen.

OSS kan makkelijk uitgeprobeerd worden. Het ontbreken van licentiekosten maakt het mogelijk tegen lage kosten een Proof of Concept (PoC)** te doen. Zo kan op voorhand een aantal risico’s worden uitgesloten. De functionaliteit, performance en stabiliteit kan worden getest. Er kan een (proef) migratie worden gedaan en de exitkosten kunnen proefondervindelijk uitgezocht worden.

** het risico hierbij is dat een slechte implementatie een verkeerd negatief beeld geeft van de software…

Nog een aantrekkelijk aspect van OSS is dat bedrijven en organisatie altijd de vrijheid hebben om de code aan te passen of te laten aanpassen. Zo kunnen custom functies worden geïmplementeerd of drivers toegevoegd worden. Hiervoor kunnen professionele developpers worden ingehuurd of zelfs mensen van de community van het betreffende stuk software.

Een risico waarover veel wordt gesproken bij OSS, zijn Itellectual Property (IP) schendingen en de aanklachten die daarmee gepaard gaan. Microsoft meent al jaren dat Linux patenten van Microsoft schendt. Verschillende bedrijven (klanten) hebben dat risico inmiddels afgekocht bij Microsoft. Overigens is tot op de dag van vandaag nooit gespecificeerd om welke code het precies gaat. De reden daarvoor is eenvoudig. De community herschrijft de code in zo’n geval meteen en daarmee vervalt alle “grip” die Microsoft heeft op Linux. En dat is niet in het belang van Microsoft. Verschillende commerciële aanbieders van OSS (zoals bijvoorbeeld Red Hat en Novell) beschermen hun klanten tegen dergelijk IP zaken.

Conclusie 

Het is goed software op rationele gronden te kiezen. Toch speelt emotie vaak een grote rol. Dit is niet in het belang van de organisatie die de software gaat gebruiken. Er zijn verschillende tools (o.a. gewogen keuze matrix en business case) die kunnen helpen de emotie tijdens het keuze proces binnen de perken te houden. In de praktijk kan verwacht worden dat het keuze proces zowel rationeel verloopt als dat er emotie een rol speelt.

OSS is, rationeel gezien, bij alle aspecten een optie. De specifieke situatie zal dan bepalen of het past, of dat een closed source software pakket beter aansluit. Emotie kan het oordeel zowel naar closed source software als naar OSS laten doorslaan. De ervaring leert dat rond OSS emotie zeker  een rol speelt.

In de praktijk zal eigenlijk altijd sprake zijn van
zowel een rationeel proces als emotie. De moeilijkheid
schuilt hierin dat emotionele motieven vaak rationeel
onderbouwd zullen worden. Dus, "rationeel gecamoufleerd"
worden emotionele motieven nagestreefd.
Emotionele motieven kunnen zijn dat men voorkeur heeft
voor een product of leverancier, maar dat niet
rationeel onderbouwd kan worden.

Als laatste is er natuurlijk de keuze voor maatwerk. Als software pakketten niet voldoen, is er altijd de optie het zelf te maken (of te laten het maken). In de markt wordt nog veel software zelf ontwikkeld. Of het nu gaat om applicaties op telefoons en tables (de zogenaamde “apps”) of het aanpassen van webshops, er zijn nog steeds erg veel bedrijven bezig met software development. OSS biedt buitengewoon veel mogelijkheden voor maatwerk of het aanpassen van bestaande software.