Closed source software met customisation verkopen

[Keugels]

Beste forummers,

 

Wij zijn software aan het ontwikkelen die we B2B aan willen bieden. Nu komt er voor elke klant een groot deel aan customisation aan te pas. Ik zit in dubio hoe dit precies aan te willen bieden, en hoe dit door anderen gedaan wordt.

 

In principe is de basis software closed-source; dit is een basis systeem die voor elke klant gebruikt zal worden. Hieromheen komt een groot deel customisation voor de klant, waar door de klant voor betaald gaat worden; deze custom ontwikkeling zal voor de meeste klanten door blijven lopen; in de loop der tijd zullen er nieuwe klant-specifieke features aangevraagd worden.

 

Mijn vraag is nu. Wij bieden software aan, waarbij wij ons basissysteem gaan gebruiken. Hierop bouwen wij verder naar het eindproduct voor de klant. Wij zullen de software gaan hosten. Wij rekenen de klant ontwikkelingskosten en een hosting/license fee per maand/jaar.

 

Wat nu als de klant klaar met ons is? Wij hebben een systeem ontwikkeld op basis van onze eigen closed-source software. De klant heeft echter betaald voor een groot deel van de ontwikkeling van de software, gebouwd op ons systeem. Wij gaan uiteraard ons closed-source systeem niet vrijgeven. Met ons is de klant ook zijn/haar software kwijt (?).

 

Is de klant dan maar zijn/haar investering kwijt? Zit de klant voor eeuwig vast aan ons? Hoe werkt dit precies, wat is hier een goede weg in? Ik weet dat het meer gebeurt op deze manier, maar ik ben heel benieuwd hoe andere bedrijven dit afhandelen.

 

In de loop der tijd investeert de klant veel in nieuwe features. Wij rekenen voor extra features/onderhoud een x bedrag per uur. Is het verstandig een maximale jaarlijkse verhoging in percentages in het contract op te nemen? Als de klant 20 jaar klant is kunnen wij uiteraard tegen die tijd niet meer de uurprijs van 20 jaar geleden hanteren, maar de klant wil ook zekerheid dat, nu ze aan ons 'vastzitten', wij de prijzen niet ineens onredelijk hoog maken.

 

Iemand ervaringen met dit scenario? Hoe gaan andere bedrijven hiermee om?

 

[TwaBla]

 

Werken niet alle systeemhuizen op vergelijkbare basis, met meerjarige ontwikkel- of beheersovereenkomsten voor mixtures van standaard software en maatwerk?

[kuifje]

Ik krijg de indruk (maar weet het niet zeker) dat de closed source software jullie eigen software is (niet van een externe partij die de klant ook elders kan kopen)?

 

Dan zit de klant inderdaad aan jullie vast, in de zin dat hij heel veel dubbele kosten zal moeten maken om weg te gaan. Dat is dus goed voor jullie, maar als eerlijke ondernemer wil je daar natuurlijk geen misbruik van maken.

 

Je gaat als klant met een dergelijke leverancier ook pas een relatie aan als je er (terecht of onterecht) op vertrouwd dat die relatie lang goed zal blijven, en dat de leverancier niet inderdaad misbruik zal maken. Er zit dus ook wel een deel eigen verantwoordelijkheid bij de klant. Je hoeft je niet overdreven in te spannen de klant tegemoet te komen als blijkt dat hij zich vergist heeft en liever bij een ander zou zitten.

 

Kortom, ik denk eigenlijk dat je met je basisidee niet veel verkeerd kunt doen: een bepaald bedrag voor de basissoftware, en een eerlijk uurtarief voor de custom ontwikkeling.

 

En als de klant dan toch weg wil, kun je altijd nog case-by-case bepalen of je hem tegemoet wilt komen, bijvoorbeeld door de basissoftware voor een bepaald tarief toch beschikbaar te maken voor die klant of zijn nieuwe leverancier.

 

Maar aan de ander kant: maatwerk is nu eenmaal maatwerk, in iedere business, wie dat wil weet dat het maar eenmalig bruikbaar en heeft daar blijkbaar vrede mee.

 

[Ward van der Put]

