Door karma4: Het eenvoudige antwoord om een lockin te vermijden is om naar de gewenste dienst te kijken en die zo lean agile mogelijk in te richten met voldoende maar niet overdreven ontkoppelpunten.
Eenvoudiger dan dat dat is het niet.
Dank je, dat is een neutrale houding tegenover de technologie. In München heeft men voor de werkstations vijf varianten vergeleken die van volledig propriëtair tot volledig open source liepen. Die kwamen er voor hun doeleinden redelijk gelijkwaardig uit, qua kosten was de geheel propriëtaire oplossing het gunstigst, maar qua lock-in was juist de open source-variant het gunstigst. Na het toepassen van wegingen won die laatste keuze.
Men maakte zich zorgen over de binding aan een enkele leverancier, wat precies is wat lock-in is, en koos voor de optie met voldoende ontkoppelpunten in dat opzicht. Los van de vraag of het goed of slecht is uitgepakt, waarover de meningen nogal ver uiteenlopen (en aangezien je niet in de toekomst kan kijken weet je nooit zeker of je keuzes geweldig uitpakken), vind ik zo'n selectieproces niet getuigen van open source-evangelisme. Jij lijkt overal waar open source is meteen evangelisten aan het werk te zien, en daarmee wek je de indruk dat er in jouw ogen alleen uit evangelisme voor open source gekozen kan worden en dat het niet de uitkomst kan zijn van een weging van hoe verschillende oplossingen op criteria scoren.
Ga je naar ICT dan hoor je dat er smart blockchain met een ERP pakket via Agile Scrum spring en open source software als standaarden gebruikt moeten worden.
Mag ik erop wijzen dat je in je eerst zin "zo lean
agile mogelijk" schreef? Je ontsnapt zelf ook niet helemaal aan de modewoorden. ;-)
Nu overdrijf is wat maar het mag helder zijn. Als je de technische speeltjes boven het te bereiken doel stelt krijg je een vendor dienstverlener techniek lockin en snel een faal.
Wil je lock-in vermijden dan heb je volgens mij het meest aan standaards. En dan niet zoals het zo vaak wordt gebruikt, "we standaardiseren op product X", maar standaards die door meerdere partijen worden ondersteund. Als je een documentformaat gebruikt dat door meerdere office-pakketten wordt ondersteund dan verminder je daarmee je afhankelijkheid van een specifiek pakket. Als je voor data-uitwisseling met anderen gestandaardiseerde, leverancieronafhankelijke berichtformaten gebruikt dan verminder je de afhankelijkheid van specifieke leveranciers.
Propriëtaire leveranciers hebben vaak als voordeel dat ze qua features toevoegen heel actief zijn en behoorlijk gelikt ogende produkten maken (al is dat ook vaak oppervlakkig en valt de praktijk nog wel eens tegen zodra je niet meer alleen met de oppervlakte te maken hebt), maar als nadeel dat ze er erg op gericht kunnen zijn om alleen lippendienst aan standaards en uitwisselingsmogelijkheden met software van anderen te bewijzen. In de de praktijk richten ze dingen vaak actief zo in dat je steeds meer van hun produkten nodig hebt om een vlot werkend geheel te hebben, de interoperabiliteit met alternatieve produkten valt vaak tegen. Dat maakt het volhouden van die ontkoppelpunten die je noemde moeilijk.
Ik heb bijvoorbeeld meegemaakt dat Sharepoint zogenaamde portlets ondersteunde volgens een daarvoor geldende standaard. Alleen kon je portlets van buiten Sharepoint wél in de Sharepoint-omgeving tonen maar was het onmogelijk om dingen die voor Sharepoint gemaakt werden in een portal-omgeving van een andere leverancier op te nemen. Dat betekent dat als je aan Sharepoint begon je als klant gedwongen werd om het als primaire systeem te gebruiken, en dat een migratie naar Sharepoint relatief makkelijk was maar een migratie ervandaan een ramp. Ik ben niet bij met mijn kennis hierover, maar in de tijd dat ik het constateerde was het maar één van de vele, vele voorbeelden van dit patroon, het dook overal op waar je wat beter keek.
Als je supplier lock-in wilt vermijden dan wil je dat soort situaties voor zijn. Vergelijk dat met ouderwetse e-mailsystemen, die volgens standaards als SMTP, POP3 en IMAP werken, op Unix-systemen. Bevalt de POP3-server je niet? Is een andere SMTP-server beter voor je? Begint de webinterface (die via IMAP de mail benadert) bejaard over te komen? Je kan gewoon een component eruit halen en er een alternatief voor in de plaats zetten. Natuurlijk is dat meer werk dan next-next-finish, maar het kan wel degelijk, want het is modulair van opzet en praat volgens vaste standaards met elkaar. De ontkoppelpunten zijn er omdat alle componenten die ondersteunen, ze passen als vervangbare onderdelen in het geheel.
Volgens mij is dat iets wat open source over het algemeen beter doet dan propriëtaire software.
Neem de meer volwassen vervoersmarkt. Een paar aanbieders voor vrachtwagens en ook maar een paar voor banden en toch is er kennelijk geen vendor lockin maar genoeg concurrentie. De vrachtwagendealer bemoeit zich niet met het vervoer en de vervoerder niet met het bouwen van vrachtwagens. Wat toezicht (overheid) dat iedereen zich aan de reels met bijbehorende gedragingen houdt. Natuurlijk niet geheel vlekkeloos maar een veel beter eindresultaat voor degenen die vervoer nodig hebben. Denk zelf eens na waarom dat verschil zo groot is.
Dat verschil is zo groot omdat de vervoersmarkt niet het soort trucs kan toepassen waarvan ik zojuist Sharepoint als voorbeeld gaf. Een laadruimte is een laadruimte. De vrachtwagen zelf zit vol afhankelijkheden van de leverancier, het is maar de vraag of de krukas van een concurrent erin past, maar die afhankelijkheid strekt zich niet uit tot de goederen die je ermee vervoert. Bij IT is de verwevenheid tussen de "vrachtwagen" en de "goederen" vaak veel groter. Standaardisatie van opslag- en uitwisselformaten is belangrijk om daarvan los te komen. De pest is dat commerciële leveranciers daar alleen een belang bij hebben als ze
niet in een (bijna-)monopoliepositie zitten maar standaardisatie een gunstige gezamenlijke strategie tegen de grote monopolist is. Als softwarebedrijven te machtig zijn zijn ze in staat om klanten hun platform in te zuigen.
In München hebben ze in ieder geval een poging gedaan om daaraan te ontsnappen. Petje af daarvoor. Ik denk dat open standaards het beste wapen hiertegen zijn, en dat de praktijk uitwijst dat open source-ontwikkelaars meer open staan voor het ondersteunen van standaards zonder valkuilen in te bouwen dan de grote commerciële ontwikkelaars.
Bij overheden speelt naast het universele belang van open standaards ook de controleerbaarheid van het bestuur een rol. Als je wilt kunnen controleren wat je overheid doet moet je ook kunnen zien wat hun software eigenlijk doet, want die voert een hoop van het werk uit. Openbaarheid van de broncode heeft dus een functie binnen de democratie. Ook dat is een argument voor open source in die context.