Open source software is gemeengoed geworden en lijkt geen angst meer aan te jagen bij gebruikers. Is dat terecht? In het algemeen geldt dat de software door leveranciers wordt geleverd zonder licentiekosten in rekening te brengen en is het gebruik van deze software gratis. Een belangrijke vraag die zich dan voordoet is: hoe zit het met businessmodel van deze gratis softwareleveranciers? Is gratis ook echt gratis en welke risico’s kleven hieraan?
Opensourcesoftware is gemeengoed geworden. Gartner voorspelt zelfs dat in 2015 in 85 procent van de commerciële softwarepakketten open source technologie zal worden opgenomen. Verder stelt het onderzoeks- en adviesbureau dat 95 procent van de reguliere it-organisaties dit jaar tenminste één element van opensourcesoftware zal benutten. Zelfs de Nederlandse Overheid stimuleert eigen overheidsorganisaties om gebruik te maken van vrije software. Opensourcesoftware lijkt dus geen angst meer aan te jagen bij gebruikers. Is dat terecht? Want hoewel de meeste it’ers van mening zullen zijn dat de werking van open source zich allang en breed heeft bewezen, kleven er ook nog steeds risico’s aan deze vorm van software. Vooral in relatie tot het eigen businessmodel en daarmee de continuïteit van de organisatie.
Gratis
Voor opensourcesoftware geldt in het algemeen dat de software door de leveranciers wordt geleverd zonder licentiekosten in rekening te brengen. Dat betekent dat het gebruik van deze software gratis is. Een belangrijke vraag die zich dan voordoet is: hoe zit het verdienmodel en daarmee het businessmodel van deze gratis softwareleveranciers in elkaar? Is gratis ook echt gratis?
Er kan een aantal standaard businessmodellen worden opgesteld met bijbehorende risico’s. Grofweg zijn er twee soorten risico’s te onderscheiden. Eén: risico’s die betrekking hebben op de continuïteit van de leverancier. Hoe groot is de kans dat deze leverancier over een jaar nog bestaat? En ten tweede risico’s op de uiteindelijke kosten. Als er niet betaald wordt voor software, maar wel voor dienstverlening, kan de rekening uiteindelijk tegenvallen als blijkt dat die dienstverlening toch echt nodig is om de software effectief te kunnen gebruiken.
Soorten businessmodellen
De meest voorkomende businessmodellen van opensourcesoftwareleveranciers, met bijbehorende risico’s, beschrijf ik hieronder.
Hobbyisten
Bij dit businessmodel zetten software-leveranciers hobbyisten in voor het ontwerpen en schrijven van de software. Dit is een risicovol model, omdat de medewerkers zelf veel investeren (tijd, hardware, werkplek) en hier weinig tot niets voor terugkrijgen. De kans dat medewerkers afhaken is groot. Zo kunnen zij na verloop van tijd een andere hobby kiezen of minder tijd krijgen voor de uitvoering van de software-opdracht. Juist het feit dat de afnemers niet betalen voor de gebruikte software, maar hiermee wel geld verdienen, kan voor de medewerkers ook een motivatie zijn om te stoppen met het vrijwilligerswerk. Daarnaast is het lastig de kwaliteit die de medewerkers afleveren te garanderen. Vaak zie je ook dat minder leuke activiteiten, zoals testen en het schrijven van documentatie, erbij inschieten. Als er geen beloning tegenover het werk staat, kunnen er moeilijk eisen aan de medewerkers worden gesteld en dus aan de uiteindelijke software.
Sponsors
Leveranciers die dit model gebruiken, krijgen hun inkomsten binnen door advertenties te plaatsen of e-mailadressen van klanten door te verkopen. Zolang dit helder is voor de afnemers, is dat een eerlijk model. Vaak kan een afnemer kiezen voor een betaalde licentie zonder advertenties of een gratis licentie met advertenties. Dit businessmodel is minder risicovol dan het hobbyisten-model, maar de duurzaamheid van de software is afhankelijk van de beschikbaarheid van voldoende adverteerders. Dat is wel een risico op langere termijn. Als adverteerders afhaken, kan het businessmodel in elkaar zakken en kan dit ten koste gaan van de continuïteit van de gratis softwareleverancier en dus ook het eigen verdienmodel.
Betalende en niet-betalende klanten
In dit model draaien de betalende klanten op voor alle kosten, dus ook de kosten van de niet-betalende klanten. In het algemeen zijn de betalende klanten (grote) bedrijven en de niet-betalende klanten consumenten of kleine bedrijven. Meestal krijgen betalende klanten meer functionaliteit dan niet-betalende klanten. Vaak dient het niet-betaalde product om klanten te binden en in een later stadium alsnog te laten kiezen voor het betaalde product. Dit model is stabieler en duurzamer dan de eerste twee modellen, zolang er voldoende betalende klanten zijn. Hoe minder betalende klanten, hoe duurder het product voor betalende klanten moet zijn om de kosten op te kunnen brengen.
Gratis software en betaalde dienstverlening
Net als bij het batalen-niet-betalen-model spelen ook in dit model betalende en niet-betalende klanten een rol. Het verschil is dat bij dit model alle klanten de software gratis krijgen en alleen betalen voor dienstverlening. Klanten die dienstverlening afnemen, betalen dus in feite ook voor de bouw van de software. Cruciaal in dit model is dat er voldoende klanten zijn die gebruik maken van de betaalde dienstverlening en dat de tarieven voor de dienstverlening concurrerend genoeg zijn. Dienstverlenende concurrenten die niet de kosten voor het bouwen van de software hebben, kunnen de dienstverlening waarschijnlijk altijd tegen een lagere prijs aanbieden. De dienstverlening van de bouwer van de software moet dus voldoende toegevoegde waarde hebben om een hogere prijs te rechtvaardigen. Het risico voor klanten zit ‘m in de mogelijkheid dat de prijzen voor de dienstverlening niet concurrerend genoeg zijn, waardoor de continuïteit van de leverancier in gevaar komt.
Risico’s inschatten
Dat er kosten worden gemaakt voor het bouwen van opensourcesoftware is onvermijdelijk. Belangrijke vraag is wie die kosten betaalt en hoe duurzaam die constructie is. Hoe groter de afhankelijkheid in het eigen businessmodel van de gratis opensourcesoftware, hoe belangrijker het is het businessmodel van de leverancier in kaart te brengen. In de praktijk komen natuurlijk allerlei combinaties van verschillende businessmodellen voor, wat het inschatten van de risico’s complex kan maken. Pas als al deze risico’s voldoende zijn achterhaald en adequaat zijn ingeschat, kan het eigen businessmodel op dit punt gefundeerd en duurzaam zijn.
Ewout, Jan heeft een punt over jouw aannames.
Het ging inderdaad niet om Joomla, maar over EllisLab Expression Engine. En veruit de meeste PHP frameworks en CMS-en kennen een vrij slechte kwaliteit van code. PHP is een flexibele taal met een zeer breed draagvlak wat als gevolg heeft dat er veel rommel geproduceerd wordt, en het erge is; in de basis werkt het. De Erlang community is een stuk kleiner en daar kom je veel minder rommel tegen domweg omdat Erlang het alleen doet als je weet wat je aan het doen bent.
Je ‘indiaantje-koekoek’ retoriek vind ik overigens heel slap en beledigend. Ook daarin laat je precies zien hoe jij over anderen denkt.
En “beschuldigen van onthechtingsverschijnselen?” Wat is dit nu weer voor een zinsnede? Ik doe hooguit waarnemingen, en bekentenis? Nee, ik communiceer gewoon transparant en open, ik zuig kennis op en deel mijn kennis. Want ik weet niet wat jij allemaal uit mijn reactie leest (Assuming.. again!) Maar mijn punt 1 waren acties van anderen waarmee ik te dealen kreeg. Wat dus los staat van jouw beheer en beheersbaar “mening”.
@Henri
Jouw voorbeeld 1 is niet realistisch, en je haalt ‘m zelf ook weer grotendeels omver. OpenOffice werd geforkt naar LibreOffice, maar de kans dat er een HenriOffice komt omdat jij iets anders wilt met tabellen lijkt me erg klein, vooral omdat je het onderhoud dan ook zelf moet doen.
Jouw voorbeeld 2 is een mooi voorbeeld hoe een community samen de kwaliteit van open source software borgt.
@Jan
Zelf aanpassingen maken in zeer specifieke open source software kan natuurlijk wel. Het blijft dan mogelijk open source, maar de veel geroemde voordelen dat iedereen de code reviewt en verbetert is dan natuurlijk weg.
@Jan
Een rapport vluchtig lezen en dan afdoen als dertien in een dozijn is precies waar je mij van beschuldigd, niet gehinderd door enige dossierkennis allerlei niet onderbouwde aannames doen. Betreffende het ‘indiaantje-koekoek’ wees ik trouwens op het kinderspelletje waar het om de onbeweeglijkheid gaat als we achterom kijken.
@Henri
Dat het gisteren .Net was en vandaag EllisLab Expression Engine gaat om inwisselbaarheid van code, kijkend naar bijbehorende ecosysteem (Azure?) bestaat een service uit wat meer onderdelen. Uiteraard kun je ook elke discussie doodslaan door de ander in een hoek te zetten, een reflex die ik vaak bij je zie als je begint over ‘serverknuffelaars’ wanneer het om beheerbaarheid van oplossingen gaat.
Hier is hoe ik er als koper naar kijk:
Bij alle software die je in huis haalt moet je kijken naar funktionaliteit, maatwerk, kosten, onderhoud en zekerheid. Zowel bij closed source als bij open source heb je jaarlijkse kosten en risiko’s voor de kontinuïteit.
Voor dat laatste is altijd de vraag: stel dat de leverancier/bron of de ondersteuning of het hele pakket wegvalt, wat dan? Als je daar geen antwoord op hebt moet je het simpelweg niet doen. Meestal is het redelijk eenvoudig: meestal wordt de boel gewoon overgenomen door een ander, of je kiest een andere toko die het onderhoud kan overnemen, en anders stap je over op een ander systeem. Je houdt er zowizo al rekening mee dat elk systeem een leefcyclus heeft dus op afzienbare termijn vervangen moet worden.
Het punt: ik zie daar geen verschil tussen closed source en open source. Op het niveau van de bedrijfsleiding speelt vooral de genoemde angst een rol, en dat die angst afneemt verruimt de keuzes en de mogelijkheden.
Ewout, het topic is open source. Het voorbeeld van Expression Engine is gewoon een voorbeeld, als het over wegzetten gaat ben je daar meester in.
Mijn mening of keuze van code of eco systeem is gewoon stabiel. Dat ik persoonlijk een .NETter ben geweest en dat we nu als onderneming daar niets meer mee doen (ik schrijf zelf ook geen code meer), dat verandert niets aan mijn opinies en meningen met betrekking tot cloud computing.
En ja, ik geloof niet meer in het knuffelen van hardware. In ieder geval niet in het perspectief van eind-gebruikende organisatie.
@Frank : Het was een voorbeeld, zo bouwen we ook eigen extensie op Django framework en wellicht open sourcen we die dadelijk.
Voor de .NET mensen hier.
Waarom zou ook Microsoft zich steeds meer met OSS bezig gaan houden?
Ze brengen zelfs hun eigen Linux distro uit?
@Henri
Sorry, Henri maar alles draait – zoals ik in 2012 al stelde in panelsessie – om de governance en van daaruit uiteindelijk de make or buy beslissing waarbij je dus gebruik kunt maken van open source. Misschien moeten we niet spreken van open source maar slim source, je hoeft tenslotte niet het hele framewerk te adopteren. Discussie ging om modulaire uitbreidingen die je niet nodig hebt, behoorlijk on-topic als ik kijk naar het artikel.
Hoef je hopelijk niet uit te leggen dat vervreemden van je CapEx nog niets veranderd aan je OpEx. Tenslotte is de cloud nog gewoon: Get them in, move them up and keep them there.
Om weer terug te komen op het oorspronkelijke artikel; ik sluit mij aan bij Jaap van Belkum. Je wekt de schijn dat open source het/een probleem is en gaat met het begrip business model enigszins eendimensionaal om. Voor de goede orde Microsoft is internationaal in haar houding tav open source verbeterd, maar misschien volgt Microsoft in Nederland een eigen koers?
Om na 15 jaar open source in Nederland dit te moeten lezen vind ik jammerlijk. Misschien nuttig om ontwikkelmodel, businessmodel, verdienmodel en de praktijk wat genuanceerder en daarmee duidelijker met elkaar in verband te brengen.
@Frank
Je punt is duidelijk al vraag je het in dit geval aan de verkeerde persoon, want inderdaad, als ervaren ontwikkelaar met actieve rol in de open source community, doe ik dit soort dingen. 🙂
Ik heb ook bij verschillende organisaties de software die ik zelf heb ontwikkeld bij Escrow moeten onderbrengen omdat sommige klanten dit eisten. Die zijn zelf ook niet in staat om dit aan te passen, maar er zullen zat bedrijven zijn die maar al te graag deze klanten zouden willen overnemen.