Open source of open mind?
Eerder deze week twitterde ik, dat ik een vergadering had bijgewoond waarbij op een hele open manier de voor- en nadelen van een open source oplossing werden besproken. Ik kreeg op die post spontaan nogal wat reacties, blijkbaar leeft het onderwerp breder.
Het gesprek dat wij hadden begon als volgt: een uitgever waarvoor wij circa drie jaar geleden een maatwerksite hebben neergezet gaf aan dat gebruik van open source ‘beleid’ wordt bij komende projecten. Het belangrijkste argument is, zo zei men in alle openheid, een mindere afhankelijkheid van één leverancier. Een valide en begrijpelijk argument wat mij betreft, maar in de praktijk toch weerbarstiger dan op papier.
Proprietary software
Bij Liones gebruiken we open source voor ‘standaard’ sites (zoals Wordpress voor Publishr.nl). Daarnaast maken we voor de meeste maatwerksites gebruik van het Microsoft .NET platform, en dan meer precies de programmeertaal C#. Gedurende de vele projecten die we hebben uitgevoerd is er gestreefd naar optimale herbruikbaarheid van componenten zo is er een ‘bibliotheek’ van eigen, doorontwikkelde en geteste componenten ontstaan. Dankzij deze bibliotheek van componenten wordt ‘maatwerk’ steeds vaker ‘semi-maatwerk’ .
Deze bibliotheek noemen we het ‘Liones Platform’. Overigens hebben meerdere serieuze internetbureau’s in de loop der tijd een dergelijk eigen platform ontwikkeld, meer of minder volwassen. Er gelden geen licentiekosten voor het gebruik van het platform. Ook krijgt de klant desgewenst volledige toegang tot de broncode. In die zin is de ‘source open’ en zou iedere intelligente .NET programmeur onderhoud moeten kunnen uitvoeren op de applicaties.
Toch is dat meestal niet voldoende om aan ‘open source-beleid’ te voldoen. Het belangrijkste criterium is, zo geven klanten aan, is de vraag of meerdere partijen werken met het platform. Dat is bij het Liones Platform nauwelijks het geval, met andere woorden: het is ‘proprietary software’.
Open source en toch vendor-lock in
Beschikbaarheid van meerdere (een groot aantal) implementatiepartijen is dus een belangrijk argument voor een open source-beleid. CMS-en en portal-frameworks als Drupal, Joomla, Wordpress, Liferay en Typo3 kennen een groot aantal implementatiepartijen en passen daar dus binnen.
Het gesprek dat wij hadden ging erover of het toepassen van een ‘echt’ open source-systeem inderdaad leidt tot minder afhankelijkheid van een leverancier. Deze uitgever had een andere ervaring. In de afgelopen tijd is er, gebruik makende van een ‘echte’ open source pakket, een site gebouwd met nogal wat specifieke functionaliteit. Daarvoor was veel aanpassing en maatwerk bovenop de gekozen open-source oplossing nodig.
Juist doordat het open source pakket ‘standaard te weinig mogelijkheden biedt, waren deze maatwerk onderdelen nodig. Tegelijkertijd bleek, dat het installeren van een nieuwe versie van het open source framework onder de site, niet meer mogelijk was omdat daarmee de werking van de maatwerk aanpassingen ‘omviel’. De bouwer van deze site had aangegeven te verwachten dat een andere partij ‘minstens een paar maanden’ nodig zou hebben om het maatwerk goed te kunnen onderhouden. Met andere woorden, ondanks het gebruik van ‘open source’ ontstond maatwerk met exact dezelfde afhankelijkheid als het geval was geweest bij het gebruiken van ‘proprietary software’ .
Wat is een goede keuze?
De vraag aan ons was, welk platform wij zouden aanbevelen om een volgende site op te realiseren, dit met de wens van een minimale leveranciersafhankelijkheid in gedachten. Gezien het FO, voorzien wij zoveel maatwerk aan de site, dat de meeste open source CMS-en afvielen. Toepassing van online beschikbare portlets zou een onbeheersbare ‘kerstboom’ opleveren van modules. Tegelijkertijd levert het toepassen van een open source platform beperkingen op ten opzichte van ons eigen platform. Dus toch pleiten voor onze ‘proprietary’ oplossing, in weerwil van het genoemde open source-beleid?
Conclusie
Al doordenkend kom ik tot de conclusie dat ‘vendor lock-in’ bij specifieke functionaliteit vrijwel onvermijdelijk is. Dit baseren op open source is geen oplossing. De enige manier om dat te omzeilen, lijkt het afzien van specifieke functionaliteit. Mijn ervaring is echter ook, dat er maar weinig uitgaven (uitgevers) zijn die het gevoel hebben volledig uit de voeten te kunnen met standaardoplossingen.
Kortom: als een mindere ‘vendor lock in’ het doel is, is open source beleid geen oplossing, maar is een ‘alleen-maar-standaardoplossingen-beleid’ nodig. Met andere woorden, we zijn nog steeds op zoek naar de ultieme ‘blokkendoos’: http://www.publishr.nl/2009/01/de-blokkendoosbelofte/
Wellicht ook interessant!
Jan Benedictus is de oprichter en directeur van Liones. Sinds 1997 actief in uitgeefland.
Zie ook http://www.linkedin.com/JanBenedictus en http://www.twitter.com/JanBenedictus Bekijk meer berichten van Jan Benedictus
Dit is toch wel een heel bijzondere redenering op basis van heel vage voorbeelden. Goed gebruik bij Open Source is “don’t hack core”. Natuurlijk, als je dan een module maakt die alleen jij gebruikt, moet je hem zelf bij de tijd houden als je naar een volgend versienummer gaat.
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..
Een situatie zoals hierboven beschreven, waarbij de upgrade van een open source pakket het maatwerk incompatible maakt, lijkt me een ernstige design fout te zijn. Backwards compatibility zou door elke open source developer hoog in het vandel gedragen moeten worden, en meestal is dit ook wel het geval. Meestal is het dus de developer van de extra functionaliteit die uit de bocht gaat door zijn uitbreidingen op een verkeerde manier te schrijven.
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
De definitie van open source heeft te maken met de licentie, niets anders. Als iemand meerdere eisen wil stellen (meerdere partijen) lijkt me dat niet zoveel met open source van doen te hebben. Qua vendor lock in kan dat dan natuurlijk wel een zinnige aanvulling zijn…
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).
@mths Dank voor je reacties. Ik heb het gevoel dat onze ideeën meer overeenkomen dan je op het eerste gezicht zou denken. Je zin: “Natuurlijk, als je dan een module maakt die alleen jij gebruikt, moet je hem zelf bij de tijd houden als je naar een volgend versienummer gaat” raakt eigenlijk de kern van wat ik bedoel. Want de “jij” in dit verhaal is aan de ene kant de (niet technische) uitgever, aan de andere kant is er de andere “jij” (de developer / leverancier) nodig om ‘m bij de tijd te houden. De laatste zin van je tweede post zegt eigenlijk hetzelfde; je moet er klaar voor zijn zelf het onderhoud over te nemen, danwel kunnen beoordelen of de module actief onderhouden wordt. Drupal is zonder meer succesvol, maar het principiële uitgangspunt wat je noemt wordt niet altijd behaald.
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?
Gebruik maken van open source is geen garantie voor het vermijden van een lock-in situatie, maar biedt wel demogelijkheden daartoe. Punt is dat de partij die het maatwerk levert gehouden moet worden (door de opdrachtgever) om de spelregels voor open source te volgen. Voor het maatwerk deel moet de leverancier dus niet IN de code gaan aanpassen maar netje modules maken waarin de specials worden ondergebracht. Mocht het zo zijn dat de open source code (of API) niet de juiste hooks heeft om de speciale uitbreiding te kunnen maken, dan kan hij er voor kieze de hook in de source aan te brengen – en die aanpassing dan ook te doneren aan de open source community (incl documentatie etc.)
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.
Jan – allereerst vind ik ‘t top dat je dit post en er dus verder over na aan ‘t denken bent. Das mooi en dat waardeer ik. Eigenlijk ben je onbewust of bewust – dat weet ik niet – een van de principes aan ‘t toepassen waarom open source in veel (maar lang niet alle) gevallen superieure kwaliteit software levert: je deelt gedachten, kennis en twijfels met vele oprecht geinteresseerde mensen en daardoor wordt je beeld van ‘t ter zake doende onderwerp continue verbeterd, aangepast en genuanceerd.
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;)
Laat een reactie achter!
Business »
TenPages.com: boeken uitgeven via crowdfunding
Gisteravond werd ‘de revolutie in uitgeefland’ gelanceerd: TenPages.com. Iedereen kan hier de eerste tien pagina’s van zijn manuscript uploaden, waarna bezoekers kunnen beleggen in dit manuscript. Uiteindelijk zal het boek bij voldoende support worden uitgegeven …
Redactie »
Times Topics: hoe nieuwsdossiers een SEO-troef werden
Dossiers op nieuwspagina’s vervullen een belangrijke rol voor de vindbaarheid van online nieuwsbronnen. De New York Times heeft met TimesTopics in de afgelopen jaren een enorm netwerk van ‘hub pages’ opgebouwd. Hierover sprak Rand Fishkin (SEOmoz) onlangs met Marshall Simmonds, ‘Chief Search Strategist’ bij onder meer de New York Times Company.
Social media »
‘Het blaadje waar niemand om durfde te vragen is er toch gekomen’
Met een blanco cover en de tekst ‘Het blaadje waar niemand om durfde te vragen is er toch gekomen. Wij zetten de eerste stap. Wie maakt nummer 2?’ verscheen donderdag 18 februari de eerste editie …
Techniek »
Watervalmodel: Grafisch Ontwerp
Dit is het zesde artikel in een reeks over het tot stand komen van een maatwerk-website. Een introductie, de analysefase en ontwerpfase , en het functioneel ontwerp en het technisch ontwerp werden reeds eerder besproken. …
Trends »
De niet-gezochte-vondst
“Wow, interessant” is het gevoel dat ontstaat wanneer je onverwacht iets vindt waar je eigenlijk niet naar op zoek was. Of sterker nog, je was helemaal nergens naar op zoek maar loopt tegen iets leerzaams, leuks, interessants, of inspirerends aan.
Archief
Blogroll
Tag Cloud
Event Mashups
Willekeurige berichten
Laatste video
nieuwste berichten
Laatste reacties
Top 5 van de afgelopen week