Wat nu als de klant klaar met ons is? Wij hebben een systeem ontwikkeld op basis van onze eigen closed-source software. De klant heeft echter betaald voor een groot deel van de ontwikkeling van de software, gebouwd op ons systeem. Wij gaan uiteraard ons closed-source systeem niet vrijgeven. Met ons is de klant ook zijn/haar software kwijt (?).

 

Is de klant dan maar zijn/haar investering kwijt? Zit de klant voor eeuwig vast aan ons? Hoe werkt dit precies, wat is hier een goede weg in? Ik weet dat het meer gebeurt op deze manier, maar ik ben heel benieuwd hoe andere bedrijven dit afhandelen.

Dat is typisch een vendor lock-in en veel producenten van closed-source software streven doelgericht naar die klantenbinding middels gedwongen winkelnering en koppelverkoop.

 

Je zorg lijkt me terecht, want links en rechts om me heen zie ik dat bedrijven en ondernemers vendor lock-ins spuugzat zijn. Dat is een van de redenen waarom open-source software geliefd is. In bepaalde categorieën software ben je met closed-source code zelfs compleet kansloos.

 

Er zijn toch aardig wat compromissen te bedenken. Ik neem om te beginnen aan dat je de closed-source software niet per klant herschrijft, maar er maatwerk aan toevoegt. Dan kun je de software bijvoorbeeld deels encrypten of (pre)compilen, zodat je klant wel de leesbare code van zijn maatwerk ontvangt, maar de closed-source onderlaag onleesbaar is.

 

Als je je interfaces en API's op orde hebt, zou je het closed-source gedeelte ook kunnen aanbieden als webservices. Opnieuw kun je de klant dan gewoon zijn eigen maatwerk geven, maar beperk je het recht op het gebruik van het closed-source gedeelte tot een abonnement. Wordt het abonnement niet meer betaald, dan worden er geen services meer geleverd. Klaar.

 

Aangezien je software te hosten is, zou ik ten slotte eens kritisch kijken of alles wel zó uniek is dat het hoognodig beschermd moet worden. Waarschijnlijk wordt zo'n 80 procent al op vergelijkbare wijze gedaan in een of andere open-source vorm. En dan hoef je niet 100 procent closed-source te maken, maar slechts de 20 procent die echt uniek is en kun je klanten met de resterende 80 procent tegemoet komen.

[TwaBla]

Voor mijn begrip: zijn SAP of Microsoft Office of Salesforce niet ook closed-source?

[Ward van der Put]

Voor mijn begrip: zijn SAP of Microsoft Office of Salesforce niet ook closed-source?

Jazeker, alleen gaat de vergelijking niet helemaal op omdat alledrie out of the box te gebruiken zijn, terwijl het verdienmodel van de TS vooral steunt op het programmeren van uniek maatwerk per individuele klant. Daar lijkt de schoen 'm ook te wringen voor de TS: hij wil best wel het individuele maatwerk aan de opdrachtgever afstaan, maar niet het closed-source framework waarop het maatwerk draait. (Vergelijk het in lekentermen met een besturingssysteem en een applicatie: een Windows-programma werkt niet zonder Windows.)

 

[Branko Collin]

Als je je klant tegemoet wil komen, kun je aan de volgende dingen denken:

 

- Een escrowregeling voor je broncode. Ga jij failliet, kunnen je klanten alsnog bij de code. (Er is een complete bedrijfstak hierop ingericht, dus zat plekken waar je kunt uitvinden hoe dit precies in zijn werk gaat.)

 

- Zorg dat de data exporteerbaar is. Dat hoeft echt niet te betekenen dat je koppelingen gaat maken met de pakketten van concurrenten, als een vakmens maar in staat is die koppeling voor je eventuele ex-klant te maken.

 

Juridisch gezien zijn gegevens geen zaak, dus ook niet op te eisen. Des te prettiger is het dan als er een leverancier is die de data gewoon ter download aanbiedt.

 

- Zoals Ward al zegt, je kunt je product opsplitsen in een gehoste dienst, een API en een customisation service. Bij de gehoste dienst kun je ook API-sleutels verkopen, zodat je klant zijn aanpassingen eventueel via een ander bureau kan laten realiseren. Kost jullie omzet, maar het biedt je de kans het basisproduct te verbeteren. Dat jullie de basiscode uit je hoofd kennen en daarom de beste aanpassingen kunnen leveren, spreekt daarbij voor zich.

 

