Als bedrijf wil je zonder al te veel moeite kunnen wisselen van softwareleverancier. In praktijk blijkt dat soms lastig te zijn. Bijvoorbeeld bij gemeenten, die te afhankelijk zouden zijn van een tweetal grote IT-leveranciers. Aan de hand van deze casus wordt bezien hoe afhankelijkheid ontstaat en wat je er zoal aan kunt doen.
Onlangs werd, na een onderzoek van NRC Handelsblad en Reporter Radio, gesteld dat Nederlandse gemeenten te afhankelijk zijn van een tweetal grote it-leveranciers. Een ‘duopolie’ en ‘vendor lock-in’ zouden tot een dysfunctionele marktsituatie leiden. Laten we eerst eens kijken of de termen ‘duopolie’ en ‘vendor lock-in’ terecht worden gebruikt om de situatie te beschrijven.
Volgens van Dale gaat het bij een monopolie om ‘de situatie dat iemand als enige iets kan of mag verkopen’. Gaat het om twee leveranciers, dan noemen we het een duopolie. Een blik in de Softwarecatalogus voor gemeenten leert dat, alleen daar al, 178 leveranciers een of meer producten aanbieden. Enkele kernapplicaties worden soms slechts door een handvol aanbieders aangeboden, maar feitelijk is er dus geen sprake van een duopolie.
Vendor lock-in dan? Wikipedia zegt hierover: ‘Vendor lock-in maakt een klant afhankelijk van een leverancier voor producten en diensten, omdat hij niet in staat is om van leverancier te veranderen zonder substantiële omschakelingskosten of ongemak. Om te kunnen spreken van vendor lock-in dient er bovendien sprake te zijn van een superieur of beter alternatief waar de klant naar zou willen overstappen. Zou er geen superieur of beter alternatief zijn dan is de gekozen oplossing optimaal en zal de klant de afhankelijkheid van de leverancier niet beschouwen als een lock-in.’ Twee dingen vallen op in deze omschrijving: er moet een beter alternatief beschikbaar zijn en het hangt mede af van de mate waarin de afnemende partij in staat is om over te stappen of er sprake is van een vendor lock-in. Uit het uitgevoerde onderzoek blijkt dat ‘de helft van de gemeenten hun eigen positie ziet als niet sterk genoeg om zelf te beslissen welke systemen ze zal aanschaffen en dus blijven ze maar bij oud en vertrouwd”. In hoeverre er bij gemeenten wel of geen sprake is van een vendor lock-in is daarmee lastig in zijn algemeenheid te zeggen.
Pad-afhankelijkheid
Kies je strategisch voor een bepaald product of leverancier, dan sla je daarmee altijd een bepaalde weg in. Windows of Linux? Oracle of SQL Server? On-premise of cloud? Centric of Pink Roccade? Heb je een belangrijke keuze eenmaal gemaakt, dan worden toekomstige keuzes vaak in lijn daarmee gemaakt. Soms omdat het duidelijke voordelen biedt, soms omdat gekozen oplossingen als standaard zijn benoemd en gebruik verplicht is gesteld.
Als bedrijf of sector strategische keuzes maken en afspreken welke paden je daarbij gaat volgen is verstandig. Maar er zit ook een keerzijde aan, die wordt aangeduid met de term ‘pad-afhankelijkheid’: hoe langer je een pad volgt, des te lastiger kan het worden om er nog van af te wijken. Bijvoorbeeld omdat er al veel in is geïnvesteerd en het pad verlaten (te) veel moeite of geld kost. Kun je daardoor geen gebruik meer maken van beschikbare betere alternatieven dan is het duidelijk dat we in de lock-in fuik zijn beland.
Voorkomen is beter
Een lock-in is soms niet of nauwelijks te voorkomen. We kennen allemaal software die ooit prima functioneerde maar sluipenderwijs veranderde in ‘legacy’ waar niemand meer blij mee was, maar waarvan afscheid nemen bijna niet mogelijk was. Maar gelukkig zijn er wel manieren om lock-in’s zoveel mogelijk te voorkomen.
Een bekende manier daarvoor is om te kiezen voor gebruik van, bij voorkeur open, standaarden. Binnen de Nederlandse overheid speelt het Forum Standaardisatie hierin een belangrijke rol. Gebruik van benoemde open standaarden wordt daar verplicht gesteld voor overheidsorganisaties. Uitwisselen van gegevens wordt er mee vereenvoudigd en partijen worden minder afhankelijk van leveranciers. Bij gemeenten wordt al tientallen jaren gebruik gemaakt van het Standaard Uitwissel Formaat (StUF) om gegevensuitwisseling tussen verschillende leveranciers te vergemakkelijken. Iets dat, zo blijkt ook uit het uitgevoerde onderzoek, in praktijk geen garantie voor succes is, maar wel algemeen als nuttig wordt beschouwd.
Een andere manier om afhankelijkheid tegen te gaan is om meer gebruik te gaan maken van open source software. Daarbij is het idee dat oplossingen dan ook onderhouden kunnen worden door anderen dan eerste leverancier en er meer ruimte komt voor innovatie. Via overheidsprogramma’s als OSOSS (Open Standaarden en Open Source Software) en NOiV (Nederland Open in Verbinding) heeft de overheid hier een aantal jaren in geïnvesteerd. Te constateren is dat het gebruik van open source software slechts in een enkele gemeente, bijvoorbeeld de gemeente Ede, serieuze vormen heeft aangenomen. In welke mate daarmee de afhankelijkheid van leveranciers afneemt is overigens niet zo duidelijk, omdat slechts een handjevol gemeenten beschikt over eigen software-ontwikkelcapaciteit en dus voor eventuele aanpassingen van broncode aangewezen blijft op externe partijen.
Break-out
Ook als er volgens de definitie geen feitelijk duopolie of lock-in lijkt te zijn, kan het natuurlijk wel als zodanig door klanten worden ervaren. In dat geval is er de keuze om je in de bestaande afhankelijkheid te schikken en er het beste van te maken of om maatregelen te nemen om de afhankelijkheid te verminderen (‘break-out’).
Om uit een ervaren lock-in te ontsnappen zijn investeringen in tijd en geld nodig. Zowel techniek-gerelateerd (dataconversie, koppelingen) als organisatorisch (opleiding, gewenning). Om hoeveel het daarbij gaat hangt af van externe factoren (is er een alternatief en hoe lastig is het om over te stappen) en van interne factoren (hoeveel deskundigheid is er in huis?). In de praktijk vaak reden genoeg om nog eens goed te beoordelen of het gras bij de buren wel zo groen is als het lijkt.
Wil je echt van je leverancier af, maar is er geen beter alternatief beschikbaar, dan kun je besluiten om (mee) te werken aan een nieuwe, betere, oplossing. Binnen de gemeentewereld zijn daar een aantal, meer en minder geslaagde, voorbeelden van. Zo hebben 34 gemeenten jaren geleden via de coöperatieve vereniging Dimpact hun krachten gebundeld en proberen ze daarmee onder andere de afhankelijkheid van leveranciers te verminderen. De gemeenten Eindhoven, Woerden en Boxtel maakten onlangs bekend dat zij in coöperatie-vorm, samen met een ict-bedrijf, zelf software gaan ontwikkelen om niet langer afhankelijk te zijn van commerciële leveranciers. Ten slotte worden er steeds meer landelijke voorzieningen beschikbaar gesteld voor gebruik door overheidsorganisaties. waarmee wordt voorkomen dat iedere organisatie zelf daarvoor de markt op moet (bijvoorbeeld DigiD, eHerkenning, MijnOverheid).
Balanceren
Leverancier-afhankelijkheid zal er altijd zijn. Zelfs wanneer je als organisatie je eigen bedrijfs-software ontwikkelt, heb je te maken met software die door derden wordt ontwikkeld zoals systeemsoftware, middleware en ontwikkeltools.
Een goede middenweg vinden tussen effectief gebruik maken van wat de markt biedt en toch voldoende kunnen (bij)sturen blijkt niet eenvoudig te zijn (iets dat overigens niet alleen voor it geldt). Oplossingen in de sfeer van ‘ze moeten gewoon’ zijn binnen de context waarbinnen organisaties werken meestal te kort door de bocht. Zo kan de politiek-bestuurlijke context waarbinnen gemeenten werken er toe leiden dat een aanpak die bij een commercieel bedrijf goed werkt niet zomaar is te kopiëren.
Zoals hoogleraar informatica Hans Mulder naar aanleiding van de onderzoeksuitkomsten in een interview met Reporter Radio opmerkte lijkt het er op dat zowel gemeenten als leveranciers gevangen zijn in de bestaande verhoudingen. Daaruit ontsnappen blijkt, gelet op alle pogingen die al zijn gedaan, nu nog te lastig te zijn. Maar zeg nooit nooit. Zowel maatschappelijk als technologisch volgen veranderingen elkaar in steeds hoger tempo op en zullen er voor beide partijen de komende jaren nieuwe kansen komen. Of die gaan leiden tot fundamentele veranderingen zal de tijd leren.
Gerelateerde informatie
De Wikipedia-omschrijving van ‘vendor lock-in’ is afkomstig uit de dissertatie ‘Barrieres en doorwerking: Een onderzoek naar de invloed van het open source en open standaarden beleid op de Nederlandse aanbestedingspraktijk’ van Dr.Mr. Mathieu Paapst.
Reactie van Centric op het door NRC Handelsblad en Reporter Radio uitgevoerde onderzoek waarnaar hierboven wordt verwezen.
Antwoord van minister Plasterk op vragen over het monopolie van softwareleveranciers van gemeenten.
Ik heb op verschillende niveaus bij verschillende overheden hier dicht bij gestaan en me telkens weer met enige verbijstering verbaasd, woordspeling I know, over impotentie, incompetentie, knulligheid maar vooral, blindheid.
Twee zeer eenvoudige voorbeelden….
Bij de gemeente Amsterdam vroeg ik tijdens een meeting zeer eenvoudig aan de dienstenleverancier wanneer men iets dacht op te leveren zoals zij zelf hadden aangekondigd maar daartoe nog steeds niet in staat waren gebleken. De dame vertegenwoordigster vond die insteek ‘zeer onprettig’ en wenste daar niet op in te gaan. Zij deed haar beklag bij de programma manager, een oudere dame van de gemeente zelf, die mij op het matje riep en mij stelde ‘dat wij zo niet met elkaar om gaan….’ Ik heb haar eenvoudig gevraagd wat zij van de situatie vond dat een leverancier domweg eenvoudige afspraken niet na komt en de impact op het gehele traject….. Dit bleek volkomen onbespreekbaar. Ik heb meteen daarna de opdracht terug gegeven.
Uit verschillende publicaties is iedereen wel duidelijk waartoe dergelijke instelling bij de Gemeente Amsterdam heeft geleid.
Een tweede is het ongoing debacle bij VWS en het IT gebeuren rond verschillende projecten. In eerdere inventarisatieronden aan Ab Klink zijn verschillende IT project voorstellen in rapportage neergelegd die moesten leiden tot het versnellen en uniformeren van verschillende processen in de zorg en ontsluiting van patientendata.
Vanuit de perceptie dat dit het best kon worden bereikt met bestaande middelen en mogelijkheden heeft Ab Klink voor een voor hem zeer rendabele weg gekozen waardoor er niet alleen miljarden nodeloos zijn weggesijpeld maar inconsistenties ‘IT wijze’ en tegenstellingen hebben geleid tot enorme vertragingen en verspillingen. Saillant detail, ook Edith Schippers heeft dit gecontinueerd. Op de vraag aan de leveranciers van diverse systemen om broncodes te overhandigen aan de overheidsdiensten?? Daar moet heden ten dage nog steeds gehoor worden gegeven. Ietwat vreemd als u bedenkt dat vooral bij programmeer delen de opdrachtgever uiteindelijk ook eigenaar is van hetgeen word besteld.
De belastingbetaler is van deze drama’s dedupe en de verantwoordelijken kunnen niet eens op verregaande incompetentie en falen worden aangesproken.Leveranciers en hoofdrolspelers zijn de financiële winnaars.
Kan dit anders, moet dit anders? Vanuit perceptie van IT professionaliteit absoluut. De blamage van dergelijk situatie geld namelijk de commerciële IT partijen die weten hoe het mechanisme van ‘vendors lock’ werkt en daar ook op word ingezet.
Als wij zien dat het door Elias bedachte BIT feitelijk een toetsingsbureau had moeten zijn met kennis van IT programma. project en change en release modellen wat nu dus weer een ambtenarenclubje zal gaan worden, kan men vooruit zien dat overheidsprojecten grotere vertragingen zullen oplopen, niet af zullen zijn, per definitie, van dit probleem.
Er zijn geen investeringen noodzakelijk voor een breakout m.i. Men zal bij de aanbesteding aandacht moeten schenken dat de opdrachtgever te allen tijde een kopie van de productie zich moet toe-eigenen want die betaald daar tenslotte voor. Zo zal dat bij een eventuele ‘breakout’ dan ook de basis kunnen vormen van continueren.
Aansluitend heeft het mij altijd bevreemd dat partijen die aantoonbaar hebben gefaald gewoon weer bij een volgende tendering van de overheid aan tafel mogen aanschuiven. Ik daag hier graag elke IT professional uit die ditzelfde weet te bewerkstelligen bij de klant waar die haar/zijn laatste fuck up uitvoerde.
De overheid dient zich ervan te vergewissen, dat ook te laten zien, ter zake kundig te zijn en zich niet in de positie van een venderslock te laten manoeuvreren. Zij mag best wel proactief de belastingbetaler laten zien hoe zij waken voor belastinggeld.
Het zou de leverancier sieren veel actiever te zijn in het doen van prognose en opleveringsforecast en zich daar dan ook aan te houden en vooral zich niet langer meer te bedienen van de heilige graag ‘vendorslock’. Daarmee schaat je namelijk eigen aanzien, het aanzien van de IT professional die voor je werken en die je in dienst hebt en niet in de laatste plaats dat je oog hebt dat je werkt voor en met geld van de belastingbetaler.
Eat your hart out Ton Elias.
Just some thougts….
Tja, het is eenvoudig om te zeggen dat er 178 leveranciers binnen de software catalogus zijn, maar om functies van de 176 leveranciers te integreren bij de grote twee is onmogelijk dan wel met grote kosten te doen. De grote jongens houden hun systemen mooi dichtgespijkerd en (open) koppelingsmogelijkheden zijn zeer beperkt. Dat noem ik vendor locking, hou de deur dicht en voorkom koppeling van andere leveranciers. Helaas is het bij de (lokale)overheid zo dat er weinig mogelijkheden zijn om te innoveren, dit vereist n.l. investeren en daar is meestal geen geld voor, al de financiële middelen gaan op aan beheer dan wel investeren in vernieuwing bestaande systemen.
Intrigerend artikel van Ad Gerrits. Het plaatje is alleen wat incompleet. Er ìs sprake van een lock-in situatie, alleen speelt die zich zowel bij de opdrachtgevende overheden als bij de leveranciers af. Even een klein voorbeeldje: Die overheden hebben ooit massaal gekozen voor standaardisatie op Oracle databases. In de tijd dat ze dat deden, was dat, denk ik, de beste keuze, gezien in het licht van wat er toen op de markt was en wat dat kòn. Oh ja, er wàs wel meer, maar daar moest je dan heel veel meer geld voor neertellen om ook in een soort lock-in terecht te komen (bijvoorbeeld van IBM). In de loop der jaren zijn de licentiekosten voor Oracle echter steeds meer de pan uit gerezen, meegegroeid, zeg maar, met de jachten van Larry Ellison. Dat, gekoppeld aan overheidsbezuinigingen, maakt dat we nu niet meer zo onverdeeld blij zijn met die keuze. Maar ja, de leveranciers zitten ook in een lock-in, want die hebben zich met huid-en-haar overgeleverd aan allerlei slimme features en tools uit en rond dat Oracle DBMS en kunnen daar dus niet meer los van, tenzij ze al die tools en features gaan ‘over-coderen’ in hun eigen software; nou, dat wordt óók duur!!
Dit is maar één voorbeeldje van het vast-zitten. En natuurlijk: er zijn enkele goede voorbeelden van gemeenten die tijdig overstapten op iets anders, zoals de genoemde open-source voorbeelden. Opvallend is dat het vrijwel altijd òfwel grote gemeenten zijn met veel ICT’ers, òf gemeenten waar enkele zeer ge- en be-dreven ‘hobbyisten’ rondlopen met heel veel ‘kennis van verstand’. Veel kleinere gemeenten die het met minder ICT’ers of zonder de bijzondere soort ‘hobbyisten’ (let wel: beslist niet denigrerend bedoeld, want die mensen zijn hun gewicht in goud waard!) moeten stellen, kunnen aan dit spel niet meedoen.
De ‘lock-in’ situatie maakt aan de kant van de opdrachtgevers, dat ze de relatie goed willen houden, zoals het afhankelijke kind zijn ouders vaak wil ‘pleasen’ om niet de kans te lopen dat hij het zonder bed, bad en brood zou moeten stellen. De leveranciers komen de aangegane verplichtingen regelmatig niet na, en er is vrijwel geen overheidsorganisatie die dan zegt: “Nu zet ik alle betalingen stop, totdat dit is opgelost, want dit is klinkklare wanprestatie!”. En zo komen de leveranciers er gewoon mee weg, dus waarom zouden ze het beter gaan doen?! Fons van der Stee met zijn nasale stem zei ooit: “Wat nôdig is, is Lâf !” En inderdaad: het vraagt Lef om tegen je leverancier van wie je afhankelijk bent, te zeggen dattie kan fluiten naar zijn centen; maar ‘nôdig is het wâl’, anders komen we nooit uit deze lastige situaties.
Wordt ongetwijfeld vervolgd …
Ja natuurlijk Vendor Lock-in!
Zolang gemeenten nog kromliggen voor Oracle, terwijl de zakelijke markt massaal naar Open Source databases aan het migreren zijn; Vendor Lock-in
Zolang Oracle langskomt met Juristen i.p.v. verkopers: Vendor Lock-in!
Zolang Centric volhoudt dat haar software alleen op Oracle Enterprise draait: Vendor Lock-in.
De hele wereld draait inmiddels op Open Source software en de gemeente markt in NL ziet deze markt als alleen Open Office onderhouden door paardenstaarten op zolderkamertjes.
Denk aan: Facebook, Google en Android, Twitter, Linkedin,
Maar ook: Hosting van gaming industrie, het gros van alle webservers (feitelijk het gehele internet), het bouwen van films, alle Ubers enz van deze wereld.
Maar ook: uw mobiel, uw TV, uw auto (als het een beetje een recent model is) enz enz…
Elke software breakthrough company is momenteel gebouwd op Open Source software.
Open Source betekent dat gemeenten de keuze hebben om een softwareleverancier te zoeken voor dezelfde oplossingen. Voorbeeld: bevalt Red Hat niet? Dan kiest u voor CentOS of SUSE. De gehele omgeving mag gewoon blijven draaien. Ik kan voorbeelden blijven noemen.
Mensen: wake up! Start met veranderen. En dat niet met Word en Excel enz., maar met virtualisatiesoftware, databases, besturingssystemen, middleware enz.
Ik ben geschokkeerd door dergelijke artikelen die claimen dat Vendor Lock-in niet erg is, of “het kan toch niet anders”. Wat betaald u voor Oracle?
Keuze genoeg. Centric draait technisch gezien al lang op PostgreSQL. Sla met de vuist op tafel.
Ik las de reactie van Centric op het artikel in NRC Handelsblad
QUOTE:
In de afgelopen jaren hebben wij veel gemeenten een succesvolle overstap zien maken van andere leveranciers naar onze oplossingen.
Ergens bij Centric loopt iemand rond met een enorm gevoel voor humor.
@ReneCrevile: ik lees dat je veel ervaring binnen de overheid hebt. Merk dat de reacties ook met name daarover gaan. Maar ik denk dat een fenomeen als leverancierafhankelijkheid in alle bedrijfstakken van toepassing is. Verder terechte constatering aan het eind dat verbeteringen zowel bij de leverancier klant als bij de klant mogelijk zijn.
@dl het wat ik in het artikel zeg is dat er, gelet op de definities, zeker niet voor alle gemeenten sprake is van een vendor lock-in. Dat je zegt “Dat noem ik vendor locking” snap ik, maar laat ook zien dat door de verschillende invulling van het begrip het niet meer zo veel zegt wanneer het wordt gebruikt in een krantenkop.
@RobDeKrieger: je voorbeeld van Oracle illustreert goed hoe lastig het in praktijk is om pad-afhankelijkheid te voorkomen (waarbij je terecht signaleert dat er hierin grote onderlinge verschillen bij gemeenten zijn). Ben het ook helemaal met je eens dat er (niet alleen, maar wel noodzakelijk) een flink portie “Lâf” nodig is.
@CoenHamers Hoezo claim ik dat Vendor Lock-in niet erg is? Natuurlijk is vendor lock-in erg. Wat ik zeg is dat er altijd afhankelijkheid zal zijn en dat het lastig is om te voorkomen dat die te groot wordt. Gebruik van (meer) open source software kan daar uiteraard zeker bij helpen. Maar ik zie het zelf niet als de heilige graal waarmee alle afhankelijkheid verdwijnt. Zeker niet bij kleine organisaties die zelf weinig of geen IT-kennis in huis hebben.
@Pascal: voor de helderheid: ik heb geen enkel belang bij Centric. Maar ik kan uit eigen ervaring bevestigen dat overstappen naar een product van hen succesvol kan verlopen.
Een vendor lock-in kan zowel positief als negatief worden benaderd. Positief is de mate van bekendheid en structuur die vendor lock-in met zich meebrengt. De organisatie hoeft maar eenmalig kennis op te doen en vervolgens kunnen alle medewerkers met de software werken. Bij open source schuilt het gevaar dat de organisatie afhankelijk wordt van personen. Hierdoor kunnen applicaties niet uitgefaseerd worden. Als er zelf aan open source software wordt gewerkt, is eigenaarschap van deze oplossing een kracht, maar tegelijkertijd ook een risico voor de organisatie die gebruik maakt van de software. En dan praten we nog niet eens over organisaties die zelf software ontwikkelen. De lock-in ligt in deze gevallen namelijk niet bij de vendor, maar bij de personen die gebruikmaken van de technologie om deze applicaties te ontwikkelen. In veel gevallen beschikt alleen de persoon die de applicatie heeft ontwikkeld over de benodigde broncode en kennis. Hierdoor is een hele organisatie afhankelijk van één persoon, waardoor er in feite een eigen lock-in is gecreëerd. Organisaties moeten er daarom niet vanuit gaan dat open source dé oplossing is voor het voorkomen van een lock-in.
Het negatieve aspect van een lock-in is natuurlijk het risico dat een organisatie vastzit aan bepaalde software-keuzes die eerder zijn gemaakt, terwijl de organisatie later misschien liever een andere weg inslaat. De pad-afhankelijkheid, zoals dit in het artikel wordt genoemd.
Inzicht en kennis zijn het allerbelangrijkst. In het algemeen hebben gemeenten, net als andere organisaties, onvoldoende zicht op hun contractniveau als het gaat applicatieleveranciers. Door goed zicht te hebben op de huidige situatie kunnen organisaties het beste omgaan met een mogelijke vendor lock-in. Welke applicaties heb ik nodig, welke applicaties zijn daadwerkelijk in gebruik en zijn er meerdere van dit soort applicaties in mijn IT-landschap aanwezig? Door antwoord te hebben op deze vragen, heeft een organisatie genoeg kennis om een discussie aan te gaan met de vendor, op het moment dat de organisatie een andere weg in wil slaan. Vaak worden door verkeerd inzicht of gebrek hieraan, verkeerde beslissingen genomen. Inzicht geeft de organisatie de kans intern de discussie te voeren over pad-afhankelijkheid en op basis van het verkregen inzicht de risico’s te benoemen en zo mogelijk te beperken.
Als het een organisatie zelf niet lukt om duidelijk zicht te krijgen op hun softwaregebruik, is het verstandig om hier externe hulp voor in te schakelen.
Verschillende applicaties afnemen van 1 leverancier, die goed samenwerken, waarbij de onderlingen koppelingen goed functioneren en de interface hetzelfde is, lijkt me geen lock-in maar een bewuste keuze.
Dat er geen API’s zijn voor andere (externe) software is natuurlijk wel vervelend, maar vrij standaard in de software wereld (hoewel dat steeds beter wordt).
Wat wel als vervelend wordt ervaren is dat je geen keuze hebt in de onderliggende infrastructuur, zoals de gebruikte database. Want in tegenstelling tot wat Coen stelt levert Centric nog geen ondersteuning op PostgreSQL. Bij elk probleem zul je de applicatie dus moeten testen op Oracle en dat levert weer extra beheer op.
Het zou mooi zijn als de software database onafhankelijk wordt gemaakt, dan is er vrije keuze.
@ Ad Gerrits
Beste Ad, ik ken de situatie natuurlijk niet alleen van de overheden maar bij overheden speelt die doorgaans wel, het sterkst en stuitender, gewoon bij herhaling. Waar het mij om gaat is dat dat liedje zo voorspelbaar is dat het stuitend is dat het mogelijk blijft dat falende leveranciers gewoon weer mee mogen tenderen en als ze het idee hebben dat de klant hun procesje niet op orde hebben of volgen, als eerste bij de rechter staan.
Common sense, deemoed, het idee dat we het hier wel over miljarden aan gemeenschapsgeld hebben spelen dan klaarblijkelijk geen enkele rol meer.
@Jeen Opperdijk: Zoals ik schreef: technisch gezien draaien de applicaties van Centric op PostgreSQL. Echter, zoals u beaamt, Centric levert geen ondersteuning mits de applicatie van Centric draaien op een Oracle database. Prachtig voorbeeld van een “Centric/Oracle vendor lock-in” die daarmee een verkwisting van gemeenschapsgeld aan onnodige Oracle licenties veroorzaakt.
In mijn optiek is de door u genoemde “vrije keuze” het tegenovergestelde van het statement in dit artikel..
Een vendor lock-in voorkomen is niet alleen een ruime keuze tussen leveranciers (hoewel dat bij de lokale overheid ook valt te betwisten, gezien eerdere artikelen op deze site), maar de mogelijkheid te kunnen wisselen van leverancier zonder substantiële omschakelingskosten of ongemak. Door gebruik te maken van Open Source databases, OS, virtualisatie etc. is dit mogelijk.