Verslag: Common Ground en businessmodellen

Op 6 juli vond de meetup Common Ground en businessmodellen plaats, in het kader van de Demodam Hackathon. Met een divers gezelschap aan leveranciers, een aantal ambtenaren en een promovendus op het gebied van platform ecosystemen vond een open gesprek plaats over de gevolgen van de transitie naar open source software. Het klassieke businessmodel waarbij leveranciers voorinvesteren in software en die investering terugverdienen via licenties, wordt onder Common Ground immers grotendeels vervangen door een ecosysteem aan leveranciers en overheden, waarbij elk hun eigen rol nog moeten vinden.

Boris van Hoytema, directeur van de Foundation for Public Code, gaf een korte introductie over open source samenwerkingsmodellen.

Hierna gingen twee subgroepen met elkaar in gesprek. Hieronder worden de hoofdpunten van die gesprekken weergegeven. Dit gespreksverslag is geschreven door een aantal deelnemers aan de sessie.

Groep 1

Open source vrijgeven van code kost niet per se extra tijd (door supportvragen en issues die worden ingeschoten); de uitdaging is eerder het betrokken krijgen van de community. Met een betrokken community kan je product sneller innoveren doordat andere partijen erop kunnen uitbreiden. Dat geeft een betere dienstverlening voor de klanten. Het goed kunnen samenwerken met andere partijen in het ecosysteem is daarbij belangrijk. De Demodam Hackathon helpt daarbij.
Hackathons zijn ook fijn omdat je problemen met integratie veel eerder tegenkomt. Dit werkt risico beperkend: die problemen was je anders toch wel tegengekomen, en het is vervelend als dat gebeurt nadat je je aan een tender gecommitteerd hebt. De lijnen worden korter tijdens de hackathon en dat werkt makkelijker samen.
De verschillende partijen in het gesprek hebben een verschillende positie ten opzichte van open source. Een van de aanwezige leveranciers zet deels in op open koppelingen. Niet alle applicaties worden gelijk al open source vrijgeven: dit gebeurt stapsgewijs.
Voor een andere leverancier was de leidende gedachte bij de overgang van een closed source licentiemodel naar open source software dat het open model duidelijk de toekomst lijkt te hebben. Dat was voor hen de reden om de code van hun oplossing vrij te geven. Ze hopen dat dit het voor anderen makkelijker maakt om door te innoveren op hun software. Nog een andere leverancier is vanaf het begin al op basis van een open source business model gaan werken.
Samenwerking met andere partijen is makkelijker mogelijk door open source, doordat je modulair functionaliteit kunt bouwen waarbij tegelijkertijd diverse leveranciers componenten bouwen.
Veel gemeenten zijn nog aan het zoeken, hoe werkt het dan met open source, hoe zit het met de dienstverlening eromheen? Een van de leveranciers is bezig met een community op te zetten omtrent doorontwikkeling. Het businessmodel wijzigt voor hen van licentie naar service, support en continuïteit. Het zou voor hen geen probleem zijn als andere partijen ook diezelfde dienstverlening zouden bieden op basis van hun code, maar ze hebben er veel vertrouwen in dat zij zelf de beste partij zijn om die support te bieden.
Voor het eerst vrijgeven van grote brokken zelf ontwikkelde code kan ook een risico opleveren, doordat mensen door de broncode te bestuderen ook kwetsbaarheden daarin kunnen ontdekken. Daarom is het verstandig code extra te laten doorlichten door externe partijen (pentests, audits, etc) op het moment dat je een grote closed source code base open maakt. Aan de andere kant ontstaan veiligheidsproblemen vaak voor een groot deel door achterlopende dependencies (ofwel code van anderen die wordt hergebruikt die niet geactualiseerd wordt) en niet door de eigen code.

Groep 2

De discussie over open source gaat vaak eigenlijk over hoe publieke partijen hun publieke taak goed kunnen vervullen, maar omdat hij gevoerd wordt in de context van het aanbesteden van individuele oplossingen valt hij vaak in het niet.
Doordat open source met IT wordt geassocieerd word het gesprek erover vaak door beleidsmakers en management genegeerd, terwijl de open samenwerking juist ook voor hen een essentieel element is. Open source heeft ook een maatschappelijke functie.
Business Model … van wie? Van commerciële partijen? Of over het ecosysteem?
Waardestromen van het platform ecosysteem in beeld brengen is wat anders dan het businessmodel. Dus helder houden vanuit welk perspectief over waarde wordt gesproken.
Bovendien scherp houden dat er in businessmodellen voor commerciële stakeholders binnen het ecosysteem ‘shareholder value’ een rol kan spelen, terwijl vanuit publiek perspectief ‘stakeholder value’ belangrijk is.
Open Source … of Open Collaboration? e-governance? Het beeld, wat al eerder geschetst is, is dat open source voornamelijk een IT feestje is. Echter is open source veel breder dan alleen de techniek. Open source werkt goed in communities wat iets zegt over hoe je samenwerkt maar ook hoe de budgetten/potjes worden beheerd. Overheidspartijen worden nu wel eens overvallen met ecosysteem dynamiek (oh hemel iemand heeft een pull request gedaan op onze software) en weten dan niet goed hoe ze daar mee om moeten gaan.
Wat is de grens tussen kant en klare software en open (source) software? Vaak zit het hem al in de uitvraag, men is opzoek naar een oplossing die ze opnieuw moeten uitvragen. Dan kijk je voornamelijk functioneel en worden de voordelen van open source als bijzaak beschouwd.
Is het duidelijk welke software rechtstreeks de publieke taak ondersteunt? Nee, dat is volstrekt onduidelijk.
De discussie wordt vaak vanuit IT gevoerd, maar government -> digitale government -> e-government -> e-governance! Dat is een totaal andere discussie / aanvliegroute, maar die wordt veel te weinig gevoerd.
Het wordt een hybride wereld: open en closed source software
Het lijkt een kip-ei probleem: Met andere uitvraag vanuit de overheid worden andere behoeften duidelijk en volgen er andere (commerciële) business modellen. Met andere business modellen worden andere uitvragen gedaan vanuit de overheid …
Uitvraag, visie, regie, kennis (vooral binnen overheid) ⇐⇒ (commerciële) business modellen
Collaboration model:

• tussen overheden
• met marktpartijen
• multi-party

Documentatie over compliancy aan BIO etc is belangrijk, fijn als dit ook bij de code aanwezig is.
Best practices ontbreken, bijv. over governance modellen.