- Als je abonnementen gaat leveren, dan zitten daar vast voorwaarden bij. Niet ongebruikelijk is dat bij wanbetaling de service wordt stopgezet. Je zou daar een soort overgangsregeling bij kunnen doen dat bijvoorbeeld data nog enkele jaren gratis is op te vragen of dat de service read-only nog een maand doorloopt. Een klant die in zwaar weer terecht is gekomen en daardoor niet meer kan betalen, gaat echt niet gemakkelijker van betaling worden als je essentiële diensten afsluit.

 

Zoals Kuifje suggereert, is vertrouwen belangrijk in dit soort relaties. Liever dat je bij een klant een goed gevoel achterlaat.

[TwaBla]

Jazeker, alleen gaat de vergelijking niet helemaal op omdat alledrie out of the box te gebruiken zijn, terwijl het verdienmodel van de TS vooral steunt op het programmeren van uniek maatwerk per individuele klant.

Volgens mij wemelt het van de IT-bedrijven die een flinke boterham verdienen aan het op maat inpassen van SAP en Microsoft bij bedrijven en instellingen. Hoe noem je die: system integrators?

 

Niet om te beterweten hoor, maar ik vraag me gewoon af wat nou het verschil is. Misschien het ontbreken van die integrators, oftewel derden die ook maatwerk kunnen leveren met hetzelfde closed-source framework?

 

[LiGuido]

Wat jij doet is heel normaal in softwareland. Je bouwt een framework en vervolgens schrijf je maatwerk software om jouw klant zo goed mogelijk te helpen. Dat maatwerk wordt betaald door de klant. Voor het framework (de basis) wordt een licentie genomen waar per maand of per jaar voor betaald wordt. Eventueel bied je nog hosting aan. Iedereen werkt zo.

 

Hoe los je het nu op als jouw klant weg wilt? Dan geef je hem inderdaad niet de code, ook niet het maatwerk gedeelte omdat dat bijna onmogelijk is om te scheiden. Wat je hem wel geeft een een kopie van zijn data. Het liefst in CSV, zodat hij die data kan aanleveren aan zij nieuwe leverancier (net zo als dat jij natuurlijk oude data kan converteren naar jouw systeem).

 

Het feit dat hij investeert in maatwerk is wel waar. Maar hij hoeft maar een klein deel te investeren omdat jij al een framework hebt. Had je dat niet, dan moet hij veel meer geld investeren om een maatwerkpakket te krijgen.

 

 

[Keugels]

Vrij late reactie van mijn kant, HigherLevel zit niet echt in mijn dagelijkse patroon.

 

Bedankt voor alle duidelijke reacties. Het zit dus inderdaad zo als ik beschreef, al wist ik niet dat dit zo'n veelgebruikte vorm was.

 

Goede tips ook wat betreft de mogelijkheid van het exporteren van data, de escrow regeling en de suggesties voor een iets andere opzet.

 

Het is inderdaad het idee om een deel 'open' te houden, en een deel gesloten. Het open gedeelte zou dan ook door derden gerealiseerd kunnen worden. Het gesloten gedeelte zal gesloten blijven; hier zal ook een licensing systeem in zitten. Het maatwerk dat hier aan toegevoegd wordt zal niet zonder ons systeem kunnen werken, dus de vraag is nog even in hoeverre we dat koppelen. Mede door de tips in deze thread zit ik nu te denken in hoeverre het mogelijk is onze core aan te bieden met een API, waar derden tegenaan kunnen praten; dit heeft ook zijn voordelen. (Ik lees dit stukje net terug en zie dat het wat verwarrend is: Er is een deel dat sowieso voor het grootste deel open zal zijn voor derden; de core zal sowieso gesloten zijn, en er is nog een gedeelte maatwerk dat nauw samenwerkt met de core; of we dit met een API doen en het doen van dat maatwerk openstellen voor derden, of dit in eigen hand houden, dat is de issue die ik hierboven weergeef)