Aad Kamsteeg raakt de kern goed: “…open source is geen garantie voor het vermijden van een lock-in situatie, maar biedt wel de mogelijkheden daartoe…”. Doordat je *niet* de source code zelf aanpast maar gebruikt maakt van hook-ins, API’s, plugins (allemaal zaken die een goede open source architectuur levert en uitbreidbaarheid van het product faciliteren) en deze vervolgens goed documenteert bereik je wel degelijk leveranciers onafhankelijkheid. Want als je je aan deze technische spelregels houdt, dan kan iedere leverancier met kennis van ‘t basis pakket (in dit geval Drupal) binnen zeer korte tijd zich het maatwerk daarop eigen maken. Dat is de crux: 80-90% van de functionaliteit zit n.l. al in het basis pakket. Als dat n.l. niet zo zou zijn, dan is ‘t verkeerde basis pakket gekozen. De fout die vaak gemaakt wordt is inderdaad dat de open source code vervuild wordt met “quick hacks” die dan een vendor lock-in veroorzaken.

“Een paar maanden nodig hebben om ‘t maatwerk goed te kunnen onderhouden” is eigenlijk al een indicatie dat er iets niet klopt bij ‘t maatwerk. Ik wil hier bij wel opmerken dat de oorzaak hiervan zowel aan de opdrachtgeverskant kan liggen (bepaalde “features” niet moeten willen) alswel aan de developer’s kant (technisch “verkrachten” van het basis systeem noem ik dat).

Bij het goed toepassen van sterke software engineering principes kan bovenstaande voorkomen worden. Pas als we echt inhoudelijk gaan praten over wat goede software engineering (en design en architectuur) dat wel inhoudt wordt ‘t pas echt interessant. Ik zou zeggen, laat dat nou eens het onderwerp zijn van een volgende post (dan ga ik je laten zien dat de betreffende uitgever veel technischer is dan je wellicht zou veronderstellen;)

Helaas is het zo dat er nogal wat “snelle hacks” in de code zelf worden gedaan (en niet of slecht gedocumenteerd) die niet of nauwelijks zijn te traceren, laat staan te onderhouden door anderen.

Overigens: de term “vendor lock-in” is voortgekomen uit de situatie waar de informatie van een bedrijf in een niet uitwisselbaar (proprietary format) werd opgeslagen en onderhouden, zodat het feitelijk onmogelijk werd (wordt) om van software te wisselen zonder (veel) informatie te verliezen. Situatie met open source / closed source ligt net even anders.

Wat het voorkomen van lock-in voor informatie betreft is het zaak om voor die oplossingen / toepassingen te kiezen die de internationale open standaarden hanteren en ook het commitment hebben om die te blijven volgen. Veelal zijn dat (nog) voornamelijk de open source oplossingen.

De WC-Eend opmerking is grappig en een bekende beeldspraak, maar niet helemaal van toepassing. De klant vraagt hier ‘open source bleekwater’, en het liefst zou ik daar naadloos bij aansluiten. Vind je niet dat ik valse verwachtingen zou wekken als ik zou doen alsof ieder project zomaar zonder meer door iedere willekeurige andere partij in beheer te nemen zou zijn? Dat kan ik alleen maar beloven als er geen maatwerk nodig is?

Drupal is een typisch project dat niet backward compatible is. Ze bieden wel altijd een upgrade pad, de vraag is of al je modules dat ook doen (dat is wel het principiele uitgangspunt). Wat je daar ook van kunt vinden, Drupal is zonder meer een succesvol systeem.

Persoonlijk vind ik de afhankelijkheid van modules ontwikkeld door derden een van de grootste risico’s. Bij Drupal zijn duizenden modules, maar je moet zorgvuldig nagaan hoe ‘actief’ die module lijkt te zijn. (of er klaar voor zijn het onderhoud zelf over te nemen).

Ook begrijp ik niet goed waarom Open Source enkel Open is als het door meerdere partijen gebruikt wordt. Het belangrijkste aspect van open source lijkt me dat eenieder die het wil (en dus niet enkel de klanten) de code kan bekijken. Indien het hier om baanbrekend werk gaat van hoogstaande kwaliteit, zal verspreiding niet op zich laten wachten.

Natuurlijk moet ook de interne code beschermd worden, het is immers een investering van het bedrijf. Maar om ultiem van de “vendor lock in” af te geraken is er maar één stap voorwaards: open source ermee

Is die module zelf open source gemaakt? Biedt het interessante functionaliteit, dan is de kans groot dat anderen je meehelpen die module up-to-date te houden.

Heb je werkelijk totaal unieke functionaliteit nodig die nergens iemand anders ter wereld gebruikt… ja, wat zeur je dan over ‘afhankelijk van leveranciers’?

Ik zie niet in hoe in bovenstaande voorbeeld geen sprake is van ‘een mindere vendor lock in’ – in de open source variant is dat wel degelijk het geval.

De discussie zou heel wat zuiverder gevoerd kunnen worden met zeer concrete voorbeelden. Welke functionaliteit gaat het om en welk platform is gekozen? Was dit wel het juiste? Is gekeken naar open source alternatieven en alternatieve oplossingen om hetzelfde te bereiken?

Dit is een wc-eend praatje: wij van liones adviseren liones want liones biedt ‘specifieke functionaliteit’ die 100% door ons onderhouden moet worden, u bent 100% van ons afhankelijk, maar dat is toch onvermijdelijk…uhuh..