Wij merken de laatste tijd een opleving van het onderwerp open source software bij overheden. Dat is ook wel logisch, aangezien het in lijn ligt met de gedachten die spelen rond Common Ground, waarbij overheden onder andere toegang willen blijven houden tot al hun data en eigenaar van hun eigen data willen blijven ook wanneer ze stoppen met een leverancier.
Software die daarnaast ook open source is, geeft je bovendien toegang tot de software zelf. Omdat er minimaal al 43 type open source licenties zijn, zien wij een alles dekkende definitie als onmogelijk en benoemen we liever wat wij bedoelen in dit artikel. Wat wij met open source bedoelen is alle software waarvan de broncode volledig online beschikbaar is om te bekijken en te downloaden en die (deels) gratis te gebruiken is. Het gaat hierbij dus niet om álle software die gratis te gebruiken is. Software die enkel gratis te gebruiken is, zonder dat je bij de broncode kunt komen, noemen we freeware (een samentrekking van free en software).
Als commerciële partij die nu al 12,5 jaar investeert in eigen SaaS-producten voor de gemeentelijke markt, vinden wij het interessant om uit te werken wat een mogelijk open source business model is. We doen dat aan de hand van een concrete casus: ons SaaS-product HIOR. HIOR is geen open source, maar in deze casus onderzoeken we welk business model daarvoor passend zou kunnen zijn.
Simon Onbelet
Developer
Aangemaakt op .
Wat willen we bereiken?
Nu we hebben vastgesteld wat wij met open source software bedoelen, stellen we een lijst op van wat we verwachten dat een overheidsorganisatie wil bereiken.
Ze willen software die ze hebben ingekocht blijven gebruiken, met of zonder de originele leverancier.
Ze willen (lokale versies van) de software kunnen aanpassen, zodat ze voor hun unieke use cases prototypes of productie-oplossingen kunnen maken.
Ze willen dat de investering die zij maken met geld van de maatschappij, de maatschappij ook ten goede komt. Software die gemaakt is voor een gemeente zou je gratis beschikbaar willen maken voor anderen.
Dit lijken ons de kernpunten van wat een overheidsorgaan wilt met open source. Wij als leveranciers van maatwerksoftware ontlenen ons huidige bestaansrecht ook aan het feit dat we de volgende wensen vervullen voor onze gemeentelijke klanten.
Een organisatie wil vaak niet de enige gebruiker zijn van de software. Met meer gebruikers kunnen zij de kosten van onderhoud en uitbreidingen delen. Ook ontstaat er met meer gebruikers onderlinge kennisuitwisseling en verbeteren werkprocessen daardoor.
Een organisatie wil de technische kennis van het ontwikkelen en onderhouden vaak niet in huis halen.
Een organisatie kan en wil zich vaak niet bezighouden met de omliggende zaken van software uitbaten: het vinden van nieuwe gebruikers, het doornemen en voldoen aan alle technische kaders, het technisch inrichten van de software, het hosten van de software online, het inwerken van gebruikers, het bijhouden van support, het schrijven van gebruikersdocumentatie, het aanleveren van jaarlijkse technische rapportages en het up-to-date houden van de software.
Een organisatie wil niet jaar op jaar een investeringsrisico lopen. Projectmatige gelden voor de bouw of uitbreiding van software worden zeker door overheidsorganisaties uitgegeven, maar het is juist niet de bedoeling dat je jaarlijks terugkerende projectgelden nodig hebt.
Overheden willen niet dat er issues of uitbreidingen worden gemaakt die niet in hun belang zijn. Bijvoorbeeld uitbreidingen aangevraagd door burgers of bedrijven die de software ook zijn gaan gebruiken.
Deze extra set aan wensen die wij nu als leverancier vervullen, verwachten we ook gehoor aan te moeten geven bij een open source model. Wanneer een ambtelijke organisatie zelf open source gaat werken zonder commerciële partij, zouden de twee lijstjes al redelijk afdoende zijn om succesvol open source te laten groeien. Als commerciële leverancier hebben wij echter nog wat aanvullende eisen die we zouden moeten inpassen in een open source model:
Ik heb er baat bij dat leveranciers elkaars open source pakketten gebruiken en verbeteren, zodat we met minder werk meer waarde kunnen leveren in onze producten.
Ik heb er baat bij dat open source werken mijn concurrentiepositie niet verslechtert. De kosten zijn namelijk inherent hoger: het onderhouden van een open source-community vraagt om communicatie en het zorgvuldig verwerken van bijdragen. Daarnaast is er het zakelijke risico dat derden de software vermarkten zonder daarvoor te betalen.
Ik wil dat er regie blijft over de wijzigingen die worden doorgevoerd op de broncode. Het risico dat we willen vermijden is dat verschillende leveranciers en ambtenaren wijzigingen doorvoeren en per abuis op andere plekken fouten of security issues introduceren.
Als leverancier heb ik voldoende financiële zekerheid nodig in ruil voor een lange termijn commitment om de software open source te blijven doorontwikkelen.
Leveranciers van software zijn inwisselbaar na elke aanbesteding. Het is daarom zaak dat wij onze open source software dusdanig goed laten aansluiten op bestaande processen dat opdrachtgevers ons als preferred supplier blijven aanmerken.
Als leverancier wil ik even veel of minder tijd kwijt zijn aan contractonderhandelingen in plaats van deeltijd bezig zijn met het verzamelen van gelden, of gelden moeten verzamelen om een bug of issue per keer op te lossen.
Wat je tussen de regels door leest in deze totale set aan eisen is dat open source commerciële voor en nadelen heeft waar we als leveranciers iets mee moeten. Dat komt omdat open source ten dele ook draait op developers die uit passie in hun eigen tijd en tempo de software onderhouden. Zij maken het gratis beschikbaar vanuit persoonlijke overtuigingen, in hun eigen tijd, naast hun werk of op basis van sponsors. Als commerciële organisatie kan je niet op basis van sponsors of op basis van de vrije tijd van onze medewerkers werken.
Op onderzoek uit
Met deze eisen in het achterhoofd gaan we op onderzoek naar hoe de open source oplossingen die wij gebruiken hun geld verdienen, om vervolgens te kijken naar wat een wenselijk business model voor HIOR zou kunnen zijn.
Software die gratis te gebruiken is en waarvan iedereen de broncode kan inzien, klinkt in eerste instantie als een heel slecht business model en iets wat vooral voorkomt bij ideologische bedrijven of stichtingen. Je investeert in een product om het daarna gratis weg te geven. Toch zijn er redenen waarom een bedrijf met winstoogmerk er ook voor kan kiezen om open source software uit te brengen.
Open source software heeft als een van de voordelen dat de broncode ook door de community kan worden onderhouden. Developers die een fout in het systeem opmerken of een idee hebben voor een nieuwe functionaliteit, kunnen voorstellen doen voor code-wijzigingen bij de eigenaar van de broncode. Wanneer die wijziging wordt geaccepteerd en aan de code wordt toegevoegd, hebben alle gebruikers van de software (na een update) daar baat bij. Hierdoor kan de doorontwikkeling van software in rap tempo doorgaan zonder extra kosten.
Een van de uitdagingen van open source software is de mogelijkheid om er geld aan te verdienen. Sterker nog, in de meeste gevallen blijft het aantal gebruikers dat overgaat van niet-betalende naar betalende klant onder de 1%. Het klinkt wellicht in eerste instantie wat vreemd om geld te verdienen met een gratis softwareproduct, maar er zijn voldoende wegen om alsnog een slaatje te slaan uit open source software.
Onderaan de streep zijn er vijf kernconcepten die wij hebben gevonden waarmee er aan open source geld verdiend wordt. Dit zijn:
Premium features
Support en consultancy
Aankoop van garanties
Advertenties (marketing)
Usage
Nu hoor ik je misschien denken: "en donaties en pay-what-you-want dan?!" Er zijn echter nog geen voorbeelden van open source software bedrijven die hiermee winstgevend zijn geworden. Op ieder van deze kernconcepten zullen we hieronder ingaan, zodat duidelijk wordt wat we ermee bedoelen. Wat wel goed is om vooraf te vermelden, is dat het ene verdienmodel het andere uiteraard niet uitsluit; een business model kan bestaan uit meerdere verdienmodellen binnen één softwareproduct.
Premium features
Een van de meest voor de hand liggende modellen is premium features. Hiermee bedoelen we alle functionaliteiten binnen software waarvoor wel betaald moet worden om ze te kunnen gebruiken. Een voorbeeld hiervan is GitLab. GitLab werkt met een model waarbij je de community-versie gratis kunt gebruiken, maar voor extra features de betaalde versie wilt benutten.
Een ander en wellicht meer aansprekend voorbeeld is een LinkedIn premium abonnement. LinkedIn is dan wel geen open source, maar dit model wordt uiteraard ook toegepast op betaalde SaaS-producten. Zodra je een premium abonnement aanschaft, krijg je ineens de mogelijkheid om veel meer functionaliteiten te gebruiken. Deze functionaliteiten bestaan al binnen het platform en zijn voor iedereen beschikbaar die betaalt. Desondanks is het platform ook prima bruikbaar zonder betaald abonnement.
Support en consultancy
Bij support en consultancy wordt bijvoorbeeld maatwerk ontwikkeld binnen bestaande software op aanvraag van een gebruiker. Dit maatwerk kan dan voor alleen de betalende klant of voor meerdere klanten beschikbaar worden gemaakt. Daarnaast kan het zijn dat de open source software veel configuratie-opties heeft, of dat er trainingen worden aangeboden om de software te leren gebruiken. Het kan immers zo zijn dat er bepaalde kennis nodig is om de software effectief in te zetten.
Een voorbeeld hiervan zijn bedrijven die servers inrichten voor andere bedrijven. De servers draaien bijvoorbeeld op Ubuntu, wat gratis beschikbaar is voor iedereen. Echter is er wel kennis van servers benodigd om Ubuntu te kunnen installeren en later te onderhouden. Dit soort bedrijven biedt vaak ook contracten aan voor het monitoren van de servers en het advies daaromheen.
Aankoop van garanties
Het business model rondom aankoop van garanties is een vrij breed model. Met garanties bedoelen we namelijk alle beloftes die een bedrijf doet over een softwareproduct in ruil voor geld. Denk hierbij aan uptime (de garantie dat de software bereikbaar is), veiligheid (de garantie dat je data en andere software op dezelfde server veilig is) of prestaties van de software.
Een voorbeeld van dit business model is Coolify: een open source softwarepakket dat gratis te gebruiken is wanneer je het op een eigen server installeert, maar waar ook een betaalde mogelijkheid is wanneer het via hun cloud-functionaliteit wordt gebruikt. Dit is in beide gevallen dezelfde software, maar de cloud-variant garandeert dat je altijd bij je software kunt en gratis support krijgt van beheerders.
Advertenties
Een andere optie is uiteraard adverteren of andere vormen van marketing. Door advertenties te tonen aan gebruikers van je software haal je niet alleen rechtstreeks inkomsten uit je gebruikers, maar ook uit derde partijen. Een variant hierop is het adverteren van je eigen, betaalde producten of diensten.
Een goed voorbeeld is het Belgische bedrijf Spatie. Zij leveren open source software, maar bieden daarnaast ook betaalde producten aan. Ze leveren kwalitatief goede open source software producten en adverteren aan hun gebruikers ook hun betaalde oplossingen. De betaalde producten zijn geen vervanging voor het open source product, maar bijvoorbeeld een aanvulling of staan er zelfs volledig los van.
Usage
Onder usage verstaan we het beperken van het gebruik van de applicatie. Dit kan op meerdere manieren: een manier hiervan is het totale gebruik beperken, een andere is het gebruik beperken voor een bepaald doel.
Een heel relevant voorbeeld hiervan is het aantal tokens binnen AI. De voornaamste functionaliteit, namelijk het gebruik van de chat, wordt achter een betaalmuur geplaatst. In veel gevallen is het mogelijk om de AI-chat eerst gratis te gebruiken, maar na het verstrijken van de tokens komt het product achter een betaalmuur.
Een voorbeeld waarin beperking wordt toegepast voor een bepaald doel is Terraform. Terraform gebruikt een Business Source License waarmee de software niet commercieel gebruikt mag worden, maar wel gratis is voor privégebruik.
Een tussenstap: source-available licenties
De kans is aanwezig dat je niet eerder hebt gehoord wat een Business Source License is. Omdat dit type licentie cruciaal is in onze afweging straks, leggen we kort uit wat het inhoudt en hoe het zich verhoudt tot een verwante variant die in het ecosysteem bekend is geworden: de Server Side Public License.
Klassieke open source licenties zoals MIT, Apache 2.0 of MPL leggen geen enkele beperking op aan commercieel gebruik. De klassieke open source software komt vaak ook niet vanuit commerciële bedrijven. Wanneer commerciële bedrijven deze software gebruiken, levert dat daarom verder geen conflict op. Deze vormen van licenties worden echter onhoudbaar wanneer je open source software aan wilt bieden met een commercieel doel. Een leverancier die jarenlang investeert in doorontwikkeling, ziet dan in één klap zijn investering door iemand anders te gelde gemaakt zonder bijdrage terug aan de community. Dit probleem heeft in de afgelopen jaren een aantal nieuwe licentievormen opgeleverd, vaak source-available genoemd in plaats van open source.
Business Source License (BSL)
De Business Source License is in 2013 ontwikkeld door MariaDB, een database provider, en sindsdien overgenomen door onder andere Couchbase, Cockroach Labs, Sentry en, in 2023, HashiCorp. HashiCorp besloot in augustus 2023 om Terraform, Vault, Nomad en andere producten over te zetten van de Mozilla Public License naar BSL, met als belangrijkste argument dat te veel concurrenten verdienden aan hun open source werk zonder eraan bij te dragen.
De BSL doet drie dingen die voor onze afweging interessant zijn. Ten eerste blijft de broncode openbaar: iedereen kan hem inzien, aanpassen en zelf draaien. Ten tweede mag de software niet worden uitgebaat op een manier die concurreert met de oorspronkelijke leverancier. Een ander bedrijf mag onze software dus niet als beheerde SaaS aanbieden aan gemeenten. Ten derde valt iedere versie na vier jaar automatisch terug op een van de eerder genoemde traditionele open source licenties. Daarmee blijf je niet eeuwig hangen in een grijs gebied; oude versies worden uiteindelijk echt open source.
De Open Source Initiative, de organisatie die officieel bepaalt wat een open source licentie mag heten, erkent de BSL niet als open source. Voor puristen is dat een streep door de rekening. Voor commerciële partijen die langdurig willen investeren in software voor de overheidsmarkt, is het juist wat een werkbaar verdienmodel mogelijk maakt.
Server Side Public License (SSPL)
De SSPL is in 2018 ontwikkeld door MongoDB, een database provider, als reactie op cloudproviders zoals AWS, die MongoDB als beheerde dienst aanboden zonder bij te dragen aan de community. Andere database- en infrastructuurbedrijven zoals Elastic en Redis Labs hebben in dezelfde periode soortgelijke stappen gezet door eigen restrictieve licenties in te voeren.
De SSPL is strenger dan de BSL: SSPL zegt: als je deze software aanbiedt als dienst aan derden, bijvoorbeeld een database-as-a-service, dan moet je álles wat je gebruikt om die dienst te leveren onder SSPL beschikbaar maken. Niet alleen de database zelf. Ook de orkestratielaag, de monitoring, de management-tools, de schalingssoftware, de backup-systemen, de load balancers, werkelijk alles in de stack dat wordt ingezet om de service te draaien. In de praktijk maakt dat commercieel hergebruik vrijwel onmogelijk. Voor MongoDB werkt dat uitstekend, want het beschermt hun cloud-omzet. Voor onze context is de SSPL waarschijnlijk een stap te ver: hij biedt sterkere bescherming, maar mist de automatische aanpassing van de licentie die de BSL juist aantrekkelijk maakt voor gemeenten met Common Ground-ambities.
De zesde, geheime optie: commoditize your complement
Er is een zesde optie die wij bewust niet in het rijtje hierboven hebben opgenomen, omdat hij eigenlijk niet in dezelfde categorie thuishoort. De vijf modellen die we tot nu toe hebben besproken zijn manieren om rechtstreeks geld te verdienen met open source software. Maar er is ook een strategische manier om open source in te zetten, niet als een product dat je verkoopt, maar als gereedschap dat je core business indirect versterkt. In de Engelstalige literatuur staat dit bekend als "commoditize your complement", een term die Joel Spolsky in 2002 introduceerde en die inmiddels het standaard-playbook is geworden van de grootste techbedrijven ter wereld.
Het idee is eenvoudig. Als je geld verdient aan één onderdeel van een waardeketen, is het slim om de aangrenzende onderdelen zo goedkoop mogelijk te maken: hoe goedkoper de complementaire delen, hoe meer vraag er ontstaat naar jouw deel. Google maakt Android, Chromium en Kubernetes open source niet uit altruïsme, maar omdat ze hun geld verdienen aan zoekadvertenties; hoe goedkoper de onderliggende techniek, hoe meer mensen gebruikmaken van Search. Meta geeft Llama gratis weg omdat ze advertenties verkopen op Facebook en Instagram, geen taalmodellen. Nvidia maakt AI-software open source omdat ze GPU's verkopen en willen dat zoveel mogelijk ontwikkelaars dingen bouwen die die GPU's nodig hebben.
Voor ons als softwareleverancier aan de gemeentelijke markt is de relevante vraag: wat is eigenlijk onze core business? De verleiding is om "de software" te antwoorden. Dat wij onze software zelf bouwen en onderhouden voelt als de meest logische verdediging van ons bestaansrecht. Onze echte meerwaarde is twaalf jaar aan relaties met gemeenten, kennis van het compliance-veld (BIO, AVG, Common Ground), de hosting- en beheer expertise, het support apparaat en de domeinkennis van hoe openbare ruimte, projecten, wijken en burgers op gemeentelijk niveau in elkaar grijpen. We leveren niet simpelweg regels code, dat kan ieder softwarebedrijf. Wij leveren meer dan dat.
Dat verandert de open source rekensom fundamenteel. Als onze software niet onze core business is maar een complement, dan is open source uitbrengen geen weggeven van het kroonjuweel, dan is het juist het goedkoper maken van de aangrenzende delen van de keten zodat meer waarde stroomt naar het deel waar wij sterk in zijn. Concreet zouden we bijvoorbeeld een kleiner product als Kijk op je Wijk volledig open source kunnen maken, als strategische showcase die de deur opent naar gesprekken over Projecten op Kaart en HIOR wat dan betaalde diensten blijven.
Een ander voorbeeld zou zijn het onderliggende datamodel van HIOR open source uitbrengen, zodat andere leveranciers compatibele producten kunnen bouwen en gemeenten daadwerkelijk kunnen wisselen van leverancier, wat de Common Ground-gedachte oprecht dient, terwijl wij hosting en beheer behouden.
De catch is dat deze strategie alleen werkt wanneer je core business daadwerkelijk verdedigbaar is. Als onze meerwaarde alleen de code was, zou open source uitbrengen zelfsabotage zijn. Het feit dat we deze optie überhaupt serieus kunnen overwegen, is op zichzelf al een nuttige diagnose: het vertelt ons dat onze waarde elders zit. En dat is op zichzelf interessant om te weten, ongeacht of we open source uiteindelijk strategisch inzetten of niet.
Maar wat moet ik nu kiezen?
Het echte antwoord is natuurlijk de eeuwige dooddoener: "dat ligt aan je situatie". En hoewel dat klopt, hebben we wel degelijk ideeën over welke situatie om welke aanpak vraagt. Want de situatie mag dan wel om een bepaald model vragen, er zijn factoren die het succes van een model kunnen beïnvloeden. Een eenvoudig voorbeeld is dat adverteren binnen software waarschijnlijk weinig oplevert wanneer de gebruikersgroep relatief klein is. Dat wil overigens niet zeggen dat een softwareproduct met weinig gebruikers altijd weinig oplevert.
HIOR is een digitaal handboek voor het beheer van richtlijnen binnen de openbare ruimte. Het aantal personen dat dit product daadwerkelijk gebruikt is relatief klein, en toch genereren we hier omzet mee die we liever niet kwijtraken. De reden dat deze kleine groep gebruikers bereid is om te betalen, is de impact die de software heeft op hun werkzaamheden.
De impact die het product maakt is een factor die te berekenen is wanneer je weet hoe lang het proces gemiddeld duurt zonder automatisering. Daarbij moet je ook rekening houden met de tijd die naast het proces nodig is om fouten op te lossen en processen te stroomlijnen. In het geval van HIOR lost het onder andere het probleem op dat aannemers werken met verouderde richtlijnen in hun bestek en dat richtlijnen niet getoetst worden.
Wanneer je weet hoeveel tijd jouw software bespaart, kun je gaan kijken naar functionaliteiten die misschien nog meer tijd besparen of nog meer fouten voorkomen of misschien zelfs processen mogelijk maken die er eerst niet waren. De gemiddelde tijdsbesparing van die feature (of set features) geeft je gelijk een idee van wat een realistisch bedrag is dat je kunt vragen voor het gebruik ervan. Bespaart je software slechts vijf uur per maand, dan is de kans van slagen lager wanneer de prijs gelijk staat aan vijf uur werken voor de gebruiker. De prijsstelling moet een duidelijke winst voor de gebruiker weerspiegelen. Daarbij kun je de afweging maken om features goedkoper aan te bieden wanneer de software meer gebruikers heeft, om zo het aantal gebruikers dat bereid is voor die features te betalen te vergroten.
Er zijn dus een hoop factoren die de keuze kunnen beïnvloeden. Als we deze allemaal zouden betrekken op HIOR, komen we tot de volgende conclusie.
Conclusie
Een open source business model kiezen voor de overheidsmarkt is geen kwestie van één model uit de zes prikken, maar van een passende combinatie samenstellen voor zowel het product als de leverancier. De succesvolle voorbeelden uit de markt laten zien dat winstgevende open source bijna altijd een hybride is. Dat geldt zeker voor de Nederlandse gemeentelijke markt, waar de Common Ground-gedachte wel openheid eist, maar waar gemeenten in de praktijk zelden zelf willen hosten, beheren of doorontwikkelen.
Voor HIOR, een SaaS-product voor een kleine maar hoogwaardige gebruikersgroep, is de combinatie van garanties (hosting, uptime, SLA) en premium features de meest logische. Het garanties-deel sluit aan op wat gemeenten daadwerkelijk willen inkopen: ontzorging op hosting, beheer en compliance. Het features-deel zorgt voor voorspelbare recurring omzet die de doorontwikkeling financiert. Advertenties vallen voor de B2G-context af; geen overheid wil reclame in haar softwareproduct. Support en consultancy zijn altijd een waardevolle bijverdienste, maar als hoofdmodel onvoldoende schaalbaar voor onze omvang.
De acht leveranciers eisen die wij eerder schetsen worden grotendeels opgelost door één licentiekeuze: een Business Source License (BSL), in de stijl die HashiCorp in 2023 koos voor Terraform en Vault, en die oorspronkelijk door MariaDB werd ontwikkeld. De BSL geeft gemeenten alle praktische vrijheden die ze nodig hebben; broncode inzien, zelf hosten, aanpassen voor eigen use cases, blijven hosten na het stoppen van een leverancier, maar voorkomt dat een andere commerciële partij onze investering simpelweg overneemt en doorverkoopt aan dezelfde gemeenten.
Bijkomend voordeel: na vier jaar valt elke versie van de software automatisch terug op een traditionele open source licentie, wat de Common Ground-gedachte op lange termijn alsnog dient. Het is in de strikte zin niet wat puristen "echt" open source noemen, de Open Source Initiative erkent BSL niet, maar het lost wel het tragedy-of-the-commons probleem op dat anders de doorontwikkeling smoort. Bedrijven als MongoDB en Elastic kozen overigens voor de strengere SSPL met soortgelijke motieven, maar die licentie heeft geen automatische terugval en is voor de overheidscontext mogelijk te restrictief.
Met betrekking tot de premium features binnen HIOR is de keuze welke functies betaald of gratis worden geen ethische maar een rekenkundige: meet de tijdsbesparing van een feature en spiegel daar een prijs aan die een duidelijke winst voor de gebruiker oplevert. Functionaliteiten met een hoge tijdsbesparing per gebruiker, zoals de projectenmodule bij HIOR, zouden achter de betaalmuur kunnen; functionaliteiten die de basis vormen blijven gratis beschikbaar, zoals het zoeken naar richtlijnen binnen een gebied. Op die manier komt onze investering met publiek geld ook daadwerkelijk de maatschappij ten goede, zonder dat we ons eigen bestaansrecht ondergraven.
Het aanbieden van premium features is een heel eenvoudig business model waar vaak voor gekozen wordt. Het is echter een model wat ook frustratie oplevert. Niemand wilt maar de helft van de functionaliteiten van een applicatie ter beschikking hebben. Dit maakt de werkelijke vraag nog prangender.
Als commerciële partij kunnen wij op aanvraag maatwerk ontwikkelen, een community bouwen rondom open source, support leveren, garanties bieden of betaalmuren opgooien om te blijven voldoen aan de Common Ground en geld te verdienen met open source. Maar waar wil de publieke sector nog voor betalen? Wat is de meerwaarde die wij als commercieel bedrijf moeten leveren? In plaats van het bedenken van een combinatie van verdienmodellen die wellicht bij ambtenaren op een manier op weerstand stuit, is het veel interessanter om de vraag om te draaien naar de ambtenaren toe.
Hoe gaan we de Common Ground belangen behartigen voor de publieke sector en de commerciële belangen van ons? Een van de uitdagingen die we nu al voorzien is een stuk waar het Common Ground te kort schiet. Als commerciële partij is het toegestaan om maatwerk te leveren aan gemeenten zolang alles open source beschikbaar blijft. Dat is heel interessant wanneer een gemeente daarvoor wilt betalen. Maar waar is de incentive voor een commerciële partij om de bijdragen van andere developers aan de code toe te voegen? Het beheren van open source software kost tijd en kan uit vele hoeken komen, dus wie gaat daar voor betalen? Dit vraagstuk onderzoeken we in een nader artikel.
De zesde optie, open source als strategisch wapen, laten we voor HIOR bewust links liggen. Dit is om meerdere redenen. Een van die redenen is dat er eerst bij gemeenten kritisch naar de huidige staat van de richtlijnen gekeken moet worden door Planterra, onze samenwerkingspartner. Zonder goede richtlijnen is het lastig HIOR te gebruiken. Dit kan het sentiment opleveren dat de applicatie niet goed zou functioneren terwijl het probleem enkel in de begeleiding zit. Ook is onze eigen investering in HIOR al vrij groot. Wanneer wij HIOR nu als open source aanbieden is dat nadelig voor onze concurrentiepositie waardoor het lastiger wordt om onze eigen investering terug te verdienen. We sluiten daarmee niet uit dat verschillende producten in onze portfolio uiteindelijk verschillende open source aanpakken krijgen.
Voor een andere applicatie betekent dit dat de stap naar open source geen sprong in het diepe hoeft te zijn, maar een gefaseerde aanpassing van wat we al doen. Het product kan migreren naar open source met BSL-licentie zonder dat het verdienmodel fundamenteel verandert. Wat verandert is de relatie met de markt: meer transparantie, meer mogelijkheid tot samenwerking met andere leveranciers en met de gemeenten zelf, en een geloofwaardiger verhaal richting overheden die om Common Ground vragen. Wat hetzelfde blijft: wij blijven verantwoordelijk voor de doorontwikkeling, het onderhoud en de hosting en blijven daar redelijk geld voor vragen.
Wij van Cell[0] willen graag open source gaan werken voor de gemeentelijke markt. We gaan graag met je in gesprek hoe we daar omheen ook een verdienmodel maken waarmee we een eerlijke boterham kunnen verdienen.
Wij horen graag van je!
Heb jij een fantastisch idee voor een applicatie, zoek je advies of heb je een opmerking? Diede en Bertus gaan graag met je in gesprek!
