open source software business model oss - study and...
TRANSCRIPT
UNIVERSITEIT GENT
FACULTEIT ECONOMIE EN BEDRIJFSKUNDE
ACADEMIEJAAR 2009 – 2010
Open source software business model (OSS): study and analysis of commercial OSS
business model and innovation ecosystems
Masterproef voorgedragen tot het bekomen van de graad van
Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Sarah Govaert
onder leiding van
Prof. Dr. Ir. Frank Gielen
UNIVERSITEIT GENT
FACULTEIT ECONOMIE EN BEDRIJFSKUNDE
ACADEMIEJAAR 2009 – 2010
Open source software business model (OSS): study and analysis of commercial OSS
business model and innovation ecosystems
Masterproef voorgedragen tot het bekomen van de graad van
Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Sarah Govaert
onder leiding van
Prof. Dr. Ir. Frank Gielen
I
Permission Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of
gereproduceerd worden, mits bronvermelding.
Sarah Govaert
II
Voorwoord Hierbij wil ik van de gelegenheid gebruik maken om een aantal mensen te bedanken die het
mogelijk hebben gemaakt om dit eindwerk te verwezenlijken.
Ten eerste wil ik mijn promotor Professor Dr. Ir. Frank Gielen bedanken voor de hulp en
begeleiding tijdens het voorbije jaar.
Ik wil ook graag de mensen bedanken die bereid waren om tijd vrij te maken voor een interview:
Hermes De Backere, Carlos De Pelecijn, Steven Eggenstein en Tim Rentmeesters. Ook Joseph
Daman bedank ik om de gehele tekst na te lezen en te verbeteren.
Tot slot wil ik ook mijn ouders, mijn broer, mijn vriend en mijn vriendinnen bedanken voor hun
steun, liefde en vriendschap.
III
Inhoudsopgave
PERMISSION ............................................................................................................................................. I VOORWOORD .......................................................................................................................................... II INHOUDSOPGAVE ................................................................................................................................ III LIJST VAN GEBRUIKTE AFKORTINGEN ........................................................................................ V
LIJST VAN FIGUREN ............................................................................................................................ VI LIJST VAN TABELLEN ....................................................................................................................... VII INLEIDING ................................................................................................................................................. 1 1. STATE OF THE ART ANALYSE .................................................................................................... 3
1.1 Open Source Software .................................................................................................................. 3 1.1.1 Definitie ................................................................................................................................ 3 1.1.2 Geschiedenis ......................................................................................................................... 6 1.1.3 Licenties ................................................................................................................................ 7
1.2 ICT bedrijfsmodellen .................................................................................................................. 12 1.2.1 De Software Industrie ......................................................................................................... 13 1.2.2 De Software Waardeketen .................................................................................................. 15 1.2.3 Wat is een Bedrijfsmodel? .................................................................................................. 15 1.2.4 Software Bedrijfsmodel ...................................................................................................... 17 1.2.5 OSS in de Software Industrie .............................................................................................. 20
1.3 Open Source Software bedrijfsmodellen .................................................................................... 22 1.3.1 Open Source Software en Professionele Softwaregebruikers ............................................. 22 1.3.2 Open Source Software Bedrijfsmodellen ............................................................................ 23 1.3.3 Invloed van de Licentie ....................................................................................................... 28 1.3.4 Invloed van de Licentiestrategie ......................................................................................... 28 1.3.5 Invloed van de Ontwikkelingsstrategie ............................................................................... 29
2. PARTNERSHIPS: OPEN SOURCE EN NIET-OPEN SOURCE SOFTWAREBEDRIJVEN . 31 2.1 Economische Ecosystemen en Software Ecosystemen ............................................................... 31 2.2 Modellen van Coöperatie ............................................................................................................ 33 2.3 Software Partnerships ................................................................................................................. 37
2.3.1 Soorten Partnerships ........................................................................................................... 38 2.4 De Open Source Gemeenschap ................................................................................................... 40
3. ONDERZOEKSVRAAG EN METHODOLOGIE ........................................................................ 45 3.1 Onderzoeksvraag ......................................................................................................................... 45
IV
3.2 Methodologie .............................................................................................................................. 45 3.2.1 Selectie van de Cases .......................................................................................................... 46 3.2.2 Geldigheid en betrouwbaarheid .......................................................................................... 48 3.2.3 Zwakten en sterkten van de gebruikte methodologie .......................................................... 49
4. ONDERZOEK ................................................................................................................................... 53 4.1 Open Source Partnerprogramma’s .............................................................................................. 53 4.2 Open Source en Niet-open Source Partnerprogramma’s ............................................................ 65 4.3 Interview Resellers ...................................................................................................................... 74
4.3.1 JBoss Red Hat ..................................................................................................................... 75 4.3.2 Interview Xplore Group ...................................................................................................... 77 4.3.3 Interview Realdolmen ......................................................................................................... 82 4.3.4 Interview Capgemini ........................................................................................................... 88
4.4 Horizontale analyse ..................................................................................................................... 96 4.4.1 Klanten ................................................................................................................................ 96 4.4.2 Financiële Stromen en Partnerprogramma .......................................................................... 97 4.4.3 Keuze en Strategie .............................................................................................................. 98 4.4.4 Infrastructuur vs Middleware .............................................................................................. 99 4.4.5 SearchSystemsChannel.com ............................................................................................. 100
4.5 Interview Red Hat ..................................................................................................................... 102 4.5.1 Het Partnerlandschap ........................................................................................................ 102 4.5.2 Eindklanten en Partners .................................................................................................... 103 4.5.3 Financieel Model............................................................................................................... 105
5. ALGEMEEN BESLUIT ................................................................................................................. 109 LIJST VAN GERAADPLEEGDE WERKEN ..................................................................................... VII BIJLAGE 1: REFERENTIES PARTNERPROGRAMMA’S .......................................................... XIII BIJLAGE 2: PARTNERPROGRAMMA’S - VOORBEELDEN ...................................................... XIV
Alfresco: Europe, the Middle East and Africa SI Programme Benefits ............................................... XIV
Pentaho: Reseller Benefits .................................................................................................................... XV
BIJLAGE 3: ANALYSE PARTNERPROGRAMMA’S ................................................................. XVIII Tabel 1 .............................................................................................................................................. XVIII Tabel 2 ................................................................................................................................................ XXII Tabel 3 .............................................................................................................................................. XXVI
BIJLAGE 4: UITGETYPT INTERVIEW XPLORE GROUP ...................................................... XXIX
BIJLAGE 5: UITGETYPT INTERVIEW REALDOLMEN ....................................................... XLVII BIJLAGE 6: UITGETYPT INTERVIEW CAPGEMINI .................................................................. LXI BIJLAGE 7: UITGETYPT INTERVIEW RED HAT ................................................................... LXXX
V
Lijst van gebruikte afkortingen
BSD: Berkeley Software Distribution
GNU: GNU’s not Unix
GNU GPL: GNU General Public License
GNU LGPL: GNU Lesser General Public License
IT: Informatie Technologie
OSS: Open Source Software
OS: Open Source
RHEL: Red Hat Enterprise Linux
SECO: Software Ecosysteem
TCO: Total Cost of Ownership
VI
Lijst van Figuren Figuur 1: Licenties die worden gebruikt door open source gerelateerde bedrijven 9
Figuur 2: Software waardeketen 15
Figuur 3: Conceptueel model van coöperatie in internationale strategische distributiekanaal allianties 33
Figuur 4: Jboss.org vs Jboss.com 76
Figuur 5: Financieel model Red Hat 107
VII
Lijst van Tabellen Tabel 1: Negen bouwstenen van een bedrijfsmodel 17
Tabel 2: open source partnerprogramma’s - algemene voordelen 56
Tabel 3: open source partnerprogramma’s – opleidingsvoordelen 57
Tabel 4: open source partnerprogramma’s – verkoopsvoordelen 58
Tabel 5: open source partnerprogramma’s – marketing voordelen 59
Tabel 6: open source partnerprogramma’s – technische ondersteuning 60
Tabel 7: open source partnerprogramma’s – vereisten 61
Tabel 8: open source partnerprogramma’s – partnerniveaus en –vergoedingen 62
Tabel 9: SugarCRM vs. Salesforce.com – algemene voordelen 69
Tabel 10: SugarCRM vs. Salesforce.com – opleidingsvoordelen 70
Tabel 11: SugarCRM vs. Salesforce.com – verkoopsvoordelen 70
Tabel 12: SugarCRM vs. Salesforce.com – marketing voordelen 71
Tabel 13: SugarCRM vs. Salesforce.com – technische ondersteuning 72
Tabel 14: SugarCRM vs. Salesforce.com – vereisten 73
Tabel 15: SugarCRM vs. Salesforce.com – partnerniveaus en –vergoedingen 74
1
Inleiding Open source software (OSS) is ontstaan vanuit een kleine gemeenschap bestaande uit
computerfreaks en ideologen, maar is uitgegroeid tot een uitgebreide gemeenschap van
gebruikers waaronder bedrijven, overheden en particulieren. OSS is software waarvan de
broncode vrij te verkrijgen is en die steeds onder een bepaalde “Open Source”- of “Copyleft”
licentie wordt verspreid. OSS wordt ontwikkeld door een gemeenschap van programmeurs die
samenwerken op vrijwillige basis. Broncode van eigendomssoftware daarentegen wordt
beschermd door auteursrechten en verbiedt dat iemand anders dan de rechtmatige eigenaar de
broncode gebruikt, kopieert en distribueert. Terwijl de waardecreatie van de traditionele software
industrie voor het grootste gedeelte gebaseerd is op de eigendom van deze auteursrechten zijn ze
gratis bij OSS. Dit is de grote tegenstelling tussen OSS en traditionele software waarmee de IT-
industrie sinds eind jaren ‘90 wordt geconfronteerd. (Messerschmitt & Szyperski, 2005)
In de eerste plaats zijn er bedrijven ontstaan die zich enkel toespitsten op OSS. Het is voor deze
bedrijven niet mogelijk om zeer grote licentievergoedingen te vragen, aangezien zij niet over de
intellectuele eigendom beschikken van de software. Zij kunnen geen gebruik maken van
traditionele software bedrijfsmodellen en hebben andere manieren moeten zoeken om geld te
verdienen. Om een beter inzicht te verkrijgen in deze OSS bedrijven wordt in de eerste plaats
nagegaan wat de bedrijfsmodellen zijn die worden toegepast door OSS bedrijven.
In de literatuur is er geen of bijna geen onderzoek gedaan naar de logistieke component van een
bedrijfsmodel gebaseerd op OSS. Nochtans is het een belangrijk onderdeel van de strategie van
een bedrijf. (McNaughton, 1996) Het gebruik van resellers binnen de IT wereld is een algemeen
gebruikte praktijk en zal dus waarschijnlijk ook waarde hebben voor OSS bedrijven. (de Goede,
2010) In deze masterproef is het daarom de bedoeling om na te gaan wat de invloed en impact is
van OS op drie onderdelen van deze logistieke component: de partnerrelaties tussen reseller en
OSS bedrijf, de activiteiten van de reseller en het managen van het partnerkanaal door een OSS
bedrijf.
Om meer inzicht te krijgen in de partnerrelaties zal in een eerste stap een analyse worden
gemaakt van de partnerprogramma’s. Vele softwarebedrijven maken gebruik van een
partnerprogramma om de samenwerking tussen partners te organiseren. Een dergelijk
2
programma kan worden teruggevonden op de website van softwarebedrijven. Een
partnerprogramma geeft voor een gedeelte weer wat een reseller kan verwachten, zoals de
voordelen en de vereisten, wanneer hij overweegt om partner te worden. Op basis van deze
bestaande gegevens zal een analyse worden gemaakt van partnerprogramma’s van acht OS
producten. Daarna wordt op basis van deze analyse een vergelijking gemaakt met niet-OS
partnerprogramma’s.
Aangezien een klant een lagere vergoeding betaalt voor OSS zal de marge die een reseller krijgt
in absolute waarde kleiner zijn dan deze bij eigendomssoftware. Daarom is de vraag waarom
resellers OSS willen verkopen. Voor eindklanten is het ook niet altijd even duidelijk wat OSS
juist is. Om de impact van OSS op de reseller meer in detail na te gaan werden drie interviews
afgenomen bij resellers die actief zijn in België. Om een zo homogeen mogelijk beeld te
verkrijgen binnen deze drie interviews, gaat het telkens om dezelfde OSS, namelijk JBoss. JBoss
is een applicatieserver, dat is software die applicaties beheert. Het bedrijf dat hiervoor
professionele ondersteuning aanbiedt, Red Hat, is al meer dan tien jaar actief op de markt. Het
nadeel aan dit onderzoeksopzet is dat het niet meteen mogelijk zal zijn om de resultaten zonder
meer te veralgemenen voor alle OSS.
Om af te sluiten werd ook bij Red Hat Benelux een interview afgenomen om een beter inzicht te
krijgen hoe OSS bedrijven een partnerkanaal beheren en organiseren. Er zal ook worden
nagegaan wat de impact is op de organisatie van een partnerkanaal wanneer er wordt gewerkt
met OSS. Eén onderdeel dat meer specifiek zal worden onderzocht zijn de financiële stromen
tussen resellers en het OSS bedrijf zelf. Doordat het mogelijk was om dit interview bij Red Hat
af te nemen wordt de geldigheid van dit kwalitatief onderzoek versterkt.
Aangezien het gaat om een explorerend onderzoek in dit domein is het belangrijk om de focus te
leggen op een initieel inzicht in het thema. Daarom werd er voor gekozen om het onderzoek te
baseren op één soort OSS. Op basis van de resultaten van dit kwalitatief onderzoek kan verder
onderzoek worden gedaan dat meer van kwantitatieve aard is.
3
1. State of the Art analyse
1.1 Open Source Software
1.1.1 Definitie
Software bestaat uit een set van instructies die de activiteiten van de centrale besturingseenheid
van een computer sturen. Deze instructies kunnen worden voorgesteld als broncode of
machinetaal. Broncode is het geheel van programma instructies in hun oorspronkelijke hogere
taal, zoals geschreven door de programmeur. In de informatietechnologie wordt informatie in de
meest eenvoudige vorm opgeslagen als binaire eenheden. De binaire vorm is enkel verstaanbaar
voor een machine of computer terwijl de broncode ook verstaanbaar is voor een iemand die de
programmeertaal begrijpt waarin de broncode is geschreven. Het voordeel de broncode ter
beschikking te hebben is de mogelijkheid om de broncode te veranderen, eventueel fouten of
“bugs” te vinden en te herstellen. (Messerschmitt & Szyperski, 2005)
Afhankelijk van de software licentie en distributie die wordt gebruikt kunnen een aantal soorten
software worden geïdentificeerd. (Ghosh, Glott, Krieger, & Robles, 2002)
• Eigendomssoftware: De distributie van deze software gebeurt in binaire vorm. Dat
betekent dat de softwaregebruiker niet de mogelijkheid heeft om de software te
veranderen of fouten op te sporen en te herstellen. (Ghosh, Glott, Krieger, & Robles,
2002) (Messerschmitt & Szyperski, 2005)
• Shareware: Voor een initiële periode is shareware gratis, maar na een testperiode moet
een licentievergoeding worden betaald. (Ghosh, Glott, Krieger, & Robles, 2002)
• Freeware: Voor deze software moet geen licentievergoeding worden betaald, maar voor
een complementair product moet wel worden betaald. (Ghosh, Glott, Krieger, & Robles,
2002)
• Open Source Software: De broncode van deze software is beschikbaar voor iedereen.
(Ghosh, Glott, Krieger, & Robles, 2002)
Deze masterproef behandelt deze laatste categorie, namelijk OSS. Lange tijd heeft de
eigendomssoftware in de IT industrie de belangrijkste rol gespeeld, maar met de komst van OSS
4
is dat aan het veranderen. Eigendomssoftware moet meer en meer marktaandeel afstaan aan
OSS.
Een belangrijk verschil tussen OSS en eigendomssoftware is de licentie die wordt gebruikt om de
intellectuele eigendomsrechten te beschermen. Bij eigendomssoftware is het bedrijf eigenaar van
de software en is in het bezit van de intellectuele eigendommen. Op die manier wordt verhinderd
dat concurrenten, of anderen, de software kunnen kopiëren en doorverkopen. Door bij OSS
gebruik te maken van een soort “copyleft” licentie wil men er juist voor zorgen dat iedereen de
software kan gebruiken. OSS wordt ontwikkeld binnen een bepaalde gemeenschap van
programmeurs. (Ghosh, Glott, Krieger, & Robles, 2002) (Lerner & Tirole, 2001)
Er kunnen een aantal voor- en nadelen worden opgesomd die van toepassing zijn voor OSS in
vergelijking met eigendomssoftware.
Algemene nadelen
• Bij het vrijgeven van broncode bestaat het gevaar dat er varianten ontstaan van de
software. Wanneer er discussie ontstaat tussen programmeurs kan er fragmentatie van de
code plaatsvinden. (Schilling, 2008) (Lerner & Tirole, 2001) (Hecker, 1999)
• Doordat de software wordt ontwikkeld door gebruikers ervan, wordt er software
ontwikkeld dat gericht is op ervaren gebruikers. Er wordt dan ook weinig aandacht
besteed aan het gebruiksvriendelijk maken van de software. Dit creëert tegelijk een
mogelijkheid voor bedrijven om de software gebruiksvriendelijk te maken en te voorzien
van handleidingen e.d. en dus geld te verdienen. (Feller, Fitzgerald, Hissam, & Lakhani,
2005)
• Een bedrijf dat zijn code vrijgeeft, maakt het niet alleen toegankelijk voor programmeurs,
maar ook voor andere bedrijven. Een concurrent kan winst genereren zonder te investeren
in de ontwikkeling. (Hecker, 1999)
Algemene Voordelen
• De kwaliteit van de software is één van de belangrijkste argumenten in het voordeel van
OSS. Een frequent gequoteerde stelling is de Wet van Linus “ given enough eyeballs, all
bugs are shallow ”(Raymond, 1999a, p. 29) dat kan worden gevonden in het essay “The
5
Cathedral and the Bazaar” van Eric S. Raymond. Dit wil zeggen dat door broncode vrij
verkrijgbaar te maken het mogelijk wordt om sneller en efficiënter ‘bugs’ of fouten in de
broncode te vinden en te herstellen. Deze methode van ontwikkeling zou software ook
meer betrouwbaar, robuust, veilig en bestand tegen tegenslagen maken. (Raymond,
1999a) (Feller, Fitzgerald, Hissam, & Lakhani, 2005)
• OSS kan worden beschouwd als “user-driven” innovatie. Gebruikers van software zijn
vaak degenen die actief zijn in de OS gemeenschap. Wanneer eigendomssoftware wordt
gemaakt moet er steeds een gedetailleerde analyse worden gemaakt van de
functionaliteiten die nodig zijn. Daarom moeten alle mogelijke gebruikers in rekening
worden genomen en dat is vaak een grote uitdaging voor softwarebedrijven. Bij OSS zijn
het de gebruikers die de software ontwikkelen en zou er dus een betere afstelling zijn
tussen de benodigde functionaliteiten en de effectieve functionaliteiten. (Lerner & Tirole,
2001) (Messerschmitt & Szyperski, 2005)
• De “Total Cost of Ownership” is een belangrijk punt voor managers bij de aankoop van
software en is lager bij OSS. Het bepalen van de TCO is geen eenvoudige taak omdat
vele factoren meespelen. Voor de meeste software, ook OSS, is er steeds nood aan
ondersteuning, opleiding, installatie,... maar de initiële kost voor OSS is zeker en vast
lager dan bij eigendomssoftware. Voor vele gebruikers is dit zeker een aantrekkelijk punt.
(Van Aardt, 2006)
• De flexibiliteit voor de gebruiker en het vermijden van “vendor lock-in” is ook een vaak
aangehaald voordeel. Bij OSS ben je niet gebonden aan één bepaald softwarebedrijf. Er is
ook de mogelijkheid om verschillende software te combineren met elkaar. Doordat de
broncode voor iedereen ter beschikking staat. (Feller, Fitzgerald, Hissam, & Lakhani,
2005)
• Bedrijven bevinden zich in een veeleisende omgeving. Dankzij OSS kunnen kleine
bedrijven die vaak niet dezelfde R&D mogelijkheden hebben dan grote bedrijven, ook op
basis van een kwalitatief software product een inkomstenstroom creëren. Met behulp van
de OS gemeenschap kunnen zij namelijk software snel op de markt brengen tegen lagere
kosten. (Lerner & Tirole, 2001) (Hecker, 1999)
6
1.1.2 Geschiedenis
Het is nuttig om de geschiedenis van OSS te bespreken om twee redenen. Het geeft enerzijds een
inzicht in de mensen die zich met deze materie bezig houden. Binnen de IT wereld kan de OSS
beweging immers beschouwd worden als een groep mensen die initieel een bepaalde ideologie in
gedachte hebben. Maar dit is allemaal geëvolueerd van een eerder anticommercieel
gedachtegoed naar een fenomeen dat ook uitgebreid wordt gebruikt in de commerciële wereld.
(Fitzgerald, 2006) Anderzijds is het belangrijk om dit in de context te plaatsen van bedrijven die
commerciële OSS willen kopen om in een bedrijfsomgeving te gebruiken.
Men kan drie perioden onderscheiden in de geschiedenis van het ontstaan van OSS.
Samenwerking tussen programmeurs bij de ontwikkeling van software kan namelijk worden
teruggevonden van in de vroege jaren 60’. (Lerner & Tirole, 2001)
Periode 1: 1960 – 1980
In deze periode werd voornamelijk hardware verkocht en was software nog niet belangrijk.
Programmeurs van verschillende organisaties deelden dan ook hun broncode met elkaar.
Belangrijke besturingssystemen en het internet zijn ontwikkeld in een academische omgeving. In
de jaren 70 heeft men zich gefocust op het ontwikkelen van een besturingssysteem dat kon
functioneren op meerdere computer platformen. Een belangrijk voorbeeld hiervan is Unix, dat
ontwikkeld werd door AT&T Bell Laboratories. Er werden toen nog geen stappen ondernomen
om enigszins eigendomsrechten te eisen of hergebruik van code te beperken. (Lerner & Tirole,
2001) (Ghosh, Glott, Krieger, & Robles, 2002)
Periode 2: 1980 -1990
Een belangrijke gebeurtenis voor de coöperatieve software ontwikkeling was de verandering in
AT&T’s beleid betreffende de eigendomsrechten van Unix. Gebruikers van Unix moesten nu
betalen voor het gebruik van het besturingssysteem. De code was dan ook niet meer vrij te
verkrijgen. Een tegenreactie hierop kwam van de programmeur Richard Stallman die een
alternatief voor Unix ontwikkelde: GNU. GNU staat voor “GNU’s Not Unix”. Dit was dus een
soort van anticommerciële actie tegen het commercialiseren van software. Programmeurs die
deze ideologie hebben worden dan ook vaak tot de hackercultuur gerekend. Daarnaast
ontwikkelde Stallman de eerste licentie die een belangrijke rol zou spelen in de verdere
7
ontwikkeling van de gehele OS gemeenschap. De “GNU General Public License” was de eerste
belichaming van het principe van de ‘copyleft’. Kopieën van een programma dat de GNU GPL
als licentie heeft moeten, ook wanneer de code gedeeltelijk werd veranderd, opnieuw aan de
GNU GPL licentie voldoen. Dit wordt vaak aangeduid met het ‘virale effect’ en heeft een
belangrijke implicatie voor het commerciële gebruik van de code. Een bedrijf dat broncode,
onderworpen aan de GNU GPL uitbreidt met nieuwe code, is dan ook verplicht deze vrij te
geven. (Lerner & Tirole, 2001) (Ghosh, Glott, Krieger, & Robles, 2002)
Periode 3: na 1990
Door het ontstaan van het internet werd de samenwerking tussen programmeurs op grote schaal
mogelijk. Samen met de toename in bijdragen, ontstonden er verschillende nieuwe open source
projecten. Eén daarvan is het besturingssysteem Linux dat kan worden beschouwd als een van de
meest succesvolle OS projecten. Er werden ook alternatieve licenties ontwikkeld die minder
strikt zijn dan de GNU GPL. In 1997 werd de organisatie het “Open Source Initiative” opgericht
en ze is nog steeds één van de belangrijkste organisaties voor het promoten van OSS. Deze
organisatie heeft tegelijk de “Open Source Definition” gelanceerd die door de OS gemeenschap
wordt aanvaard. Zij hebben ook een groot aantal licenties getoetst aan deze OS definitie en
goedgekeurd. De bedoeling van deze definitie was de software een meer commercieel imago te
geven. Velen zagen een opportuniteit om deze software ook als commercieel goed te
beschouwen en op basis daarvan commerciële activiteiten uit te bouwen. (Lerner & Tirole, 2001)
(Ghosh, Glott, Krieger, & Robles, 2002)
Het belang hiervan ligt bij de gemeenschap van programmeurs en het algemene imago van OSS.
Een OS project is afhankelijk van vrijwilligers die om verschillende redenen bijdragen aan een
project, zoals in het hoofdstuk over OS gemeenschappen te lezen is. Er moet aan een aantal
regels worden voldaan, zoniet zullen er niet veel vrijwilligers zijn die bijdragen aan broncode.
Steun van de gehele OS gemeenschap is één van de belangrijkste succesfactoren van een OS
project. (Bonaccorsi & Rossi, 2003) (Dahlander & Magnusson, 2008)
1.1.3 Licenties
De bijhorende licentie bij OSS is het belangrijkste instrument in de structuur bij het beheren van
een OS project. Wanneer een bedrijf er voor kiest om de broncode van zijn software vrij te geven
8
zal er voor een bepaalde OS licentie moeten worden gekozen. Voor een bedrijf heeft de keuze
van de licentie een belangrijke implicatie op het bedrijfsmodel. (451 Group, 2008) Dit heeft
namelijk een impact op zowel de ontwikkeling van de software, de licentiestrategieën die
mogelijk zijn voor verschillende producten en de strategieën die mogelijk zijn om inkomsten te
genereren. Een goede OS licentie biedt ook een garantie aan de vrijwillige software ontwikkelaar
dat hij/zij eerlijk zal worden behandeld. (Hecker, 1999) Een korte omschrijving van de
verschillende soorten OS licenties is nodig om de verdere bedrijfsmodellen te begrijpen.
De verschillende OS licenties kunnen worden opgedeeld in twee grote categorieën: wederkerige
licenties en toegeeflijke licentie. (451 Group, 2008)
Wederkerige licenties
Onder de categorie wederkerige licenties verstaan we deze licenties, die bepalen dat
aanpassingen van de broncode opnieuw onder dezelfde licentie moeten zijn. Dit maakt het
gebruik van de code in eigendomssoftware moeilijker. De twee belangrijkste wederkerige
licenties zijn de GNU General Public License en de GNU Lesser General Public License. Ze
worden verder besproken. (451 Group, 2008)
Toegeeflijke licenties
De naam zelf geeft aan dat het hier gaat om licenties die minder vereisten stellen aan de
gebruiker. Het is mogelijk om de broncode te veranderen en te distribueren onder eender welke
licentie met inbegrip van commerciële producten waarvan de broncode niet zichtbaar is.
Voorbeelden hiervan zijn de BSD licentie, de Apache Licenties, de Mozilla Public Licentie en de
Eclipse Public Licentie. (451 Group, 2008)
9
Figuur 1: Licenties die worden gebruikt door open source gerelateerde bedrijven
Bron: 451 Group, Open Source is not a Business Model
Uit een onderzoek blijkt dat 74% van de OSS die door bedrijven wordt gebruikt een wederkerige
licentie heeft. De andere 26% van de OSS heeft een toegeeflijke licentie. (451 Group, 2008)
De GNU General Pulic License v2 (GNU GPL v2)
Dit is een van de meest gebruikte OS licenties, daarom zal deze ook meer in detail worden
besproken. De meeste licenties die hier verder worden besproken verschillen niet fundamenteel
van deze licentie, vandaar dat er telkens naar deze populaire licentie kan worden verwezen. Mits
men voldoet aan een aantal voorwaarden worden de volgende handelingen toegestaan:
• Sectie 1: Het is toegestaan om de onveranderde broncode van de software te kopiëren en
te distribueren. (Wilson R. , 2009a)
• Sectie 2: Het is toegestaan om de broncode te veranderen en deze broncode te
distribueren. (Wilson R. , 2009a)
10
• Sectie 3: Het is toegestaan om gecompileerde versies van het software programma te
distribueren, zowel van veranderde als onveranderde versies. (Wilson R. , 2009a)
Dit zijn de voornaamste onderdelen van de GNU GPL v2. De voorwaarden waaraan men moet
voldoen zijn:
‐ Elke gedistribueerde kopie, zowel veranderd als onveranderd, maakt een vermelding van
de GNU GPL v2 licentie. (Wilson R. , 2009a)
‐ Elke kopie van veranderde broncode moet worden gedistribueerd met een GPL v2
licentie. Dit betekent dus dat software die afkomstig is of afgeleid werd van broncode
met de GNU GPL v2 licentie opnieuw onderworpen moet zijn aan de GNU GPL v2
licentie. Dit is het zogenaamde virale effect van dit soort licenties. (Wilson R. , 2009a)
‐ De gecompileerde versies van een programma bevatten de relevante broncode of
vermelden waar men de relevante broncode kan terugvinden. (Wilson R. , 2009a)
Met betrekking tot deze licentie kunnen een aantal dingen worden opgemerkt. In de meeste
literatuur maakt men vermelding van deze licentie als zijnde niet erg bedrijfsvriendelijk. Ze kan
namelijk worden gecategoriseerd onder de wederkerige licenties. Maar er zijn een aantal
voordelen voor de bedrijfswereld verbonden aan deze licentie. Bedrijven kiezen er soms voor om
een tweevoudige licentie strategie toe te passen. Dat betekent dat een bedrijf zijn code vrijgeeft
onder de GNU GPL v2 licentie en een traditionele commerciële licentie. Dat bedrijf kan als
enige de broncode die in de gemeenschap werd ontwikkeld opnemen in de commerciële versie
van het product en veranderingen aanbrengen zonder deze publiek te moeten maken. Op die
manier wordt het onmogelijk voor concurrenten om de code in gesloten code te integreren en
gelijkaardige producten te verkopen. (Wilson R. , 2009a) Andere mythes rond deze licentie zijn
de volgende:
• Mythe 1: Vele bedrijven die enkel geïnteresseerd zijn in het intern gebruik van de code
zullen ook worden ontmoedigd door deze licentie. Dit wordt vaak vermeld als een nadeel
van de GNU GPL, maar is een mythe. Men is niet verplicht om verandering aan de code
vrij te geven, wanneer de software voor privé gebruik is. (Wilson R. , 2009a)
11
• Mythe 2: Bij het gebruik van een gedeelte van de broncode voor software, moet men de
volledige broncode vrijgeven. Het is dus niet altijd mogelijk om de code te integreren met
broncode die een toegeeflijke OS licentie of commerciële licentie heeft. Wanneer het
enkel gaat om het samennemen van deze broncode met een andere code, dus geen
veranderingen van de OS broncode, is men niet verplicht om de code van de gesloten
software vrij te geven. (Wilson R. , 2009a)
De GNU Lesser of Library GPL
De GNU LGPL is afgeleid van de GNU GPL en werd ontwikkeld voor software bibliotheken,
maar ze wordt vandaag daar niet alleen meer voor gebruikt. Met bibliotheek wordt een groep van
softwarefuncties bedoeld die worden gebruikt door andere softwareprogramma’s. Software met
deze licentie kan worden opgenomen in eigendomssoftware. Deze licentie zorgt ervoor dat het
mogelijk is om wijde verspreiding van een (superieur) software product te vergemakkelijken en
op die manier kan het concurreren met commerciële producten. (Wilson R. , 2009b) (Ghosh,
Glott, Krieger, & Robles, 2002)
De MIT1, BSD en BSD-stijl licenties
De BSD (Berkeley Software Distribution) licentie werd voor de eerste maal gebruikt voor UNIX
en is verschillend van de GNU GPL v2 en GNU LGPL v2. Ze is namelijk minder beperkend dan
GNU (L)GPL. Ze laat toe om het product in commerciële toepassing te gebruiken. Distributie en
gebruik in broncode en binaire vorm is toegestaan, zowel van de veranderde als onveranderde
versies. (Wilson R. , 2009e) (Hecker, 1999)
In de originele BSD licentie was een clausule te vinden die het gebruik van de licentie sterk
bemoeilijkte. Het gaat hier over de vereiste om bij alle afgeleide producten de originele auteur te
vermelden en te erkennen. In latere BSD licenties zoals de ‘new BSD license’ en de ‘simplified
BSD license’, werd deze clausule verwijderd. Nu is het enkel niet toegestaan om gebruik te
maken van de naam van vorige bijdragers voor promotionele activiteiten zonder geschreven
toestemming. (Wilson R. , 2009e) (Hecker, 1999)
1 Massachusetts Institute of Technology
12
De Netscape Public License (NPL) en de Mozilla Public License (MPL)
De NPL was ontwikkeld door Netscape zodat de Netscape Navigator OSS kon worden, maar
tegelijkertijd bleef de software in handen van Netscape. Deze licentie bevat namelijk speciale
privileges voor Netscape. Het geeft hen de mogelijkheid om wijzigingen aan de broncode te
onderwerpen aan een andere licentie, mogelijk een commerciële licentie. Op deze manier kunnen
wijzigingen worden opgenomen in eigendomssoftware. Deze clausule die specifiek is voor
Netscape werd uit de NPL verwijderd en is de MPL. De MPL is dus bruikbaar voor andere
bedrijven die eigendomssoftware OSS willen maken. Het verschil met de GPL is dat de MPL
expliciet toelaat om MPL code te combineren met afzonderlijk gesloten code om
eigendomssoftware en extra commerciële functionaliteiten te creëren (en dit volgens bepaalde
regels die uitgestippeld zijn in de licentie). Dit maakt de licentie dus bijzonder aantrekkelijk voor
bedrijven. (Hecker, 1999) (Wilson R. , 2009c)
Apache licentie v2
Deze licentie is gelijkaardig aan en gebaseerd op de BSD licentie. Deze licentie werd door de
Apache Software Foundation ontwikkeld voor de populaire OS webserver Apache. De licentie
kent expliciet patentrechten toe voor het gebruiken, veranderen en distribueren van de software.
Het is ook toegelaten om de broncode op te nemen in eigendomssoftware projecten. Deze tweede
versie is niet compatibel met de GNU GPL v2. Dit komt doordat er in deze licentie een clausule
aanwezig is die bepaalt dat de patentrechten die men heeft worden opgeheven wanneer de
licentiegever gerechtelijk wordt vervolgd door de licentiehouder. De 3de versie van de GNU GPL
zou wel compatible zijn met de Apache licentie. (Wilson R. , 2009d)
1.2 ICT bedrijfsmodellen
In de eerste plaats is het nuttig om een studie te maken van software als economisch goed.
Software heeft een aantal unieke eigenschappen in vergelijking met fysieke goederen. Daarop
wordt kort de software waardeketen besproken. Daarna wordt er nagegaan wat juist wordt
bedoeld met het concept bedrijfsmodel. Daarop volgend wordt het software bedrijfsmodel
besproken. Nadat de software bedrijfsmodellen zijn besproken is er een uiteenzetting over de
evoluties binnen de software industrie. Om af te sluiten wordt er gekeken hoe OSS in de
software-industrie zijn weg baant.
13
1.2.1 De Software Industrie
Het is nuttig om de economische eigenschappen van het product software te bespreken omdat ze
uniek zijn. Deze eigenschappen hebben ook een impact op de manier waarop waarde kan worden
gecreëerd. De software industrie kan dan beschouwd worden als intrinsiek verschillend van de
meer traditionele industrieën. De reden hiervoor is dat “analyse gebaseerd op conventionele
economie niet nuttig is in de informatie industrie, omdat conventionele economie uitgaat van
schaarste”. (Clarke & Dempsey, 2004) (Van Aardt, 2006) Aangezien het kopiëren van software
geen productiekosten met zich meebrengt is schaarste dus geen factor. Voor vele fysieke
goederen wordt de waarde van het product gecreëerd bij de productie. Voor software gelden niet
dezelfde principes. De ontwikkelingskosten die men initieel moet investeren om een
softwareproduct te creëren is niet de grootste kost die men maakt. De kosten die men maakt voor
onderhoud zijn vaak belangrijker. Het eigendomsrecht van software is ook anders georganiseerd
dan bij fysieke goederen. De eigendom van broncode is gebaseerd op intellectuele eigendom en
niet op het fysieke bezit. (Ghosh, Glott, Krieger, & Robles, 2002) (Messerschmitt & Szyperski,
2005)
Er kunnen ten minste vier belangrijke categorieën software worden geïdentificeerd:
geïntegreerde software, infrastructuursoftware, componenten en applicatiesoftware.
• Geïntegreerde software is samengebonden of verweven in uitrusting en
informatietoestellen. Voor de gebruiker is deze software niet herkenbaar als een apart
geheel dat onafhankelijk is van de hardware. (Messerschmitt & Szyperski, 2005)
• Infrastructuursoftware is afzonderlijk beschikbaar voor de gebruiker zelf als deze
software initieel werd gebundeld met de hardware. De gebruiker kan dus de
infrastructuur software vervangen. (Messerschmitt & Szyperski, 2005)
• Componenten worden gekocht en verkocht in de markt en worden samengevoegd tot
applicaties. Deze componenten zijn dus geen volledige applicatie en kunnen worden
vervangen of verbeterd. (Messerschmitt & Szyperski, 2005)
Het onderscheid tussen infrastructuur- en applicatiesoftware is belangrijk omdat beiden
afhankelijk zijn van elkaar. Infrastructuursoftware voorziet in de mogelijkheden om grote
verscheidenheid aan applicaties te ondersteunen. Applicatiesoftware is afhankelijk van de
14
infrastructuursoftware en is hoofdzakelijk gericht op specifieke behoeften van de eindgebruiker.
(Messerschmitt & Szyperski, 2005)
Voor sommige applicaties is het nodig dat er controle is op de toegang tot de applicaties. Dit
heeft betrekking op de mogelijkheid om te bepalen wie de toestemming heeft om een applicatie
te gebruiken, de mogelijkheid om te identificeren wie probeert om toegang te krijgen tot de
applicatie en de mogelijkheid om toegang te weigeren tot de applicatie. Herbruikbare software
componenten kunnen deze functies implementeren die dan kunnen worden geïntegreerd in
meerdere applicaties. Deze softwarecategorie wordt middleware genoemd en is een laag die
wordt toegevoegd aan de bestaande infrastructuur die onder de applicatielaag ligt.
(Messerschmitt & Szyperski, 2005)
Er zijn een aantal uitdagingen specifiek voor de software industrie en een aantal termen
belangrijk voor software die kort worden besproken:
• De beschikbaarheid van complementaire producten heeft een invloed op de waarde van
software. Besturingssystemen zoals Windows, Mac OS, Linux zijn voorbeelden van
infrastructuursoftware. Een bepaalde applicatiesoftware zoals een tekstverwerker kan
beschikbaar zijn op een besturingssysteem zoals Windows maar niet op Linux. Dit vormt
een beperking voor het gebruik van deze applicatie, onafhankelijk van de kwaliteit van de
applicatie zelf. De beschikbaarheid van complementaire producten is belangrijk. De
waarde van een besturingssysteem zal dus niet alleen afhangen van de kwaliteit, maar
ook van de beschikbaarheid van applicaties. (Messerschmitt & Szyperski, 2005)
(Schilling, 2008)
• Een andere uitdaging voor de software industrie is industriecoördinatie. De infrastructuur
van vele verschillende softwarebedrijven moet kunnen samenwerken, applicaties moeten
kunnen samenwerken met infrastructuur en applicaties moeten ook op complexe
manieren samenwerken voorbij de grenzen van de verschillende organisaties.
(Messerschmitt & Szyperski, 2005)
• “Netwerk externalities”: Software is typisch een markt met “netwerk externalities”. Dit
wil zeggen dat de baten bij het gebruik van een bepaald goed stijgen met het aantal
andere gebruikers van hetzelfde product. De waarde van een bepaald product stijgt dus
15
met toenemende grootte van het netwerk van gebruikers. (Schilling, 2008)
(Messerschmitt & Szyperski, 2005)
• “Installed base”: De “installed base” is het aantal gebruikers van een specifieke
technologie. (Schilling, 2008)
• “Switching” kosten: De kosten die men heeft wanneer men van producent wil
veranderen. Dit resulteert in “vendor lock-in” dat een competitief voordeel is voor een
bepaalde producent. (Messerschmitt & Szyperski, 2005)
1.2.2 De Software Waardeketen
De software waardeketen bestaat uit drie grote onderdelen: de productie of het programmeren,
marketing, verkopen (distributie) en diensten. Er kan een onderscheid worden gemaakt tussen de
waardeketen voor gestandaardiseerde software en de waardeketen voor op maat gemaakte
software. (Ghosh, Glott, Krieger, & Robles, 2002)
Figuur 2: Software waardeketen
1.2.3 Wat is een Bedrijfsmodel?
Vooraleer een bedrijfsmodel te beschrijven wordt eerst het concept bedrijfsmodel besproken. In
de literatuur kunnen verschillende definities en onderdelen worden gevonden van een
bedrijfsmodel. Eén definitie die wie kunnen vinden is deze in een essay van Rajala et al:
“Waarde creatie processen en vaststellen van mogelijkheden in de markt en deze omzetten in
inkomsten door een verzameling van activiteiten, processen en transacties”.(Rajala, Rossi, &
Tuunainen, 2003, p. 3) Een idee dat terug komt in de literatuur is het procedurele karakter van
een bedrijfsmodel. Er zijn een aantal elementen die kunnen worden beschreven:
Productie/programmering Diensten
Software
ontwikkeling
Software
documentatie
Software
verpakking Marketing
en sales
Implementatie en/of
integratie opleiding ondersteuning
Applicatie-
management
16
‐ Waarde, Waarde creatie proces: beschrijft datgene wat van waarde is voor het
klantensegment. (Fitzgerald, 2006) (Galoppini, 2007) (Rajala, Rossi, & Tuunainen, 2003)
‐ Het distributie kanaal: Wat zijn de rollen van de verschillende actoren in de business?
Hoe worden de producten of diensten gedistribueerd? (Fitzgerald, 2006) (Galoppini,
2007) (Rajala, Rossi, & Tuunainen, 2003)
‐ Inkomsten: Op welke manier worden inkomsten gegenereerd? (Fitzgerald, 2006)
(Galoppini, 2007) (Rajala, Rossi, & Tuunainen, 2003)
‐ Klanten segment: Wat is de doelgroep? (Galoppini, 2007)
In de essay “Clarifying Business Models: Origins, Present, and Future of the concept” staat een
uitgebreide definitie van een Bedrijfsmodel: “Een bedrijfsmodel is een conceptueel instrument
dat een verzameling van elementen en hun relaties bevat en dat toelaat om de bedrijfslogica van
een bepaald bedrijf te verduidelijken. Het is een beschrijving van de waarde die een bedrijf biedt
voor één of meerdere klantensegmenten en van de architectuur van het bedrijf en diens
partnernetwerk voor het creëren, marketen en leveren van deze waarde […] voor het genereren
van winstgevende en duurzame inkomstenstromen”. (Osterwalder, Pigneur, & Tucci, 2005, pp.
17-18) Algemeen zijn er negen verschillende domeinen of bouwstenen die een bedrijfsmodel
omschrijven. (Osterwalder, Pigneur, & Tucci, 2005)
17
Tabel 1: Negen bouwstenen van een bedrijfsmodel
pilaar bouwsteen omschrijving
product Value PropositionGeeft een allesomvattend overzicht van de producten
en diensten van een bedrijf
Doelgroep Beschrijft het segment van klanten waaraan het bedrijf waarde wil bieden
Distributiekanaal Beschrijft de verschillende middelen van een bedrijf om tot de klant te komen
RelatiesBeschrijft de linken die een bedrijf vestigd met de
verschillende klantensegmentenValue Configuration Beschrijft de organisatie van activiteiten en middelen
Core Competency Beschrijft de vaardigheden die nodig zijn om het bedrijfsmodel uit te voeren
Partnernetwerk
Beschrijft het netwerk van cooperatieve overeenkomsten met andere bedrijven die nodig zijn
om op efficiente wijze waarde te bieden en te commercializeren
Kostenstructuur Beschrijft de monetaire gevolgen van de middelen gebruikt in het bedrijfsmodel
InkomstenmodelBeschrijft de manier waarop een bedrijf geld verdiend
via verschillende inkomstenstromen
klanten interface
management van infrastructuur
financiele aspecten
Bron: (Osterwalder, Pigneur, & Tucci, 2005) p18
In literatuur over bedrijfsmodellen van zowel OSS als CSS bedrijven wordt meestal enkel een
beschrijving van de “value proposition” en de financiële aspecten gevonden. Het is ook niet echt
nodig om elk van de negen domeinen hier te bespreken. Een element dat dus wel verder zal
worden besproken en onderzocht is dat van het partnernetwerk.
1.2.4 Software Bedrijfsmodel
Voor er wordt gekeken naar OSS bedrijfsmodellen, wordt het software bedrijfsmodel dat lange
tijd werd en wordt toegepast in de software industrie besproken. Dit is een lange tijd stabiel
geweest, maar is de laatste jaren ook aan het veranderen. Software is nog geen volgroeide
industrie en blijft in constante evolutie. (Cusumano, 2007a)
Het Standard software bedrijfsmodel
In de software industrie zijn er steeds drie categorieën geweest die inkomsten genereren.
18
• De conventionele manier binnen de eigendomssoftware industrie om inkomsten te
genereren voor een softwarebedrijf is door klanten het recht op gebruik van de software
te verkopen en dus niet het feitelijke product te verkopen. De kost van licenties die recht
op gebruik verlenen kunnen op verschillende manieren worden bepaald en berekend. Zo
kan men software voorzien van een licentie per gebruiker, per machine, per organisatie...
De licentie kan ook afhankelijk zijn van de doeleinden waarvoor de software wordt
gebruikt. (Hecker, 1999) (Cusumano, 2007a)
• Softwarebedrijven verkopen naast deze licenties ook onderhoudscontracten, die vaak in
de vorm van een jaarlijkse vergoeding worden uitbetaald. Zolang deze jaarlijkse
vergoeding wordt betaald krijgen eindgebruikers updates, patches en eventueel
technische ondersteuning. (Cusumano, 2007a)
• Als laatste kunnen ook nog inkomsten voortvloeien uit diensten zoals installeren en
integreren van de software, opleiden van gebruikers en eventueel het aanpassen of op
maat maken van software producten. (Cusumano, 2007a)
Een licentie vergoeding en eenmalige diensten, zoals implementatie en integratie, kunnen
worden beschouwd als een directe inkomstenstroom, terwijl onderhoudscontracten een
inkomstenstroom genereren die verspreid is over lange tijd. (Cusumano, 2007a)
Van een product naar diensten georiënteerde industrie
Producten zoals computerspelletjes en besturingssystemen zoals deze van Microsoft genereren
de meerderheid van hun inkomsten uit de verkoop van kopieën of licenties. Voor deze producten
is er één grote kost en dat is deze van het ontwikkelen van de software. Nadat deze kost is
gemaakt is het de bedoeling om zoveel mogelijk kopieën of licenties te verkopen aangezien de
marginale kost om kopieën of licenties te produceren (bijna) nul is. Maar vele andere software
producten staan onder druk om hun verkoopstrategieën te veranderen. De prijzen van vele
ondernemingssoftware dalen. Oorzaken zou men kunnen vinden in de opkomst van OSS, het
internet... Bij OSS is de licentiekost in wezen nul. Wat er heeft tot geleid dat eindgebruikers zich
verzetten tegen het betalen van grote sommen geld voor gestandaardiseerde software producten.
Softwarebedrijven zien ook dat inkomsten uit diensten en onderhoud/ondersteuning in stijgende
lijn gaan. De inkomsten uit softwareproducten dalen en worden zelfs kleiner dan deze uit
19
diensten en onderhoud, dit is het fenomeen ‘crisscross’. De inkomsten van softwarebedrijven zijn
meer en meer afkomstig uit jaarlijkse vergoeding voor patches, upgrades en technische support
of ondersteuning. (Cusumano, 2007a) (Cusumano, 2008b)
Een nieuwe prijzenstrategie die wordt gebruikt is deze van de abonnementenlicentie. De klant
koopt het recht om de software te gebruiken maar voor een bepaalde periode, bijvoorbeeld een
jaar. Op die manier wordt de eenmalige uitgave van een licentie opengebroken en gecombineerd
met onderhoud. Een andere variatie hiervan is Software as a service. De klant koopt opnieuw een
abonnement maar voor een korte periode, zoals een maand, gecombineerd met “webhosting”.
Dat wil zeggen dat de toegang naar de software wordt verleend via het internet. Op die manier
wordt het voor de klant of gebruiker overbodig om voor complexe installatie en integratie kosten
te betalen. Tegelijk kunnen er ook professionele diensten worden aangeboden zoals op maat
ontwikkeling. (Cusumano, 2008b)
Een interessante economische analyse die kan verklaren waarom deze verschuiving plaatsvindt,
heeft betrekking op de verkoopswaarde en gebruikswaarde van een product. De gebruikswaarde
van een software programma is de economische waarde als een tool, een instrument dat
productiviteit verbetert. De waarde van een programma als verkoopbaar product is de
verkoopswaarde. Velen gaan er van uit dat software ontwikkeling ook kan worden vergeleken
met een productieomgeving zoals auto’s, elektronica... (Raymond, 1999b) Men gaat namelijk uit
van de volgende twee veronderstellingen:
• De tijd nodig om een software programma te ontwikkelen wordt vergoed door de
verkoopswaarde. (Raymond, 1999b)
• De verkoopswaarde van een software product verhoudt zich tot de kosten voor het
schrijven van de software en de bekomen gebruikswaarde. (Raymond, 1999b)
In het essay “The Magic Cauldron” van de auteur Eric Steven Raymond worden deze twee
stellingen ontkracht en wordt de software industrie eerder omschreven als een diensten industrie.
De meest recente versie van dit essay is van 2000 en de auteur maakt reeds de analyse dat
software meer als een dienst moet worden beschouwd. (Raymond, 1999b)
20
Een eerste bevinding is het feit dat de grootste taak van programmeurs het onderhoud van een
software toepassing is. De middelen en kosten nodig voor het schrijven van de broncode voor
een verkoopbaar product is een klein deel van een groter geheel. Op deze manier wordt dan ook
de eerste stelling van hierboven verworpen. Om te bewijzen dat de tweede stelling niet correct is
maakt men de vergelijking met andere ontastbare goederen. Wanneer de originele producent of
de maker van bijvoorbeeld muziek of een database zijn activiteiten stopt, zullen consumenten
niet stoppen met het gebruik van deze goederen. In tegenstelling tot wanneer softwarebedrijven
hun activiteiten beëindigen zal men niet bereid zijn om hier nog voor te betalen onafhankelijk
van de theoretische gebruikswaarde of ontwikkelingskosten die werden gemaakt. Het is namelijk
zo dat de prijs die een consument wil betalen wordt bepaald door de verwachte toekomstige
waarde van de diensten van een bedrijf (met diensten bedoelt men verbeteringen, upgrades en
follow-up van de software). Eén uitzondering hierop zijn computerspelletjes. Deze hebben
weinig of geen nood aan updates en dergelijke. (Raymond, 1999b)
Hieruit kan worden besloten dat de prijsstructuur van software, een eenmalige
licentievergoeding, niet altijd economisch het meest verantwoorde is om als prijsstrategie te
gebruiken. Voor softwaresystemen is de “Total Cost of Ownership” ook een belangrijk gegeven.
TCO is een methodologie en filosofie die naast de kost van een aankoop ook andere kosten in
rekening neemt die gerelateerd zijn aan deze aankoop. Een groot deel van de TCO van een
softwareaankoop komt uit de aankoop van de software, operationeel houden van de software,
onderhoud, debuggen en uitbreidingen, faciliteiten, personeel,... (Raymond, 1999b)
(Messerschmitt & Szyperski, 2005) (Ellram, 1995)
Nieuwe technologieën, andere prijsstrategieën, andere manieren om software bij de klant te
brengen en het bereiken van nieuwe klantensegmenten vormen ook een basis voor nieuwe
software bedrijfsmodellen. (Cusumano, 2008b)
1.2.5 OSS in de Software Industrie
De huidige bedrijfswereld ondergaat zeer snel veranderingen en het is dan ook niet altijd even
eenvoudig om deze veranderingen op een grote schaal op te volgen en zeer accuraat te
herkennen. Sommige literatuur stelt dat het OS fenomeen een revolutionaire impact heeft op de
IT industrie en de regels van het spel heeft veranderd. (Fitzgerald, 2006)
21
Vele softwarebedrijven hebben niet de mogelijkheid of de (financiële) middelen om de
activiteiten te ondersteunen die nodig zijn om een goed software product te produceren en te
concurreren met bestaande softwarebedrijven. OSS wordt dan ook voorgesteld als de oplossing.
(Hecker, 1999)
OSS heeft ervoor gezorgd dat er een grote druk is op prijsniveaus. Het is nu mogelijk voor
startende bedrijven om snel de softwaremarkt binnen te treden tegen een lage kost. (Hecker,
1999)
Bestaande softwarebedrijven en andere bedrijven die software verkopen werden dan ook
geconfronteerd met het fenomeen OSS. Enerzijds kan dit een opportuniteit bieden. Software
ontwikkelaars kunnen bijvoorbeeld eigendomssoftware schrijven voor OSS platforms. De
software van IBM, Oracle en SAP is ook beschikbaar voor het OSS besturingssysteem Linux en
dit kan beschouw worden als een winstgevende bron van inkomsten. (West, 2003)
De reactie van eigendomssoftware bedrijven is afhankelijk van de mate waarin software kan
worden beschouwd als een bron van competitief voordeel. Een bedrijf zoals Microsoft is volledig
afhankelijk van de software die wordt ontwikkeld. Daartegenover staat de strategie van IBM die
meer kan worden beschouwd als “solution provider”. Het jaarlijkse rapport van IBM bevat
expliciet OSS als een deel van de bedrijfsstrategie en zegt duidelijk verder OS oplossingen te
willen bieden aan klanten. (West, 2003)
Softwarebedrijven kunnen dus experimenteren om de juiste mix te vinden tussen totaal gesloten
software tegenover volledig open software of OSS. Tot nu toe heeft men twee hybride
strategieën kunnen vinden. (West, 2003)
• Openen van onderdelen: De controle van basisproducten van software kan men open
maken, terwijl men de volledige controle behoudt over andere delen of lagen software die
grotere opportuniteit biedt voor differentiatie. (West, 2003)
• Gedeeltelijk open: De technologie voor een gedeelte openbaar maken en dat onder strikte
voorwaarden zodat het waarde biedt voor klanten. Op deze manier is het niet mogelijk
voor concurrenten om de technologie verder te gebruiken. (West, 2003)
22
Een voorbeeld hiervan is het OS project Eclipse, dat oorspronkelijk door IBM werd ontwikkeld.
De Eclipse Foundation waakt nu volledig onafhankelijk over de toekomst van het Eclipse
platform. IBM is de voornaamste bijdrager aan het project samen met nog vele andere bedrijven.
Een groot aantal van de eigendomsproducten van IBM zijn gebaseerd op dit platform, dat is dan
ook de reden waarom OSS een deel van de strategie van IBM is. (The Eclipse Foundation, 2010)
1.3 Open Source Software bedrijfsmodellen
In dit hoofdstuk worden de bedrijfsmodellen die door OSS bedrijven worden gebruikt behandeld.
Vandaag de dag is het moeilijk geworden om een strikt onderscheid te maken tussen OSS
bedrijven en niet-OSS bedrijven. Ook softwarebedrijven zoals IBM, Oracle,... hebben in hun
aanbod softwareproducten die gebaseerd zijn op OSS. Er zijn ook veel OSS bedrijven die
software verkopen die eigenlijk een combinatie is van OSS en eigendomssoftware.
Eerst wordt er nagegaan waarom professionele gebruikers van OSS via een bedrijf de software
aankopen, in plaats van de broncode direct van de gemeenschap te nemen. Daarna zal een
overzicht worden gegeven hoe de bedrijfsmodellen op basis van OSS eruit zien.
1.3.1 Open Source Software en Professionele Softwaregebruikers
Wat is de toegevoegde waarde van OSS bedrijven voor de bedrijfswereld als de code vrij te
verkrijgen is? OSS bedrijven zijn essentieel voor de commerciële toepassing van OSS in
bedrijven. Vele OSS is zeer aantrekkelijk wegens zijn lage kosten en goede prestaties, maar in
een commerciële omgeving is het belangrijk om meer dan alleen de broncode ter beschikking te
hebben. Er zijn namelijk nog bijkomende producten en diensten nodig alvorens men OSS kan
gebruiken in een onderneming. (Feller, Fitzgerald, Hissam, & Lakhani, 2005) (Dixon, 2009)
(Wied, 2009)
• Robuuste technische ondersteuning en waarborgen: SLA’s of “Service Level
Agreements” zijn verplicht in vele ondernemingen. Het is essentieel dat er een
betrouwbaar softwarebedrijf is dat technische ondersteuning garandeert of het nu OSS of
eigendomssoftware is. (Wied, 2009)
• Schadedekking: Er is nood aan een legale entiteit die schadedekking voorziet voor OSS,
doordat er intellectuele eigendomsrisico’s zijn. Vaak zijn bedrijven onzeker over het
23
gebruik van OSS omdat men de organisatie van het intellectuele eigendom niet goed
begrijpt. Legale bijstand is dan ook een must. (Wied, 2009)
• Hogere kwaliteit: Bedrijven hebben nood aan bijkomende certificaten (d.i. bewezen
opereerbaarheid tussen software van verschillende bedrijven), complete documentatie
(bv. een handleiding) of bijkomende tests om robuustheid te garanderen in een
productieomgeving. (Wied, 2009)
• Extra functionaliteiten of mogelijkheden: Sommige bedrijven hebben speciale applicaties
nodig, aangepast aan een specifiek bedrijf of industrie. (Wied, 2009)
• Commercieel bruikbare of ‘bedrijfsvriendelijke’ licenties: OS licenties kunnen in strijd
zijn met het beleid van een bedrijf, vandaar dat er ook nood is aan andere licenties die
bruikbaar zijn voor commerciële bedrijven. Dit is bijvoorbeeld voor bedrijven die de
basissoftware aanpassen voor een specifieke bedrijfsomgeving, zoals een
architectenbureau en ze verder doorverkopen. (Wied, 2009)
• Diensten zoals installatie, implementatie, opleiding, certificaten, continue technische
assistentie, op maat ontwikkeling... (Dixon, 2009) (Feller, Fitzgerald, Hissam, &
Lakhani, 2005)
Bedrijven hebben dus nood aan professionele diensten, gecertificeerde partners, software stacks,
product management en roadmaps, bepaalde functionaliteiten, adviesraden, case studies,
gebruiksgroepen, referenties, … Professionele OSS bedrijven helpen klanten om het risico
verbonden met OSS te beheersen. Naar vele OSS is er een zeer grote vraag en er is een grote
behoefte aan ondersteuning voor ondernemingen. Contracten voor diensten die ondersteuning
bieden zijn een grote inkomstenbron geworden voor bedrijven zoals Red Hat. (Dixon, 2009)
(Wied, 2009)
1.3.2 Open Source Software Bedrijfsmodellen
De literatuur over bedrijfsmodellen rond OSS is zeer uitgebreid en kan vaak grote verschillen
vertonen. Onderzoek heeft zich dan ook vaak geconcentreerd op het vinden van afgelijnde
bedrijfsmodellen die worden gebruikt. Bij gevolg heeft elke essay de bedrijfsmodellen voor OSS
bedrijven op een andere manier omschrijft en dat er ook veel overlapping is tussen de
bedrijfsmodellen. Men geeft dan ook vaak aan dat de bedrijfsmodellen elkaar niet uitsluiten en er
24
verschillende combinaties mogelijk zijn. De oorzaak hiervoor kan te vinden zijn in het feit dat er
vele elementen zijn die variatie creëren in de manier waarop een OSS bedrijf werkt. Men is dan
ook gebruik gaan maken van de term “hybride” bedrijfsmodellen waarmee men heeft geprobeerd
om verschillende variaties in bedrijfsmodellen te consolideren in één term. In wat volgt zal een
meer complete beschrijving worden gegeven hoe OSS bedrijven een inkomen trachtten te
genereren.
Eén van de eerste en bekendste wetenschappelijke artikels die dit onderwerp behandelde was
“Setting up shop” van Hecker. Het werd geschreven in 1998 en is dus bijgevolg niet meer
volledig aangezien er nog steeds veel evolutie plaatsvindt in deze industrie. De meer recente
literatuur benadert de materie ook op een andere manier, namelijk door het rapporteren van de
activiteiten die een inkomen kunnen genereren op basis van OSS en niet een categorisatie te
maken van mogelijke bedrijfsmodellen. Uit onderzoek blijkt dat vele bedrijven deze activiteiten
combineren in plaats van zich te beperken tot één activiteit. (Van Aardt, 2006) (Chesbrough &
Appleyard, 2007) (451 Group, 2008) De lijst van mogelijke bedrijfsmodellen wordt dan te groot
en onoverzichtelijk, vandaar dat het duidelijker is een overzicht te geven van de activiteiten die
mogelijk zijn. Naast deze mogelijke inkomstenstrategieën die kunnen worden gekozen door een
OSS bedrijf heeft de licentie- en ontwikkelingsstrategie die wordt gebruikt ook een belangrijke
invloed op hoe het bedrijfsmodel er uit ziet. Dit zal dan ook verder worden besproken. Dit model
is gebaseerd op een rapport van de 451 groep die een grootschalig onderzoek heeft uitgevoerd bij
116 bedrijven in de IT industrie. De 451 groep is een bedrijf dat professioneel onderzoek doet en
analyses maakt over de ontwikkelingen en innovatie in bedrijfs-IT. Zij hebben zich niet beperkt
tot bedrijven die hoofdzakelijk inkomsten hebben uit OSS, maar er hebben ook bedrijven
deelgenomen die in hun productaanbod OSS naast eigendomssoftware aanbieden zoals IBM en
Oracle. (451 Group, 2008)
Inkomsten strategie
Omdat de broncode van de software beschikbaar is voor iedereen is de vraag hoe men van de
software gebruiker geld kan verkrijgen. Er zullen dus op een of andere manier goederen en
diensten worden aangeboden die niet afhankelijk zijn van de broncode zelf. Hieronder wordt een
lijst van activiteiten of strategieën besproken die een inkomen kunnen voortbrengen voor OSS
bedrijven. (451 Group, 2008)
25
• Commerciële licenties: De commerciële licentie is een traditionele licentie die naast de
OS licentie wordt gebruikt. (451 Group, 2008)
• Abonnementen: Dit houdt in dat er een jaarlijks herhaalbare overeenkomst wordt
afgesloten voor ondersteuning en diensten met betrekking tot een bepaalde software
stack. Voor de eindgebruiker is dit een verzekeringspolis tegen de nood aan ad hoc
diensten en ondersteuning. In het abonnement hebben gebruikers vaak ook recht op
regelmatig updates, upgrades, programmeerfout herstellingen, ... (451 Group, 2008)
(Chesbrough & Appleyard, 2007) (Van Aardt, 2006)
• Diensten en ondersteuning: Hier gaat het om ad hoc ondersteuning, diensten, opleiding
en adviescontracten. (451 Group, 2008) (Van Aardt, 2006)
• geïntegreerde hardware: Bedrijven die hardware verkopen kunnen er voor kiezen om
OSS software te distribueren samen met de hardware of met hardware producten die
verkocht worden met een commerciële licentie. (451 Group, 2008) (Van Aardt, 2006)
• Geïntegreerde software: OSS kan ook deel uitmaken van een groot commercieel
software pakket. (451 Group, 2008)
• Software-als-een-dienst: Software-als-een-dienst is een relatief nieuw concept en
betekent dat gebruikers betalen om toegang te hebben en de software te gebruiken via het
internet. (451 Group, 2008)
• Publiciteit: De software is gratis voor iedereen en wordt gefinancierd door bijgevoegde
reclame. (451 Group, 2008) (Van Aardt, 2006)
• Ontwikkeling op maat: Bedrijven kunnen ook voor klanten de software op maat
ontwikkelen om aan specifieke vereisten te voldoen. (451 Group, 2008)
• Andere producten en diensten: Het kan ook zijn dat bedrijven OSS niet gebruiken om
directe inkomstenstromen te genereren, maar het zijn dan complementaire producten die
voor de inkomsten zorgen. (451 Group, 2008) (Van Aardt, 2006)
Licentie strategieën
De licentie strategie heeft betrekking op de keuze van de licentie van het OS project en de
licenties die worden gebruikt voor het resulterende softwareproduct. (451 Group, 2008)
26
• Dubbele licentie: Dezelfde broncode bestaat onder verschillende licenties, meestal gaat
het om een OS licentie en een commerciële licentie. Een OSS bedrijf kan dit toepassen
wanneer het de eigenaar is van de intellectuele eigendomsrechten. De gebruiker kan een
commerciële gebruiker of een niet-commerciële gebruiker zijn. De commerciële
gebruiker heeft vaak liever een commerciële licentie omdat men liever niet gebruik maakt
van de GNU GPL licentie. (451 Group, 2008) (Van Aardt, 2006)
• OS licentie voor de kern: De basis broncode van het software product is vrij beschikbaar
onder een OS licentie, maar een bedrijfsversie of professionele versie bevat de broncode
van het open gedeelte en ook toevoegingen waarvan de broncode gesloten is en dus een
commerciële licentie heeft. (451 Group, 2008)
• Open en gesloten: De OSS wordt aangevuld met aparte eigendomssoftware producten die
apart worden ontwikkeld en verkocht met een commerciële licentie. (451 Group, 2008)
• OS licentie: De software kan ook gebaseerd zijn op alleen OSS. (451 Group, 2008)
• Samengevoegde OS: Een softwarebedrijf beperkt zich niet tot één OS project en kan dus
verschillende OSS samenvoegen die verschillende OS licentie hebben. (451 Group, 2008)
• Gesloten: Het product is gebaseerd op OSS maar is niet beschikbaar met een OS licentie.
(451 Group, 2008)
Ontwikkelingsstrategie
Niet elk OSS bedrijf zal op dezelfde manier afhangen of gebruik maken van een OS
gemeenschap. Wanneer men op basis van commerciële toevoegingen een inkomen wil genereren
zal men deze intern moeten ontwikkelen. (451 Group, 2008)
• Interne ontwikkeling: De software heeft een OS licentie, dus de gehele broncode is
toegankelijk voor het publiek, maar de ontwikkelingen worden hoofdzakelijk gedaan
door de werknemers van één bedrijf. (451 Group, 2008)
• Gemeenschap ontwikkeling: De software heeft een OS licentie en de ontwikkelingen
worden hoofdzakelijk gedaan door een gemeenschap van individuen of bedrijven. (451
Group, 2008)
• Combinatie van interne en gemeenschap ontwikkeling: Een product of dienst dat door een
OSS bedrijf wordt aangeboden kan gebaseerd zijn op een combinatie van OS projecten
27
die ontwikkeld worden door verschillende gemeenschappen van individuen of bedrijven.
(451 Group, 2008)
• Hybride ontwikkeling: Er kan een kruising zijn waarbij de software wordt ontwikkeld
zoals bij de voorgaande strategieën, maar een aantal functionaliteiten wordt ontwikkeld
door het OSS bedrijf en die is dan ook bedoeld voor commerciële doeleinden. (451
Group, 2008)
Commerciële OSS versus Gemeenschap OSS
In de literatuur vinden we ook een onderscheid tussen commerciële OSS en gemeenschap OSS.
Dat kan in verband worden gebracht met de ontwikkelingsstrategieën die in dit onderzoek
werden gedefinieerd. Dirk Riehle suggereert een alternatieve benaming voor commerciële OSS
om verwarring te vermijden, namelijk “single-vendor commercial open source”. Dit is dus
software die één bedrijf bezit en ontwikkelt. Volgens deze definitie is een commercieel OSS
bedrijf in het bezit van de legale rechten m.b.t. de software en bepaalt welke code wordt
opgenomen en welke niet. Volgens een rapport van Gartner zou tegen 2012 meer dan 50% van
alle inkomsten uit OSS afkomstig zijn van projecten die worden geleid door één bedrijf.
Voorbeelden zijn MySQL, SugarCRM, Jaspersoft en Alfresco. (Riehle, 2009)
De broncode van gemeenschap OSS is verkrijgbaar onder één enkele licentie en iedereen kan de
software gebruiken en er inkomsten van genereren. Voorbeelden hiervan zijn het Linux
besturingssysteem, de Apache webserver en de PostgreSQL database. Economisch belangrijke
OSS projecten worden in toenemende mate vertegenwoordigd door non-profit stichtingen zoals
de Apache Software Foundation. (Riehle, 2009)
De broncode van “single-vendor commercial open source” kan bestaan onder verschillende
licenties, afhankelijk van de noden van het bedrijf aangezien deze beschikt over de
eigendomsrechten. Frequent wordt de OS broncode voorzien van een licentie zoals de GNU GPL
en een andere versie wordt voorzien van een commerciële licentie. Volgens Dirk Riehle kunnen
ceteris paribus commerciële OSS bedrijven sneller met een superieur product naar de markt
gaan, aan een lagere operationele kost en kunnen ze makkelijker verkopen in vergelijking met
traditionele softwarebedrijven. (Riehle, 2009)
28
Er is een debat gaande rond de juiste definitie en termen die moeten worden gebruikt. Hier werd
er voor gekozen om gebruik te maken van de terminologie ‘interne ontwikkeling’ en
‘gemeenschap ontwikkeling’. Gemeenschap OSS en commerciële OSS is een veelgebruikte
alternatieve benaming. Andere benamingen die kunnen worden gevonden zijn: onafhankelijk en
afhankelijk, gemeenschap en gevangen, organisch en niet-organisch. Deze laatste benaming
verwijst naar het idee dat de ontwikkeling in een gemeenschap voortkomt uit een gemeenschap
die op natuurlijke wijze is ontstaan. De niet-organische OS gemeenschappen daarentegen zijn
gestructureerd rond gemeenschappen die worden gedomineerd door de werknemers van een
bepaald OSS bedrijf. (Riehle, 2009)
1.3.3 Invloed van de Licentie
De licentie van de software heeft duidelijk een impact op de ontwikkelingsstrategie die wordt
gekozen of die kan worden gekozen. Het OSS bedrijf kan niet altijd de licentie kiezen. Er zijn
veel OS projecten die werden opgestart door vrijwilligers. Wanneer een bedrijf op basis van een
bepaald OS project een inkomen wil genereren kan ze op basis van de licentie een
inkomstenstrategie kiezen die dan ook compatibel is met die licentie en de beste
inkomstenmogelijkheden biedt. Deze situatie heeft zich in het verleden frequent voorgedaan,
maar vandaag de dag is het meer waarschijnlijk dat de bedrijfsstrategie een invloed heeft op de
keuze van de OS licentie. (451 Group, 2008)
De wederkerige licentie wordt voornamelijk gebruikt wanneer het OSS bedrijf het meeste van de
OSS ontwikkelt. De wederkerige licentie zorgt er voor dat het moeilijk is voor concurrenten om
de broncode in eigendomssoftware om te zetten. (451 Group, 2008)
Wanneer de ontwikkelingen voornamelijk gebeuren door een gemeenschap van individuen of
bedrijven zal er eerder een toegeeflijke licentie worden gebruikt. (451 Group, 2008)
1.3.4 Invloed van de Licentiestrategie
De licentiestrategie die een OSS bedrijf toepast heeft hoofdzakelijk een impact op de mogelijke
inkomstenstrategieën die kunnen worden gebruikt. Wanneer er een OS licentie wordt gebruikt
voor de kern zullen in de meeste gevallen de inkomsten komen uit commerciële licenties. Bij een
enkele OS licentie of samengevoegde OS licenties zullen de inkomsten eerder voortkomen uit
abonnementen. Het gebruik van andere producten en diensten wordt voornamelijk gebruikt bij de
29
open en gesloten licentiestrategie. Voor de dubbele licentie worden voornamelijk abonnementen
en commerciële licenties gebruikt. (451 Group, 2008)
1.3.5 Invloed van de Ontwikkelingsstrategie
De ontwikkelingsstrategie van een bepaald OS project heeft een grote impact op de licentie- en
inkomstenstrategie die een OSS bedrijf kan gebruiken om zijn producten en diensten te
produceren. De ontwikkelingsstrategie heeft ook een invloed op de relatie tussen het OSS bedrijf
en de OS gemeenschap waarin deze actief is. (451 Group, 2008)
• Interne ontwikkeling: Als het OSS bedrijf in het bezit is van de intellectuele eigendom
van de software kan een dubbele licentie strategie worden gebruikt. Wanneer dit niet het
geval is kan ook OS licentiestrategie worden toegepast. (451 Group, 2008)
• Gemeenschap ontwikkeling: Wanneer de software van het OSS bedrijf voornamelijk door
een bepaalde gemeenschap wordt ontwikkeld is de keuze met betrekking tot de
licentiestrategie eerder beperkt, namelijk enkel een OS licentie of samengevoegde OS
licentie. (451 Group, 2008)
• Combinatie van interne en gemeenschap ontwikkeling: De samengevoegde OS licentie en
de gewone OS licentie kan worden gebruikt wanneer de ontwikkeling worden
gerealiseerd door een combinatie van een bedrijf en een gemeenschap. (451 Group, 2008)
• Hybride ontwikkeling: In dit model zijn een groter aantal licentiestrategieën mogelijk,
namelijk de gesloten, de open en gesloten licentie en de OS licentie voor de kern. (451
Group, 2008)
De impact van de ontwikkelingsstrategie kan als volgt worden samengevat:
• Interne ontwikkeling: In de meerderheid van de gevallen worden abonnementen gebruikt.
Daarnaast zijn ook de commerciële licenties, Software-als-een-dienst, ad hoc diensten en
ondersteuning een bron van inkomsten voor deze ontwikkelingsstrategie. (451 Group,
2008)
• Gemeenschap ontwikkeling: Opnieuw is het gebruik van abonnementen het meest
populair. Ad hoc diensten en ondersteuning worden ook in 1 van de 5 gevallen gebruikt.
Ontwikkeling op maat, publiciteit en ingesloten/geïntegreerde hardware wordt ook
gebruikt. (451 Group, 2008)
30
• Combinatie van interne en gemeenschap ontwikkeling: Er wordt voornamelijk gebruik
gemaakt van abonnementen en ingesloten/geïntegreerde hardware. (451 Group, 2008)
• Hybride ontwikkeling, het bedrijf levert de grootste bijdragen: Hier wordt er voor bijna
de helft van de gevallen gebruik gemaakt van de commerciële licentie. In 20% van de
gevallen wordt er gebruik gemaakt van abonnementen. (451 Group, 2008)
• Hybride ontwikkeling, de gemeenschap levert de grootste bijdragen: Er wordt gebruik
gemaakt van de abonnementen, commerciële licentie, ingesloten/geïntegreerde software
en hardware en publiciteit (451 Group, 2008)
• Hybride ontwikkeling, combinatie van een bedrijf en een gemeenschap: Het gebruik van
andere producten en diensten is de meest populaire inkomstenstrategie. Daarna zijn ook
de abonnementen en commerciële licenties een veelgebruikte strategie bij dit model van
ontwikkelen. (451 Group, 2008)
Hieruit kunnen we besluiten dat de meest gebruikte inkomstenstrategie deze van de
abonnementen en de commerciële licentie is. (451 Group, 2008)
De ontwikkelingsstrategie heeft ook een zeer belangrijke impact op de relaties met de
gemeenschap. Dit zal in een verder hoofdstuk meer uitgebreid worden besproken. (451 Group,
2008)
In dit eerste hoofdstuk heeft de lezer kennis kunnen maken met OSS en de IT-industrie. Op deze
manier heeft men achtergrondinformatie om de onderwerpen in de volgende hoofdstukken beter
in de juiste context te kunnen plaatsen. In het volgende hoofdstuk zal dieper worden ingegaan op
de praktijk van samenwerking tussen bedrijven, algemeen voor alle bedrijven en voor de IT-
industrie. Vanuit financieel standpunt is het belangrijk voor een bedrijf om de juiste strategie te
ontwikkelen met betrekking tot relaties tussen andere bedrijven. Deze relaties met andere
bedrijven worden steeds belangrijker doordat meer en meer bedrijven zich concentreren op hun
kernactiviteiten. Daarom is het van belang dat de randactiviteiten, die door andere bedrijven
worden uitgevoerd, effectief en efficiënt gerealiseerd worden.
31
2. Partnerships: Open Source en Niet-open Source Softwarebedrijven
2.1 Economische Ecosystemen en Software Ecosystemen
In 1993 introduceerde J.F. Moore het principe van business ecosysteem, naar analogie met
ecosystemen uit de natuur. Zowel in natuurlijke als sociale systemen kan men co-evolutie
herkennen d.i. een proces waarbij afhankelijke ‘soorten’ evolueren in een eindeloze wederkerige
cyclus. Succesvolle bedrijven zijn namelijk deze die snel en effectief evolueren. Innovatieve
bedrijven kunnen niet evolueren in een vacuüm, zij moeten allerhande middelen aantrekken en
coöperatieve netwerken creëren. J.F. Moore definieert een “Business Ecosystem” als “een
systeem waarin vaardigheden van bedrijven samen evolueren rond een nieuwe innovatie: ze
werken coöperatief en competitief om nieuwe producten te ondersteunen, klantenbehoeften te
bevredigen en uiteindelijk de volgende innovatie te incorporeren”. (Moore, 1993, p. 76)
De manier waarop organisaties software verwerven en verder ontwikkelen is sterk aan het
veranderen. (Farbey & Finkelstein, 1999) Rajala et al melden dat de samenwerking tussen
softwarebedrijven in verschillende bedrijfsnetwerken een stijgende trend is en op grote schaal
gebeurt. (Rajala, Rossi, & Tuunainen, 2003)
Volgens Lamber concurreren bedrijven niet langer als onafhankelijke entiteiten, maar doen ze
dat als “supply chains” of aanbod ketens. (Lambert & Cooper, 2000) Dit kan worden
doorgetrokken naar de software industrie. Bedrijven gaan zich meer concentreren op een
kernactiviteit en besteden niet-strategisch relevante activiteiten uit aan andere bedrijven. Op deze
manier ontstaan complexe “software supply networks”. (Jansen, Finkelstein, & Brinkkemper,
2007)
S. Jansen et al passen het concept van business ecosysteem toe op de software industrie. Ook zij
merken op dat softwarebedrijven zich meer en meer positioneren in een netwerk, zij zijn
namelijk afhankelijk van software leveranciers, VAR’s, klanten enz... Softwarebedrijven moeten
zich concentreren op 3 verschillende perspectieven of niveaus in het Software Ecosysteem
(SECO), namelijk het SECO niveau, het softwarenetwerk niveau en het niveau van het
softwarebedrijf. (Jansen, Finkelstein, & Binkkemper, 2009)
32
Software ecosysteem niveau
Een SECO kan worden gedefinieerd als een set van bedrijfsactiviteiten die functioneren als één
unit en integreren in een gedeelde markt voor software en diensten, inclusief de relaties tussen
die verschillende bedrijfsactiviteiten. (Jansen, Finkelstein, & Binkkemper, 2009)
Software aanbodnetwerk niveau
Een “Software Supply network” SSN kan dan ook worden omschreven als een keten verbonden
software, hardware en diensten organisaties die samenwerken om aan een bepaalde marktvraag
te voldoen. (Jansen, Finkelstein, & Binkkemper, 2009) (Jansen, Finkelstein, & Brinkkemper,
2007)
Niveau van het softwarebedrijf
Een softwarebedrijf is een organisatorische entiteit die software functionaliteiten ontwerpt,
maakt en uitbrengt binnen in een SECO. (Jansen, Finkelstein, & Binkkemper, 2009)
Het SSN is het niveau waarop partnerships worden gevormd. Er kunnen op dit niveau 3
verschillende uitdagingen worden herkend:
• Het instellen van relaties in een SSN: Methoden voor het aangaan van contracten met
partners en identificatie van de relatie is nodig om softwarebedrijven verder te assisteren
in het oprichten en verder ontwikkelen van hun eigen SSN. Het is dus belangrijk om
relaties met (potentiële) klanten en leveranciers actief te houden. Daarenboven moet ook
een beleid worden opgesteld m.b.t. hoe softwarebedrijven zichzelf introduceren
tegenover potentiële klanten en leveranciers in forums, bij evenementen, in het marketing
kanaal... (Jansen, Finkelstein, & Binkkemper, 2009)
• frequentie en timing tussen verschillende productlanceringen: Het is belangrijk om
als software ontwikkelaar steeds de nieuwste software zo snel mogelijk te hebben, zodat
de nieuwste mogelijkheden opnieuw kunnen worden gebruikt. Maar de eindgebruiker
moet tegelijkertijd beschikken over stabiele systemen met een doorzichtige “return on
investment” van upgrades. (Jansen, Finkelstein, & Binkkemper, 2009)
• Managen van de kwaliteit in het SSN: In het bijzonder is het belangrijk dat
bijvoorbeeld een plug-in van een bepaalde softwareapplicatie een voldoende hoge
33
kwaliteit heeft en dat deze kwaliteit wordt onderhouden. De tevredenheid van klanten
m.b.t. een bepaald software product of dienst is namelijk afhankelijk van de ervaring met
zowel het basis of hoofd product en de plug-in. (Jansen, Finkelstein, & Binkkemper,
2009)
2.2 Modellen van Coöperatie
Figuur 3: Conceptueel model van coöperatie in internationale strategische
distributiekanaal allianties
Bron: Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, Strategic alliances in international distribution channels,
2006, p. 1096
In het conceptueel model van coöperatie in internationale strategische distributiekanaal allianties
hebben drie karakteristieken van samenwerking een invloed op het niveau van samenwerking.
Dat heeft op zijn beurt een invloed op de prestatie van de alliantie en de tevredenheid van de
relatie. Dit model kunnen we vinden in de essay “Strategic alliances in international distribution
channels” van Meht et al en wordt bevestigd door een onderzoek bij een aantal bedrijven.
(Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006)
Prestaties
Tevredenheid van de kanaalleden
Leeroriëntatie
Intensiteit van de relatie
Levensduur van de relatie
+
+
+ Coöperatie
+
+
+
34
Leeroriëntatie
Partners moeten leren van elkaar om op die manier de kerncompetenties van elkaar over te
nemen zodat ze samen één gemeenschappelijk strategisch voordeel worden. Op deze manier
kunnen partners onderling van elkaar leren en ervaringen met elkaar delen. Dit verbetert de
kerncompetenties van de strategische alliantie en coöperatie tussen de verschillende partijen. De
leeroriëntatie wordt gemeten aan de hand van de waarde die een bedrijf hecht aan leren als een
voordeel op lange termijn. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006)
Levensduur van relatie
De levensduur van de relatie heeft zowel betrekking op de effectieve lengte van de relatie als de
verwachting dat de relatie zal verder worden gezet of het verlangen om de relatie verder te
zetten. Literatuur is het erover eens dat langdurige relaties meer voordelen bieden en
winstgevender zijn. Er is al bewezen dat hoe langer partners elkaar kennen en elkaar vertrouwen,
ze ook meer bereid zijn om veranderingen te aanvaarden. Dit geldt vooral voor industriële
markten omdat een partnership vaak hoge investeringen vereist en op die manier worden de
afhankelijkheden tussen partijen en de barrières om uit de relatie te stappen hoger. (Mehta, Polsa,
Mazur, Xiucheng, & Dubinsky, 2006)
Intensiteit van de relatie
In de context van exportkanalen kan intensiteit van de relatie worden gedefinieerd in termen van
verwantschap. Intensiteit kan ook worden benaderd in termen van continuïteit van de relatie. Een
andere bron definieert dit als de atmosfeer of klimaat van de relatie. De intensiteit van een relatie
tussen partners heeft dus ook een invloed op de samenwerking tussen koper en verkoper. (Mehta,
Polsa, Mazur, Xiucheng, & Dubinsky, 2006)
Prestaties
In dit model worden prestaties gedefinieerd als de mate waarin het gedrag van de internationale
distributiepartner bijdraagt tot de objectieven van de producent. (Mehta, Polsa, Mazur, Xiucheng,
& Dubinsky, 2006)
35
Tevredenheid van de kanaalleden
Traditioneel wordt tevredenheid van kanaalleden beschouwd als een bepalende factor die de
moraal van de kanaalleden en de motivatie om deel te nemen aan collectieve activiteiten
beïnvloedt. Zelfs wanneer een bedrijf de mogelijkheid heeft om macht uit te oefenen, zou dit op
een positieve manier moeten gebeuren ten voordele van de tevredenheid van kanaalleden.
(Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006)
Tevredenheid van kanaalleden kan worden gedefinieerd als een positieve gevoelstoestand die
voortkomt uit een beoordeling van alle aspecten van de relatie van een bedrijf met een ander
bedrijf. Hierbij zijn er twee aspecten van belang namelijk de economische en de niet-
economische psychosociale aspecten. De economische tevredenheid heeft te maken met de
perceptie van economische beloningen die resulteren uit de relatie met een partner zoals
verkoopsvolume en marges. Hier gaat het om het bereiken van bepaalde doelen en de
effectiviteit en productiviteit waarmee dit gebeurt. Niet-economische tevredenheid heeft
betrekking op de vraag of de uitwisseling met de partner op een bevredigende, aangename en
eenvoudige manier verloopt. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006) (Rajala,
Rossi, & Tuunainen, 2003)
Er kunnen vier onafhankelijke dimensies worden gedefinieerd die de grootste componenten zijn
van kanaaltevredenheid. De tevredenheid wordt gemeten door na te gaan wat de gevoelens zijn
met betrekking tot de kwaliteit van de volgende items:
• Administratie: geeft weer hoe toereikend de interacties tussen de distributeur en de
producent worden afgehandeld, hoofdzakelijk door middel van administratief personeel
van de producent. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006) (Schul, Little, &
Pride, 1985)
• Diensten ondersteuning: vaststellen hoe goed de producent de distributeur ondersteunt
met behulp van promotionele ondersteuning, bestuurlijk en hulp door verkoopsopleiding
en ideeën voor nieuwe diensten. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006)
(Schul, Little, & Pride, 1985)
• Beloningen: geeft de aantrekkelijkheid weer van de regeling voor zowel extrinsieke
beloningen (bv. winst en promotionele vergoedingen) als intrinsieke beloningen (bv.
36
status, imago en “verkoopsawards”) die worden gegeven door de producent aan de
distributeur (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006) (Schul, Little, & Pride,
1985)
• Vergoedingsbeleid van producent: beschrijft de gevoelens van de distributeur betreffende
de eerlijkheid van het programma ten opzichte van de distributeur en de procedures voor
de initiële kost of vergoeding van de relatie en de continue diensten vergoeding. (Mehta,
Polsa, Mazur, Xiucheng, & Dubinsky, 2006) (Schul, Little, & Pride, 1985)
In een aanbodketen of een aanbodnetwerk is het belangrijk om de relaties met bedrijven die
distributiefuncties uitoefenen op een goede manier te beheren. Het is dan ook waardevol om
goede samenwerking en vertrouwen te hebben binnen een aanbodnetwerk. Maar goede
samenwerking en vertrouwen is niet zo eenvoudig om te bekomen en te onderhouden. (Chopra &
Meindle, 2001) Zo kunnen we twee beschouwingen vinden om samenwerking en vertrouwen te
bekomen:
• “Deterrence-based view”: Hier gaat men ervan uit dat de verschillende partijen gebruik
maken van contracten om samenwerking te bewerkstelligen. Men veronderstelt dat door
deze contracten alle partijen elkaar op een eerlijke wijze behandelen, maar dan puur uit
zelfbehoud. (Chopra & Meindle, 2001)
• “Process-based view”: Hier zegt men dat samenwerking en vertrouwen iets is dat groeit
in de tijd als resultaat van een aantal interacties tussen de verschillende partijen. Positieve
interactie versterkt het vertrouwen in de andere partij en bewerkstelligt samenwerking.
(Chopra & Meindle, 2001)
In de praktijk sluiten beide theorieën elkaar niet uit. Het is namelijk zo dat in de meest effectieve
partnerships beide benaderingen worden toegepast. Partijen die nog maar juist samenwerken
zullen initieel sterk steunen op contracten, anderzijds zullen partijen die al enige tijd met elkaar
samenwerken nog steeds contracten afsluiten. Vanuit de aanbodketentheorie is het zo dat
wanneer partijen elkaars objectieven als die van zichzelf beschouwen, een optimale situatie is
bereikt. (Chopra & Meindle, 2001)
37
2.3 Software Partnerships
“In de IT-wereld kan een idee of product nog zo goed zijn, als je geen partners vindt, blijf je
letterlijk alleen staan” (de Goede, 2010, p 1) Dit kunnen we lezen in een artikel van Paul de
Goede, de kanaalmanager van Juniper Benelux. Voor IT producten is ook integratie met andere
producten en systemen van vitaal belang en een goede reden om aandacht te besteden aan een
goede partnerstrategie. (de Goede, 2010)
Paul de Goede wijst hier op drie terreinen waarop een leverancier een partner kan helpen:
1. Financiën: De leverancier moet er voor zorgen dat de relatie voor de partner
financieel aantrekkelijk is, bijvoorbeeld door aantrekkelijke marges aan te bieden. (de
Goede, 2010)
2. Producten (en diensten): De partner moet met behulp van betrouwbare producten van
de leverancier de mogelijkheid hebben om in te spelen op de behoeften in de markt.
(de Goede, 2010)
3. Support: een partner moet maximaal worden ondersteund bij zowel de presales, sales
en postsales. (de Goede, 2010)
Wanneer bedrijven nieuwe markten willen veroveren zijn een aantal strategische beslissingen
met betrekking tot partnerships van vitaal belang om succes te behalen. Er moet worden beslist
welke activiteiten in de nieuwe markten zullen worden gedaan, welke van deze activiteiten de
verantwoordelijkheid zullen zijn van een partner en welke activiteiten intern zullen worden
gedaan. Omdat partners zowel kansen als de markt moeten identificeren is het kiezen van het
juiste partnerkanaal de sleutel tot een succesvolle internationalisering. Het partnerkanaal voorziet
ook in de koppeling tussen de klant en het bedrijf en is dus een belangrijke link met alle andere
componenten van de marketing mix. De marketing mix is de strategie met betrekking tot “de vier
p’s”: product, prijs, promotie en plaats. Het is niet evident om het partnerkanaal, de plaats, te
veranderen dan andere aspecten van de marketing mix, vandaar dat het belangrijk is om dit op
een zorgzame manier te plannen. (McNaughton, 1996)
Op de populaire blog, thevarguy.com, over het IT-kanaal worden aan de hand van een onderzoek
een aantal uitspraken gedaan. De blog rapporteert ook over ontwikkelingen rond OSS en partner
programma’s. Zij zien dat in een eerste stadium vele starters rond OSS eerder onafhankelijk van
38
resellers opereerden. Maar om verder te kunnen groeien, hebben deze bedrijven nood aan
partners om globale distributie en ondersteuning te garanderen. Een trend hierin is dat deze
partnerprogramma’s mondiaal zijn en niet regionaal of landspecifiek. (The VAR Guy, 2009)
Naar aanleiding van deze informatie kan worden besloten dat vele OSS bedrijven geconfronteerd
worden met het oprichten van een internationaal partnernetwerk om producten te distribueren.
2.3.1 Soorten Partnerships
Wanneer we de verschillende partnerprogramma’s bekijken van verschillende softwarebedrijven,
inclusief OSS bedrijven, zien we verschillende categorieën opduiken. Een aantal onder hen
hebben reeds een algemeen aanvaarde benaming en definitie.
System integrator
System integrators zijn bedrijven die de klant helpen om een (gedeelte van een) IT-infrastructuur
op te zetten door verschillende componenten te combineren tot een geïntegreerd systeem.
Doordat de complexiteit van technologie is toegenomen hebben meer klanten nood aan complete
oplossingen. De verschillende software en hardware van een systeem moet goed geïntegreerd
zijn met het gehele IT netwerk. System integrators zijn vaak neutraal m.b.t. verschillende
producten en hanteren een algemene aanpak t.o.v. IT. Het kan zijn dat een SI ook software
ontwikkelt voor een specifieke klant en in dat opzicht kunnen ze soms ook als ISV worden
beschouwd. (Pcmag, 2010f) (Shavit, 2007)
Onafhankelijke softwareverkoper (Independent Software Vendor)
Dit zijn bedrijven die zich bezighouden met het maken en verkopen van software producten die
bruikbaar zijn op één of meer computer hardware besturingssysteem platforms. Het is zo dat
wanneer er meerdere applicaties of softwareproducten beschikbaar zijn voor een bepaald
besturingssysteem, dit extra waarde biedt voor een bedrijf dat een besturingssysteem verkoopt.
Het is onmogelijk voor dit bedrijf om alle applicaties die nodig zijn voor de gebruiker te
ontwikkelen, vandaar dat men gebruik maakt van ISV’s. Een andere reden waarom ISV’s van
belang zijn is dat zij zich vaak specialiseren in een specifiek domein zoals gezondheidszorg,
39
industrie,.... Ook hier kunnen we vermelden dat ISV’s ook als system integrators kunnen worden
beschouwd wanneer ze hun klanten diensten voorzien bij het opstellen van een IT systeem.
(Shavit, 2007) (Pcmag, 2010a) (Lehto, 2007)
Original equipment manufacturer OEM
Dit is een term die naar twee mogelijke categorieën kan verwijzen die in essentie het
tegengestelde zijn van elkaar. In de oorspronkelijke betekenis van het woord bedoelt men een
bedrijf dat uitrusting levert aan andere bedrijven om deze dan verder te verkopen of te integreren
in een ander product, waarbij men dan de merknaam gebruikte van het andere bedrijf dat het
product uiteindelijk verkoopt aan de eindconsument. Een ander meer recente gebruik van dit
woord is voor een bedrijf dat producten en componenten koopt en deze hergebruikt of
incorporeert in een nieuw product onder de naam van de OEM. (TechTarget, 2008a) (Pcmag,
2010c) (Shavit, 2007)
Value Added Reseller (VAR)
Een VAR is een bedrijf dat aan bestaande producten waarde toevoegt door ze te bundelen.
Doordat de kost van hardware en software gedaald is, dalen ook de marges en trachten vele
VAR’s hun bedrijfsmodel uit te breiden met meer winstgevende activiteiten. Meer bepaald het
beheren van diensten, zoals de Managed Service Providers. (Pcmag, 2010d) (Pcmag, 2010g)
(TechTarget, 2008b) (Shavit, 2007)
Managed service providers (MSP)
Dit is een organisatie die “managed services” of beheersdiensten biedt. Een managed service
provider kan de computer systemen en netwerken van de klant beheren die zich ofwel bevinden
bij de klant zelf of in een datacenter van een derde partij. Op deze manier voorziet de MSP in het
controleren en onderhouden van de IT uitrusting. Een MSP kan verschillende dienstenniveaus
aanbieden beginnende bij het melden van problemen tot het repareren van defecten. Sommigen
beschouwen een echte MSP als een organisatie die op een proactieve manier omgaat met
40
onderhoud, namelijk niet wachten tot de klant of gebruiker een probleem meldt, maar het
systeem van de klant monitoren en meteen stappen ondernemen wanneer een probleem zich
manifesteert. (Shavit, 2007) (Pcmag, 2010b)
Solution Provider
Een Solution Provider is een bedrijf dat oplossing biedt aan andere bedrijven. Het gaat hier om
softwarebedrijven, een dienstenleverancier of een VAR die op een allesomvattende manier een
klant bijstaat vanaf probleemdefinitie tot installatie en dan verder met support/ondersteuning. De
solution provider zal normaal eerst een analyse maken van de huidige infrastructuur van de klant,
hij maakt een evaluatie van wat de klant nodig heeft, stelt de hardware en software samen die
nodig is om deze benodigdheden te leveren en installeert deze hardware en software bij de klant.
Vaak voorziet deze solution provider in een continue stroom van diensten en ondersteuning.
(Pcmag, 2010e)
De voorgaande classificaties zijn vaak terug te vinden in partnerprogramma’s van
softwarebedrijven die via een IT channel producten verkopen. We moeten wel opmerken dat er
vaak overlapping is of abstractie van deze categorieën. Soms zal men de Value Added Reseller
afkorten tot reseller. Een solution provider is in de eerste plaats ook een reseller, maar voorziet in
nog meer diensten zoals ondersteuning, integratie, op maat maken van software,...
2.4 De Open Source Gemeenschap
”Het is meer gebruikelijk voor bedrijven om strategische allianties te vormen met
gemeenschappen van OS ontwikkelaars. De gemeenschap ontwikkelt het product en reduceert
dus de kostenlast voor de bedrijven”. (Feller, Fitzgerald, Hissam, & Lakhani, 2005, p. 280) Voor
bedrijven is de gemeenschap dus zeer belangrijk. Daarom is de vraag “waarom zouden software
ontwikkelaars mee willen helpen aan de broncode van een bepaald bedrijf?” een belangrijk
aandachtspunt voor bedrijven die via de OS gemeenschappen hun software willen ontwikkelen.
(Fogel, 2005) (Hecker, 1999)
Eerst beantwoorden we de vraag waarom een individu in zijn vrije tijd en zonder financiële
vergoeding tijd zou willen besteden aan het schrijven van broncode voor een
41
softwareprogramma. In de groep van OS programmeurs kunnen 2 groepen worden
onderscheiden. De eerste groep zijn mensen waarvoor het schrijven van software een hobby is.
Na het werk en in het weekend spenderen zij tijd aan het meewerken aan een
softwareprogramma. De bijdrage van deze groep is wel eerder beperkt. De enorme omvang van
de resultaten verworven binnen de OS wereld kan voor een groot deel aan een tweede groep
worden toegewezen. Dit is de groep die wordt gevormd door mensen van de hackercultuur. Deze
programmeurs besteden een aanzienlijke hoeveelheid tijd en kennis in OS gemeenschappen.
Waarom doen zij dit? (Bonaccorsi & Rossi, 2003)
Eerst en vooral beschouwen ze hun inspanningen en werk als een vorm van intellectuele
voldoening die kan worden vergeleken met dat van een wetenschappelijke ontdekking. Andere
leden kunnen de broncode lezen en geven feedback ter verbetering van de broncode.
Tegelijkertijd zijn de resultaten zichtbaar voor iedereen en voorziet dat in een vorm van prestige
of aanzien in de gemeenschap voor de programmeur in kwestie. Ten tweede beschouwen hackers
programmeren als een vorm van kunst. Sommigen omschrijven dit dan ook als een artistieke
bevrediging, die kan geassocieerd worden met het oplossen van complexe computerproblemen.
Sommigen herontdekken in deze informele werkvorm van programmeren het plezier van
creativiteit die in de commerciële wereld verloren is gegaan. De redenen zijn dus eerder
technisch en niet ideologisch. Daarenboven voorziet prestige en zichtbaarheid de kans voor
programmeurs om te worden opgemerkt door softwarebedrijven. Als laatste zien we dat nieuwe
OS projecten vaak worden opgericht vanuit een tekort dat wordt ervaren. Als men tevergeefs
zoekt naar software die bepaalde functies kan uitoefenen kan een programmeur zelf beslissen om
een programma te schrijven en op zoek te gaan naar andere programmeurs voor hulp hierbij.
(Bonaccorsi & Rossi, 2003)
Zoals eerder gezegd is een goede OS licentie, goedgekeurd door OSI, een eerste garantie voor
een vrijwilliger in de OS gemeenschap dat hij/zij eerlijk zal worden behandeld. Daarnaast moet
een bedrijf de leden van een OS gemeenschap eerlijk en fair behandelen, naast de formele regels
uitgestippeld in een licentie. De licentie kan worden beschouwd als een formeel contract tussen
gebruikers van de OSS. Gebruikers moeten elkaar ook eerlijk behandelen en dat kan worden
beschouwd als een informele afspraak. (Bonaccorsi & Rossi, 2003)
42
Aan de hand van een onderzoek in 2008 bij 4 verschillende OSS bedrijven hebben L. Dahlander
en M. Magnusson een aantal belangrijke uitdagingen en aandachtspunten kunnen herkennen voor
bedrijven die willen gebruik maken van OS gemeenschappen. Gezien de vele mislukte pogingen
van bedrijven om een OS gemeenschap op te bouwen die de basis vormt van een commercieel
haalbare handel is het duidelijk dat het niet evident is om een duurzame relatie met zo’n
gemeenschap op te bouwen. Zij hebben op deze manier drie verschillende belangrijke
activiteiten kunnen aanduiden als een eerste stap om succes te bereiken. (Dahlander &
Magnusson, 2008)
1. Gebruik maken van OS gemeenschappen om de middelen basis uit te breiden
Bedrijven kunnen dit op twee manieren doen. Ten eerste bestaat er de mogelijkheid om een
nieuwe gemeenschap op te richten en extern mensen aan te trekken om mee te helpen. Ten
tweede kan men broncode van bestaande gemeenschappen identificeren en gebruiken.
(Dahlander & Magnusson, 2008)
Wanneer men een nieuwe gemeenschap wil gaan oprichten is het vaak een uitdaging om een
voldoende grote groep medewerkers/vrijwilligers bij elkaar te krijgen. Aan deze keuze is ook een
grote initiële kost verbonden aangezien bedrijven eerst een deel van de broncode zelf moeten
schrijven. Daarnaast moeten mensen binnen het bedrijf ook tijd besteden aan het samenwerken
met de gemeenschap om verdere ontwikkeling te stimuleren. Tegelijkertijd kan deze strategie
wel een goede marketing tool zijn om merkherkenning te verhogen. (Dahlander & Magnusson,
2008)
MySQL is een bedrijf dat deze strategie heeft toegepast en een sterke positie in de markt heeft
veroverd. Zij hebben zich initieel geprofileerd in een nichemarkt want in een gevestigde
massamarkt zou de competitie te groot zijn. Nadat MySQL zich in deze nichemarkt als
hoofdspeler kon vestigen konden ze hun markt omzetten in één die veel groter is geworden.
Producten van MySQL zijn voldoende op maat gemaakt om een grote groep klanten aan te
trekken. De mogelijkheid voor MySQL om software op maat te ontwikkelen komt doordat zij
gebruik kunnen maken van een grote gebruikersgemeenschap. (Dahlander & Magnusson, 2008)
Een bedrijf kan er ook voor kiezen om een bestaande gemeenschap te zoeken en verder te
bouwen op bestaande OSS. Deze strategie zou een grotere flexibiliteit bieden omdat men dan
43
niet gebonden is aan één bepaalde gemeenschap of software. Een ander voordeel is dat er reeds
een voldoende aantal leden aanwezig zijn in de gemeenschap. Daartegenover staat dat een bedrijf
beperkte invloed kan uitoefenen op de verdere ontwikkeling van de software t.o.v. de eerste
strategie. Het is ook niet eenvoudig om vast te stellen welke gemeenschap of software een
strategisch voordeel kan bieden. (Dahlander & Magnusson, 2008)
2. De strategie van het bedrijf op één lijn brengen van dat van de gemeenschap
Dit is een belangrijk punt gezien de 2 verschillende partijen, bedrijf en vrijwilliger, gedreven
worden door verschillende motieven. Het is dan ook belangrijk dat een bedrijf ondubbelzinnige
licentiepraktijken toepast die duidelijkheid bieden over de eigendomsrechten. Het gaat hier om
procedures omtrent auteursrechten voor de software van het bedrijf en de broncode die werd
ontwikkeld door vrijwilligers van de gemeenschap. (Dahlander & Magnusson, 2008)
Ook kunnen bedrijven een tactiek uitwerken om de ontwikkelingen in de gemeenschap te
beïnvloeden. Bedrijven in het onderzoek maakten gebruik van subtielere methoden om
gemeenschappen in een bepaalde richting te sturen. Er is de mogelijkheid om belangrijke
individuen in de gemeenschap extra voordelen aan te bieden. Deze voordelen kunnen financieel
zijn, extraatjes voor bepaalde taken of een salaris om een leidinggevende rol in de gemeenschap
aan te nemen. Bedrijven geven wel aan dat het gebruik van dergelijke methode aan risico’s
onderhevig is, maar deze risico’s zouden kleiner zijn dan de baten. (Dahlander & Magnusson,
2008)
Hierbij kan worden vermeld dat bedrijven worden geconfronteerd met het feit dat de meeste
individuen in een OS gemeenschap vooral geïnteresseerd zijn in een intellectuele uitdaging. Bij
het ontwikkelen van een software product of dienst kunnen twee taken worden onderscheiden.
Enerzijds is er het schrijven van nieuwe oplossingen en anderzijds zijn er ook ‘routine’ taken
zoals testen en het zoeken naar programmeerfouten (bugs). Dit zijn intellectueel minder
uitdagende taken en is dus minder “populair” bij vrijwilligers. Een bedrijf dat er in slaagde een
kostenefficiënte opzet te creëren is MySQL. Zij deden vele van de noodzakelijke routinetaken
intern en gaven dan voor de gemeenschap nieuwe versies snel ter beschikking zodat
ontwikkelaars aan nieuwe dingen konden werken. Voor andere bedrijven werd de kost voor het
uitoefenen van invloed te groot en is men moeten overgaan naar een ander bedrijfsmodel.
(Dahlander & Magnusson, 2008)
44
3. Resultaten integreren en delen
De code ontwikkeld in de gemeenschap kan niet zomaar direct door een bedrijf worden
opgenomen. Naast de eerste twee aandachtspunten moet een OSS bedrijf deze code in één lijn
brengen met de eigen commerciële producten. Hiervoor identificeert men twee mogelijke
tactieken. (Dahlander & Magnusson, 2008)
Eerst en vooral moet men middelen toewijzen aan het evalueren en selecteren van broncode
gegenereerd door de gemeenschap. Uit het onderzoek blijkt dat dit een tijdsintensieve en niet-
evidente taak kan zijn. (Dahlander & Magnusson, 2008)
Ten tweede kan men niet-strategische code die door het bedrijf zelf werd ontwikkeld aan de
gemeenschap ‘geven’. Op deze manier wordt vertrouwen gecreëerd binnen de gemeenschap
jegens het OSS bedrijf. Een nadeel is dat op deze manier concurrenten indirect informatie
kunnen vergaren over ontwikkelingen binnenin het bedrijf. Het is ook zo dat de licentie van OSS
vaak niet de keuze laat om code al dan niet vrij te geven. (Dahlander & Magnusson, 2008)
Opnieuw kunnen we hier benadrukken dat OS een nuttige bron kan zijn van broncode en
software ontwikkelingsmogelijkheden. Tegelijk worden bedrijven geconfronteerd met nieuwe
uitdagingen die gepaard gaan met deze vorm van innovatie. (Dahlander & Magnusson, 2008)
In dit hoofdstuk heeft de lezer kunnen kennismaken met theorieën over samenwerking tussen
bedrijven. Het is ook duidelijk dat samenwerking tussen bedrijf in toenemende mate belangrijk
wordt, ook voor de IT-industrie. In deze masterproef is het de bedoeling om de uitdagingen die
er zijn voor OSS bedrijven met betrekking tot samenwerking met andere bedrijven te
onderzoeken. Specifiek gaat het hier om de samenwerking tussen bedrijven met als doel het
product, in dit geval de software, tot bij de eindklant te brengen. Een voorbeeld van de impact
dat het werken met OSS heeft op samenwerking met anderen is de relatie tussen een OSS bedrijf
en de OS gemeenschap. Deze theorieën en dit voorbeeld zijn belangrijk als inleiding voor het
onderzoek dat werd uitgevoerd en verder zal worden besproken. Literatuur met betrekking tot
samenwerking bij softwarebedrijven is eerder beperkt en te algemeen. Vandaar dat er ook wordt
overgegaan tot kwalitatief onderzoek.
45
3. Onderzoeksvraag en Methodologie
3.1 Onderzoeksvraag
De onderzoeksvraag van deze masterproef is “hoe werken de partnermodellen van OSS
bedrijven?”.
Het is de bedoeling om na te gaan wat de invloed is van OS op:
• Partnerprogramma’s en partnerrelaties
• Resellers
• OSS bedrijven en hun partnerkanalen
Om het antwoord hierop te vinden wordt de onderzoeksvraag opgedeeld in een aantal meer
specifieke onderzoeksvragen:
• 1.1 Hoe zijn partnerprogramma’s van OSS bedrijven opgesteld?
• 1.2 Zijn deze partnerprogramma’s van OSS bedrijven verschillend met de
partnerprogramma’s van eigendomssoftware bedrijven?
• 2.1 Waarom willen resellers OSS verkopen?
• 2.2 Hoe heeft OS een invloed op de wijze waarop resellers te werk gaan?
• 3.1 Welke financiële stromen zijn er tussen de OSS bedrijven en resellers?
• 3.2 Hoe werken de OSS bedrijven samen met resellers?
3.2 Methodologie
De vragen 1.1 en 1.2 worden beantwoord aan de hand van een analyse van de
partnerprogramma’s van OSS bedrijven. Sommige van deze partnerprogramma’s zijn te vinden
op de website van softwarebedrijven. Het is de bedoeling om te weten hoe deze
partnerprogramma’s werken en dus na te gaan wat de belangrijke elementen zijn. Dit zal worden
gedaan aan de hand van “unobtrusive measures”, dat kan worden vertaald als “discrete
metingen”. Dat zijn bestaande materialen en gegevens die niet werden gecreëerd voor het
onderzoek en ze zijn ideaal voor kwalitatief onderzoek. (Baarda, de Goede, & Teunissen, 2005)
46
Om op de vragen 2.1 en 2.2 te antwoorden werden drie interviews afgenomen bij resellers van
JBoss. Als laatste werd er ook een interview afgenomen bij Red Hat, het bedrijf dat RHEL2 (Red
Hat Enterprise Linux) en JBoss verkoopt. Eerst en vooral wordt elk interview apart besproken
m.a.w. van elk interview wordt een verticale analyse gedaan. Daarna zal binnen een horizontale
analyse worden gezocht naar overeenkomsten tussen de verschillende interviews.
3.2.1 Selectie van de Cases
De analyse van de partnerprogramma’s van OSS bedrijven is op basis van een meervoudige
casestudy van acht gelijksoortige cases. (Baarda, de Goede, & Teunissen, 2005) Er zijn een
aantal redenen waarom er voor acht casestudies werd gekozen.
• Slechts een beperkt aantal bedrijven geeft informatie over hun partnerprogramma op hun
website.
• Niet alle informatie over de partnerprogramma’s is even gedetailleerd.
• Elk partnerprogramma is anders waardoor het te complex zou worden bij een analyse van
een groter aantal cases.
• De selectie van cases is op basis van een lijst van OSS bedrijven met een sterk
uitgebouwd partnerkanaal.
Deze 8 bedrijven zijn gekozen uit een lijst van 50 verschillende OSS bedrijven die de basis was
voor een onderzoek uitgevoerd door de ‘The Var Guy’. Thevarguy.com is een populaire blog
over het IT kanaal en wordt gepubliceerd door Nine Lives Media Inc. De blog rapporteert
ondermeer ook over ontwikkelingen rond OSS en partnerprogramma’s. De bedoeling van dit
onderzoek was een classificatie op te stellen op basis van de volgende variabelen:
• Gehele omvang van partner ecosysteem
• Jaarlijkse groei van partnernetwerk
• Jaarlijks groeipercentage van partnernetwerk
• Percentage van totale inkomsten afkomstig van partners
• Intern aantal werknemers per partner
• Eigen ervaring
2 Dat is de bedrijfsversie van de OSS Linux geproduceerd door Red Hat.
47
Er werd uiteindelijk een top 25 opgesteld van de belangrijkste OSS bedrijven met een stabiel
partnerkanaal (op basis van voorgaande criteria). De andere 25 OSS bedrijven werden
geïdentificeerd als OSS bedrijven met potentieel om een goed partnerkanaal op te bouwen. Het
was niet mogelijk om voldoende data te vinden over het partnerkanaal van deze 25 OSS
bedrijven. Deze top 25 werd opgesteld op basis van een online onderzoek bij de OSS bedrijven
zelf en partners. Uit deze top 25 werden 6 bedrijven gekozen:
• Red Hat Inc. (nummer 1)
• Sun Microsystems met MySQL (nummer 2)
• Digium (nummer 4)
• SugarCRM Inc. (nummer 11)
• Alfresco (nummer 12)
• Pentaho (nummer 13)
Een laatste bedrijf is Acquia dat in de lijst van potentiële OSS bedrijven staat. Red Hat heeft in
2004 het bedrijf JBoss overgenomen dat een middleware product verkoopt. Red Hat biedt aan
resellers twee verschillende producten waarvan het partnerprogramma licht van elkaar verschilt,
zoals we verder zullen zien.
Door gebruik te maken van dit uitgebreid onderzoek werd getracht om er voor te zorgen dat de
bedrijven die hier als onderwerp worden behandel voor een grotere betrouwbaarheid van het
onderzoek zorgen. Zij werden niet op toevallige wijze gekozen maar uit een lijst van OSS
bedrijven die reeds hebben bewezen dat ze een economisch leefbaar bedrijf en partnerkanaal
hebben uitgebouwd.
De vergelijking tussen deze OSS partnerprogramma’s en de partnerprogramma’s van
eigendomssoftware bedrijven is minder evident. Op basis van de top 100 lijst van de grootste
softwarebedrijven werden drie bedrijven gekozen om te vergelijken met de analyse die wordt
gemaakt van de OSS partnerprogramma’s. (Software Top 100, 2009) Deze softwarebedrijven
zijn:
• Microsoft (nummer 1)
• IBM (nummer 2)
48
• Oracle (nummer 3)
3.2.2 Geldigheid en betrouwbaarheid
De geldigheid van een kwalitatief onderzoek heeft te maken met de juistheid van de
onderzoeksbevindingen. Er kan een onderscheid worden gemaakt tussen de interne geldigheid en
de externe geldigheid. De interne geldigheid is afhankelijk van het onderzoeksopzet, dat is de
mate waarin het onderzoeksopzet een geldig antwoord kan vinden op de onderzoeksvraag. De
externe geldigheid is de mogelijkheid om de resultaten van het onderzoek toe te passen op
vergelijkbare situaties. Gegevens zijn betrouwbaar wanneer ze niet afhankelijk zijn van
toevallige factoren. Wanneer men in een ander onderzoek op een later tijdstip dezelfde gegevens
verzameld en de resultaten zijn dezelfde dan kan men spreken van betrouwbare gegevens.
(Baarda, de Goede, & Teunissen, 2005)
Er moet dus worden opgemerkt dat de interne geldigheid beperkt is. De vergelijkingsbasis is
namelijk niet erg sterk. Microsoft, IBM en Oracle zijn bedrijven die al lange tijd bestaan, grote
bedrijven zijn en zeer veel verschillende software en hardware aanbieden. De OSS bedrijven
echter bestaan nog niet zo lang, de inkomstenstroom is klein in vergelijking met de andere
eigendomssoftware bedrijven en er wordt eerder een beperkte hoeveelheid softwarepakketten
aangeboden. Daarom zal er, naast een bespreking van de partnerprogramma’s van deze drie
softwarebedrijven, ook een meer gedetailleerde case study zijn tussen SugarCRM en
Salesforce.com. Beide bedrijven verkopen “Customer Relationship Management” applicaties en
er is een gedetailleerde beschrijving van de partnerprogramma’s beschikbaar.
Er wordt in de analyse van de OSS partnerprogramma’s gebruik gemaakt van MySQL van Sun
Microsystems. Op 27 januari 2010 werd Sun Microsystems overgenomen door Oracle.(Oracle,
2010a) De invloed van deze overname voor MySQL is niet meteen duidelijk, maar Oracle heeft
wel de intentie om meer geld te investeren in MySQL.(Oracle, 2010b) Deze overname is echter
minder dan vier maanden geleden gebeurd en Oracle zal nog niet alle hervormingen hebben
doorgevoerd die het wil en gaat uitvoeren.
In deze masterproef worden de partnerships tussen resellers en softwarebedrijven besproken en
dus niet Original Equipment Manufacturers of Independent Software Vendors.
49
De keuzemogelijkheden voor interviews waren eerder beperkt tot resellers die in België een
afdeling hebben, resellers die ook OSS en eigendomssoftware verkopen en resellers die bereid
waren om mee te werken aan dit onderzoek. Na een uitgebreid aantal telefonische contacten
hebben drie resellers, die geregistreerd waren als partner op de website van Red Hat, toegezegd
tot een interview. Op deze manier werd het onderzoeksveld beperkt tot één OSS. Het gevolg
hiervan is dat er beperkingen zijn met betrekking tot de geldigheid van dit onderzoek, meer
bepaald de externe geldigheid. De resultaten van een onderzoek zijn slechts geldig voor een
andere case wanneer deze case gelijkaardig is aan de cases die werden gebruikt in dat onderzoek.
De impact van het soort software is niet meteen gekend en daarom is het niet mogelijk om de
resultaten van het onderzoek te veralgemenen zonder te vermelden dat dit een beperkende factor
kan zijn. (Baarda, de Goede, & Teunissen, 2005)
Doordat het mogelijk was om bij de kanaalmanager van het desbetreffende bedrijf, Red Hat, een
interview af te nemen werd een grotere interne geldigheid en goede consistentie ingebouwd in
het onderzoek.
3.2.3 Zwakten en sterkten van de gebruikte methodologie
Aan het gebruik van bestaande materialen en gegevens voor kwalitatief onderzoek zijn een
aantal voor- en nadelen verbonden:
Nadelen
• Het is geen directe bron van informatie. (Baarda, de Goede, & Teunissen, 2005)
• Doordat de onderzoeker een interpretatie van de gegevens maakt, bestaat het gevaar dat
vanuit het perspectief van de onderzoeker eigen betekenissen worden gecreëerd. (Baarda,
de Goede, & Teunissen, 2005)
• De context waarin het materiaal is gecreëerd ontbreekt vaak. (Baarda, de Goede, &
Teunissen, 2005)
• Het kan zijn dat de informatie gecensureerd of gekleurd is of dat een deel ervan
verdwenen is. (Baarda, de Goede, & Teunissen, 2005)
• Er is gevaar voor elite-vertekening: veel materialen zijn vaak afkomstig van de
bovenlagen van de samenleving. (Baarda, de Goede, & Teunissen, 2005)
50
In dit onderzoek zijn een aantal van deze nadelen aanwezig. Zo gaat het hier om een indirecte
bron van informatie. De resultaten van het onderzoek zullen ook in bepaalde mate afhankelijk
zijn van de interpretatie van de gegevens. Elk partnerprogramma is anders, er zijn elementen die
vaak terugkomen, maar er zijn ook veel verschillen zoals verder zal worden aangetoond. Het zou
ook kunnen dat de gegevens gecensureerd zijn. Een bedrijf moet namelijk een lijst van voordelen
en vereisten opstellen die een partner kan verkrijgen. Het zou kunnen dat de informatie over deze
partnerprogramma’s rooskleuriger wordt voorgesteld om op die manier meer partners te kunnen
overtuigen. Het zou ook kunnen dat bedrijven sommige informatie achterhouden omdat deze van
confidentiële aard is.
Voordelen
• De onderzoekssituatie wordt niet verstoord. (Baarda, de Goede, & Teunissen, 2005)
• Betere toegankelijkheid, je moet geen toestemming vragen om het bestaande materiaal te
verkrijgen. (Baarda, de Goede, & Teunissen, 2005)
• Minder ethische problemen. (Baarda, de Goede, & Teunissen, 2005)
• Hogere betrouwbaarheid en geldigheid door non-reactiviteit. Reactiviteit wil zeggen dat
mensen zich anders gaan gedragen wanneer ze weten dat ze in een onderzoek zijn
betrokken. (Baarda, de Goede, & Teunissen, 2005)
• Sneller en goedkoper. (Baarda, de Goede, & Teunissen, 2005)
• Meervoudige bruikbaarheid en analyseerbaarheid. Er is de mogelijkheid om bestaand
materiaal verschillende keren vanuit een andere invalshoek te bekijken. (Baarda, de
Goede, & Teunissen, 2005)
Met betrekking tot de betrouwbaarheid en geldigheid van de analyse van bestaande gegevens
kunnen een aantal dingen worden vastgesteld. De kwaliteit van gegevens die niet specifiek zijn
voor een bepaald onderzoek is in regel beter dan gegevens die wel specifiek voor een onderzoek
zijn. Maar het nadeel van deze informatie is dat ze werd gecreëerd binnen een bepaalde context
en met een bepaald doel. Daarom kan het zijn dat de betrouwbaarheid van deze gegevens eerder
beperkt is en moet worden gezien binnen een bepaalde context.
De partnerprogramma’s zijn publieke documenten en zijn geschreven voor een bepaalde
doelgroep of specifiek lezerspubliek en zijn dus opgesteld met een bepaald doel. De doelgroep
51
hier zijn mogelijke resellers en deze documenten zijn opgesteld met het doel om resellers te
informeren over hoe binnen dat specifiek OSS bedrijf wordt samengewerkt met partners. Soms
worden publieke documenten ook geschreven om het gedrag van mensen te beïnvloeden en
wordt dus sommige informatie bewust weggelaten of toegevoegd.
Voor het vervolg van het onderzoek wordt er gebruik gemaakt van interviews om een antwoord
te vinden op de opgestelde onderzoeksvraag. Meer bepaald vier interviews waarvan drie bij
resellers en één interview bij een OSS bedrijf. Deze resellers verkopen alle drie één bepaald OSS
pakket (JBoss) en het OSS bedrijf (Red Hat) dat werd geïnterviewd is verantwoordelijk voor de
commerciële toepassing van dit OSS pakket. Er zijn een aantal gevolgen verbonden aan het
gebruiken van interviews voor onderzoek (Baarda, de Goede, & Teunissen, 2005):
• Het is een flexibele methode om informatie te verzamelen over een onderwerp. Het biedt
de mogelijkheid om in te spelen op antwoorden die worden gegeven tijdens het interview.
(Baarda, de Goede, & Teunissen, 2005)
• Het biedt de mogelijkheid om dieper in te gaan op een onderwerp en op een kwalitatieve
manier antwoord te vinden op vragen. (Baarda, de Goede, & Teunissen, 2005)
• Eén van de grote nadelen van deze manier van gegevens verzamelen is dat het bekomen
resultaat sterk afhangt van zowel degene die wordt geïnterviewd als van de interviewer.
Enerzijds kan het zijn dat de geïnterviewde niet over de juiste kennis beschikt of dat hij
of zij niet het juiste antwoord geeft op de vraag vanwege een bepaald standpunt.
Anderzijds kan het zijn dat de interviewer niet de juiste vragen stelt, vragen vergeet te
stellen of dat hij of zij nog niet voldoende kennis heeft over het onderwerp. (Baarda, de
Goede, & Teunissen, 2005)
Bij dit onderzoek werd er gebruik gemaakt van open interviews en niet gestructureerde
interviews. Wegens de beperkte informatie die te vinden is in de wetenschappelijke literatuur
betreffende het onderwerp, namelijk het standpunt van de reseller m.b.t. OSS, is dit de
aangewezen vorm van interviewen. (Baarda, de Goede, & Teunissen, 2005)
Voordelen en nadelen van een open interview:
52
• De waarden van de geïnterviewde komen goed tot uiting. (Baarda, de Goede, &
Teunissen, 2005)
• De invloed van de interviewer is groter. (Baarda, de Goede, & Teunissen, 2005)
• De interviewer moet over voldoende kwaliteiten beschikken. (Baarda, de Goede, &
Teunissen, 2005)
• Er is minder voorbereidingstijd nodig. (Baarda, de Goede, & Teunissen, 2005)
• Er bestaat een kans dat de relevante onderwerpen niet aan bod zouden komen. (Baarda,
de Goede, & Teunissen, 2005)
• Deze vorm is vooral van toepassing wanneer de voorkennis van de interviewer eerder
beperkt is. (Baarda, de Goede, & Teunissen, 2005)
In dit hoofdstuk kon de lezer meer te weten komen over de methodologie die gebruikt werd in dit
onderzoek. Aan elk onderzoeksopzet zijn steeds een aantal voor- en nadelen verbonden. Gezien
het doel van dit onderzoek kan de keuze van het onderzoeksopzet worden beargumenteerd. In het
volgende hoofdstuk wordt in detail besproken wat de resultaten waren van het onderzoek. De
lezer moet rekening houden met de beperkingen van het onderzoeksopzet wanneer hij de
uiteenzetting van dit onderzoek leest.
53
4. Onderzoek In de eerste plaats zal een analyse worden gemaakt van de OSS partnerprogramma’s zoals
hierboven beschreven. Kort worden de OSS bedrijven besproken en welke software ze juist
verkopen. Daarna wordt de analyse besproken en zullen een aantal conclusies worden getrokken.
In het vervolg van het onderzoek worden de interviews bij de resellers en het softwarebedrijf
besproken. Om te beginnen wordt eerst het bedrijf en het softwarepakket waar het over gaat
voorgesteld. Daarna worden de interviews elk apart besproken en om af te sluiten zullen een
aantal conclusies worden getrokken.
4.1 Open Source Partnerprogramma’s
Vooraleer de partnerprogramma’s worden besproken worden kort de verschillende bedrijven
besproken.
Red Hat Inc
Red Hat is een bedrijf dat gespecialiseerd is in infrastructuur en middleware, meer bepaald het
OS besturingssysteem Linux en JBoss. Recentelijk zijn ze ook bezig met “virtualization”. In
2008 hebben ze ook meer de focus gelegd op internationale uitbreiding en hebben de
partnerprogramma’s ook een meer mondiale focus. Red Hat wordt verder in het onderzoek nog
meer uitgebreid besproken. Linux en JBoss zijn twee OS projecten die door een grote
gemeenschap worden ondersteund. Red Hat heeft inkomsten uit het verkopen van professionele
diensten, opleidingen, certificaten en abonnementen. (Red Hat, 2010) (The VAR Guy, 2009)
Sun Microsystems
MySQL werd in 2008 overgenomen door Sun en is de meest bekende OS database. In theorie
zou Sun gebruik kunnen maken van zijn uitgebreid partnernetwerk om verkoop van MySQL te
stimuleren. Het rapport van The Var Guy dat plaatsvond in 2009 gaf al aan dat Sun
teleurstellende omzetcijfers rapporteerde. In januari 2010 is Sun dan ook overgenomen door
Oracle. MySQL maakt gebruik van een dubbele licentie en verkoopt abonnementen, consulting,
opleiding en certificaten. (The VAR Guy, 2009)
54
Digium
Digium is het bedrijf dat achter het populaire Asterisk staat, een telefonie-platform. 80 procent
van de inkomsten wordt bij Digium via het partnerkanaal gegenereerd. Het is een van de grootste
kanshebbers om een beursgenoteerd bedrijf te worden. Digium maakt gebruik van een dubbele
licentie en verkoopt abonnementen en extra ondersteuning. (The VAR Guy, 2009)
SugarCRM
SugarCRM werd opgericht in 2004 en verkoopt het meest populaire OS “Customer Relationship
Management” (CRM) software pakket. Zij verkopen abonnementen, professionele diensten,
ondersteuning en opleiding. (The VAR Guy, 2009)
Alfresco
Alfresco werd opgericht in 2005 en verkoopt OS Content Management systemen. In 2007 kwam
slechts 15 procent van de inkomsten van partners, maar in 2008 steeg dit tot 60 procent. Zij
maken gebruik van een dubbele licentie, namelijk een OS licentie voor de gemeenschapsversie
en een commerciële licentie voor de bedrijfsversie en verkopen dat door middel van
abonnementen. (The VAR Guy, 2009)
Pentaho
Pentaho is het OS alternatief voor “Business Intelligence” (BI) en verkoopt abonnementen,
opleidingen en professionele diensten zoals consulting. Het bedrijf werd opgericht in 2004 en
meer dan de helft van de inkomsten zijn afkomstig uit het partnerkanaal. (The VAR Guy, 2009)
Acquia
Acquia is gespecialiseerd in Content Management systemen, meer specifiek het Drupal systeem.
Zij voorzien in producten, diensten en technische ondersteuning voor Drupal. De software van
Acquia wordt ook aangeboden op de Red Hat Exchange, een online marktplaats voor klanten en
resellers, wat bewijst dat het gaat om een bedrijf met veel potentieel volgens Red Hat. Het
partnerprogramma is pas actief sinds 2008 en is dus nog vrij nieuw. (The VAR Guy, 2009)
55
Analyse van de Partnerprogramma’s
In bijlage 3, tabel 1 kan de eerste analyse van de partnerprogramma’s worden gevonden. In
volgorde van de kolommen werden de elementen van de partnerprogramma’s opgenomen in de
tabel en aangegeven welk van deze elementen terugkomen in de verschillende
partnerprogramma’s. Dus als eerste werd het partnerprogramma van Red Hat en JBoss
geanalyseerd en daarna werden extra elementen toegevoegd van Sun, Digium, SugarCRM,
Alfresco, Pentaho, Acquia,... In een tweede stap worden een aantal gelijkaardige elementen
samengenomen. Elementen die slechts één keer voorkwamen in de tabel werden verwijderd om
een te grote complexiteit te vermijden. Deze tabel is te vinden in bijlage 3, tabel 2. De
bespreking is op basis van deze laatste tabel.
In de eerste plaats vermeldt elk partnerprogramma een aantal voordelen en een aantal vereisten.
Deze voordelen zijn onderverdeeld in een vijftal categorieën: algemene voordelen,
opleidingsvoordelen, verkoopsvoordelen, marketing en technische ondersteuning.
56
Tabel 2: open source partnerprogramma’s - algemene voordelen
RH
- In
fras
truct
uur
RH
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
VOORDELEN
algemene voordelenwelkom pakket 1/2/3 1/2/3 2toegang tot een partnernetwerk / partnerforum
1/2/3 1/2/3 1/2 1/2/3 1/2/3 2/3 1/2/3 7
mogelijkheid tot deelname aan een sales- of marketingcampagne
2/3 2/3 2/3 3
nieuwsbrief/regelmatig informatie
1/2/3 1/2/3 1/2/3 3
vermelding in partnerlijst 1/2/3 1/2/3 1/2 1/2/3 1/2/3 1/2 6vermelding in een voorkeurslijst
1/2 2/3 2 3
succesverhalen/case study 2/3 2/3 1/2/3 3toegang tot commercieel product voor intern gebruik
1/2 2/3 2/3 1/2 4
Roadmap 1/2 3 2mogelijkheid tot deelname aan evenementen en sponsoring
1/2 1/2/3 1/2/3 1/2 4
(gezamenlijke) persberichten 1/2 1/2/3 2/3 3Legende
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Bij de algemene voordelen zijn een aantal elementen frequent terug te vinden: de toegang tot
een partnernetwerk of partnerforum en de vermelding van de partner in een partnerlijst op de
website van het OSS bedrijf. Deze twee elementen komen respectievelijk zeven en zes keer voor
57
in de partnerprogramma’s. De volgende elementen kunnen in minstens 3 partnerprogramma’s
worden teruggevonden3:
• Mogelijkheid tot deelname aan een sales- of marketingcampagne (3)
• Een nieuwsbrief of regelmatig ontvangen van informatie (3)
• Vermelden van succesverhalen of casestudies op de website van het OSS bedrijf (3)
• Mogelijkheid om te beschikken over het product voor intern gebruik (testen, demo’s...)
(4)
• Mogelijkheid tot deelname aan evenementen en sponsoring (4)
• (gezamenlijke) persberichten (3)
Tabel 3: open source partnerprogramma’s - opleidingsvoordelen
RH
- In
fras
truct
uur
RH
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
opleidingsvoordelen(verkoop- en technische)opleiding 1/2/3 1/2/3 1/2/3 1/2/3 2/3 1/2/3 5
productopleiding (via internet) 1/2/3 1/2/3 2verkoopsopleiding (via internet)
1/2/3 1/2/3 1/2 1/2 4
korting op opleidingen 2/3 2/3 1/2 1/2/3 2/3 1/2 2/3 7Legende
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
De opleidingsvoordelen hebben betrekking op opleiding of certificaten die te koop zijn bij het
OSS bedrijf. Het kan gaan om product-, technische- en verkoopsopleiding die wordt aangeboden
of een korting voor opleidingen of certificaten. Het meest populaire, te vinden bij zeven van de
acht OSS bedrijven, is de korting voor opleiding.
3 De frequentie van de elementen staan tussen haakjes
58
Tabel 4: open source partnerprogramma’s - verkoopsvoordelen
RH
- In
fras
truct
uur
RH
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
verkoopsvoordelenmarge 1/2 1/2/3 2kortingen 2/3 2/3 2referral vergoedingen 1/2/3 1 2toegang tot een sales team/ 2/3 2/3 1/2/3 3sales materiaal, tools en ondersteuning
1/2/3 1/2 2
lead distributie/lead 2/3 2/3 1/2/3 2/3 2/3 5partnermanager 3 3 2/3 2/3 3 2/3 6 Legende
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Bij de verkoopsvoordelen is er slechts één element dat zes keer voorkomt in de acht
partnerprogramma’s en één element dat vijf keer voorkomt. Er zijn dus minder gelijkenissen
tussen de verschillende elementen bij de verkoopsvoordelen. Het eerste element is de
beschikbaarheid van een partnermanager die bij zes partnerprogramma’s pas wordt aangeboden
op een hoger niveau dan het eerste. Het tweede element is het toegewezen krijgen van
(gekwalificeerde) leads. De categorie “marge en korting” kan worden samengenomen en komt
dan voor in vier van de acht programma’s. Deze categorie kan dan worden beschouwd als (een
deel van) de financiële vergoeding voor de reseller. Elementen die minstens 2 maal gevonden
worden, zijn4:
• Referral vergoeding (2)
• Toegang tot een verkoopsteam (2)
• Toegang tot verkoopsmaterialen, verkoopstools en verkoopsondersteuning (2)
4 De frequentie van de elementen staan tussen haakjes
59
Er moet worden opgemerkt dat de verkoopsvoordelen die worden vermeld niet altijd de
werkelijkheid representeren. Red Hat bijvoorbeeld biedt de reseller korting op de
abonnementen die de reseller kan verkopen. (infra p. 107)
Tabel 5: open source partnerprogramma’s – marketing voordelen
RH
- In
fras
truct
uur
RH
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
marketing voordelen(product marketing) collateral en campagnes 1/2/3 1/2/3 1/2 1/2/3 1/2/3 2/3 2/3 7
product demonstratie (niet om te verkopen)
1/2/3 1/2/3 1/2 2/3 2/3 5
templates en richtlijnen voor campagnes/marketing materiaal
1/2/3 1/2/3 1/2 2/3 4
gebruik van partnerprogramma logo
1/2/3 1/2/3 1/2 1/2/3 1/2/3 1/2/3 6
partnerprogramma certificaat 1/2/3 1/2/3 2/3 3
Marketing Development Fund 3 3 3 2/3 4
De categorie “productmarketing onderpand en campagnes” werd samengenomen met
“onderpand” tot één categorie en kan worden gevonden bij zeven van de acht OSS bedrijven. Bij
het marketing onderdeel van de voordelen wordt het gebruik van het (partnerprogramma) logo
bij zes van de acht aangeboden. De mogelijkheid om het product te demonstreren is aanwezig bij
vijf programma’s. De beschikbaarheid van een “Marketing Development Fund” is te vinden bij
vier van de acht OSS bedrijven. Andere elementen en hun frequentie zijn:
• Templates en richtlijnen voor campagnes en marketing materiaal (4)
• Een partnerprogramma certificaat (3)
60
Tabel 6: open source partnerprogramma’s – technische ondersteuning
RH
- In
fras
truct
uur
RH
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
technische ondersteuningtechnische ondersteuning 1/2/3 2/3 1/2 3toegang tot kennis 1/2/3 1/2/3 1/2/3 2/3 2/3 5korting op professionele diensten
2/3 2/3 2
technische (pre-)verkoop ondersteuning (via internet)
2/3 2/3 3 2/3 4
Legende
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Technische ondersteuning is een categorie die bij drie van de acht partnerprogramma’s niet kan
worden teruggevonden namelijk deze van Alfresco, SugarCRM en MySQL. De drie elementen
die kunnen worden gevonden zijn5:
• Toegang tot kennis (5)
• Korting op professionele diensten (3)
• Technische (pre)verkoop ondersteuning (eventueel via internet) (4)
5 De frequentie van de elementen staan tussen haakjes
61
Tabel 7: open source partnerprogramma’s – vereisten
RH
- In
fras
truct
uur
RH
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
VEREISTENinvullen van een partnerprogramma aanvraagformulier en profiel
1/2/3 1/2/3 1/2/3 3
aanvaarden van de partnerprogramma overeenkomst
1/2/3 1/2/3 1/2 1/2/3 2/3 1/2/3 6
jaarlijkse deelnamevergoeding 2/3 2/3 2/3 1/2/3 2 5
jaarlijkse minimum inkomsten doelen
2/3 2/3 1/2/3 3
minimum aantal abonnementen, hoeveelheid inkomsten
2/3 1/2/3 1/2/3 3
minimum aantal getrainde mensen (verkoop of technisch) 2/3 2/3 2
minimum aantal gecertificeerde mensen
2/3 2/3 2/3 2/3 4
jaarlijks (12 maandelijks) bedrijfsplan
2/3 2/3 2/3 3
actieve participatie in gefocuste marketing programma's
3 3 2/3 3
minimum aantal succesverhalen van klanten jaarlijks voorleggen
2/3 2/3 1/2/3 3
Legende
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Wat betreft de vereisten vermeldt Alfresco enkel een bepaalde certificatieprocedure die moet
worden gevolgd. MySQL vermeldt enkel een partnervergoeding die moet worden betaald op het
62
hoogste niveau en Pentaho geeft aan dat een partnerovereenkomst moet worden getekend. Red
Hat, JBoss, Acquia, SugarCRM en Digium vermelden meer vereisten. Het kan zijn dat dit is
omdat vereisten minder gemakkelijk vermeld worden in een partnerprogramma ofwel dat er
minder zijn.
Het aanvaarden of ondertekenen van de partnerprogramma overeenkomsten is nodig bij zes van
de acht programma’s. Het betalen van een jaarlijkse vergoeding voor deelname aan het
partnerprogramma is ook vereist bij vijf van de acht OSS bedrijven. In vier programma’s is het
ook nodig om een aantal gecertificeerde of opgeleide mensen te hebben. De volgende elementen
en hun frequentie zijn ook vereisten die worden teruggevonden:
• Invullen van een aanvraagformulier en profiel (3)
• Jaarlijks een inkomstendoel vooropstellen (3)
• Jaarlijks een aantal producten/abonnementen verkopen of inkomen behalen (3)
• Er moet jaarlijks een bedrijfsplan worden opgesteld (3)
• Verplichte deelname in marketingcampagne of programma (3)
• Het voorleggen van een minimum aantal referenties of succesverhalen bij klanten (3)
Tabel 8: open source partnerprogramma’s – partnerniveaus en –vergoedingen
RH
- In
fras
truct
uur
RH
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
aantal partnerniveaus 3 3 2 3 3 3 2 3partnervergoeding per niveau
1 0 0 0 $ 2000 02 $ 980 $ 3200 4000 $ 6000 $ 29993 $ 980 $ 3200 * $ 12000
Legende
* Onderhandelbaar
63
Een andere eigenschap van de partnerprogramma’s is dat ze steeds een aantal niveaus bevatten
waartussen verschillen bestaan in zowel voordelen als vereisten. Zes programma’s hebben drie
niveaus, twee hebben twee niveaus. Vijf van de acht OSS bedrijven vermelden expliciet de
partnervergoedingen die moeten worden betaald bij de verschillende niveaus:
• Voor Red Hat moet op het eerste niveau niets worden betaald en op het tweede en derde
niveau moet dezelfde vergoeding worden betaald. Voor het infrastructuurprogramma
moet minder worden betaald (zijnde $ 980), dan voor het middlewareprogramma, (zijnde
$ 3200).
• Bij Acquia is het eerste niveau gratis. De prijs van het tweede niveau is $ 4 000. De prijs
voor het derde niveau is onderhandelbaar.
• Bij SugarCRM is de kostprijs van het laagste niveau, $ 2 000, driemaal kleiner dan het
tweede niveau en zesmaal kleiner dan het derde niveau. Het tweede niveau, dat $ 6 000
kost is tweemaal kleiner dan het derde niveau dat $ 12 000 kost.
• Voor MySQL moet pas op het tweede niveau een partnervergoeding worden betaald die
$ 2 999 bedraagt.
Al deze elementen die in de partnerprogramma’s kunnen worden teruggevonden kunnen
gesitueerd worden in het conceptueel model van coöperatie dat eerder werd besproken.
Leeroriëntatie
Om te kunnen deelnemen aan de partnerprogramma’s wordt er van de resellers gevraagd om een
aantal mensen opleiding te laten volgen. Partners kunnen ook vaak toegang krijgen tot kennis,
informatie, een nieuwsbrief, de roadmap, een partnerportaal of netwerk,.... Dit maakt het
mogelijk voor partners om de kerncompetenties te ontwikkelen die nodig zijn om het product
van het softwarebedrijf te verkopen.
Levensduur van relatie
Alle partnerprogramma’s zijn opgesteld in niveaus. De meerderheid heeft een drietal niveaus die
verschillen in voordelen en vereisten voor partners. Onrechtstreeks wijst dit op de intentie om
een relatie op te bouwen met elke partner die zich engageert. Er zijn ook niet te verwaarlozen
investeringen nodig om tot de hoogste niveaus te geraken. Er moeten een aantal mensen in het
64
productteam aanwezig zijn en een aantal gecertificeerde of opgeleide mensen. Voor de reseller is
dit een niet te verwaarlozen investering.
Intensiteit van de relatie
Er wordt niet meteen verwezen naar de intensiteit van de relatie in de partnerprogramma’s. Wat
er wel op kan wijzen dat de intensiteit van de relatie hoger zal zijn naarmate de reseller een hoger
partnerniveau bereikt is de beschikbaarheid van een partnermanager.
Prestaties
Dit kan niet worden afgeleid uit de partnerprogramma’s.
Tevredenheid van de kanaalleden
Dit is een factor die wel kan teruggevonden worden in de partnerprogramma’s. De tevredenheid
van de kanaalleden wordt beïnvloed door de voordelen die worden aangeboden.
• Administratie: dit heeft te maken met de manier waarop vragen en problemen van de
reseller worden behandeld.
• Diensten ondersteuning: de reseller kan in de partnerprogramma’s een grote
verscheidenheid aan marketing-, verkoopsondersteuning en technische ondersteuning
krijgen.
• Beloningen: de referral vergoeding is een voorbeeld van een beloning voor de reseller die
een nieuwe klant kan aanwerven.
• Vergoedingsbeleid van producent: dit is het geheel van marges, kortingen en andere
financiële voordelen die de reseller kan krijgen. Daartegenover staat de
partnervergoeding die door de reseller moet worden betaald.
Aan de hand van dit conceptueel model van coöperatie zien we dat de elementen van de
partnerprogramma’s die werden geïdentificeerd kunnen bijdragen tot betere samenwerking en
beter prestaties van het distributiekanaal.
65
Conclusie
Uit deze analyse van de verschillende partnerprogramma’s kan worden geconcludeerd dat er
bijna geen elementen zijn die standaard terugkomen in alle partnerprogramma’s die werden
besproken. De belangrijkste overeenkomsten die in elk partnerprogramma terugkomen is de
verschillende categorieën van voordelen. Er zal meestal een indeling als volgt zijn:
• Algemene voordelen
• Opleidingsvoordelen
• Verkoopsvoordelen
• Marketingvoordelen
• Ondersteuningsvoordelen
De ondersteuningsvoordelen kunnen technische voordelen zijn, maar ook ondersteuning bij de
verkoop door resellers.
4.2 Open Source en Niet-open Source Partnerprogramma’s
In de eerste plaats worden de partnerprogramma’s van Oracle, IBM en Microsoft besproken van.
Daarna zal er een gedetailleerde vergelijking zijn tussen SugarCRM en Salesforce.com.
Oracle
Oracle bestaat reeds 30 jaar en verkoopt zowel hardware als software, meer specifiek
middleware, applicatie- en databasesoftware. (Oracle, 2010c) Het partnerprogramma van Oracle
bestaat uit vier verschillende niveaus:
• Remarketer (gratis)
• Silver level (500 $)
• Gold level (2500 $)
• Platinum level (9995 $)
66
Het partnerprogramma van Oracle is bedoeld voor vijf verschillende “Knowledge Zones”:
Database, Middleware, Applications, Server & Storage Systems en Industries. De elementen van
het partnerprogramma zijn ingedeeld als volgt6:
• Voordelen en middelen (12)
• “Enablement” voordelen en instrumenten (8)
• Voordelen en instrumenten voor ontwikkeling (4)
• Marketing voordelen en instrumenten (12)
• Voordelen en instrumenten voor verkoop (17)
• Voordelen en instrumenten voor ondersteuning (13)
• Voordelen en instrumenten voor specialisatie (13)
In totaal zijn er 79 elementen in het partnerprogramma van Oracle. Dit zijn enkel de voordelen
voor de partners. Bij de analyse van de OSS partnerprogramma’s kunnen 33 verschillende
elementen worden gevonden. Vandaar dat de vergelijking van deze lijst met elementen en het
Oracle partnerprogramma complex is. Dit wijst erop dat Oracle een groot bedrijf is en een sterker
uitgebouwd partnerprogramma heeft.
De vereisten worden eerder kort beschreven voor elk partnerniveau. Elk niveau, behalve van het
Remarketer niveau, moet een web account aanmaken, jaarlijks de partnervergoeding betalen, een
inschrijvingsformulier invullen en het aanvaarden van de Oracle Partnernetwerk
overeenkomsten. De omschrijving van de vereisten is dus minder uitgebreid als de voordelen
voor partners.
IBM
De geschiedenis van IBM, International Business Machines, gaat helemaal terug tot 1911. Zij
voorzien in zowel hardware als software. Het partnerprogramma van IBM bestaat uit drie partner
niveaus:
• Member (gratis)
• Advanced (gratis)
6 Tussen haakjes staan het aantal elementen in elke categorie.
67
• Premier (geen vermelding of er al dan niet een vergoeding moet worden betaald)
Het Premier niveau is enkel op uitnodiging.
De “voordelen en middelen” van het IBM partnerprogramma zijn ingedeeld in vijf verschillende
categorieën7:
• Marketing (57)
• Verkoop (58)
• Technisch (27)
• Opleiding (9)
• Samenwerking (19)
In totaal zijn er 170 verschillende voordelen in het partnerprogramma van IBM. Bij de analyse
van de OSS partnerprogramma’s werden 36 verschillende elementen geïdentificeerd. Opnieuw
zou een vergelijking een vrij complexe aangelegenheid zijn en kan er worden geconcludeerd dat
het partnerprogramma van IBM en Oracle meer gedetailleerd beschreven is en meer elementen
bevat. Tot hiertoe zijn de categorieën van voordelen wel gelijkaardig.
De vereisten worden kort beschreven voor elk partnerniveau. Het Member partnerniveau vereist
slechts een minimale verbintenis van de partner namelijk een online registratie en het aanvaarden
van de “Partnerworld” overeenkomsten. Voor het “Advanced” en “Premier” partnerniveau wordt
er bij IBM met een puntensysteem gewerkt. Bijvoorbeeld voor een bepaalde hoeveelheid
inkomsten voor IBM producten en een bepaalde klantentevredenheidscore kunnen een aantal
punten worden behaald. Er moet ook aan een aantal minimumvoorwaarden worden voldaan met
betrekking tot het aantal mensen dat technische- en verkoopsopleiding gevolgd heeft bij IBM.
Microsoft
Microsoft is een bedrijf dat actief is sinds eind jaren 70. Het partnerprogramma van Microsoft
wordt niet erg duidelijk uitgelegd op de website van het softwarebedrijf. Er zijn drie
partnerniveaus en er kan voor deze drie niveaus een lijst worden teruggevonden met voordelen.
Bij Microsoft zijn er 41 voordelen in deze lijst. Daarnaast staat er op de website van Microsoft 7 Tussen haakjes staan het aantal elementen in elke categorie.
68
ook een andere lijst met voordelen voor een Microsoft partner waarvan de categorisatie
vergelijkbaar is met de andere partnerprogramma’s, namelijk: opleiding, verkoop en marketing,
licenties en ondersteuning. In vergelijking met wat er bij de OSS bedrijven wordt gevonden is dit
een ingewikkeld partnerprogramma.
Vandaar dat er wordt overgaan tot een gedetailleerde vergelijking tussen SugarCRM en
Salesforce.com
Salesforce.com vs. SugarCRM
Salesforce.com is een bedrijf dat klanten voorziet in Customer Relationship Management (CRM)
software door gebruik te maken van “Cloud Computing” en werd opgericht in 1999.
Het aantal voordelen voor partner bij Salesforce.com is beduidend hoger dan het aantal bij
SugarCRM, namelijk 24 bij Salesforce.com en 11 bij SugarCRM. Hiervan zijn er 7 die zowel
voorkomen bij Salesforce.com als SugarCRM.
69
Tabel 9: SugarCRM vs. Salesforce.com – algemene voordelen
Suga
rCR
M
Sale
sfor
ce.c
om
VOORDELEN
algemene voordelenwelkom pakkettoegang tot een partnernetwerk / partnerforum
1/2/3 1/2/3
mogelijkheid tot deelname aan een sales- of marketingcampagne
2/3 3
nieuwsbrief/regelmatig informatie 1/2/3vermelding in partnerlijst 2/3vermelding in een voorkeurslijst 3succesverhalen/case studytoegang tot commercieel product voor intern gebruik
1/2/3
Roadmap 2/3mogelijkheid tot deelname aan evenementen en sponsoring
1/2/3 1/2/3
(gezamenlijke) persberichten 2/3verkopen van technologieën 1/2/3
Van de 11 algemene voordelen die bij de analyse van de OSS partnerprogramma’s werden
geïdentificeerd zijn er 9 die ook aanwezig zijn in het partnerprogramma van Salesforce.com. De
twee meest voorkomende elementen, toegang tot een partnernetwerk en vermelding in een
partnerlijst komen ook voor bij Salesforce.com. Er is één element dat wordt vermeld bij
Salesforce.com en niet de OSS partnerprogramma’s en dat is de toelating om de technologieën
van Salesforce.com te verkopen.
70
Tabel 10: SugarCRM vs. Salesforce.com – opleidingsvoordelen
Suga
rCR
M
Sale
sfor
ce.c
om
opleidingsvoordelen(verkoop- en technische)opleiding 1/2/3productopleiding (via internet)verkoopsopleiding (via internet)korting op opleidingenkorting op certificaten
De opleidingsvoordelen zijn zowel voor SugarCRM en Salesforce.com beperkt. Enkel
SugarCRM vermeld dat de partner toegang heeft tot verkoops- of technische opleiding.
Tabel 11: SugarCRM vs. Salesforce.com – verkoopsvoordelen
Suga
rCR
M
Sale
sfor
ce.c
om
verkoopsvoordelenmarge 1/2/3kortingenreferral vergoedingentoegang tot een sales team/ 2/3sales materiaal, tools en ondersteuninglead distributie/lead referral/qualified leads 2/3 1/2/3lead/deal registratie 1/2/3 1/2/3partnermanager 2/3 3
Salesforce.com vermeld bij de verkoopsvoordelen geen marge of korting voor de reseller, maar
zoals uit het partnerprogramma van Red Hat blijkt worden de marges of kortingen voor resellers
niet steeds vermeld. (Infra, p 107) De twee meest populaire elementen bij OSS
partnerprogramma’s, lead distributie en een partnermanager, zijn ook elementen die terugkomen
71
bij Salesforce.com. De mogelijkheid om een lead of deal te registreren is een element dat niet bij
de 7 andere OSS partnerprogramma’s maar wel bij SugarCRM en Salesforce.com.
Tabel 12: SugarCRM vs. Salesforce.com – marketing voordelen
Suga
rCR
M
Sale
sfor
ce.c
om
marketing voordelen(product marketing) collateral en campagnesproduct demonstratie (niet om te verkopen)templates en richtlijnen voor campagnes/marketing materiaal
1/2/3
gebruik van partnerprogramma logo 1/2/3 1/2/3partnerprogramma certificaatMarketing Development Fund 3distributie via een online marktplaats 1/2/3
De mogelijkheid om het logo van het partnerprogramma te gebruiken is het enige element dat bij
beide bedrijven terug komt. Voor de partners van Salesforce.com is het mogelijk om op een
online marktplaats producten te distribueren. Dit is een element dat nieuw is en niet bij de OSS
bedrijven kan worden teruggevonden.
72
Tabel 13: SugarCRM vs. Salesforce.com – technische ondersteuning
Suga
rCR
M
Sale
sfor
ce.c
om
technische ondersteuningtechnische ondersteuning 1/2/3toegang tot kennis 1/2/3korting op professionele dienstentechnische (pre-)verkoop ondersteuning (via internet)gratis licenties 1/2/3onbeperkte ontwikkelings- en testomgevingen 1/2/3
toolkit voor ontwikkeling en codebibliotheken 1/2/3
technische discussie fora 1/2/3technische support van de gemeenschap 1/2/3
Het is opvallend dat voornamelijk het aantal elementen met betrekking tot de technische
ondersteuning bij Salesforce.com hoger is dan SugarCRM. Bij Salesforce.com zijn er 6
verschillende elementen die worden beschreven als technische ondersteuning. SugarCRM
vermeld enkel dat er technische ondersteuning is. Hier kan worden gewezen op de beperking van
het gebruik van bestaande gegevens. Om in detail te weten of de technische ondersteuning bij
SugarCRM in essentie minder is dan bij Salesforce.com zou dit aan de hand van interviews of
vragenlijsten verder moeten worden onderzocht.
73
Tabel 14: SugarCRM vs. Salesforce.com – vereisten
Suga
rCR
M
Sale
sfor
ce.c
om
VEREISTENminimum klantentevredenheidscijfers 1/2/3invullen van een partnerprogramma aanvraagformulier en profielaanvaarden van de partnerprogramma overeenkomst
1/2/3
jaarlijkse deelnamevergoeding 1/2/3jaarlijkse minimum inkomsten doelen 1/2/3minimum aantal abonnementen, hoeveelheid inkomsten
1/2/3 1/2/3
minimum grootte van team 1/2/3minimum aantal getrainde mensen (verkoop of technisch)minimum aantal gecertificeerde mensen 2/3 1/2/3jaarlijks (12 maandelijks) bedrijfsplan 2/3actieve participatie in gefocuste marketing programma's
2/3
jaarlijkse sponsoring 2/3minimum aantal succesverhalen van klanten jaarlijks voorleggen
1/2/3 2/3
Legende
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Het aantal vereisten ten opzichte van het aantal voordelen voor partners is groter bij SugarCRM
dan bij Salesforce.com. Voor Salesforce.com zijn er twee vereisten die niet in de lijst van de
OSS partnerprogramma’s staan, namelijk verplicht een minimum klantentevredenheidscijfer en
verplicht jaarlijkse sponsoring. Er moet geen partnervergoeding worden betaald door partners
van Salesforce.com, maar zij moeten er zich wel toe verbinden om te proberen een minimum
omzet te behalen. Beide bedrijven hebben nog twee andere elementen gemeen namelijk verplicht
een minimum aantal succesverhalen voorleggen en een minimum aantal gecertificeerde mensen
in huis hebben.
74
Tabel 15: SugarCRM vs. Salesforce.com – partnerniveaus en –vergoedingen
Suga
rCR
M
Sale
sfor
ce.c
om
aantal partnerniveaus 3 3partnervergoeding per niveau
1 $ 20002 $ 60003 $ 12000
jaarlijkse minimum inkomsten1 $ 10 0002 $ 100 0003 $ 300 000
Zoals reeds werd vermeld bij de lijst van vereisten moet er geen partnervergoeding worden
betaald door partners van Salesforce.com, wat wel het geval is bij reseller van SugarCRM. Dit
heeft als gevolg dat het niet mogelijk is om dit met elkaar te vergelijken.
Er kan dus worden bevestigd dat het niet-OSS partnerprogramma meer voordelen vermeld dan
het OSS partnerprogramma. Omgekeerd vermeld het OSS partnerprogramma meer vereisten dan
het niet-OSS partnerprogramma. De partnerprogramma’s zijn toch zeer verschillend van elkaar
en er zijn geen elementen die specifiek zijn voor OSS bedrijven.
Het is duidelijk dat voor de grote bedrijven zoals Salesforce.com, Microsoft, IBM en Oracle het
aantal voordelen in de partnerprogramma’s veel groter is. De vereisten worden minder sterk in
detail besproken of zijn gewoon niet zo groot in aantal. In de interviews zal hier verder op
ingegaan worden.
4.3 Interview Resellers
Op basis van de voorgaande literatuurstudie kunnen een aantal zaken worden afgeleid waarvan
kan worden nagegaan waarom resellers geïnteresseerd zouden zijn in het verkopen van OS
producten en diensten.
75
Eerst en vooral kan een onderscheid worden gemaakt tussen niet-financiële en financiële redenen
waarom resellers ervoor kiezen om ook OSS te verkopen aan klanten. Hierbij moet worden
opgemerkt dat het moeilijk zal zijn om binnen bedrijven financiële informatie te bekomen. In de
eerste plaats is het doel van deze masterproef dan ook om dit kwalitatief te onderzoeken wegens
de beperking om kwantitatieve gegevens te bekomen.
Elk interview wordt opgedeeld in vier hoofdstukken. Ten eerste wordt de structuur van de
reseller besproken en de producten en diensten die hij biedt. Daarna wordt de relatie tussen de
partner en eindklant met betrekking tot OSS besproken. Ten derde wordt er dieper op de
financiële stromen en partnerprogramma’s ingegaan. Als laatste wordt kort de keuze voor OSS
en strategieën m.b.t. OSS behandeld.
4.3.1 JBoss Red Hat
Red Hat is opgericht in 1993 en is gespecialiseerd in infrastructuur en middleware, meer bepaald
het OSS besturingssysteem Linux en OS middleware JBoss. Recentelijk zijn ze ook bezig met
“virtualization”. Het is sinds 1999 een beursgenoteerd bedrijf. Red Hat is de leider van Linux
voor ondernemingen en professionele toepassingen. Het is één van de meest herkenbare OS
merknamen. Het productportfolio bestaat uit de Red Hat Linux versie voor ondernemingen
(RHEL), JBoss middleware voor ondernemingen, Red Hat “virtualization” voor ondernemingen
en een groot aanbod aan management en diensten.
In 2008 hebben ze ook meer de focus gelegd op internationale uitbreiding en hebben de
partnerprogramma’s een meer mondiale focus. Linux en JBoss zijn twee OS projecten die door
een grote gemeenschap van ontwikkelaars wordt ondersteund. Zij hebben dan ook hoofdzakelijk
inkomsten uit het verkopen van abonnementen, professionele diensten, opleidingen en
certificaten.
Aan de hand van de studie over OSS bedrijfsmodellen die eerder werd beschreven kan dit OSS
bedrijf als volgt worden geclassificeerd:
• Licentie: De Red Hat Linux Enterprise versie van Linux is gebaseerd op het OS project
Linux dat de OS licentie GNU GPL heeft. Voor JBoss wordt er gebruik gemaakt van de
GNU LGPL.
76
• Licentiestrategie: Red Hat maakt gebruik van de OS licentie voor zowel Red Hat Linux
Enterprise als JBoss.
• Ontwikkelingsstrategie: De meeste software wordt ontwikkeld door de gemeenschap van
programmeurs. Zij laten het grootste gedeelte van het werk over aan de gemeenschap. Er
wordt wel gebruik gemaakt van een uitgebeid proces om de broncode uit de gemeenschap
om te zetten in een softwarepakket dat bruikbaar is voor professioneel gebruik.
• Inkomstenstrategie: In eerste instantie zijn abonnementen de belangrijkste bron van
inkomsten. Daarnaast voorzien zij ook in professionele diensten zoals consulting,
opleiding, certificaten... .
Figuur 4: JBoss.org vs. JBoss.com
bron: Xplore Group
77
JBoss
JBoss bedrijfsmiddleware bestaat uit een gecertificeerd en ondersteund platform en framework.
Het is gebaseerd op de projecten in de JBoss gemeenschap.
Zoals in figuur 4 te zien is worden de projecten uit de JBoss gemeenschap gebruikt als basis voor
de JBoss bedrijfsversie. De focus bij de JBoss gemeenschap is het vroeg en frequent uitbrengen
van de projecten. Elk van de meer dan 35 projecten heeft een andere planning, andere versie,
andere afhankelijkheden... . De meest ontwikkelde en beste projecten worden er uitgenomen en
verder bewerkt door Red Hat. De JBoss bedrijfsversie van Red Hat is door de mensen van Red
Hat geïntegreerd, gecertificeerd, ze is doorheen een uitgebreid Q/A proces gegaan, voorzien van
volledige ondersteuning, documentatie, veilige configuratie en een update beleid voor meerdere
jaren. Klanten kunnen dan een abonnement aankopen bij Red Hat voor deze bedrijfsversie van
JBoss en hebben op die manier toegang tot professionele ondersteuning van Red Hat.
Tijdens de interviews worden WebSphere van IBM en WebLogic van Oracle beschouwd als de
grootste commerciële tegenhangers van JBoss Red Hat. Vandaar dat in de verdere bespreking
steeds een vergelijking wordt gemaakt tussen JBoss van Red Hat, WebSphere van IBM en
WebLogic van Oracle. Tijdens het interview wordt er ook vaak verwezen naar de “.org” versie
of de “.com” versie. Hiermee wordt de gemeenschapsversie en de bedrijfsversie van JBoss
bedoeld.
4.3.2 Interview Xplore Group
1. Xplore Group
Xplore Group is een onderdeel van Cronos, een Belgisch bedrijf dat werd opgericht in 1991.
Cronos is een e-business integrator die er naar streeft zijn klanten innovatieve en praktische
oplossingen te bieden om hen op die manier competitief te maken. De structuur van Cronos is
eerder onconventioneel, Cronos is namelijk opgedeeld in ongeveer 150 bedrijfjes die zich elk
specifiek focussen op een bepaalde technologie, oplossing of sector. Voor klanten is dat niet
altijd even duidelijk, vandaar dat ze de laatste jaren bezig zijn met een aantal bedrijfjes te
clusteren. Xplore Group is een nieuwe holding binnen Cronos die verantwoordelijk is voor de
Java tak. Er zijn ook ander clusters zoals één voor hardware en één cluster die bezig is met alles
wat ERP, CRM, BI en dergelijke is. En dan zijn er nog twee aparte clusters, één die werkt met
78
Oracle en een andere met Microsoft. Grote klanten hebben vaak de voorkeur om één
aanspreekpunt te hebben en dit wordt dan ook afgehandeld of gestuurd vanuit Cronos zelf.
Hetzelfde geldt voor wanneer men werkt aan projecten voor de overheid.
Xplore Group is dus de Java tak binnen Cronos en dat is waarvoor Mr. De Backere
verantwoordelijk is. Xplore Group kan dan nog eens worden opgedeeld in vijf bedrijfjes die elk
een expertise hebben in een andere applicatieserver technologie. Een eerste bedrijf werkt met
WebLogic van BEA, dat door Oracle is overgenomen. Er is een tweede bedrijf dat met IBM
WepSphere werkt. Daarnaast is er nog een derde bedrijfje dat verantwoordelijk is voor alles wat
OSS betreft en dat is dan meer specifiek het JBoss platform. Een vierde bedrijf is bezig met
XML en als laatste is er nog een vijfde afdeling rond de Adobe technologie. Deze kennis- en
competentiecentra hebben een personeelsbestand van zo’n 150 mensen.
De kernactiviteit van Xplore Group is op maat gemaakte ontwikkeling van Java applicaties.
Algemeen zijn zij bezig met het in beheer nemen van een volledig IT project in bedrijven.
Xplore Group biedt zijn klanten een aantal diensten aan die als volgt kunnen worden
gecategoriseerd:
• Architectuur definitie en Implementatie
• Ontwikkeling Consulting
• Projectontwikkelingsdiensten
• Auditing en kwaliteitsgarantiediensten
Enerzijds doen ze dus consulting voor hun klanten en anderzijds voeren zij analyse taken uit.
Consulting is het verhuren van een aantal ontwikkelaars voor de ontwikkeling van een bepaalde
applicatie. Een klant heeft dan op voorhand een keuze gemaakt met betrekking tot het Java
platform, het aantal ontwikkelaars, het ontwerp…. Wanneer het gaat om een bedrijf dat deze
keuzes nog niet gemaakt heeft zal Xplore Group voorzien in de stappen die nodig zijn om het IT
project te verzorgen. Een project bestaat uit een aantal fasen. In een eerste stap wordt een analyse
gedaan, waarbij er wordt gepraat met de mensen in het bedrijf die betrokken zijn bij het project.
De bedoeling is om te achterhalen wat de eindgebruiker wil, wat men moet bouwen, hoe dat er
moet uitzien. Er wordt een functionele analyse gemaakt, waaruit architecten de architectuur
verder gaan uitwerken en bepalen wat wel en niet belangrijk is. Dat is het technische gedeelte.
79
Verder wordt er ook een keuze gemaakt uit de tools die men zal gebruiken, waarna er wordt
overgegaan tot de ontwikkeling, dat is het schrijven van het programma, het testen van het
programma… Daarnaast doen zij ook auditing in bedrijven waar er bijvoorbeeld problemen zijn
met de prestaties van een applicatie. Wanneer een applicatie niet goed werkt kunnen één of
meerdere van de architecten van Xplore Group naar de klant gaan en het probleem oplossen. Een
laatste dienst is projectmanagement dat wordt verzorgd door een aantal projectmanagers die
instaan voor het opvolgen en in goede baan leiden van projecten.
2. Klanten
Java ontwikkeling is voor Xplore Group iets dat hoofdzakelijk plaatsvindt in grotere bedrijven.
Het is belangrijk om te weten hoe deze grote bedrijven en mogelijke klanten denken ten opzichte
van OSS. De grootste zorg die vele klanten of bedrijven hebben tegenover OSS is of het gaat om
zaken die voldoende veilig zijn om in een kritische bedrijfsomgeving te gebruiken. Voor de
meeste bedrijven is OSS nog iets nieuw, meestal kennen ze het concept wel, maar bestaat er een
verkeerd beeld. Wat dikwijls voorkomt is het idee dat OSS gratis is. Men weet ook vaak niet dat
er professionele bedrijven zijn die voorzien in ondersteuning die nodig is om deze software te
gebruiken in bedrijfskritische omgevingen.
Er zijn twee manieren waarop Xplore Group een project kan verkopen voor JBoss. Ten eerste
kan het zijn dat klanten wel weten dat er een “.org” versie is, de gemeenschapsversie, maar de
“.com” versie waarop professionele ondersteuning wordt aangeboden kennen ze niet. Het is in
bedrijven namelijk zo dat technische mensen in de IT-afdeling reeds met JBoss.org werken.
Deze bedrijven halen dan zelf de pakketjes uit de JBoss gemeenschap die voor hen interessant
zijn. Zij komen dan bij een reseller zoals Xplore Group terecht met een aantal problemen of om
een meer gestandaardiseerde aanpak te organiseren. Dit creëert voor Xplore Group een
opportuniteit om aan de klant duidelijk te maken dat er voor deze software ook ondersteuning
bestaat op basis van abonnementen. Op die manier kunnen zij deze abonnementen verkopen aan
klanten.
Een tweede aspect dat belangrijk is voor Xplore Group om JBoss te verkopen aan klanten is de
financiële crisis en het langzaamaan veranderend idee rond OSS. Het financiële en
psychologische effect is niet te verwaarlozen. IT-budgetten zijn één van de eerste die worden
80
verminderd als gevolg van de economische crisis. Klanten gaan dus op zoek naar een betere
afstemming tussen hun behoeften en de producten die ze kopen. Doordat vele bedrijven OSS
associëren met ‘gratis’, zijn ondernemingen meer geneigd om ook OSS in beschouwing te
nemen. Klanten zien vaak dat ze zeer veel geld moeten uitgeven aan licenties voor producten
zoals WebSphere of WebLogic. Langs de andere kant zien bedrijven meer en meer het OSS
verhaal dat goedkoper is en een goede naam begint te krijgen op de markt. De bedrijfsversie van
JBoss en de professionele ondersteuning die er dus is, kennen bedrijven vaak niet. Voor een
bedrijf is dan de vraag “waarom betalen voor JBoss, als het ook gratis verkrijgbaar is?”. De
reseller moet dus de klant de voordelen van de bedrijfsversie ten opzichte van de
gemeenschapsversie duidelijk maken. Het kan zijn dat klanten geen abonnement kopen en bij
problemen een beroep doet op de reseller om de problemen op te lossen. Wanneer de mensen
van Xplore Group een aantal dagen bij dat bedrijf moeten langsgaan om dat probleem op te
lossen kan de factuur die zij betalen zelfs hoger zijn dan een jaarlijks abonnement voor JBoss.
Daarom dat Xplore Group aan klanten het aankopen van abonnementen aanraadt.
Het enige nadeel dat bedrijven kunnen ervaren wanneer zij werken met de bedrijfsversie is dat
deze versie technologisch achter zit op de gemeenschapsversie. Dat komt omdat Red Hat de
projecten die actief zijn in de JBoss gemeenschap eerst moet analyseren, daaruit een
samenstelling maken van de beste projecten, deze samenstelling testen en debuggen… alvorens
te komen tot de bedrijfsversie die klaar is voor gebruik in een professionele omgeving.
Voor een klant is de TCO een belangrijk gegeven. De TCO voor JBoss ligt meestal lager dan die
voor IBM WebSphere, maar er zijn wel een aantal elementen die hier invloed op hebben.
Wanneer een klant bijvoorbeeld van IBM WebSphere wenst over te gaan naar JBoss is daar
steeds een migratiekost aan verbonden samen met kostbare tijd. Er moet een studie worden
gedaan om het huidige kostenplaatje te vergelijken met het implementeren van JBoss als
applicatieserver. Voor Xplore Group is het verzorgen van deze migratietrajecten ook een deel
van hun activiteiten.
3. Financiële Stromen en Partnerprogramma
Een eerste vaststelling die kan worden gemaakt is dat Xplore Group eigenlijk onmiddellijk van
het “ready partner level” naar het “advanced partner level” is gegaan. Ten eerste moet er een
81
vergoeding betaald worden om tot dat niveau te behoren. Daarnaast is het ook belangrijk om een
bepaald aantal mensen bij JBoss een opleiding te laten volgen en hen dus aan de hand van een
examen certificaten te laten behalen. Het verschil tussen het “ready partner level” en het
“advaced partner level” is dus enerzijds het kostenplaatje en anderzijds het aantal mensen in je
organisatie met een bepaalde kennis van JBoss. Een ander groot verschil is de korting die je als
reseller krijgt bij het “advanced partner level”. Xplore Group krijgt dus extra korting bij de
distributeur en zij kunnen ook op die manier licenties goedkoper aankopen en klanten een
korting aanbieden. Deze kortingen worden dus niet vermeld in de partnerprogramma’s zoals we
eerder hebben gezien.
De verantwoordelijke bij Xplore Group heeft geen notie van enige grote verschillen in
partnerprogramma’s tussen IBM of JBoss. Over het algemeen zijn de partnerprogramma’s in
dezelfde stijl, zoals de vereiste om een aantal gecertificeerde mensen te hebben, betalen van een
jaarlijkse vergoeding… Het grote belang van deze partnerprogramma’s ligt in de waarde die ze
creëren voor de reseller en het OSS bedrijf. De reseller moet zich engageren ten opzichte van het
OSS bedrijf door aan een aantal voorwaarden te voldoen zoals het betalen van een vergoeding en
het opleiden van mensen. Daartegenover staat dat het OSS bedrijf zich ook engageert door
korting te bieden, door verkoopsondersteuning, marketingondersteuning… Het feit dat je partner
bent bewijst ten opzichte van de klant dat je over een aantal competenties beschikt met
betrekking tot de technologie. Het laat zien dat je een samenwerking hebt met de mensen van
JBoss, dat je als partner bij problemen rechtstreeks bij JBoss terecht kan en dat je toegang hebt
tot een bepaald netwerk voor ondersteuning.
Binnen het partnerprogramma van JBoss kan nog een derde partnerniveau worden onderscheiden
namelijk het “premier level”. Er is feitelijk niet erg veel verschil tussen het “advanced partner
level” en het “premier partner level”. De reseller wordt dan wel op de website van Red Hat
geregistreerd als “premier partner” en mag het logo van de “premier partner” gebruiken. Om tot
dit partnerniveau te geraken moeten er meer gecertificeerde mensen bij de reseller zijn. Eén extra
functionaliteit of dienst die interessant zou zijn voor Xplore Group en die bij het “premier
partner level” bijkomt is deze van professionele diensten. Het is zo dat Red Hat over een aantal
mensen beschikt die verspreid zijn over heel de wereld. Voor zeer grote problemen kunnen deze
82
mensen komen helpen, maar dat is zeer duur. Als “premier partner” kan met de mensen van de
reseller en deze deskundigen een samenwerking worden opgebouwd.
4. Keuze en Strategie
Het verkopen van licenties of abonnementen is helemaal niet de activiteit waarop men binnen
Xplore Group de focus legt. Voornamelijk de diensten en kennis rond de producten die men kan
verkopen is de kern van hun commerciële activiteiten. De licenties voor producten van IBM
worden in de meeste gevallen rechtstreeks verkocht door IBM zelf. JBoss daarentegen doet dit
enkel via hun partnerkanaal.8
De keuze van Xplore Group om JBoss in het aanbodpakket op te nemen komt vanuit een tweetal
overwegingen. Ten eerste staan de mensen van Xplore Group volledig achter het OS principe.
Zij zagen een gat in de markt, een opportuniteit vanuit de OS wereld en zijn daar voor gegaan.
Zij hebben dan ook de voorbije tien jaar geen ongelijk gekregen, wat wordt bewezen met de
winstgevende activiteiten die zij uitvoeren. Een tweede belangrijke reden voor Cronos om te
focussen op verschillende technologieën is de bedoeling om niet afhankelijk te zijn van één
bepaald softwarebedrijf.
4.3.3 Interview Realdolmen
De structuur en manier van werken bij Realdolmen vertoont grote verschillen t.o.v. Xplore
Group en Capgemini. De persoon die ik heb gesproken bij Realdolmen, Mr. De Pelecijn, had
meer kennis van Linux Red Hat, maar had ook wel kennis van JBoss Red Hat. Vandaar dat er
tijdens het interview van deze opportuniteit werd gebruik gemaakt om kort een vergelijking te
maken tussen de twee en wat dat betekent voor de reseller.
1. Realdolmen
Realdolmen helpt zijn klanten met het vertalen van de bedrijfsstrategieën, in efficiënte en
betrouwbare IT-oplossingen die werken binnen een vooropgesteld budget en een vooropgestelde
periode. Bedrijven hebben nood aan op maat ontwikkelde bedrijfsprocessen en IT-omgeving om
de bedrijfsdoelstellingen te halen. Doorheen de organisatie wordt er gebruik gemaakt van een
projectaanpak met de bedoeling om tastbare resultaten, kwaliteitscontrole en voortdurend
8 In België
83
toezicht te bekomen. Klanten die kiezen voor Realdolmen kiezen voor een single-source
leverancier met uitgebreide expertise in verschillende sectoren, een ervaren team, een uitgebreid
portfolio aan IT-competenties en een sterk netwerk van partners.9
In een eerste luik van de organisatie, Sales & Marketing, is er een verkoopsstructuur met
verkoopsmanagers en accountmanagers. Dat zijn teams die opgedeeld zijn per sector, ze werken
verticaal binnen Realdolmen zoals in de gezondheidszorg, de industrie... Die accountmanagers
hebben elk een lijst met klanten waarop ze jaarlijks een cijfer moeten behalen. Een tweede luik is
de “business development” omgeving. Daarin heb je terug een aantal eenheden zoals “business
solutions”, “professional services” en “infrastructure products”. De mensen in dit gedeelte
werken dan horizontaal, er wordt dan niet gewerkt volgens een bepaalde lijst met klanten, maar
er wordt gewerkt waar er klanten zijn.
Om IT-oplossingen te kunnen leveren bij bedrijven is er nood aan verschillende competenties.
Als het wordt bekeken als een ketting is er om te beginnen een eindgebruiker in een firma, die
heeft een pc en maakt gebruik van applicaties in een netwerk in een datacenter en in dat
datacenter heb je servers en applicaties draaien. Elke schakel in deze ketting is belangrijk, maar
in de meeste organisaties wordt elke schakel apart benaderd. De reden hiervoor is dat er telkens
andere kennis nodig is.
Vroeger was er bij Realdolmen een duidelijk onderscheid tussen infrastructuur en applicaties.
Maar nu wordt dat benaderd als een geïntegreerd geheel en worden er synergieën gezocht tussen
de verschillende departementen. Er zijn dus wel grenzen binnen de verschillende departementen,
maar het is ook wel duidelijk dat er veel crossfunctionele samenwerking is. Binnen het
infrastructuurgedeelte is Mr. De Pelecijn bezig met “Managed Services” waarbij een aantal taken
van de klant worden overgenomen. Dat kan gaan over onderhoud, ondersteuning … tot het
gezond houden van de infrastructuur op het hoogste niveau van de applicatie, of het volledig
overnemen van het IT luik van de klant.
2. Klanten
Voor klanten is het belangrijk dat OSS goedkoper is. Het gaat dan ook om een verhaal met twee
kanten. Van de meeste OSS zoals JBoss en Linux zijn er steeds twee verschillende versies. Er 9 http://www.realdolmen.com/
84
zijn projecten in de gemeenschap zoals Fedora die worden ondersteund door Red Hat en die
gratis zijn, maar dan heb je ook nog projecten zoals Red Hat Enterprise Linux en de
bedrijfsversie van JBoss die zich richten op de commerciële markt. Enerzijds voorzien deze OSS
bedrijven dus in ondersteuning en ontwikkeling in de ontwikkelingsgemeenschap en anderzijds
zijn zij bezig met het samenstellen en testen van een stabiele versie voor bedrijven. Bij JBoss zie
je dit heel duidelijk, er wordt dus steeds gesproken over de “.org” versie, de gemeenschapsversie
die gratis is en de “.com” versie ontwikkeld of samengesteld door Red Hat. De “.org” versie is
duidelijk goedkoper, maar daar is er enkel ondersteuning op basis van de goodwill van de
gemeenschap. JBoss Red Hat blijft de “.org” versie ondersteunen en verder ontwikkelen, maar
zij halen hun geld uit abonnementen voor ondersteuning voor de “.com” versie. Dat is de reden
waarom “JBoss.org” de grootste concurrent van JBoss Red Hat is. Het is dan ook een uitdaging
voor de reseller om dit soort software te verkopen. Er zijn veel bedrijven die JBoss
implementeren en de gratis versie gebruiken, maar voor bedrijfskritische bedrijfsprocessen is er
ondersteuning nodig en dat is de waarde dat een abonnement biedt aan de klant. In vergelijking
met andere middelware zoals WebSphere en WebLogic is de bedrijfsversie van JBoss
goedkoper.
In de Belgische markt kan een trend naar OSS worden opgemerkt. Java is ook meer aanwezig in
bedrijven en zal waarschijnlijk nog verder groeien. Vele Universiteiten zijn ook vaak met OSS
bezig in plaats van met Microsoft of andere eigendomssoftware, dus als studenten afstuderen en
in het bedrijfsleven terechtkomen in een IT-afdeling, staan zij daar meer voor open.
Een klant kan er ook voor kiezen om over te gaan van bijvoorbeeld WebSphere naar JBoss, maar
het is niet zo eenvoudig om van het ene platform naar het andere over te gaan. Maar na deze
omzetting kan er wel worden geprofiteerd van een lagere abonnementenkost. Op deze manier is
de TCO van JBoss lager dan bijvoorbeeld deze van WebSphere.
Voor Realdolmen is het belangrijk dat klanten een abonnement aankopen bij het OSS bedrijf.
Realdolmen is verantwoordelijk voor de totale applicatie, maar wanneer het gaat om een
specifiek probleem met de software van JBoss moet het mogelijk zijn om de
verantwoordelijkheid door te schuiven naar JBoss. Een klant die werkt met de
gemeenschapsversie is dus eigenlijk afhankelijk van de goodwill van de mensen in de
gemeenschap bij problemen.
85
3. Financiële Stromen en Partnerprogramma
Realdolmen is “premier partner” van Red Hat voor zowel Red Hat Linux Enterprise als JBoss
Red Hat. Voor beiden wordt jaarlijks een partnervergoeding betaald. Jaarlijks wordt er samen
met Red Hat een bedrijfsplan opgesteld, er wordt een gemeenschappelijk plan opgesteld voor
zowel Red Hat als JBoss. Bij Realdolmen is het steeds de bedoeling dat als zij voor een bepaald
product kiezen ze tot het hoogste partnerniveau gaan. Zeker op technisch vlak trachten zij zich
daar te onderscheiden door verder te gaan tot op het hoogste technische niveau. Zij streven er
steeds naar die competenties te halen zodat zij zich daar mee kunnen onderscheiden en projecten
zo goed mogelijk kunnen afhandelen.
Er kan ook worden geconcludeerd dat het eerste niveau een soort instapniveau is dat voor bijna
iedereen toegankelijk is en dat men kan toetreden door een aantal zaken op de website aan te
klikken en in te vullen.
Wanneer dieper wordt ingegaan op de partnerprogramma’s worden een aantal onderdelen even
toegelicht. Er is steeds een marketing gedeelte in de partnerprogramma’s waardoor een reseller
voor bepaalde acties die hij organiseert ondersteuning kan krijgen. Een term die men kan
terugvinden bij de meeste softwarebedrijven is “Marketing Development Fund”. Bij de ene moet
men het project voorstellen en kan men zo financiering bekomen, bij anderen krijgt de reseller
een vast jaarlijks bedrag dat kan worden besteed. In België zijn er voor de
verkoopsondersteuning van Red Hat een drietal mensen. Er is iemand verantwoordelijk voor de
verkopen, er is een partnermanager en er is iemand die verantwoordelijk is voor alles wat te
maken heeft met presales. De verkoopsverantwoordelijke heeft een vaste lijst klanten waarmee
wordt gewerkt. Wanneer de reseller bij een klant werkt die op deze lijst staat, wordt er samen
met deze verantwoordelijke gewerkt. Wanneer het om een andere klant gaat zal de
partnermanager voorzien in commerciële ondersteuning. Het is mogelijk dat de reseller beslist
om het werk alleen te doen maar het is soms makkelijker om samen met de mensen van Red Hat
in een team te werken. Dit is een systeem dat werkt bij alle softwarebedrijven.
Hieruit blijkt dan ook dat er op zich niet veel verschil is tussen de partnerprogramma’s van
verschillende softwarebedrijven. Het enige grote verschil dat er is, heeft betrekking op de grootte
van het softwarebedrijf. Microsoft werkt bijvoorbeeld op dezelfde manier als een kleiner bedrijf
86
zoals Red Hat, maar is veel groter. Er zijn dus ook veel mensen betrokken en meer resellers die
ook partner zijn met Microsoft. De vraag is dan ook of Microsoft gebruik maakt van zijn grootte
en macht om druk uit te oefenen op resellers. Maar het is beter de vergelijking te maken met een
huwelijk. Beiden, zowel het softwarebedrijf als de reseller, hangen van elkaar af. Zeker wanneer
het gaat om een reseller van de grootte van Realdolmen. Zij hebben wel degelijk een stem bij het
softwarebedrijf. Hoe meer omzet een reseller bij een softwarebedrijf heeft, hoe luider zijn stem is
en als zij de reseller verliezen hebben zij een probleem en omgekeerd als de reseller het
softwarebedrijf verliest heeft de reseller ook een probleem. Soms zijn er wel eens problemen,
maar blijven samenwerken is voor beiden een voordeel.
4. Keuze en Strategie
Realdolmen heeft ongeveer 8 jaar geleden gekozen om samen te werken met Red Hat. Het team
dat toen voor Red Hat heeft gekozen, heeft bepaalde procedures uitgevoerd die men steeds moet
verrichten wanneer een bepaald product of technologie wordt overwogen. Eerst gebeurt er een
doorlichting van de markt, om na te gaan wat de verschillende mogelijkheden zijn. Dan wordt er
geëvalueerd of deze oplossingen technisch waardevol zijn. Daarna wordt er gekeken hoe de
partnerships juist werken, hoeveel resellers er reeds zijn voor de technologie. Er wordt ook
nagegaan of deze oplossing wel past in het productgamma en men onderzoekt wie er juist achter
het product staat en hoe daarmee wordt samengewerkt.
Voor het kiezen van een applicatieserver wordt er eerst gekeken naar de taal waarin de applicatie
moet worden ontwikkeld bij de klant. Als er voor de programmeertaal Java wordt gekozen zal
men afhankelijk van de klant voor een bepaalde applicatieserver kiezen. Men gaat dan na wat de
klant zoal heeft, waar de klant naartoe wil of moet en op die manier wordt er voor een bepaalde
applicatieserver gekozen. Realdolmen doet dus JBoss, WebSphere en nog een aantal andere.
Het verkopen van licenties is niet het belangrijkste voor Realdolmen. Wat belangrijk is, is de
mogelijkheid om mensen te verhuren om applicaties te schrijven. Licenties of abonnementen
voorzien eerder in de mogelijkheid om de mensen aan het werk te zetten en diensten te verkopen.
OSS vanuit ideologie heeft geen plaats in een bedrijf. Bij de keuze voor JBoss was het belangrijk
om het team van Java ontwikkelaars in overweging te nemen. Als het team van ontwikkelaars bij
Realdolmen niet aan het werk is, dan kost dat geld want die mensen kosten de reseller geld of zij
87
nu aan een project werken of niet. Dus het is belangrijk dat deze programmeurs projecten hebben
om aan te werken. JBoss is één van de strategische producten in heel die stack die aan klanten
wordt aangeboden.
Linux Red Hat behoort tot de infrastructuursoftware. Het infrastructuurgedeelte is volledig
anders dan het applicatiegedeelte. Er is andere expertise en andere kennis nodig bij de mensen
die verantwoordelijk zijn voor dit gedeelte. Een klant heeft bijvoorbeeld infrastructuur, servers,
storage, back-up... nodig, dus alles om applicaties op te laten draaien. Dat moet allemaal in
elkaar worden geknutseld en integratie van de verschillende elementen is daarbij belangrijk.
Voor Realdolmen zijn deze professionele diensten, zoals op-maat-ontwikkeling, het verzorgen en
realiseren van projecten… dan ook heel belangrijk omdat men daar meer marge kan op krijgen
dan op het doorverkopen van software en hardware. Software wordt doorverkocht op dezelfde
manier als hardware. Software heeft net als hardware een aankoopprijs, een “uplift” of marge en
een verkoopprijs. Of het gaat om software of hardware, dat heeft niet veel invloed op die marge
bij het doorverkopen van producten. Als reseller zit je in competitie met anderen die van
dezelfde aankoopprijs vertrekken. Er is weinig toegevoegde waarde in deze situatie. Vandaar dat
veel resellers zich profileren als solution providers, system integrators, consultants om op die
manier professionele diensten te verkopen waar de reseller dus meer marge op verdient.
Bij de vraag op welke manier het mogelijk is om die marges voor de reseller te verbeteren kan er
wel worden gewezen op een aantal elementen in het partnerprogramma van softwarebedrijven.
Vaak is het zo dat er bij een aankoop een heel deel presales aan vooraf gaan. Dit is dus de initiële
fase waarin het project wordt ontwikkeld door verschillende meetings, technische demo’s... Dit
kan gemakkelijk een periode van 6 maanden bestrijken. Als de reseller een klant kan overtuigen
van bijvoorbeeld een bepaalde applicatieserver, kan de reseller deze klant registreren bij het
softwarebedrijf. Dit noemt men “lead registration”. Het kan zijn dat na deze presales, de klant
alsnog verkiest om bij een andere reseller te gaan omdat die een lagere prijs aanbiedt. Op die
manier kan het zijn dat een reseller een klant warm maakt voor een bepaald product en op het
laatste moment de klant alsnog verliest. Indien er mogelijkheid is tot “lead registration” kan de
reseller toch nog een vergoeding krijgen voor de presales.
88
In infrastructuurprojecten is het zelden mogelijk om de diensten die in de presalesperiode
worden geleverd te laten vergoeden. Bij applicaties is dat anders, omdat wanneer een applicatie
moet worden geschreven er eerst een analyse moet worden gedaan die wel vergoed kan worden.
Dan is het minder erg als een concurrent met het project gaat lopen omdat een deel van het werk
dat werd afgeleverd reeds betaald is.
Het idee dat OSS “vendor lock-in” zou vermijden is niet iets dat kan worden bevestigd. De reden
hiervoor is dat de belangrijkste leden van de JBoss gemeenschap ook werknemers zijn van JBoss
Red Hat. Wat wel kan worden voorgedragen als voordeel is de flexibiliteit en verplaatsbaarheid
die beter is bij OSS dan bij eigendomssoftware.
4.3.4 Interview Capgemini
1. Capgemini
Capgemini is een internationaal bedrijf dat actief is in meer dan 30 landen. Zij hebben meer dan
90 000 mensen in dienst en zijn vooral actief in India, Frankrijk, Engeland, de VS en Nederland.
Capgemini is van Europese oorsprong en heeft zijn hoofdzetel in Parijs. België heeft een kleinere
afdeling die zich bevindt in Diegem waar zo’n 700 mensen werken. Elke vestiging is
gestructureerd op dezelfde manier, ze is namelijk opgedeeld in vier verschillende disciplines. De
vier disciplines die binnen Capgemini bestaan zijn “consulting”, “outsourcing”, “technology
services” en “financial services”. De consultingdiscipline is niet alleen beperkt tot IT-consulting,
maar ook managementconsulting, fiscale consulting, milieuconsulting… Bij outsourcing wordt
het beheer van de applicaties en infrastructuur van een bedrijf overgenomen. “Technology
services” is professionele dienstverlening rond IT. De focus is hier wel meer op de applicatie
markt en niet zozeer op de infrastructuurmarkt. Binnen outsourcing is er een gedeelte
infrastructuur, maar dat is eerder beperkt. De dienstverlening met betrekking tot applicaties kan
gaan van het opleiden van werknemers tot het volledig uitvoeren van IT projecten.
Binnen deze discipline zijn er nog een aantal “service lijnen” of domeinen die bezig zijn met een
specifieke technologie. Het gaat hier om een zestal verschillende domeinen: Business
Intelligence, Enterprice Content Management, ERP systemen, legacy, Graphical Information
Systems en Java. Mr. Eggenstein behoort tot deze laatste groep en is daar vooral bezig met de
oplevering van projecten. Dat betekent dat hij verantwoordelijk is voor een eenheid van mensen
89
die de projecten effectief uitvoert bij klanten en deze mensen aanstuurt in het kader van
competentie ontwikkeling en people management. Daarnaast is hij ook bezig met het zoeken van
nieuwe projecten en nieuwe klanten.
In het kader van OSS is Capgemini in België voornamelijk bezig met de applicatiesoftware, dat
is dus het bouwen van nieuwe toepassingen met behulp van OSS. De focus ligt voornamelijk op
Java ontwikkeling waar zij werken met een aantal OS frameworks en applicatieservers zoals
Tomcat en JBoss. Binnen heel die groep van OS applicatieservers richten zij zich voornamelijk
op JBoss. De reden hiervoor is dat het gaat om OSS waar een groot bedrijf, namelijk Red Hat,
achter staat.
Capgemini is ook reseller van WebSphere (van IBM) en WebLogic (van Oracle). Heel wat grote
klanten bij Capgemini werken met WebSphere van IBM. Dit komt voor een gedeelte doordat
deze grote klanten ook in het bezit waren van mainframes van IBM.
Een groot deel van de zaken die verder worden besproken gaat over het verkopen van projecten
aan klanten. Daarom wordt eerst kort even besproken wat zo’n project juist inhoudt en wat de
diensten zijn die zij aanbieden binnen zo’n project.
Wanneer een klant bijvoorbeeld een internetapplicatie wil bouwen, zijn er heel wat stappen die
daaraan vooraf gaan. Eerst en vooral moet er een behoefteanalyse of studie gebeuren. De reseller
moet nagaan wat de klant juist wil, wat belangrijk is, wie de eindgebruikers zijn... Deze stap is
gemiddeld 5 à 10 procent van het budget. Daarna gebeurt er een detailanalyse waar men
onderzoekt hoeveel schermen er nodig zijn, welke knoppen er op die schermen moeten, welke
gegevens er nodig zijn... Hier gaat het hier om een functionele en technische analyse. Deze stap
kan 40 tot 50 procent van het totale budget inhouden. De stap die daarop volgt is deze van het
effectief ontwikkelen van de applicatie in een bepaalde technologie. Afhankelijk van hoe groot
en hoe complex het project is zal deze dienst voor 40 procent deel uitmaken van het budget. Als
laatste is er nog een 10 tot 20 procent over voor testen, de installatie, configuratie van hardware
en installatie van de applicatieserver. Bij Capgemini gaat het dus voornamelijk om de
behoeftestudie, de functionele en technische analyse, de ontwikkeling en dan nog het testen.
Daarna komt nog er een infrastructuur- en netwerkgedeelte bij dat door de klant zelf of door
derden wordt opgezet.
90
2. Klanten
Klanten die bezig zijn met Java ontwikkeling gebruiken in ontwikkelingsactiviteiten bijna altijd
JBoss. De reden hiervoor is dat wanneer men met Java ontwikkeling bezig is men bijna
automatisch in aanraking komt met JBoss. In vele IT departementen kan worden vastgesteld dat
technische mensen de ontwikkeling doen op JBoss.org. Dat is gratis, dat werkt goed en is
‘lightweight’. Wanneer de applicaties effectief in productie worden gezet, gebeurt dat op
WebSphere of Oracle. Het komt er dus op aan een klant te overtuigen van de kwaliteit van JBoss
en te wijzen op de goede professionele ondersteuning door Red Hat. Het kan zijn dat de klant
dan een abonnement voor JBoss aankoopt.
Capgemini geeft aan dat een ruim aantal grote klanten ook voor JBoss durft kiezen en dat zeker
de laatste twee jaar die markt toegankelijker is geworden voor het OS concept. Een belangrijk
gegeven hierbij is opnieuw de TCO. Aangezien de TCO lager is voor JBoss in vergelijking met
commerciële systemen is dit zeer aantrekkelijk voor klanten. Daarbij komt het feit dat bedrijven
willen besparen. Vrij vaak wordt er dan ook gekozen voor het stopzetten van licenties of
verlagen van de licentiekosten en daar is JBoss de ideale kandidaat voor.
Een ander belangrijk aspect is de kost verbonden aan de migratie van de ene applicatieserver
naar de andere. Daar zijn een aantal kosten aan verbonden die niet verwaarloosbaar zijn en een
invloed hebben op de TCO. Om volledig te begrijpen waarom dit zo is en hoe deze migratie een
invloed heeft op de TCO wordt hier dieper op ingegaan.
In principe worden er binnen de Java gemeenschap op democratische wijze Java specificaties
overeengekomen. Er zijn wel een aantal bedrijven die daar invloed op hebben, maar algemeen
genomen zijn deze specificaties niet gebonden aan één softwarebedrijf. Alle softwarebedrijven
met Java applicatieservers moeten deze specificaties respecteren en implementeren om
compatible te zijn met Java software. Een groot deel van die applicatieservers is compatibel met
deze specificaties, maar vaak worden er toch bepaalde specificaties geïmplementeerd die
softwarebedrijven intern hebben ontwikkeld. In veel applicaties die dan ontwikkeld is op
bijvoorbeeld WebSphere of Oracle worden API’s (Application Programming Interface) gebruikt
die door IBM of Oracle in kwestie ontwikkeld zijn en niet compatibel zijn met de standaarden.
Het gevolg is dat wanneer de applicatie van deze servers wordt afgenomen en op JBoss wordt
91
gezet, deze applicatie niet meer werkt. Er moet dus een migratiestudie worden gedaan om na te
gaan in welke mate dit een invloed zal hebben op de migratie.
De migratiestudie zal een aantal zaken analyseren om na te gaan wat het verschil in TCO zal zijn
na de migratie. Ten eerste wordt nagegaan wat het effect is van het wegvallen van de
licentiekosten voor de huidige software in vergelijking met de abonnementskosten voor JBoss.
Ten tweede wordt er ook nagaan of het mogelijk is om goedkopere infrastructuur te gebruiken in
vergelijking met de huidige infrastructuur. Als laatste wordt een analyse gemaakt van de kost die
wordt gemaakt bij het overbrengen van de applicaties naar JBoss en daar zit meestal de grootste
kost als zo’n operatie wordt uitgevoerd. Dit is zeker zo in het geval dat er bepaalde API’s werden
gebruikt die specifiek ontwikkeld zijn bij één bepaald softwarebedrijf. De beslissing die moet
worden genomen om al dan niet te migreren wordt dan ook vaak op basis van deze laatste
genomen.
Voor Capgemini is het niet echt een voordeel dat de broncode van JBoss vrij beschikbaar is.
Voor klanten is het vooral een voordeel wanneer een applicatie in productie staat en er
problemen opduiken. Men heeft dan namelijk de vrijheid om zelf tot op het laagste niveau van
het systeem te gaan en te kijken waar het probleem zit om het op te lossen. Vaak is het zo dat
wanneer er problemen zijn, de klant naar het softwarebedrijf moet gaan om het probleem te
rapporteren. Bij sommige softwarebedrijven kan het lang duren vooraleer de klant wordt
geholpen of er kan zelf een discussie ontstaan over de oorzaak van het probleem.
3. Financiële Stromen en Partnerprogramma
Klanten kunnen op verschillende manieren in contact komen met de producten van een bepaald
softwarebedrijf. Het softwarebedrijf heeft vaak een eigen sales- of presalesteam dat rechtstreeks
naar bedrijven gaat en hen tracht te overtuigen om hun product te kopen. Een groot bedrijf dat
geïnteresseerd is in WebSphere zal zijn aankoop ook niet doen via een reseller of integrator,
maar die zal daarvoor IBM rechtstreeks benaderen. Een softwarebedrijf zoals IBM zal tegelijk de
resellers aanmoedigen om bij klanten IBM te verkopen. De resellers worden door middel van
referral vergoeding aangemoedigd en beloond wanneer een reseller bijvoorbeeld WebSphere kan
verkopen. Referral vergoedingen worden betaald door zowel IBM, Oracle als Red Hat.
92
Wanneer het gaat om grote klanten zullen softwarebedrijven de potentiële klant zelf afhandelen.
Bij kleinere bedrijven zullen zij een partner contacteren in hun ecosysteem van partners en de
klant verder doorverwijzen naar deze partner. Welke partner het softwarebedrijf contacteert
hangt af van het feit welke partner in de ogen van het softwarebedrijf de meeste kans maakt om
hun software te verkopen. Zij zullen dus niet kiezen voor een reseller die consistent
concurrerende software bij klanten aanbeveelt. Het gaat dus vaak om delicate zaken, waar de
keuze die wordt gemaakt afhangt van subtiliteiten.
In het partnerprogramma van vele softwarebedrijven krijgen resellers naast een marge op de
licenties of abonnementen die ze kunnen verkopen ook een vergoeding voor het aantal nieuwe
klanten dat zij kunnen binnenhalen. Dus als een bepaalde reseller een lead effectief kan omzetten
in een verkochte licentie krijgt deze reseller op het einde van de maand een soort bonus. Voor
een softwarebedrijf is het verkopen van zoveel mogelijk licenties de belangrijkste commerciële
activiteit, zij voorzien meestal niet in diensten zoals integratie en implementatie. Dat laten de
softwarebedrijven over aan de resellers.
In de IT wereld zijn partnerprogramma’s en partnernetwerken een veel voorkomend fenomeen.
De vraag voor resellers is dan op welke manier je een voordeel hebt als je deel uitmaakt van zo’n
partnerecosysteem. uiteindelijk is iedereen partner van iedereen. Een partnerrelatie moet dan ook
worden beschouwd als iets dat nodig is om in die wereld te ‘overleven’.
Vooral de grootte van het bedrijf heeft een invloed op de partnerrelatie. Grote bedrijven die
werken samen met andere grote bedrijven. Grote bedrijven zullen er altijd voor zorgen dat deze
grote bedrijven bevooroordeeld worden t.o.v. kleinere bedrijven die ook partner zijn. Wanneer er
voor IBM een potentiële deal is bij een grote klant, zal IBM eerder geneigd zijn om Capgemini te
contacteren dan bijvoorbeeld Realdolmen. Capgemini heeft meer mensen in dienst die hun
technologie kennen, zij hebben ook meer kans om een project te verkopen, omdat een groot
bedrijf graag zaken doet met een ander groot bedrijf. Het gaat hier dus om een soort ecosysteem
dat natuurlijk groeit. IBM is de grootste partner van Capgemini omdat ook de producten van
IBM bij 90 à 95 procent van de klanten van Capgemini aanwezig zijn. Als bedrijf kom je
automatisch terecht in een bepaald ecosysteem, waar je moet in meespelen. Als reseller ben je
dan verplicht om in zo’n partnernetwerk te stappen. Dat kan beschouwd worden als een extra
stimulans om meer met het softwarebedrijf samen te werken. De grootste bron van inkomsten
93
voor een reseller komt voort uit de diensten die gebaseerd zijn op een bepaalde technologie, maar
komt niet uit de financiële vergoedingen binnen zo’n partnerprogramma.
In de partnerprogramma’s zit er ook ondersteuning voor de resellers of system integratoren.
Wanneer resellers aan een project werken bij een specifieke klant die nog geen ondersteuning
heeft van het softwarebedrijf, kan de reseller de hulp inroepen van het softwarebedrijf in kwestie
om problemen op te lossen. Wanneer Capgemini dan bij een klant komt om een project op te
starten kunnen zij tonen dat ze bijvoorbeeld “advanced” partner zijn van JBoss Red Hat en dat zij
ondersteund worden door JBoss Red Hat en dus recht hebben op ondersteuning binnen een
bepaalde tijdsspanne wanneer er zich een probleem voordoet. Het is dus belangrijk voor een
softwarebedrijf dat, wanneer alle andere softwarebedrijven ondersteuning aanbieden in hun
partnerprogramma, je zelf ook ondersteuning aanbiedt aan partners.
4. Keuze en Strategie
Voor Capgemini zijn dan de diensten die zij kunnen verkopen een belangrijke bron van
inkomsten, zoniet zouden zij JBoss niet in hun aanbodpakket hebben. Maar over het algemeen
geldt dat inkomsten uit marges en referral vergoedingen in functie van het totale project dat aan
een klant wordt verkocht verwaarloosbaar zijn. Het is ook zo dat wanneer zij als “solution
provider” een nieuwe toepassing moeten bouwen voor een klant, deze klant meestal al een
licentie heeft, voor bijvoorbeeld WebSphere of JBoss. Het gebeurt dus zelden dat Capgemini een
licentie voor een bepaalde applicatieserver verkoopt. In het beste geval kan het gebeuren dat de
huidige licenties onvoldoende zijn. Dan moeten er bijkomende licenties worden gekocht omdat
er meer gebruikers op aangesloten worden of omdat er meer functionaliteiten nodig zijn die
nieuwe of meer licenties vereisen.
Het verkopen van licenties is niet de core business, wel het verkopen van diensten. Voor
Capgemini is de verhouding in een project doorgaans zeventig procent diensten en dertig procent
licenties. Er kan een vergelijking worden gemaakt met een pc. Als men een pc aankoopt, zijn er
wel een aantal dingen die direct werken, maar vaak moet men toch eerst een aantal dingen
installeren, configureren... vooraleer de pc in gebruik kan worden genomen. Hetzelfde geldt voor
een applicatieserver, eerst worden de bouwstenen of infrastructuur gekocht maar vooraleer de
94
toepassing effectief klaar is voor de eindgebruiker moeten er nog een heleboel diensten aan
voorafgaan.
Voor Capgemini was de keuze voor JBoss tweeledig. Ten eerste heb je de commerciële kant die
vereist dat het softwareproduct moet kunnen worden gebruikt in bedrijven en dat er dus
professionele ondersteuning moet zijn. Ten tweede is het zo dat de mensen die er mee moeten
ontwikkelen het als een goed product beschouwen dat snel en kwalitatief is.
Vanuit commerciële overweging was de keuze voor JBoss als derde applicatieserver technologie
een vrij eenvoudige keuze. Voor grote bedrijven is er slechts één probleem met OSS en dat is
officiële ondersteuning. Voor OSS is dat de beperking geweest om een grote doorbraak te
kunnen realiseren. Als er wordt beslist om OSS te gebruiken is men in principe bij een probleem
aangewezen op de mensen in de gemeenschap. Voor een groot bedrijf is dat een situatie die niet
toelaatbaar is voor bedrijfskritische toepassingen. JBoss was dan ook tien jaar geleden het eerste
bedrijf dat op basis van OSS commerciële ondersteuning aanbood voor middleware software op
basis van Java. Tot voor kort waren zij de enige die dat deden. Springsource, het bedrijf dat
achter het springframework zit en nu ook een eigen applicatieserver op de markt heeft gebracht,
biedt een gelijkaardig model van professionele ondersteuning voor professionele gebruikers.
Als Capgemini een goede (OSS) concurrent wou voor Oracle en IBM die professionele
ondersteuning kon aanbieden, dan was er maar één alternatief: JBoss. Dit is vanuit het standpunt
van de klant die vraagt naar professionele ondersteuning. Vanuit technisch standpunt is JBoss
minstens even goed als WebSphere of Oracle. Wanneer de snelheid van ontwikkeling en de
voetafdruk van dit framework op infrastructuur worden vergeleken, is dat voor JBoss zelfs beter.
Daarnaast is de TCO ook veel lager in een JBoss omgeving dan bij Oracle of WebSphere, omdat
dit veel kleiner is in omvang dan WebSphere of WebLogic.
Er kan een eenvoudige vergelijking worden gemaakt met bijvoorbeeld Microsoft Office. Vele
mensen hebben deze tekstverwerker, maar de meesten van hen gebruiken slechts tien procent van
al de functionaliteiten die beschikbaar zijn. Het is bijvoorbeeld ook mogelijk om met notepad,
dat iets simpeler is, een brief of een tekstje te schrijven. Hieruit kan worden geconcludeerd dat
veel mensen enkel notepad nodig hebben en dat het voor dit soort gebruikers niet nodig is om
veel geld te spenderen aan functionaliteiten die men toch niet gebruikt. JBoss heeft dus ook een
95
softwareproduct ontworpen voor Java ontwikkeling, maar is simpeler en eenvoudiger en kan
worden gebruikt voor lightweight toepassingen. JBoss is vergelijkbaar in kwaliteit, snelheid en
beveiliging dan de grotere systemen. Daarom is het mogelijk om met dit softwareproduct een
ander deel van de markt te kunnen veroveren. De klanten die WebSphere of WebLogic kopen
hebben graag software die veel functionaliteiten omvat en hebben het budget om deze producten
te kopen. Daartegenover staat de JBoss klant die een basispakket wil dat goed werkt, de
belangrijkste functionaliteiten omvat en minder kost.
Wanneer Capgemini bij klanten komt en een applicatieserver moet voorstellen is de vraag: welk
softwarepakket zullen zij dan aanbevelen en waarom? Er wordt dan een evenwicht gezocht of
“trade-off” gemaakt tussen een aantal zaken. Een eerste punt waar rekening moet mee gehouden
worden is de kans dat een bepaald product een specifieke klant aanspreekt. Bij een groot bedrijf
is het niet meteen aangewezen om JBoss aan te bevelen in plaats van WebSphere. Bij een klant
die tegen ‘commerciële’ zaken is zal het eerder aangewezen zijn om JBoss aan te bevelen. Als
veel software bij een bepaalde klant afkomstig is van bijvoorbeeld Oracle, dan is het ook logisch
dat er dan een applicatieserver van Oracle wordt voorgesteld.
Het is niet eenvoudig om een evenwicht te vinden tussen enerzijds een keuze voor een bepaald
softwarebedrijf bij een klant en anderzijds de samenwerking met al de softwarebedrijven
waarmee je een samenwerkingsrelatie hebt. Voor Capgemini draait vooral om de klant en dat de
klant inhoudelijk en kwalitatief het beste krijgt voor zijn noden in de gegeven omstandigheden.
Meer specifiek gaat het om wat de klant juist nodig heeft, wat hij al heeft, hoeveel financiën hij
hiervoor heeft, ...
IBM stelt dan ook de vraag aan Capgemini “waarom werken jullie niet alleen met ons, waarom
werken jullie nog met anderen?”. Capgemini is er als system integrator in de eerste plaats om de
klant te dienen binnen zijn eigen mogelijkheden, beperkingen, behoeften en middelen.
Sommige resellers maken de keuze om met één bepaald softwarebedrijf te werken. Het gaat er
dus om dat de gekozen strategie optimaal wordt uitgevoerd.
96
4.4 Horizontale analyse
4.4.1 Klanten
De perceptie van klanten over OSS is iets waarover in de drie interviews werd gesproken. Er zijn
heel wat vooroordelen en misvattingen over OSS. Doordat velen niet weten dat er bedrijven zijn
die professionele ondersteuning bieden voor OSS beschouwt men dat als volledig gratis
software. De reden waarom veel bedrijven geen OSS gebruiken is omdat voor bedrijfskritische
toepassingen er nood is aan veilige software die wordt ondersteund door een bedrijf.
Het feit dat er professionele ondersteuning is door een bedrijf is een eerste reden waarom klanten
OSS kopen. Ten tweede is het ook zo dat de IT-budgetten dalen en dat vele bedrijven kosten
willen besparen. Dat is de reden waarom meer en meer bedrijven dan ook OSS in beschouwing
nemen. De TCO voor OSS is vaak lager dan voor eigendomssoftware.
Wanneer een bedrijf ervoor kiest om te migreren van een bepaalde applicatieserver, bijvoorbeeld
WebSphere, naar JBoss moet er een migratiekost in rekening worden gebracht die vaak de TCO
doet stijgen. Er wordt dan meestal een migratiestudie gedaan om na te gaan wat de
moeilijkheden en kosten van zo’n migratie zouden kunnen zijn.
Voor JBoss is het ook zo dat in de meeste bedrijven er reeds met de gemeenschapsversie wordt
gewerkt. Daardoor kan het soms makkelijker zijn om abonnementen voor JBoss te verkopen.
Het idee dat OSS “vendor lock-in” zou vermijden is niet iets dat meteen bij door de resellers kan
worden bevestigd. Het feit dat de broncode ter beschikking is zorgt wel voor meer flexibiliteit en
verhoogt de verplaatsbaarheid. Het is wel een voordeel voor klanten dat bij problemen ze niet
moeten wachten op de ondersteuning van de softwarebedrijven, ze kunnen namelijk zelf fouten
of problemen herstellen.
Aan het verkopen van OSS is dus een extra uitdaging verbonden. De reseller moet de klant
kunnen overtuigen om een abonnement te kopen bij JBoss om die professionele ondersteuning te
kunnen krijgen. Het is dus belangrijk om duidelijk het voordeel in te zien van de bedrijfsversie
ten opzichte van de gemeenschapsversie. Het enige nadeel voor de bedrijfsversie is dat de
gemeenschapsversie technologisch steeds een stap vooruit is.
97
4.4.2 Financiële Stromen en Partnerprogramma
In een partnerprogramma is het eerste niveau, dat bij JBoss het “ready partner level” is, een soort
van instapniveau. Het is eenvoudig voor een reseller om toe te treden tot dit eerste niveau. De
drie resellers behoren allemaal tot het “advanced level” of het “premier level”.
De partnerprogramma’s van verschillende softwarebedrijven zijn vergelijkbaar met elkaar. Een
partnerprogramma is steeds in dezelfde stijl: er moeten een aantal gecertificeerde mensen zijn, er
moet jaarlijks een partnervergoeding betaald worden... In elk van de interviews worden een
aantal voorbeelden gegeven van wat er zoal in een partnerprogramma aanwezig is, maar geen
enkele reseller kan duidelijk aangeven waar er een opvallend verschil is tussen OSS bedrijven en
eigendomssoftware bedrijven. Dit doet vermoeden dat we hier de term “order qualifier” kunnen
toepassen voor deze partnerprogramma’s.
De theorie over “order qualifier” en “order winner” bepaalt dat in een bedrijf de activiteiten van
een bepaalde strategie kunnen opgedeeld worden in deze twee categorieën. De “order qualifier”
zijn activiteiten die een concurrentiële noodzaak zijn, terwijl de “order winners” een competitief
voordeel zijn. (Hill, 1993) “Succesfactoren zijn variabelen waarop het management een invloed
heeft door beslissingen te nemen. Ze hebben een belangrijke invloed op de algemene
competitieve omgeving van het bedrijf. Maar succesfactoren zijn geen synoniem van competitief
voordeel. Een competitief voordeel is een sterkte, die in een gegeven markt, een invloed heeft op
het klantenbeslissingsproces in het voordeel van het bedrijf.” (Van Den Poel, 2008, pp. 7-8). De
partnerprogramma’s zijn, voor de resellers, een concurrentiële noodzaak en kunnen dus worden
beschouwd als een “order qualifier”.
In zo’n partnerprogramma is het de bedoeling dat de partner een engagement laat zien t.o.v. het
softwarebedrijf door investeringen te doen in: het opleiden van mensen, betalen van een
partnervergoeding, het realiseren van een succesverhaal bij een klant,… Daartegenover staat dat
het softwarebedrijf zich ook engageert t.o.v. de partner door het aanbieden van: kortingen,
verkoopsondersteuning, marketingondersteuning, … Wanneer in een partnerprogramma een
aantal niveaus bestaan, zoals bij Red Hat, zal er op een hoger niveau meer engagement zijn
tussen beide partijen. Om bij Red Hat van het “advanced level” naar het “premier level” te gaan
zijn er meer gecertificeerde mensen nodige bij de partner en zal Red Hat ook professionele
diensten aan de partner bieden.
98
Deelname in een partnerprogramma heeft nog een ander voordeel voor de reseller in de vorm
van een positief signaal naar de klant toe. Het laat namelijk aan potentiële klanten zien dat de
reseller beschikt over competenties met betrekking tot de technologie. Het toont ook dat de
reseller samenwerkt met het softwarebedrijf en dat bij problemen de reseller direct terecht kan bij
het softwarebedrijf.
Wat zowel bij Realdolmen als Capgemini een impact heeft op de manier waarop er wordt
samengewerkt is de grootte van het bedrijf. Grote bedrijven gaan relaties aan met grote
bedrijven. Bij grote bedrijven is de werking van het partnerkanaal meestal meer complexer dan
dat van een kleiner bedrijf zoals Red Hat. Er zijn ook veel meer resellers partner van een groot
bedrijf zoals IBM of Microsoft dan van Red Hat. Het is wel niet zo dat grote bedrijven per se
meer macht zullen uitoefenen op de reseller. Het gaat steeds om een samenwerking waarbij beide
partijen van elkaar afhankelijk zijn.
Software wordt doorverkocht op dezelfde manier als hardware. Er is weinig toegevoegde waarde
bij het doorverkopen van software. Vandaar dat veel resellers zich profileren als solution
providers, system integrators, consultants om op die manier professionele diensten te verkopen
waar de reseller dus meer marge op verdient. De meeste softwarebedrijven bieden in hun
partnerprogramma ook een aantal voordelen aan om meer inkomsten te verdienen uit het
doorverkopen van software. Voorbeelden hiervan is de lead registratie en de referral
vergoedingen
4.4.3 Keuze en Strategie
Het verkopen van licenties is bij geen van de drie resellers de kernactiviteit. Het zijn vooral de
diensten die kunnen worden verkocht die een belangrijk aandeel hebben in de inkomsten van de
resellers. De marges en vergoedingen die te verkrijgen zijn bij het softwarebedrijf zijn
verwaarloosbaar tegenover het totale budget voor een project.
Realdolmen geeft expliciet aan dat het belangrijk is dat de ontwikkelaars die zij in dienst hebben
aan projecten moeten kunnen werken. Als er geen projecten beschikbaar zijn hen genereren zij
geen inkomsten maar representeren zij enkel nog een vaste kost. Het is dan ook een voordeel als
deze technische mensen kennis hebben van verschillende technologieën.
99
Xplore Group verklaart de keuze voor JBoss vanuit twee motivaties. Ten eerste zagen zij een
opportuniteit in de markt en stonden ze achter het OS principe. Ten tweede is het de keuze
binnen Cronos om te focussen op meerdere technologieën om op die manier niet afhankelijk te
zijn van één bepaald bedrijf.
De keuze van Capgemini voor JBoss is vanuit twee overwegingen. Ten eerste kan men pas OSS
verkopen wanneer er een bedrijf is dat professionele ondersteuning aanbiedt. Ten tweede moet
de software ook technologisch vergelijkbaar zijn met andere software. JBoss biedt, in
vergelijking met WebSphere en WebLogic, minder geavanceerde functionaliteiten, maar is wel
gelijk in snelheid, kwaliteit,…
Voor elke reseller staat de klant duidelijk centraal. Het gaat er om wat in het voordeel is van de
klant en niet van de softwarebedrijven of de resellers. Er wordt voor een bepaalde
applicatieserver gekozen afhankelijk van het profiel van de klant, het budget, wat de klant nodig
heeft,…
Het is niet zo dat elk bedrijf nood heeft aan de producten van bijvoorbeeld IBM die meer
functionaliteiten hebben. Vaak is een product zoals JBoss dat goed werkt en kwaliteitsvol is,
maar minder extra features heeft, voldoende voor een klant. Het kan ook zijn dat het budget van
de klant beperkt is en dat in die context JBoss een goede oplossing is. Wanneer een eindklant
reeds in een omgeving werkt die volledig gedomineerd is door IBM producten is het logisch dat
er in die lijn wordt verder gewerkt. Omgekeerd wanneer de eindklant “tegen” IBM is, zal er een
alternatief product moeten worden voorgesteld.
Bij Realdolmen is het steeds de bedoeling om bij een softwarebedrijf tot het hoogste niveau te
gaan. Op die manier hebben ze een competitief voordeel omdat ze zich focussen om de meeste
technische expertise in huis te hebben.
4.4.4 Infrastructuur vs. Middleware
Wat belangrijk is bij de vergelijking tussen infrastructuur en middleware is het feit dat een
reseller software verkoopt zoals hardware wordt verkocht. Er is een aankoopprijs, er is een
bepaalde marge voor de reseller en een verkoopprijs die door de klant wordt betaald. Een system
integrator of solution provider gaat zich dan ook concentreren op diensten zoals op maat
100
ontwikkeling van applicaties, projectmanagement, consulting… De mogelijkheden om deze
diensten aan te bieden zijn groter voor middleware software dan voor infrastructuursoftware.
4.4.5 SearchSystemsChannel.com
De website Searchsystemschannels.com10 is een website die voorziet in nieuws, artikels,
technische tips, trends en praktische informatie. Aan de hand van een aantal FAQ’s werden een
aantal artikels gebundeld die meer inzicht geven in de uitdagingen en kansen voor resellers,
system integrators e.d. met betrekking tot OSS. Kort worden de conclusies die werden bekomen
van de interviews vergeleken met de informatie afkomstig van deze website.
• Hoewel men vaak OSS associeert met gratis software, voorziet het volgens analisten wel
in een niet onbelangrijke inkomstenstroom voor resellers en system integrators. Volgens
een marktanalyse van IDC zou bijna 30% van de inkomsten van system integrators en
value added resellers komen van OSS. (Y. Shavit, 2007) Er kan worden bevestigd dat
JBoss een niet onbelangrijke inkomstenstroom vertegenwoordigen. Wanneer er werd
gevraagd naar het aandeel van de inkomsten van JBoss ten opzichte van de andere
applicatieservers kon of wou niemand een concreet cijfer geven.
• Als gevolg van dalende IT-budgetten en de economische crisis zien bedrijven een kans
om kosten te doen dalen door OSS te gebruiken. Volgens een marktanalyse van IDC is de
adoptie van OSS door de meerderheid van bedrijven sterk aan het groeien en wordt het
opgenomen in de softwarestrategie van bedrijven. (Y. Shavit, 2007) Uit de interviews
blijkt inderdaad dat de financiële crisis en dalende IT-budgetten zeker een rol spelen in
een grotere adoptie van JBoss door de markt. Doordat het idee over OSS aan het
veranderen is en bedrijven er minder sceptisch over zijn, is er ook een grotere adoptie
door de markt.
• OSS die wordt ondersteund door bedrijven bestaat vaak in twee versies: een
gemeenschapsversie en een ondernemingsversie. Vaak is de ondernemingsversie
goedkoper dan vergelijkbare eigendomssoftware, wat er voor zorgt dat er meer ruimte is
voor de diensten die door System Integrators worden aangeboden. (Y. Shavit, 2007) Voor
JBoss bestaat er ook een gemeenschapsversie en een bedrijfsversie. Deze bedrijfsversie is
10 URL: <http://searchsystemschannel.techtarget.com/> (10/05/2010)
101
goedkoper dan de licenties die bedrijven moeten betalen voor de andere applicatieservers.
Er kon niet worden bevestigd dat dit meer ruimte biedt voor de diensten van de resellers.
• Het feit dat de broncode van de software beschikbaar is voor de System Integrator zou
ervoor zorgen dat zijn job eenvoudiger wordt. Integratie met andere software is
eenvoudiger. (Y. Shavit, 2007) Dit is niet meteen een voordeel voor de reseller, maar
eerder voor de klant. Wanneer er een probleem is met de software kan de klant naar de
broncode kijken om problemen zelf oplossen. Maar het is meer de bedoeling dat wanneer
er een probleem met de software de klant een abonnement heeft bij JBoss zodat zij het
probleem kunnen oplossen.
• OSS is meer aanwezig in grote bedrijven omdat zij graag beschikken over een goed
platform voor het bouwen van op maat gemaakte applicaties. In Kleine- en Middelgrote
ondernemingen is “software as a service” meer populair. (Y. Shavit, 2007) Er kan
worden bevestigd dat OSS meer aanwezig is in de grote bedrijven. Dat KMO's meer
kiezen voor Software-als-een-dienst kan niet worden bevestigd
• De ondersteuning die de OSS bedrijven voorzien is de grootste toegevoegde waarde die
zij bieden. (Y. Shavit, 2007) Voor de resellers is het wel zo dat de grootste toegevoegde
waarde van de bedrijfsversie van JBoss de ondersteuning is die kan worden verkregen,
maar ook de toegang tot een versie van de software die meer uitgebreid getest is voor
gebruik in bedrijfskritische omgevingen.
• Sommige klanten die geïnteresseerd zijn in OSS zijn eigenlijk enkel op zoek naar een
koopje en zullen waarschijnlijk niet bereid zijn om veel geld uit te geven aan de diensten
van een reseller. (Y. Shavit, 2007) Dit kon niet uit dit onderzoek worden afgeleid.
• Niet alle soorten software wordt even sterk gepresenteerd door de OS gemeenschap.
Voornamelijk de infrastructuur- en ontwikkelingssoftware op bedrijfsniveau is zeer sterk
aanwezig in bedrijven. Resellers concentreren zich dus het best op OSS die een sterke
ontwikkelingsgemeenschap heeft en goede ondersteuning door een softwarebedrijf. (Y.
Shavit, 2007) Aan alle resellers werd gevraagd of zij in hun productaanbod nog andere
OSS aanbieden. Bij Xplore Group kon worden bevestigd dat een ander afdeling ook Red
Hat Enterprise Linux verkocht. Bij Realdolmen werd er ook met SUSE Linux van Novell
gewerkt, maar daar hebben ze niet zo'n groot aantal klanten voor. Bij Capgemini is de
afdeling van Nederland wel meer bezig met OSS. Het is wel zo dat het onderwerp van de
102
interviews betrekking had op infrastructuur- en ontwikkelingssoftware. Het is inderdaad
zo dat het belangrijk is voor de resellers dat er goede ondersteuning is door een
softwarebedrijf.
4.5 Interview Red Hat
4.5.1 Het Partnerlandschap
In het partnerlandschap kunnen een aantal “niveaus” van resellers worden onderscheiden. Op het
hoogste niveau bevinden zich resellers zoals Xplore, Realdolmen en Capgemini, die vooral
geïnteresseerd zijn in ‘handjes verkopen’. Dat wil zeggen dat zij zich trachtten te detacheren bij
een klant. Zij proberen hun werknemers uit te lenen aan klanten door het verkopen van projecten
die een periode van bijvoorbeeld zes maanden kunnen bestrijken. Op deze manier hebben ze
zekerheid dat ze een aantal maanden vast aan de klant kunnen factureren en dat hun mensen
werk hebben. Voor sommige resellers is het daarom pas interessant om een product te verkopen
als daar ook diensten aan gekoppeld kunnen worden.
Capgemini bijvoorbeeld is een system integrator die internationaal actief is. System integrators
kunnen beschouwd worden als “influencers”. Zij werken met een bepaald aantal oplossingen bij
klanten met betrekking tot infrastructuur of middleware zoals WebSphere IBM, WebLogic
Oracle en JBoss Red Hat. Kleinere bedrijven merken dat op en zullen daar dan ook worden door
beïnvloed. Vandaar dat die van grote waarde zijn voor Red Hat. Capgemini heeft ongeveer een
twaalftal klanten waarvoor zij per jaar vier of vijf projecten realiseren. Realdolmen daarentegen
heeft rond de drieduizend klanten of meer en doen misschien vijftig of zestig projecten op
jaarbasis. Een vierde partner is Econocom die een goede “license-desk” hebben. Zij bevinden
zich op een lager niveau dan Capgemini, Realdolmen of Xplore Group. Een reseller die
hoofdzakelijk werkt met een license-desk heeft geen technische mensen in dienst en verkoopt
meestal ook geen hardware. Het enige wat zij moeten doen is met de klant nagaan hoeveel
abonnementen er nodig zijn en daar een offerte voor opmaken en bestellen bij de distributeur.
Aangezien zij geen technische mensen moeten opleiden en betalen nemen zij zeer lage marges
op hun producten. De laatste soort reseller is wat een ‘pc-boer’ of ‘dozen schuiver’ kan worden
genoemd, een soort van lokaal winkeltje dat pc elementen bij elkaar haalt en als één geheel
verkoopt. Ondanks de beperkte schaal van dit soort winkeltjes kunnen dat belangrijke partners
103
zijn omdat ze het idee van Red Hat verkopen. Al deze resellers zijn voor Red Hat het echte
partnerkanaal.
Daarnaast werkt Red Hat ook samen met Independent Software Vendors en de Original
Equipment Manufacturer. De Independent Software Vendors kopen het product van het
softwarebedrijf en geven dat een ander uiterlijk, voegen extra functionaliteiten toe en verkopen
dat verder onder hun eigen naam. De ISV’s betalen een vergoeding om de technologie te
gebruiken, maar de softwarebedrijven worden daar weinig bij betrokken, want zij geven zelf
ondersteuning, updates en upgrades aan klanten voor die omgeving. De OEM’s verkopen de
abonnementen van Red Hat, maar nemen een deel van de ondersteuning voor eigen rekening. Zij
krijgen dan ook meer korting omdat ze een deel van de technische ondersteuning zelf doen.
4.5.2 Eindklanten en Partners
De reseller wordt niet direct gepusht door Red Hat om partner te worden. Langs de ene zijde wil
Red Hat dat de resellers de technologie verkopen, maar aan de andere moet men ook met de
klant rekening houden. Kostenreductie is belangrijk voor de klant. Wanneer de klant de
licentiekosten van de eigendomsoftware kan vergelijken met de abonnementskost voor OSS zal
hij zien dat OSS goedkoper is. Tegelijkertijd moet de klant ook worden overtuigd dat de
kwaliteit vergelijkbaar is. Kunnen aantonen dat je kwalitatief een goed product aflevert als OSS
bedrijf is belangrijk omdat vele eigendomssoftwarebedrijven OSS op die manier trachten af te
breken.
Belangrijk voor Red Hat is de concurrentie afkomstig van de “.org” of gratis versie. De
gebruikers van de gemeenschapsversie zijn vaak ontwikkelaars thuis die iets willen maken voor
zichzelf of bedrijven die de licentiekost van eigendomssoftware te hoog vinden en liever met
“JBoss.org” werken. De beide versies van JBoss, de gemeenschapsversie en de bedrijfsversie,
zijn gelijkaardig in functionaliteiten. Daarom is het belangrijk om ervoor te zorgen dat men goed
begrijpt wat het verschil is tussen beide en hoe er van de gemeenschapsversie naar de
bedrijfsversie wordt gegaan. Het is belangrijk dat zowel de klant als de reseller overtuigd is van
de voordelen van de bedrijfsversie.
De relatie tussen reseller en softwarebedrijf is een vertrouwensrelatie die niet substantieel
verschilt van reseller tot reseller. Voor het softwarebedrijf zijn alle resellers en de distributeur
104
belangrijk omdat zij het belangrijkste distributiekanaal zijn. Voor de reseller is de eindklant de
belangrijkste partij, omdat zij de grootste bron van inkomsten zijn.
Eindklanten houden van direct contact met een softwarebedrijf. Wanneer een eindklant door de
reseller wordt aangesproken zal die minder enthousiast zijn dan wanneer hij wordt gecontacteerd
door een softwarebedrijf. De afdeling van Red Hat in Benelux is steeds bezig met communiceren
met potentiële klanten. Wanneer deze klant dan beslist om met Red Hat te werken zal Red Hat er
een reseller er bij halen die dan de nodige administratie en diensten zal verzorgen. Er moet dan
worden beslist met welke partner de klant verder zal werken. Red Hat stelt dan zijn partners aan
de klant voor met hun partnerniveau. De keuze hangt dan af van het feit of de klant reeds met één
van deze resellers samenwerkt of heeft samengewerkt. Wanneer het gaat om een groot project,
moet er ook voor een partner worden gekozen die de taak aankan.
In de relatie tussen Red Hat en de reseller is het partnerniveau een niet verwaarloosbaar gegeven.
Het grote verschil tussen het “advanced partner level” en “premier partner level” is het aantal
mensen dat gecertificeerd moet zijn en dus een opleiding heeft gevolgd bij Red Hat. Een
“premier partner” toont door mensen een opleiding te laten volgen een bepaald engagement
tegenover Red Hat. Red Hat zal de “premier partner” belonen voor zijn engagement door
bijvoorbeeld de reseller meer bij klanten aan te raden.
Het partnerprogramma dat hier in de Benelux wordt gebruikt is het EMEA11 partnerprogramma
dat van toepassing is voor Europa, het Midden Oosten en Afrika. Deze partnerprogramma’s zijn
wereldwijd opgesteld maar de kanaalmanager van een specifiek land kan daar voor een aantal
dingen van afwijken. Voor het opstellen van zo’n partnerprogramma wordt er niet zozeer
gekeken hoe anderen werken. Er kunnen wel ideeën komen voor een bepaald onderdeel van een
ander partnerprogramma, maar dat is eerder beperkt. Het systeem van Red Hat is volledig anders
dan dat van IBM bijvoorbeeld. Het gaat hier dan ook om twee totaal verschillende bedrijven en
ook om producten die sterk van elkaar verschillen. Tot op een bepaald niveau zullen er dus wel
overeenkomsten zijn tussen partnerprogramma’s.
Wat bij Red Hat specifiek is voor een OS product is het feit dat er in producten en diensten
waarvoor klanten een abonnement kunnen kopen een bijkomende dienst is die bescherming biedt
11 Europe, the Middle East en Africa
105
bij legale problemen met intellectuele eigendom. Het kan zijn dat iemand bij IBM een stuk code
heeft ontwikkeld en deze op “JBoss.org” achterlaat. Dit stuk code kan terechtkomen in de
“.com” versie en vermits alles open is, kan iedereen de code nalezen. Wanneer IBM dan ontdekt
dat een stuk van hun code door JBoss klanten wordt gebruikt kan IBM eisen dat elke gebruiker
van JBoss een bijdrage betaalt. Hiertegen beschermt Red Hat zijn klanten dan ook.
Het is niet in het voordeel van Red Hat wanneer een reseller voor OSS kiest vanuit ideologische
overwegingen. Ideologische mensen durven snel teruggrijpen naar de “.org” versie, daarom is
het abonnementenmodel dan ook belangrijk. In een bedrijf kunnen er drie verschillende groepen
van mensen worden geïdentificeerd met elk een ander standpunt:
• De ontwikkelaars willen dat het snel vooruitgaat, zij willen het nieuwste en willen dingen
uitproberen.
• Mensen met operationele verantwoordelijkheid die willen stabiliteit, dat ’s nachts een
server niet stilvalt en dat er gemakkelijk ondersteuning te verkrijgen is.
• De economische en financiële mensen willen iets dat gemakkelijk aanpasbaar is wanneer
de vereisten veranderen, iets dat goedkoop is en flexibel om mee te werken.
Dat zijn dus drie verschillende invalshoeken die een reseller moet benaderen bij een eindklant.
Een laatste vraag die werd gesteld is “waarom zouden klanten kiezen voor eigendomssoftware
wanneer zij kunnen kiezen voor JBoss”. In de eerste plaats moet de adoptie door de markt in
rekening worden genomen om te verklaren waarom niet iedereen met JBoss werkt. Ten tweede is
er een deel geschiedenis die meespeelt. Als een partner van IBM jaren dure software aan klanten
heeft verkocht, kan die niet zomaar bij de klant komen met een goedkoper alternatief. Dat is een
moeilijke situatie voor resellers.
4.5.3 Financieel Model
In samenwerking met de kanaalmanager van Red Hat kon het financiële partnermodel worden
opgesteld. Wanneer een OSS bedrijf er ervoor kiest om via een partnerkanaal te werken wordt er
gebruik gemaakt van een aantal tussenschakels. Daarom wordt er kort besproken waarom
bedrijven gebruik maken van tussenschakels om hun product of dienst tot bij de klant te brengen.
106
Direct verkopen versus indirect verkopen
Bedrijven kunnen hun producten op twee manieren bij de klant brengen. Er is de mogelijkheid
om gebruik te maken van het directe kanaal zoals een verkoopsteam of een online bestelsysteem.
De producent kan ook gebruik maken van tussenschakels of tussenpersonen zoals
groothandelaars of kleinhandelaars. Een direct kanaal heeft het voordeel dat de producent meer
controle heeft over het verkoopsproces, de prijzen en de diensten. Een producent kan op die
manier ook meer informatie vergaren over de consument. Maar in sommige situaties kan dit te
duur of te complex zijn. Tussenschakels kunnen de distributie van een product meer efficiënt
realiseren. (Schilling, 2008)
• Producenten werken liever met een beperkt aantal producten in grote hoeveelheden
terwijl de klant eigenlijk een beperkte hoeveelheid koopt van een groot aantal
verschillende producten. Dit is wat de tussenschakel juist doet, consolideren van
bestellingen bij de producent en het individueel aanbieden van verschillende producten
aan de klanten.
• Een tussenschakel heeft vaak ook een grotere expertise of ervaring met het aanbieden van
diensten zoals transport, beheer van voorraden, afhandelen van transacties met klanten...
Vele bedrijven werken op deze manier. Het is namelijk zo dat, voor softwarebedrijven, werken
met eindklanten moeilijk is en veel energie vraagt. Eindklanten hebben dikwijls kleine
bestellingen en vragen veel ondersteuning. Dat is allemaal zeer arbeidsintensief voor een
softwarebedrijf. Daarom heeft Red Hat ervoor gekozen, net zoals vele andere bedrijven, om te
werken met resellers. Zij verzorgen het contact met de eindklant en doen zaken zoals de
administratie en dergelijke. Resellers zelf zijn vaak ook arbeidsintensief voor het softwarebedrijf
vandaar dat er nog een tussenstap is, namelijk de distributeur. De distributeur van Red Hat is
Distrologie, zij verkopen normaal niet aan eindklanten maar aan resellers en zijn
verantwoordelijk voor de day-to-day communicatie met resellers en ze verwerken de orders van
de resellers en dergelijke.
107
Figuur 5: Financieel model Red Hat
Legende
De Reseller factureert aan de eindklant. De distributeur factureert op zijn beurt aan de reseller en
Red Hat factureert aan de distributeur. Wanneer een reseller partner wordt van Red Hat zal hij bij
het “Ready level” een korting krijgen van 15% op de catalogusprijs. Voor het “advanced level”
en het “premier level” krijgt de reseller een korting van 18% op de catalogusprijs. In het geval
dat de catalogusprijs bijvoorbeeld 100 euro is, moet de reseller op het “advanced level” slechts
82 euro betalen aan de distributeur. De distributeur zal op zijn beurt ook korting krijgen bij Red
Hat en moet dus ook minder betalen. De reseller kan dus zelf bepalen hoeveel marge hij neemt
wanneer hij een abonnement verkoopt. Wanneer een eindklant een abonnement koopt via het
partnerkanaal zal het softwarebedrijf, Red Hat in dit geval, instaan voor de producten en diensten
verbonden aan dit abonnement. Dit gebeurt rechtstreeks en wordt gerepresenteerd door de pijl
“uitlevering + support”.
Op deze manier werkt het partnerkanaal. In andere landen zoals Nederland en Duitsland wordt er
ook gewerkt met een aantal vaste klanten. Dit zijn heel grote bedrijven die wel rechtstreeks
Softwarebedrijf Distributeur Reseller Eindklant
Diensten
Betaling
Betaling (-korting) Betaling (-korting)
Uitlevering + support
Partner fee, training fee
Diensten
Partner voordelen
Diensten
Dienstenstroom
Financiële stroom
108
aankopen bij Red Hat. In België worden de producten van Red Hat voor 100 procent verkocht
via het partnerkanaal. Wereldwijd is het aandeel van het partnerkanaal ongeveer 65 procent voor
Red Hat. In België zijn er een drietal mensen die voor Red Hat direct met de eindklant werken.
Zo is er dus iemand die verantwoordelijk is voor een aantal grote klanten zoals werd uitgelegd in
het interview bij Realdolmen. Mr. Rentmeesters is de kanaalmanager en is verantwoordelijk voor
het partnerkanaal in de Benelux en de verantwoordelijk van Red Hat die werd geïnterviewd.
In dit hoofdstuk werd in detail het volledige onderzoek van deze masterproef besproken. In het
volgende hoofdstuk, het algemeen besluit, wordt kort de onderzoeksvraag herhaald en worden de
belangrijkste resultaten en conclusies besproken. Hieruit kunnen zowel academici als bedrijven
een aantal interessante conclusies en aandachtspunten lezen met betrekking tot OSS en het
partnernetwerk.
109
5. Algemeen Besluit Deze masterproef had tot doel de invloed na te gaan van OSS op drie onderdelen van de
distributie ervan: de partnerrelaties tussen reseller en OSS bedrijf, de activiteiten van de reseller
en het managen van het partnerkanaal door een OSS bedrijf.
De uitdaging van vele OSS bedrijven is in de eerste plaats een stabiel en leefbaar bedrijfsmodel
te vinden. De meer recente literatuur tracht OSS bedrijfsmodellen te omschrijven in termen van
inkomstenstromen of activiteiten die mogelijk zijn zoals commerciële licenties, abonnementen,
diensten op maat, ondersteuning… Verschillende OSS bedrijven kunnen voor hun software ook
een andere licentie, ontwikkelingsstrategie en licentiestrategie hebben. Dit heeft op zijn beurt een
invloed op de mogelijke kostenstructuur en de inkomstenstromen.
Op basis van de analyse van de partnerprogramma’s van acht verschillende OSS bedrijven
werden een aantal veel voorkomende elementen geïdentificeerd. Een partnerprogramma van
softwarebedrijven bestaat steeds uit twee onderdelen. Enerzijds biedt een OSS bedrijf een aantal
voordelen aan partners en voor sommige elementen worden deze voordelen beter naarmate het
niveau waartoe de partner behoort hoger is. Anderzijds zal de partner ook aan een aantal
vereisten moeten voldoen die strenger kunnen worden naarmate het niveau hoger is. Tabel 2 in
bijlage 3 geeft een goed overzicht van de elementen die werden geïdentificeerd samen met hun
frequentie. Een partnerprogramma zal in grote lijnen steeds op dezelfde manier opgesteld zijn.
De volgende categorieën komen namelijk steeds terug: algemene voordelen,
opleidingsvoordelen, verkoopsvoordelen, marketingvoordelen en (technische) ondersteuning. In
vergelijking met partnerprogramma’s van eigendomssoftware bedrijven is het aantal voordelen
per categorie kleiner. Dit kan worden verklaard doordat bedrijven zoals IBM en Oracle veel
groter zijn in omvang dan OSS bedrijven. Zij hebben ook al langer ervaring met partnerrelaties
en partnerprogramma’s. Dit wordt ook bevestigd in de interviews met de resellers. Voor de
resellers heeft de grootte van zowel de reseller als het softwarebedrijf invloed op de manier
waarop wordt samengewerkt. De samenwerking met grotere bedrijven is complexer dan met
kleine bedrijven.
Het partnerprogramma kan worden beschouwd als een “order qualifier” of een concurrentiële
noodzaak voor elk bedrijf dat in de IT wereld met anderen wil samenwerken. Een
partnerprogramma representeert het engagement dat beide partijen ten opzichte van elkaar zijn
110
aangegaan. Voor de reseller is de deelname aan het partnerprogramma van een softwarebedrijf
een signaal voor klanten. Het toont dat de reseller een zekere expertise heeft van de software en
een samenwerking heeft met het softwarebedrijf.
De resellers die voor dit eindwerk werden geïnterviewd kunnen worden omschreven als “system
integrators”, “solution providers” en “consultants”. Resellers kunnen ook alleen licenties of
abonnementen van software verkopen, maar er is dan weinig toegevoegde waarde waardoor
resellers geen hoge marges kunnen vragen. Vandaar dat het voor hen belangrijk is om diensten te
verkopen en projecten van klanten te beheren. Resellers gaan daarom partnerships aan met OSS
bedrijven om expertise te verkrijgen van hun technologie. Op die manier kunnen zij hun diensten
aanbieden en hun technische mensen plaatsen bij de klant. Zo creëren zij een grotere
toegevoegde waarde, waarvoor men dan ook een hogere vergoeding kan vragen.
Klanten hebben nog altijd een aantal misvattingen met betrekking tot OSS. Velen weten niet dat
er voor OSS ook professionele ondersteuning bestaat. In bedrijfskritische omgevingen is
professionele ondersteuning belangrijk, vandaar dat vele bedrijven geen OSS daarvoor
gebruiken. Sommigen gebruiken wel de gemeenschapsversie voor een aantal taken, maar niet in
een bedrijfskritische omgeving. Dit biedt wel een opportuniteit voor resellers om de
bedrijfsversie te verkopen. Het is dan ook belangrijk dat de eindklant kan worden overtuigd van
de voordelen dat de bedrijfsversie heeft ten opzichte van de gemeenschapsversie.
Als specifiek wordt gekeken naar de traditionele applicatieserver markt, kunnen er twee
prominente spelers worden geïdentificeerd: IBM en Oracle. De drie geïnterviewde resellers zijn
ook partner van deze bedrijven. Wanneer JBoss als OSS daar mee wordt vergeleken kan het
worden beschouwd als een waardevol en goedkoper alternatief. Sommige eindgebruikers hebben
niet de middelen om de duurdere systemen aan te kopen. Door de financiële crisis zijn vele IT
budgetten gedaald en zijn bedrijven op zoek naar goedkopere producten. JBoss is een product dat
in vergelijking met IBM WebSphere en Oracle WebLogic minder mogelijkheden of
functionaliteiten heeft, maar kwalitatief niet minder is.
De reseller geeft aan dat de eindklant centraal staat. Er moet zowel professionele ondersteuning
mogelijk zijn en de kwaliteit van de software moet minstens even goed zijn dan die van
eigendomssoftware. Wanneer een reseller voor een bepaalde klant een applicatieserver moet
111
voorstellen zal de keuze afhangen van het profiel van de klant. Het zal namelijk afhangen van
wat de klant juist nodig heeft en wat zijn budget is.
Het is ook van belang dat de reseller een gevarieerd gamma aan producten kan aanbieden. Uit dit
onderzoek blijkt ook dat de markt meer en meer open begint te staan voor het idee en gebruik
van OSS. Er zijn nog een aantal vooroordelen en misvattingen aanwezig, maar de kennis van
OSS wordt beter en er is een positieve trend in het voordeel van OSS en de OSS bedrijven. Er is
dan ook een grote economische opportuniteit voor resellers en OSS bedrijven om samen te
werken en te streven naar een groter marktaandeel en een solide inkomstenstroom.
Voor het OSS bedrijf is het ecosysteem zeer belangrijk want zo’n bedrijf is meer afhankelijk van
zijn omgeving dan het traditionele softwarebedrijf. Net zoals in de natuur is de balans van hun
ecosysteem zeer fragiel en moet het OSS bedrijf alle spelers in zijn omgeving zo goed mogelijk
behandelen. Een eerste belangrijke deelnemer in het ecosysteem is de OS gemeenschap, dat zijn
de ontwikkelaars die in hun vrije tijd meebouwen aan de OSS.
Een tweede belangrijke partij in het ecosysteem zijn de resellers. Vele softwarebedrijven maken
gebruik van een partnerkanaal om hun producten te distribueren. Voor Red Hat komt de omzet in
België zelfs 100% van het partnerkanaal. De reden waarom bedrijven met partners werken is
omdat rechtstreeks werken met de eindklant veel energie vraagt. Naast de reseller is er ook nog
een distributeur die de communicatie- of transactiestap vormt tussen de reseller en het OSS
bedrijf. De grootste concurrent van de betalende bedrijfsversie van een OSS bedrijf is de gratis
gemeenschapsversie. Het is daarom belangrijk dat resellers overtuigd zijn van de toegevoegde
waarde die de bedrijfsversie van OSS betekent voor een eindklant. Anders kan het zijn dat
resellers bij een eindklant een project uitvoeren met behulp van de gemeenschapsversie en
uiteindelijk niet de bedrijfsversie verkopen aan de eindklant.
Een ander belangrijk aspect is het soort software. Bedrijven die een bepaalde applicatie willen,
specifiek voor een bepaalde toepassing, kunnen die ontwikkelen in de programmeertaal Java.
Nadat de applicatie ontwikkeld is, is er nood aan een applicatieserver om de applicatie te kunnen
gebruiken. Per type applicatieserver is er een andere expertise of kennis nodig om de applicatie
te schrijven. Dit zorgt ervoor dat de eindklant nood heeft aan gespecialiseerde mensen en een
gepersonaliseerde aanpak en dat is juist waar de focus ligt bij Xplore Group, Realdolmen en
112
Capgemini. De mogelijkheid om deze gespecialiseerde diensten aan te bieden is dus ook
afhankelijk van het soort software. Infrastructuursoftware biedt minder mogelijkheden voor deze
diensten dan middelware.
Er moeten ook een aantal beperkingen van dit onderzoek worden opgemerkt. In een eerste fase
werd gebruik gemaakt van bestaande gegevens, namelijk de partnerprogramma’s. De informatie
uit deze partnerprogramma’s is betrouwbaar, maar het grote nadeel is dat er soms gegevens
worden weggelaten. In het partnerprogramma van Red Hat bijvoorbeeld vermeldt men de korting
niet die een reseller kan krijgen. Voor de interviews is een grote interne geldigheid vanwege de
keuze om één OSS bedrijf te bespreken. De externe geldigheid echter is minder goed. Zoals kon
worden vastgesteld is voor de reseller niet alle software even interessant om diensten te kunnen
verkopen. De mogelijkheid voor een reseller om bijvoorbeeld toegevoegde waarde te creëren
bovenop infrastructuursoftware is lager in vergelijking met applicatieservers. Dit doet dus
vermoeden dat de conclusies uit dit onderzoek niet zomaar gegeneraliseerd kunnen worden voor
alle OSS. De aangehaalde beperkingen kunnen een aanzet zijn tot verder kwalitatief en
kwantitatief onderzoek.
VII
Lijst van Geraadpleegde Werken
451 Group. (2008). Open Source Is Not A Business Model.
Baarda, D., de Goede, M., & Teunissen, J. (2005). Basisboek Kwalitatief onderzoek:
Handleiding voor het opzetten en uitvoeren van kwalitatief onderzoek. Groningen: Stenfert
Kroese.
Bonaccorsi, A., & Rossi, C. (2003). Why Open Source Software Can Succeed. Research Policy ,
Vol 32, pg.1243-1258.
Brinkkemper, S., Soest, I., & Jansen, S. (2007). Modeling of product software businesses:
Investigation into industry product and channel typologies. In the Inter-Networked World: ISD
Theory, Practice and Education, proceedings of the 6th international Conference on Information
Systems Development , Vol. 1, pg. 307-325.
Chesbrough, H. W., & Appleyard, M. M. (2007). Open Innovation and Strategy. California
Management Review , Vol. 50 (1), pg 57-76.
Chopra, S., & Meindle, P. (2001). Supply chain management: Strategy, planning and operation.
Upper Saddle River, NJ: Prentice-Hall.
Clarke, R., & Dempsey, G. (2004). The Economics of Innovation in the Information Industries.
Opgehaald van <http://www.rogerclarke.com/EC/EcInnInfInd.html>. (07/05/2010)
Cusumano, M. A. (2007a). The changing labyrinth of software pricing. Communications of the
ACM , Vol. 50, pg. 19-22.
Cusumano, M. A. (2008b). The Changing Software business: Moving from Products to Services.
IEEE Comp , Vol. 41 (1), pg.20-27.
Dahlander, L., & Magnusson, M. (2008). How do Firms Make Use of Open Source
Communities. Long Range Planning , 41, pg. 629-649.
VIII
de Goede, P. (2010). Van een gedegen partnerstrategie profiteert iedereen. Opgehaald van
<http://www.itreseller.be/reseller.cfm?id=112780>. (27/04/10)
Dixon, J. (2009). The Bees and the Trees. Opgehaald van
<http://wiki.pentaho.com/display/BEEKEEPER/The+Beekeeper;jsessionid=9D6EB859B201C97
66E21C788C3BF9A56>. (23/04/2010)
Ellram, L. M. (1995). Total Cost of Ownership: an analysis approach for purchasing.
International Journal of Physical Distribution & Logistics Management , Vol. 25 (8), pg. 4-23.
Farbey, B., & Finkelstein, A. (1999). Exploiting software supply chain business architecture: a
research agenda. In proceedings of the 1 st Workshop on Economics-Driven Software
Engineering Research (EDSER-1) .
Feller, J., Fitzgerald, B., Hissam, S., & Lakhani, K. (2005). Perspectives on Free and Open
Source Software. MIT Press: Cambridge, MA.
Fitzgerald, B. (2006). The Transformation of Open Source Software. Management Information
Systems Quarterly , Vol 30 (nr. 3), pg. 587-598.
Fogel, K. (2005). Producing Open Source Software. O'Reilly.
Galoppini, R. (2007). Open Source Business Models: What is an Open Source Business Model?
Opgehaald van <http://robertogaloppini.net/2007/08/30/open-source-business-models-what-is-
an-open-source-business-model/>. (23/04/2010)
Ghosh, R. A., Glott, R., Krieger, B., & Robles, B. (2002). Free/Libre and Open Source Software:
Survey and Study, FLOSS, Final Report. International Institute of Infonomics, Berlecom
Research GmbH .
Hecker, F. (1999). Setting up shop: the business of Open-Source software. IEEE Software , 16
(1), pg. 45-51.
Hill, T. (1993). Manufacturing strategy: the strategic management of the manufacturing
function. Macmillan.
IX
Jansen, S., Finkelstein, A., & Binkkemper, S. (2009). A sense of community: A research agenda
for software ecosystems. In 31st International Conference on Software Engineering, New and
Emerging Research Track , pg. 187-190.
Jansen, S., Finkelstein, A., & Brinkkemper, S. (2007). Providing transparency in the businss of
software: A modelling technique for software supply networks. In In Proceedings of the 8th IFIP
Working Conference on Virtual Enterprises , pg. 677-686.
Lambert, D. M., & Cooper, M. C. (2000). Issues in supply chain management. Journal of
Industrial Marketing Management , Vol. 29 (1), pg. 65-83.
Lehto, B. (2007). ISV. Opgehaald van
<http://searchitchannel.techtarget.com/sDefinition/0,,sid96_gci214047,00.html>.(25/04/2010)
Lerner, J., & Tirole, J. (2001). The Simple Economics of Open Source. Journal of Industrial
Economics , Vol. 50 (2), pg. 197-234.
McNaughton, R. (1996). Foreign Market Channel Integration Decisions of Canadian Computer
Software Firms. International Business Review , Vol. 5 (1), pg. 23-52.
Mehta, R., Polsa, P., Mazur, J., Xiucheng, F., & Dubinsky, A. J. (2006). Strategic alliances in
international distribution channels. Journal of Business Research , Vol. 59 (10-11), pg. 1094-
1104.
Messerschmitt, D. G., & Szyperski, C. (2005). Software Ecosystem: Understanding an
Indispensable Technology and Industry. MIT Press Books.
Moore, J. F. (1993). Predators and prey: a new ecology of competition. Harvard Business
Review , Vol. 71 (3), pg. 75-86.
Oracle. (2010c). Opgehaald van <http://www.oracle.com/index.html>. (10/05/2010)
Oracle. (2010a). Oracle and Sun. Opgehaald van <http://www.oracle.com/us/sun/index.htm>.
(24/04/2010)
Oracle. (2010b). Sun Customers Oracle Plans To. Opgehaald van
<http://www.oracle.com/features/suncustomers.html>. (24/04/2010)
X
Osterwalder, A., Pigneur, Y., & Tucci, C. (2005). Clarifying Business Models: Origins, present
and Future of the Concept. Communications of the Association for Information Science (CAIS) ,
Vol. 15, pg. 751-775.
Pcmag. (2010a). Definition of ISV. Opgehaald van
<http://www.pcmag.com/encyclopedia_term/0,2542,t=ISV&i=45489,00.asp>. (25/04/2010)
Pcmag. (2010b). Definition of managed services. Opgehaald van
<http://www.pcmag.com/encyclopedia_term/0,2542,t=managed+services&i=55605,00.asp>
Pcmag. (2010c). Definition of OEM. Opgehaald van
<http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3DOEM&i%3D48291%2C00.as
p>. (25/04/2010)
Pcmag. (2010d). Definition of reseller. Opgehaald van
<http://www.pcmag.com/encyclopedia_term/0,2542,t=reseller&i=56066,00.asp>. (25/04/2010)
Pcmag. (2010e). Definition of solution provider. Opgehaald van
<http://www.pcmag.com/encyclopedia_term/0,2542,t=solutions+provider&i=51736,00.asp>.
(25/04/2010)
Pcmag. (2010f). Definition of systems integrator. Opgehaald van
<http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3DOEM&i%3D48291%2C00.as
p>. (25/04/2010)
Pcmag. (2010g). Definition of VAR. Opgehaald van
<http://www.pcmag.com/encyclopedia_term/0,2542,t=value+added+reseller&i=53672,00.asp>.
(25/04/2010)
Rajala, R., Rossi, M., & Tuunainen, V. (2003). A framework for analyzing software business
models. Proceedings of the 11th European conference on information systems, Naples, Italy .
Raymond, E. (1999a). The Catherdral and the Bazaar. Knowledge, Technology, & Policy , Vol.
12 (3), pg 23-49.
XI
Raymond, E. (1999b). The Magic Cauldron. Opgehaald van
<http://www.labso.net/gnulinux/pdf/magic-cauldron.pdf>. (27/04/2010)
Red Hat. (2010). Opgehaald van <http://www.redhat.com/>. (10/05/2010)
Riehle, D. (2009). The Commercial Open Source Business Model. Opgehaald van
<http://dirkriehle.com/publications/2009/the-commercial-open-source-business-model/>.
(29/04/10)
Schilling, M. A. (2008). Strategic Management of Technological Innovation. New York:
McGraw-Hill/Irwin.
Schul, P., Little, T., & Pride, W. (1985). Channel Climate: Its Impact on Channel Members'
Satisfaction. Journal of Retailing , Vol. 61 (2), pg 9-38.
Shavit, Y. (2007). IT channel roles. Opgehaald van
<http://searchitchannel.techtarget.com/generic/0,295582,sid96_gci1281948_mem1,00.html#Con
sultantsanchor>. (25/04/2010)
Software Top 100. (2009). Global Software Top 100 – Edition 2009. Opgehaald van
<http://www.softwaretop100.org/software-top-100/global-software-top-100-edition-2009>.
(24/04/2010)
TechTarget. (2008a). OEM. Opgehaald van
<http://searchitchannel.techtarget.com/sDefinition/0,,sid96_gci214136,00.html>. (25/04/2010)
TechTarget. (2008b). VAR. Opgehaald van
<http://searchitchannel.techtarget.com/sDefinition/0,,sid96_gci213274,00.html>. (25/04/2010)
The Eclipse Foundation. (2010). About the Eclipse Foundation. Opgehaald van
<http://www.eclipse.org/org/>. (23/04/2010)
The VAR Guy. (2009). The VAR Guy's Open Source 50 Disrupting and Redefining the IT
Channel. Opgehaald van <http://www.thevarguy.com/wp-content/uploads/2009/01/the-open-
source-50_v12.pdf>. (30/04/10)
XII
Van Aardt, A. (2006). Business Models on Open Source Software. paper voorgesteld op de 19de
Jaarlijkse Conferentie van de NACCQ, Wellington, 7 - 10 Juli, 2006 .
Van Den Poel, D. (2008). Les 2 Strategie, markten, marktvraag, segmentatie. hoorcollege
Marketing, Academiejaar 2007 - 2008.
West, J. (2003). How open is open enough? Melding proprietary and open source platform
strategies. Research Policy , Vol. 32 (7), pg. 1259-1285.
Wied, A. (2009). Commercial open source is essential to enterprise IT. Opgehaald van
<http://www.computerworlduk.com/community/blogs/index.cfm?entryid=2443&blogid=35>.
(23/04/2010)
Wilson, R. (2009d). The Apache License (v2) – An Overview. Opgehaald van <http://www.oss-
watch.ac.uk/resources/apache2.xml>. (23/04/2010)
Wilson, R. (2009a). The GNU General Public License v2 – An Overview. Opgehaald van
<http://www.oss-watch.ac.uk/resources/gpl.xml>. (23/04/2010)
Wilson, R. (2009b). The GNU Lesser General Public License v2.1 – An Overview. Opgehaald
van <http://www.oss-watch.ac.uk/resources/lgpl.xml>. (23/04/2010)
Wilson, R. (2009c). The Modified BSD License – An Overview. Opgehaald van <http://www.oss-
watch.ac.uk/resources/modbsd.xml>. (23/04/2010)
Wilson, R. (2009e). The Modified BSD License – An Overview. Opgehaald van <http://www.oss-
watch.ac.uk/resources/modbsd.xml>. (23/04/2010)
Wilson, R. (2009c). The Mozilla Public License – An Overview. Opgehaald van
<http://www.oss-watch.ac.uk/resources/mpl.xml>. (23/04/2010)
XIII
Bijlage 1: Referenties Partnerprogramma’s
Acquia
<http://acquia.com/files/marketing/Acquia_Partner_Program_Guide-Final.pdf> (10/05/2010)
Alfresco
<http://www.alfresco.com/partners/programme/> (10/05/2010)
Digium
<http://www.digium.com/en/ecosystem/resellers/index.php?tab=requirements> (10/05/2010)
IBM
<http://www-2000.ibm.com/partnerworld/pwhome.nsf/weblook/pub_benefits.html> (10/05/2010)
Microsoft
<https://partner.microsoft.com/belux-nl/program> (10/05/2010)
MySQL
<https://partner-portal.mysql.com/guide/var.html> (10/05/2010)
Oracle
<http://www.oracle.com/partners/en/opn-program/opn-details-by-levels/index.html> (10/05/2010)
Pentaho
<http://www.pentaho.com/partners/resellers/benefits.php> (10/05/2010)
Red Hat
<http://www.europe.redhat.com/partners/partner_program_guide_emea.pdf> (10/05/2010)
SugarCRM
<http://www.sugarcrm.com/crm/partners/benefits.html> (10/05/2010)
Salesforce.com
<http://sites.force.com/partners/PP2Page?p=P_ConsultingPartnerProgramBenefits> (10/05/2010)
XIV
Bijlage 2: Partnerprogramma’s - Voorbeelden
Alfresco: Europe, the Middle East and Africa SI Programme Benefits
The programme levels and benefits are as follows:
Gold Platinum
Development Benefits
Alfresco Insider RSS Feed Y Y
Enterprise Edition for internal education, testing, demos. Number of
supported deployments. 3 Unlimited
Discussion and Alignment of Roadmap Plans Y Y
Discount on Alfresco Training % 10 15
Discount on Alfresco Certification % 20 Free
Partner Advisory Board Y Y
Partner Forums Y Y
Access to email Technical Support - Calls Unlimited Unlimited
Access to phone Technical Support Y Y
Go-To-Market Benefits
Listing in Alfresco Website Catalog Y Y
Preferred Partner Listing Y Y
Use of Alfresco Logo Y Y
Access to Marketing Material Y Y
Press R
Sales B
Access
Joint Al
Access
Joint Co
Joint W
Events
Partner
Resell r
Resell r
Requir
Abide b
Pentah
The Pengeograpdemandterms o
Market
Listing
Release
Benefits
to Alfresco
lfresco/Part
to Hosted A
ollateral
Webinar
- Co-Exhib
Sales and M
royalty on 1
royalty on 1
rements
by Alfresco
ho: Reselle
ntaho Reselphies or whod for Pentahf visibility a
ting and Bu
on Pentaho
o Sales team
tner Sales C
Alfresco Ne
iting & Spo
Marketing T
1st line supp
1st & 2nd lin
Network C
er Benefits
ller Partner o sell to spe
ho solutions and awaren
usiness Dev
o.com partne
ms
Campaigns
etwork for D
onsorship O
Training
port
ne support
Certification
s
Program is ecific and ta in their targ
ness, busines
velopment
er directory
Demonstrati
Opportunitie
n Procedures
designed prargeted vertget market. ss developm
y
ions and Ev
s
s
rimarily fortical industrThe progra
ment, trainin
valuations
r organizatioies and wan
am providesng, and disc
Joint
Y
Y
Y
Y
Y
Y
Y
15%
Y
ons in emernt to capitals many benecounts.
Gold Silv
XV
Joint
Y
Y
Y
Y
Y
Y
Y
20%
30%
Y
rging ize on the efits in
ver Bronze
V
e
Press re
Program
program
Hands-o
Partner
Pentaho
Step-by
Access
Evaluat
Annual
Access
Consult
Access
Access
Access
elease suppo
m support -
m) and co-m
on Channel
r Enablem
o sales mate
y-step on-bo
to Pentaho
tion copies o
agreement
to the Enter
tative Suppo
to the Penta
to Recorde
to the Penta
ort
content, spe
marketing
l Sales mana
ent
erial and too
oarding
Partner Por
of Enterpris
rprise Editi
ort (5 cases
aho Knowle
d Pentaho W
aho Presale
eaker, clien
ager suppor
ols
rtal
se Edition fo
on Forum
annually) -
edge Base
Web Based
s Technolog
nt, and prom
rt (>$50k ne
for approved
- Customer
Training se
gy Demons
motion (depe
et deal)
d opportunit
Support Po
essions
stration Port
ending on th
ties
rtal
tal
he
Gold Silv
XVI
ver Bronze
I
e
Access
Product
2-day c
four res
(Pre) Sa
Softwa
Referra
Discoun
Internal
Trainin
Now th
making
to pre-relea
t roadmap p
ustom func
sources
ales Engine
re and Disc
al fee (Penta
nt on Pentah
l use license
g discount
hat you have
g sure to pos
ase versions
planning
ctional/pre-s
ering suppo
counts
aho responsi
ho products
e, 6 CPU's B
e a strong u
st your area
s of the Pent
sales trainin
ort (approva
ible for sale
s
BI suite (no
understandin
of interest
taho Produc
ng at Orland
al by Pentah
es process)
ot for resale)
ng of the b
in the comm
cts
do headquar
ho, case by c
)
enefits cont
ments field.
rters for up t
case)
tact us abou
to
Gold Silv
20% 15%
20% 10%
ut becoming
XVII
ver Bronze
10%
%
%
g a Partner
I
e
,
XVIII
Bijlage 3: Analyse Partnerprogramma’s
Tabel 1
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
VOORDELEN
algemene voordelenwelkom pakket 1/2/3 1/2/3 2toegang tot een partner netwerk 1/2/3 1/2/3 1/2/3 1/2/3 2/3 1/2/3 6partner forum 1/2 1product marketing collateral en campagnes
1/2/3 1/2/3 2/3 2/3 4
nieuwsbrief/regelmatig informatie
1/2/3 1/2/3 1/2/3 3
vermelding in partnerlijst 1/2/3 1/2/3 1/2 1/2/3 1/2/3 1/2 6vermelding in een voorkeurslijst 1/2 2/3 2 3succesverhalen/case study 2/3 2/3 1/2/3 3toegang tot commercieel product voor intern gebruik
1/2 2/3 2/3 1/2 4
Roadmap 1/2 3 2deelname aan een raadscollege 1/2 1mogelijkheid tot deelname aan evenementen en sponsoring
1/2 1/2/3 1/2/3 1/2 4
(gezamenlijke) persberichten 1/2 1/2/3 2/3 3
opleidingsvoordelenverkoops- en technische partner seminaries 1/2/3 1/2/3 2
opleidingen 1/2/3 1/2/3 2/3 1/2/3 4productopleiding (via internet) 1/2/3 1/2/3 2verkoopsopleiding (via internet) 1/2/3 1/2/3 1/2 1/2 4korting op opleidingen 2/3 2/3 1/2 1/2/3 2/3 1/2 2/3 7korting op certificaten 1/2 1
XIX
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
verkoopsvoordelenmarge 1/2 1/2/3 2kortingen 2/3 2/3 2referral vergoedingen 1/2/3 1 2jaarlijkse vernieuwing van abonnementen
1/2/3 1/2/3 2
toegang tot een sales team 2/3 2/3 1/2/3 3sales ondersteuning 1/2 1sales materiaal en tool 1/2/3 1/2 2lead distributie/lead referral/qualified leads
2/3 2/3 1/2/3 2/3 2/3 5
lead/deal registratie 1/2/3 1mogelijkheid tot deelname aan een sales campagne
2/3 2/3 2
partner manager 3 3 2/3 2/3 3 2/3 6speciaal bod verzoek 2/3 3 2samenwerking met consulting departement
2/3 2/3 2
webinar 1/2 1verkoopscollateral 1/2/3 1
marketing voordelenproduct demonstratie (niet om te verkopen) 1/2/3 1/2/3 1/2 2/3 2/3 5
templates en richtlijnen voor campagnes/marketing materiaal
1/2/3 1/2/3 1/2 2/3 4
gebruik van partnerprogramma logo
1/2/3 1/2/3 1/2 1/2/3 1/2/3 1/2/3 6
gebruik partnerprogramma logo met specialisatie kenmerk
2/3 2/3 2
fysieke plaat die partnership level en specialisatie representeert
2/3 2/3 2
partnerprogramma certificaat 1/2/3 1/2/3 2/3 3
XX
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
collateral 1/2 1/2/3 1/2/3 3Marketing Development Fund 3 3 3 2/3 4deelname aan een gezamenlijk marketingprogramma
2/3 1
technische ondersteuningtechnische ondersteuning 1/2/3 2/3 1/2 3toegang tot kennis 1/2/3 1/2/3 1/2/3 2/3 2/3 5korting op professionele diensten
2/3 2/3 2
professionele ondersteuning bij ontwikkeling
2/3 1
technische pre-verkoop ondersteuning (via internet)
2/3 2/3 3 2/3 4
pre-verkoop contract 2/3 2/3 2
VEREISTENinvullen van een partnerprogramma aanvraagformulier en profiel
1/2/3 1/2/3 1/2/3 3
aanvaarden van de partnerprogramma overeenkomst
1/2/3 1/2/3 1/2/3 2/3 1/2/3 5
certificatie procedures volgen 1/2 1jaarlijkse deelnamevergoeding 2/3 2/3 2/3 1/2/3 2 5jaarlijks minimum inkomsten doelen
2/3 2/3 1/2/3 3
minimum aantal abonnementen, hoeveelheid inkomsten
2/3 1/2/3 1/2/3 3
minimum jaarlijkse inkomsten 1/2/3 1
XXI
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
minimum grootte van team 1/2/3 1minimum aantal getrainde verkoopsmensen
2/3 2/3 2
minimum aantal technisch getrainde mensen
2/3 1
minimum aantal gecertificeerde mensen
2/3 2/3 2/3 2/3 4
jaarlijks (12 maandelijks) bedrijfsplan
2/3 2/3 2/3 3
voorspelling 3 3 2actieve participatie in gefocuste marketing programma's
3 3 2/3 3
minimum aantal aanwezigen bij een jaarlijkse master klas
2/3 1
minimum aantal succesverhalen van klanten jaarlijks voorleggen
2/3 2/3 1/2/3 3
minimum aantal tevreden klanten of tevredenheidcijfer
1/2/3 1
aankopen van demo materiaal 2/3 1
aantal partnerniveaus 3 3 2 3 3 3 2 3partnervergoeding per niveau
1 0 0 0 $ 2000 02 $ 980 $ 3200 $ 4000 $ 6000 $ 29993 $ 980 $ 3200 * $ 12000
Legende
* onderhandelbaar
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
XXII
Tabel 2
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
VOORDELEN
algemene voordelenwelkom pakket 1/2/3 1/2/3 2toegang tot een partnernetwerk / partnerforum
1/2/3 1/2/3 1/2 1/2/3 1/2/3 2/3 1/2/3 7
mogelijkheid tot deelname aan een sales- of marketingcampagne
2/3 2/3 2/3 3
nieuwsbrief/regelmatig informatie
1/2/3 1/2/3 1/2/3 3
vermelding in partnerlijst 1/2/3 1/2/3 1/2 1/2/3 1/2/3 1/2 6vermelding in een voorkeurslijst
1/2 2/3 2 3
succesverhalen/case study 2/3 2/3 1/2/3 3toegang tot commercieel product voor intern gebruik
1/2 2/3 2/3 1/2 4
Roadmap 1/2 3 2mogelijkheid tot deelname aan evenementen en sponsoring
1/2 1/2/3 1/2/3 1/2 4
(gezamenlijke) persberichten 1/2 1/2/3 2/3 3
opleidingsvoordelen(verkoop- en technische)opleiding 1/2/3 1/2/3 1/2/3 1/2/3 2/3 1/2/3 5
productopleiding (via internet)
1/2/3 1/2/3 2
verkoopsopleiding (via internet)
1/2/3 1/2/3 1/2 1/2 4
XXIII
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
korting op opleidingen 2/3 2/3 1/2 1/2/3 2/3 1/2 2/3 7
verkoopsvoordelenmarge 1/2 1/2/3 2kortingen 2/3 2/3 2referral vergoedingen 1/2/3 1 2toegang tot een sales team 2/3 2/3 1/2/3 3sales materiaal, tools en ondersteuning
1/2/3 1/2 2
lead distributie/lead referral/qualified leads
2/3 2/3 1/2/3 2/3 2/3 5
partnermanager 3 3 2/3 2/3 3 2/3 6
marketing voordelen(product marketing) collateral en campagnes 1/2/3 1/2/3 1/2 1/2/3 1/2/3 2/3 2/3 7
product demonstratie (niet om te verkopen)
1/2/3 1/2/3 1/2 2/3 2/3 5
templates en richtlijnen voor campagnes/marketing materiaal
1/2/3 1/2/3 1/2 2/3 4
gebruik van partnerprogramma logo
1/2/3 1/2/3 1/2 1/2/3 1/2/3 1/2/3 6
partnerprogramma certificaat 1/2/3 1/2/3 2/3 3Marketing Development Fund
3 3 3 2/3 4
technische ondersteuningtechnische ondersteuning 1/2/3 2/3 1/2 3toegang tot kennis 1/2/3 1/2/3 1/2/3 2/3 2/3 5korting op professionele diensten
2/3 2/3 2
technische (pre-)verkoop ondersteuning (via internet)
2/3 2/3 3 2/3 4
XXIV
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
VEREISTENinvullen van een partnerprogramma aanvraagformulier en profiel
1/2/3 1/2/3 1/2/3 3
aanvaarden van de partnerprogramma overeenkomst
1/2/3 1/2/3 1/2 1/2/3 2/3 1/2/3 6
jaarlijkse deelnamevergoeding
2/3 2/3 2/3 1/2/3 2 5
jaarlijks minimum inkomsten doelen
2/3 2/3 1/2/3 3
minimum aantal abonnementen, hoeveelheid inkomsten
2/3 1/2/3 1/2/3 3
minimum aantal getrainde mensen (verkoop of technisch)
2/3 2/3 2
minimum aantal gecertificeerde mensen
2/3 2/3 2/3 2/3 4
jaarlijks (12 maandelijks) bedrijfsplan
2/3 2/3 2/3 3
actieve participatie in gefocuste marketing programma's
3 3 2/3 3
minimum aantal succesverhalen van klanten jaarlijks voorleggen
2/3 2/3 1/2/3 3
XXV
Red
Hat
- In
frast
ruct
uur
Red
Hat
- M
iddl
ewar
e
Alfr
esco
Acq
uia
Suga
rCR
M
Pent
aho
MyS
QL
Dig
ium
Freq
uent
ie
aantal partnerniveaus 3 3 2 3 3 3 2 3partnervergoeding per niveau
1 0 0 0 $ 2000 02 $ 980 $ 3200 $ 4000 $ 6000 $ 29993 $ 980 $ 3200 * $ 12000
Legende
* onderhandelbaar
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
XXVI
Tabel 3
Suga
rCR
M
Sale
sfor
ce.c
om
VOORDELEN
algemene voordelenwelkom pakkettoegang tot een partnernetwerk / partnerforum
1/2/3 1/2/3
mogelijkheid tot deelname aan een sales- of marketingcampagne
2/3 3
nieuwsbrief/regelmatig informatie 1/2/3vermelding in partnerlijst 2/3vermelding in een voorkeurslijst 3succesverhalen/case studytoegang tot commercieel product voor intern gebruik
1/2/3
Roadmap 2/3mogelijkheid tot deelname aan evenementen en sponsoring
1/2/3 1/2/3
(gezamenlijke) persberichten 2/3verkopen van technologieën 1/2/3
opleidingsvoordelen(verkoop- en technische)opleiding 1/2/3productopleiding (via internet)verkoopsopleiding (via internet)korting op opleidingenkorting op certificaten
verkoopsvoordelenmarge 1/2/3kortingenreferral vergoedingentoegang tot een sales team 2/3
XXVII
Suga
rCR
M
Sale
sfor
ce.c
om
sales materiaal, tools en ondersteuninglead distributie/lead referral/qualified leads 2/3 1/2/3lead/deal registratie 1/2/3 1/2/3partnermanager 2/3 3
marketing voordelen(product marketing) collateral en campagnesproduct demonstratie (niet om te verkopen)templates en richtlijnen voor campagnes/marketing materiaal
1/2/3
gebruik van partnerprogramma logo 1/2/3 1/2/3partnerprogramma certificaatMarketing Development Fund 3distributie via een online marktplaats 1/2/3
technische ondersteuningtechnische ondersteuning 1/2/3toegang tot kennis 1/2/3korting op professionele dienstentechnische (pre-)verkoop ondersteuning (via internet)gratis licenties 1/2/3onbeperkte ontwikkelings- en testomgevingen 1/2/3
toolkit voor ontwikkeling en codebibliotheken 1/2/3
technische discussie fora 1/2/3technische support van de gemeenschap 1/2/3
VEREISTENminimum klantentevredenheidscijfers 1/2/3invullen van een partnerprogramma aanvraagformulier en profielaanvaarden van de partnerprogramma overeenkomst
1/2/3
jaarlijkse deelnamevergoeding 1/2/3jaarlijks minimum inkomsten doelen 1/2/3
XXVIII
Suga
rCR
M
Sale
sfor
ce.c
om
minimum aantal abonnementen, hoeveelheid inkomsten
1/2/3 1/2/3
minimum grootte van team 1/2/3minimum aantal getrainde mensen (verkoop of technisch)minimum aantal gecertificeerde mensen 2/3 1/2/3jaarlijks (12 maandelijks) bedrijfsplan 2/3actieve participatie in gefocuste marketing programma's
2/3
jaarlijkse sponsoring 2/3minimum aantal succesverhalen van klanten jaarlijks voorleggen
1/2/3 2/3
aantal partnerniveaus 3 3partnervergoeding per niveau
1 $ 20002 $ 60003 $ 12000
jaarlijkse minimum inkomsten1 $ 10 0002 $ 100 0003 $ 300 000
Legende
1/2 voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
XXIX
Bijlage 4: Uitgetypt interview Xplore Group Sarah: Misschien kunnen we eerst beginnen met een beetje meer informatie over het
bedrijf. Bijvoorbeeld hoe groot zijn jullie ongeveer, wat doen jullie allemaal?
Mr De Backer: Ja, dus wat wij juist allemaal zoal doen. Cronos is één van de grootste system
integrators in Belgie, dekt bijna het volledige IT gamma, zit een duizendvijfhonderdtal mensen
ongeveer. Cronos is een beetje eigenaardig qua structuur, bestaat eigenlijk uit een 150 tal
bedrijfjes, allemaal specifiek naar een bepaalde technologie, bepaalde oplossing, bepaalde
sector.Dus we werken allemaal met kleinere entiteitjes en daar zit eigenlijk de cronos holding.
Naar de klanten toe is dat niet altijd even duidelijk, waar we nu dus de laatste jaren mee bezig
zijn is een aantal clusters te gaan bouwen. Hier Xplore Group is een nieuwe holding eigenlijk
van Java bedrijven binnen Cronos. Dan is er ook een andere cluster binnen Cronos wat hardware
verzamelt, andere clusters die meer met ERP, CRM, ook Business Intellegence, Business
objects, dergelijke zaken, datawarehousing. Dan is er ook nog een andere groep die dan meer
met Oracle bezig is en dan hebben we ook nog een apart gedeelte dat met Microsoft bezig is.
Binnen Xplore Group is er dan de Java tak, dat is dan hetgeen waar ik vooral voor
verantwoordelijk ben, maar er zijn dan ook nog wel een aantal klanten centraal van Cronos ook.
Heel grote bedrijven hebben graag één aanspreekpunt of werken met één facturatie en gaan daar
vanuit. Ook alles wat overheid betreft bijvoorbeeld, ja daar moet dan vaak aan verschillende
normen qua omzet en medewerkers voldoen. Dus die worden dan vaak vanuit Cronos gestuurd.
XploreGroup groepeerd alle Java producten en wordt dus nog een keer onderverdeeld in vijf
bedrijfjes. Die vijf bedrijfjes hebben hun focus gelegd (er is er ééntje die zitten in Leuven)
verschillende application servers. Zo is er bijvoorbeeld het vroegere BAB webapplication server,
dat is nu met de samenvloeiing van BA en Oracle, is dat Oracle weblogic geworden. Dan hebben
we nog een andere groep die zich meer focusd op het IBM platform, dat is IBM Webspere
Application Server. Dan is er nog Xplore, die focusd zich op alles wat open source betreft en
Jboss, dus dat is dat platform. Dan heb je een ander XTI die eigenlijk vanuit een XML
achtergrond komen, maar dat dan nu eigenlijk met de jaren... op XML leven dat lukt nu niet
meer dus eigenlijk doorgegroeid zijn naar full Java application server onafhankelijk. En dan is er
nog een vijfde groep, een beetje een vreemde eend zou je kunnen zeggen, dat is het competence
center Adobe. Dat is alles wat Lifecycle en Adobe Flex, Flex development, Flex is dan het RIA,
XXX
Rich Internet Application development, gaan we nog wel tegenkomen. Lifecycle heeft te maken
met intellegente documenten, tekenen van documenten, documenten waar een workflow achter
zit. Dus document A gaat voor approval naar een ander persoon en dergelijken, dus vooral
document management eigenlijk. Dat zijn eigenlijk de vijf groepjes binnen Xplore Group en
Xplore Group is een groep van een hondervijftigtal mensen, dus dat is da Java tak binnen ons.
Als je dat dan in totaal die hondervijftigtal mensen die met Java bezig zijn, dan denk ik ongeveer
zowat de grootste groep in België zijn. We schreeuwen dat niet uit, maar in wezen is dat wel
ongeveer de grootste groep hier in Beglië.
Sarah: Wel mijn algemen vraag is zo’n beetje wat is het verschil tussen de samenwerking
met open source bedrijven en niet open source bedrijven. Vaak geeft men als
eigenschappen van open source dat het van goede kwaliteit is, dat er vaak updates zijn en
dat het user driven is. Is dat iets dat leeft in de realiteit? Zijn dat redenen voor jullie om
open source te verkopen aan de klanten?
Mr De Backer: Op de markt weet ik dat nu niet... Java development speelt zich vooral af in de
grote bedrijven, ja toch minstens top honderd, top tweehonderd van België. Dus daar, die grote
bedrijven durven ook niet naar open source, nu begint dat te leven vooral open source. Maar in
het verleden, kunt je wel zeggen, nieuwe dingen, maar de vraag is zijn die veilig, is dat secure?
Die vraag kom je tot op heden, ale tot op een tijd terug, waren daar de meeste bedrijven
weigerachtig over en ja open source dat is allemaal cutting edge, nieuwe technologie, nieuwe
dingskes, daar komen wel interessante zaken op maar om dat echt in een business kritische
omgeving te gaan zetten, om dat echt operationeel in productie te gaan zetten, dat durven ze over
het algemeen niet doen. Voor kleinere prove of concepts of kleiner pakketjes of in kleine nieuwe
ontwikkelingetjes te testen of dergelijke durven ze al doen, maar echt zo in productie, in een
business kritische omgeving, dan durven ze dat meestal niet doen. Nu is dat wel zo dat meer en
meer beginnen ze ook wel te kijken naar de kosten. Ja da begint op de markt, de Java developers
zelf die werken liever met de open source, ja dat kunnen ze er gratis afhalen en ze kunnen zelf al
componentjes bij elkaar gaan halen en in plaats van een blok, bij wijze van spreken, die door
IBM of Oracle word opgelegd, ja een Java developer is graag creatief bezig en gaat zijn dingskes
van het net gaan afhalen en is met die nieuwe dingen graag bezig. Daar waar je met een Oracle
en IBM vast zit aan een propietry vendor, dus op da vlak... Dus inderdaad ja dat begint toch al
XXXI
wa meer in de markt gekend te zijn, een Jboss bijvoorbeeld, beginnen daar meer en meer
bedrijven naar te kijken. Waarom nog langer betalen, want de licentie kosten voor een Oracle,
voor een IBM die liggen redelijk hoog.
Sarah: Hoe ligt dat juist voor Jboss?
Mr De Backer: Bij Jboss heb je twee mogelijkheden, Jboss is inderdaad open source, maar wat
hebben ze nu ook gedaan, ze hebben er een Jboss enterprise versie van gemaakt. Er zijn dus twee
versies namelijk de Jboss.org en dat is eigenlijk allemaal verschillende projectjes, ik denk dat het
meer dan 35 projectjes zijn, dat zijn dus allemaal de devolpers die thuis, na hun uren, zin hebben
om iets te ontwikkelen, die daar in die community eigenlijk iets gaan maken en iemand reageert
daar dan op en gaat dan iets gaan uitbreiden. Daar zit je dus met de nieuwste zaken, die zitten in
die community en zij gaan samen over de ganse wereld heen stukjes code gaan schrijven en
dingen gaan ontwikkelen. Wat doet Jboss enterprise? Oke daar zit je dan met de onzekerheid van
is dat nu wel allemaal veilig, is dat deftig geschreven? Wat is er goed, wat is er niet goed dus dan
moet men zelf gaan zoeken en uw componenten ertussen uit gaan halen. Dus dat is hetgeen wat
de bedrijven zeggen, daar durven ze niet altijd aan te beginnen. Wat heeft Jboss nu ook gedaan,
want volledig gratis gaan geven ja daar kan je natuurlijk niet op leven. Jboss heeft een enterprise
versie daarop gemaakt. En wat doet de enterprise? Die gaat eigenlijk van al die projectjes (zoals
je kan zien op de tekening) die in de community aanwezig zijn, gaat daar de meest stabiele en
beste componenten uit halen en gaat daar een aantal platformen maken, die gaan die dus bijeen
bundelen, die gaan dat door een ‘factory’ steken, binnen Red Hat Jboss, gaan zijn al die
componentjes aan elkaar plakken, allemaal testen en daar één schoon, volledig pakket van
bouwen, waarbij dat ze dan nadien support geven op het pakket of het platform dat zij gaan
uitbrengen. Jboss werkt dus niet met licenties, maar werkt met subscription. Daar waar proprietry
vendors (IBM, Oracle) met licenties werken en bij Oracle of IBM betaal je enerzijds een vaste
licentie kost en anderzijds een kost voor support, daar waar Jboss werkt met een subscriptie en
dat eigenlijk enkel support inhoud en voor de rest heb je toegang tot patches en alle updates en
dat is dan ook wel betalend, maar die kostprijs ligt een heel stuk lager.
Sarah: Dus dat is dan de grootste toegevoegde waarde van Jboss? Die pakketjes
samenstellen en daarbovenop support leveren?
XXXII
Mr De Backer: Ja.
Sarah: Hoe zit dat dan juist allemaal in elkaar? Jullie verkopen dan het product Jboss en
zij bieden dan support, hoe loopt dus die stroom dan eigenlijk?
Mr De Backer: Dus ja wat doen wij? Het is dus eigenlijk zo dat Jboss zelf gaat dus (bijna) nooit
direct aan de klant verkopen. Jboss zelf heeft geen eigen sales mensen, zij werken via een kanaal,
dus via de channels, via partners eigenlijk. En daaronder heb je een aantal partners waaronder
wij nu ook advanced business partner zijn. We zijn onderweg naar het primium partnership. Die
partners doen dan eigenlijk de sales voor hun. En dan wordt dat eigenlijk geshipt via een
distributie, via een distributeur. Dus wij gaan eigenlijk bij de klanten vertellen wat hij allemaal
kan bij Jboss, ja we hebben onze developers ook die gewoon zijn van op Jboss te werken, en dan
gaan we het dus aankopen bij een distributeur en die gaat eigenlijk nadien, ja ge maakt een Red
Hat netwerk en dan is het eigenlijk een sleutel dat je krijgt en dan met die sleutel kan je op een
portaal en op dat portaal kan de eindklant alles, alle update, alle mogelijke support calls gaan
doen.
Sarah: En hoe zit die support dan juist in elkaar?
Mr De Backer: Bij Jboss is er productie support en development support. Als er bijvoorbeeld een
applicatie wordt gebouwd ja dan ga je meestal eerst in development, ga je die eerst gaan bouwen,
dan ga je in een testfase gaan, waar die applicatie getest wordt en dan gaat die in acceptatie,
checken of alles wel inderdaad oké is en dan gaat die pas in productie en dan draait dat op een
apparte server, draait dat in productie en dan kan de eindgebruiker daar continue mee werken.
Dus zij geven development support, dus voor developers als ze daar vast zitten stel dat hier in
productie ook nog ergens een probleem voorkomst, dan kan je ook nog productie support
hebben. Er zijn twee manieren van support, dat is een standaard, dat is gewoon tijdens de
business uren, ofwel de primium dat is dan 24u op 24, 7dagen op 7. Wat is de SLA (Service
Level Agreement) daarop, dus als je een primium hebt, dan ga je binnen het uur reactie tijd
hebben, binnen het uur gaan ze bij u terugkomen en gaan ze zorgen dat ze u kunnen helpen.
Gaan we naar een standaard support, dan hebben ze vier business uren reactie tijd. En verder een
manier van communiceren is ofwel het web, dus email of dat Red Hat network, ofwel gewoon
per telefoon. Dat is het schema dat er bestaat. Naar developer support is er ook nog een klein
XXXIII
verschil, daar heb je de standaard of professional en heb je 2 business uren dat er reactietijd is en
enterprise is 4 uur. Dat is dus het stuk qua support.
Sarah: Jullie verkopen de producten dus naar de klant toe?
Mr De Backer: Ja, er zijn nu twee manieren eigenlijk. Ofwel werken de klanten reeds op de
Jboss.org en is de klant dus al bezig in de community en haalt die daar zelf zijn dingen uit, maar
zeggen zij, “wij willen een aantal zaken standardizeren of hebben we toch nog wel wat
problemen” en dan is het die mensen proberen te overtuigen van te gaan zeggen “waarom ben je
nu eigenlijk knip-en plakwerk of knutselwerk aan het doen en ga je zelf in de community al die
dingen gaan halen, daar waar er eigenlijk als je hier nu een licentie neemt op 4 CPU basis kost
het rond de 3500 euro, als ik mij niet vergis, standaard support (dus de gewone business uren),
premium is het iets van een 5000 euro per jaar. Dus dat is geen enorme kost, ga je dan niet beter
over gaan naar de Jboss Enterprise en heb je full support en heb je één centraal punt, heb je
geteste versie da je kan gebruiken”. Dus dat is dan één strekking die dan al met dat Jboss
platform werkt, die dan eventueel naar de enterprise versie kunnen omschakelen. Wat je ook heel
vaak merkt is dat klanten niet weten dat die Enterprise versie bestaat, dat is nog niet zo goed
geweten. De laatste jaren, dat begint wel te komen. Heel vaak zegt de klant dan “ja wij werken
hier met een Jboss” waarbij ik dan vraag “is dat dan een Jboss.org of Enterprise?” dat weten ze
dan zelfs niet. Vaak is het de developer die zegt, “we zetten het hier op Jboss”. Een ander piste
die loopt is, nu met de crisis periode, ja alles wordt toch een beetje meer in het oog gehouden,
zijn de bedrijven die op deze moment op een Oracle, BA of IBM draaien die nu weet krijgen van
Jboss (Enterprise) en dat dat zeker zo goed is als Oracle of IBM, maar nog zoveel keer
goedkopen en waar het dus interessant kan zijn om naar Jboss te migereren. Natuurlijk de vraag
is, je hebt natuurlijk een migratiekost, die ook niet te onderschatten is, dus je gaat ook redelijk
wat tijd gaan insteken om te migreren. Want er zijn dan van die studies, men noemt dat Total
Cost of Ownership, dat is de studie tussen de kost die je hebt van bv. IBM licentie en support ten
opzichte van enkel subscriptie bij Jboss. Dat is eigenlijk het verschil en er zijn dan nu bedrijven
die aan het kijken zijn van “kunnen we nu niet beter naar die open source gaan”. De meesten
zeggen “wij betalen nu veel geld voor die licenties bij IBM of Oracle, maar blijkbaar kunnen we
dat evengoed gratis, want Jboss begint een goede naam te krijgen op de markt”. Dus dan
beginnen ze beginnen ze al te kijken naar de Jboss.org, zij denken dan dat dat gratis is en daar
XXXIV
tegenover staat dan IBM of Oracle waarvoor men licenties moet betalen. Jboss is eigenlijk een
tussenweg, die kennen ze vaak niet, dus dat daar dan toch nog support op mogelijk is. Voor hun
is er dan een beetje de twijfel “waarom zouden we betalen voor Jboss, terwijl we Jboss ook gratis
kunnen hebben”, maar in wezen zit er toch nog wel een verschil, zoals die support. Het enige
nadeel of verschil is dat eigenlijk de Enterprise versie een beetje achter zit op de community
versie. Omdat dat proces van projecten uit de community gaan halen, refactoren, checken en
goedkeuren, dat neemt toch wel wat tijd in beslag en tegen dat dat volledig door factory is
gegaan en dat ze een versie hebben gemaakt waarop zij support gaan leveren, is er ondertussen al
wat tijd verlopen en is er weer een nieuwe variant in de community gebracht.
Sarah: Ja met betrekking tot het partnerniveau, je zegt dat jullie nu advanced zijn en bezig
met over te stappen naar het premium partnership. Hoe komt dat dat jullie die overstap
hebben kunnen maken en wat zijn dan de voordelen?
Mr De Backer: Ja wij zijn eigenlijk onmiddelijk van ready naar advanced gegaan. Dat is een fee
dat wij betalen aan Red Hat zelf om dat te mogen gaan doen, bij wijze van spreken, dat valt al bij
al wel mee. Maar je hebt zowiezo wel twee gecertifieerde mensen nodig om naar het advanced
level te gaan, dus die moeten ergens een Jboss training gevolgd hebben en een Jboss certificaat,
dus een examen hebben gedaan. Het was zo dat dat een aantal jaren geleden bestonden die
certificatie examens, dat is dan een aantal jaren niet meer mogelijk geweest om nog mensen te
certifieren, ze organiseerden dat niet meer. Nu begint dat terug vorm te krijgen en zijn ze daar
terug mee bezig, bestaat terug één certificaat. Dus je hebt Jboss voor developers en Jboss voor
administrators. Dat zijn de twee certificaat examens die er zijn. Dus dan ben Jboss certified
developer of Jboss certified administrator.
Sarah: Die mensen zijn dan voor de reseller?
Mr De Backer: Ja dat is inderdaad eigenlijk voor onze mensen. Als werkgever kan je ook je vaste
developer in je bedrijf een certificaat laten behalen, dat hoeft niet maar dat kan. In consultincy
heeft dat toch wel een meerwaarde, “kijk deze is wel degelijk gecertifieerd, heeft daar wel
degelijk kennis van”. Ja het verschil dan met een ready partner of een advanced partner is dus
enerzijds er zit dus wel een kostenplaatje aan en je moet ook laten zien dat je een aantal mensen
met Jboss kennis in huis hebt. Dus daar ligt eigenlijk het verschil. Dus je als je advanced
XXXV
business partner bent betekent dat dat je minsten vijf à tien mensen hebt die daar kennis van
hebben. Op de website kan je die lijst terug vinden met wat de voorwaarden juist zijn voor ready,
advanced en premium. Dan naar premium partner moet je dan in totaal, denk ik, vijf
gecertifieerde mensen hebben of moeten ze dan trainingen laten volgen. Daar is dan ook het
verschil dat je als advanced partner extra korting krijgt, dat mogen we natuurlijk aan onze
klanten niet zeggen, maar krijgen we extra korting bij de distributeur, dus kunnen wij onze
licenties goedkoper gaan aankopen, waardoor dat wij onze klanten ook een korting kunnen
geven.
Sarah: Dus die marges zijn dan hoger voor jullie?
Mr De Backer: ja. Stel nu dat een ready partner een subscriptie wil gaan verkopen bij een klant,
die gaat dat over het algemeen aan de listprijs kunnen doen, waar dat wij dan 2à3% extra korting
kunnen geven.
Sarah: En hoe zit dat dan met de partner fee?
Mr De Backer: Dat ken ik niet juist uit mijn hoofd, ik denk dat dat een 5000 euro is
Sarah: Is daar dan duidelijk een verschil met bv IBM Websphere?
Mr De Backer: Dat durf ik niet direct te zeggen. Dat moet ik opzoeken. Over het algemeen is dat
in dezelfde stijl, namelijk dat je een aantal gecertifieerde mensen moet hebben. Maar die fee kan
ik wel opzoeken en laten weten. Ja uiteindelijk is de vraag waarom doe je dat, dat is een beetje
marketing eigenlijk, dat je kan laten zien en bewijzen dat je een aantal dingen kan. Je hebt me
ook zo gevonden via de website van Jboss, bij advanced partner, dan kom je uiteindelijk bij ons
terecht. Dus dat is eigenlijk een beetje meer publiciteire waarde dat dat heeft. Als je dus een
advanced partnership hebt laat je zien dat je dat je een samenwerking hebt met de mensen van
Jboss en dat je een minimum aantal mensen in huis hebt die kennis hebben van Jboss en
rechtstreeks contact kunnen hebben met hun als er problemen zijn en hebben dan ook zelf
toegang tot dat netwerk. Wij kunnen dus een aantal zaken intern testen en op voorbereiden.
Waarom we dan eventueel premium zouden willen worden is vanwege de samenwerking bij
professional services. Wat is professional services? Red Hat zelf heeft ook zijn mensen, maar die
zitten verspreid over heel de wereld. Voor echte zware problemen, maar die profielen betaal je
XXXVI
ook wel, want als die mensen moeten langskomen, die komen van heel ver. Er zijn een aantal
zaken, zoals klanten die met problemen op hun Jboss zitten die dan contact opnemen met Jboss
en dan gaan ze dat zelf gaan oplossen. Bij echt speciale problemen, dan gaan ze dat zelf
oplossen, hebben ze een aantal eigen mensen voor. Als je dan premium partner bent kan je ook
met je eigen mensen een samenwerking opbouwen, onze mensen hebben ook een heel hoog
niveau van kennis, dat die mee met professional services kunnen samenwerken. Dat is eigenlijk
een beetje het verschil. Maar in weze tussen advanced en premium partnerships is er eigenlijk
heel weinig of geen verschil.
Sarah: Is er dan een verschil tussen de support die jullie krijgen bij advanced ten opzichte
van ready?
Mr De Backer: Ja daar is al eerder een verschil. Ja naar support voor de klant of dat hij die nu
aankoopt bij ons of bij de premium, advanced of ready dat is allemaal gelijk. Support blijft
identiek, deze gaat niet vanuit ons maar vanuit Jboss. Anderzijds zijn wij wel normaal verplicht
om eigenlijk te proberen hun subscriptie model te verkopen. We hebben wel een aantal klanten
die op de Jboss.org zitten, als die problemen hebben, mogen we die volgens de regels niet
helpen, maar wij kunnen moeilijk tegen een klant zeggen “wij hebben Jboss kennis maar wij
mogen u niet helpen”, we moeten een beetje realistisch zijn, dan durven we toch wel te helpen.
Maar natuurlijk voor de klant is dat niet zo interessant, als wij iemand moeten tot bij de klant
komen, ja de gemiddelde dagprijs van een developper, hangt er van af hoe specifiek dat is, ligt al
tussen de 500à600 euro per dag. Als je die persoon 10 dagen moet laten komen, ja dan zit je aan
5000 euro, daar waar een subscriptie tussen de 3000à5000 ligt op jaarbasis. Dusja als je veel
problemen hebt, kan je veel beter een subscriptie aangaan.
Sarah: Waarom hebben jullie eigenlijk gekozen voor Jboss? Zijn er bijvoorbeeld
concurrenten van Jboss (het bedrijf) die hetzelfde doen?
Mr De Backer: Neen. Je hebt enerzijds, de proprietry vendors zoals Oracle en IBM, dan heb je
Jboss die daar met zijn Enterprise zo wat tussenin zit en dan heb je volledig open source en dat is
dan de Jboss.org. Tomcat is ook volledig open source, Glassfish ook. Maar dat zijn over het
algemeen wel de kleinere applicaties servers, die zijn dan allemaal open source. Het verschil is
dat als je op een Jboss of een Tomcat zit dat je gemakkelijker kan gaan migreren naar een ander
XXXVII
platform, daar waar je als je een licentie zit, eens dat je dat neemt kan je daar veel moeilijker uit.
Zoals ik daarnet al zei, er zijn nu wel bedrijven die daar naar kijken om te gaan migreren van
IBM, Oracle naar een Jboss, maar dat doe je niet van vandaag op morgen. Het is niet dat je aan
de ene kant de stekker uittrekt en aan de andere kant een andere stekker insteekt. Dus daar zit
dan wel een heel traject eigenlijk achter. Daar waar als je op een Jboss zit je wel makkelijker kan
doorschakelen naar een ander model.
Sarah: Voorzien jullie daar eigenlijk in, in die overgang van bv IBM naar Jboss?
Mr De Backer: Ja, dat doen we. We hebben daar een aantal migratietrajecten. Dat is eigenlijk een
groot deel van onze business.
Sarah: Op de website heb ik gelezen dat jullie een solution provider zijn, maar dat is dan
iets anders dan een consultant?
Mr De Backer: Ja, je hebt daar ook verschillende zaken. Consultant is eigenlijk het verhuren, bij
wijze van spreken, van een aantal developers, dat is puur het consultancy. Dus dat de klant, zoals
Toyota, Toyota is nu intern met een project bezig, die dan zeggen “wij gaan dat hier allemaal in
Java doen, en dat op dat platform doen en daarvoor hebben wij een team nodig van 5
developers”. Oke ja dan komt Toyota bij ons vragen “hebben jullie 5 mensen die aan die
technische kennis voldoen, kun je die naar bij ons sturen”. Dat is eigenlijk puur het stukje van
consulting. Ga je naar solution, is het eigenlijk een beetje anders, namelijk dat bijvoorbeeld
Toyota zegt “wij willen een applicatie bouwen kunnen jullie ons applicatie bouwen” of een
andere klant “zegt wij willen dat bouwen, we hebben dat idee, we zouden willen dat dat en dat
geautomatiseerd wordt” en dan gaan wij eigenlijk de oplossing bieden van “kijk wij gaan dat op
die manier doen”, gaan we daar een projectmanager aan zetten en gaan wij heel dat project in
eigen h anden gaan nemen, dan gaan we eigenlijk een oplossing gaan bieden naar de klant. Maar
dat is dus eigenlijk onze core business, dat is Java, custome made development, dus op maat
ontwikkeling van Java applicaties. Dus dan gaan we eigenlijk maatprogramma’s gaan bouwen.
Los daarvan is consultancy puur mensen gaan plaatsen, anderzijds er dan eventueel een klant die
zegt “we willen dat process gaan automatiseren, we willen een applicatie daarvoor bouwen” en
dan gaan we dat eigenlijk volledig in beheer gaan nemen.
Sarah: Is dat dan zoiets al Independent Software Vendor?
XXXVIII
Mr De Backer: Neen, dat is dan nog iets totaal anders. Dat zijn dan eigenlijk bedrijven die een
volledig pakket, zoals een boekhoud pakket, gaan bouwen specifiek voor bv een
architectenbureau en dan kan je daar niks meer aan gaan doen. Dat is off the shelve, zoals je in
de supermarkt producten uit het rek gaat halen en dat product kan over gans België bij
verschillende bedrijven verkocht worden. Maar onderliggend bijvoorbeeld zijn er dan die ISV’s
die dat boekhoudpakket, maar onderliggend draait dat dan op een Jboss. Dus zij hebben dat
ontwikkeld op een Jboss bijvoorbeeld. Daar waar wij eigenlijk een pakket op maat gaan maken,
zijn dat dan degenen die één pakket maken en daar moet je je dan houden aan de regels binnen
dat pakket. Wij gaan dan een pakket maken dat zo en zo er uitziet, volgens wat de klant wilt
(logo daar, kleur daar, die functionaliteiten). Als je een pakket vast gaat kopen heeft dat zijn
beperkingen en voor de kleinere bedrijven voldoet dat, voor andere bedrijven, voornamelijk
grote, daarom dat ik ook zeg Java custom ontwikkeling speelt zich af bij de grotere bedrijven, de
top honderd, top tweehonderd. Dus dat is eigenlijk een beetje het verschil.
Sarah: Hoe zit jullie relatie met de Jboss community eigenlijk in elkaar? Wat u daar
eigenlijk van, wie zijn bijvoorbeeld de mensen die bijdragen?
Mr De Backer: Wij zijn daar eigenlijk zelf niet zoveel mee bezig. Ik weet wel dat Jboss
inderdaad zelf een aantal eigen mensen inderdaad die ontwikkeling doen. Wat zij wel vaak doen
is de mensen die heel veel bijdragen in die community, die pikken zij er tussenuit en die gaan zij
in vaste dienst gaan nemen en dat zijn eigenlijk diegenen die juist al die projectjes in die factory
gaan nakijken. Of die mensen gaan dan nieuwe zaken in die community steken en terwijl dat ze
voor de rest bezig zijn met het refactoren van die projectjes.
Sarah: Hoe zit dat met geografische exclusiviteit?
Mr De Backer: Ja naar aantal Java mensen zijn we wel bij de grootste. Realdolmen zal ook wel
in die buurt komen. Zij zijn in België de enige premium partner. Het zou kunnen dat Capgemini
misschien ook nog advanced is. Maar daar komen wij niet zoveel in concurrentie mee. Zij
hebben meer een internationale structuur en die hebben dat op internationaal niveau eigenlijk. Ik
denk dat wij samen met Capgemini de enige Advanced partners zijn en dan heb je ook nog een
heleboel ready partners, maar dat kan je op het internet vinden.
Sarah: Het woord ecosysteem, is dat iets wat jullie bezig houdt?
XXXIX
Mr De Backer: Neen niet echt. Ja Jboss omschrijft dat wel ergens. Ja dat is wel wat marketing
blabla. Maar wat bedoelen zij daar eigenlijk mee, ja dat is in die community, dat is één
ecosysteem van allemaal open source of Jboss ‘minded’ mensen en dat noemen zij dan hun
ecosysteem. Omdat die community eigenlijk hun ecosysteem is, waar iedereen aan bijdraagt.
Maar die term gebruiken we niet echt.
Sarah: We zien dat de software industrie aan het veranderen is
Mr De Backer: Ja je ziet wel dat bedrijven vroeger meer de pakketten kochten, dat ze meer en
meer zelf iets willen maken of custom, naar hun bedrijf toe, ieder bedrijf wilt het op zijn manier
hebben en allemaal zijn eigen verschillende producten. Misschien meer maat ontwikkeling, maar
ik weet nu niet of dat zo een groot verschil.
Sarah: Ja ik denk dat dat de belangrijkste vragen waren, misschien dat u nog opmerkingen
heeft?
Mr De Backer: Ja ik heb het daarnet al gezegd, Realdolmen is op Jboss niveau één van de
belangrijkste, zij zijn wel premium, maar ik denk dat zij op zich minder met Jboss bezig zijn dan
wijzelf. Ze hebben misschien wel een paar mensen meer, maar... opzich ja, ze hebben ooit
daarvoor betaald voor die titel bij wijze van spreken, maar ik denk dat wij met Jboss meer of
rechtstreeks in contact zijn dan bij Realdolmen. Maar ik denk dat er in weze weinig verschil is
tussen hun en ons is, zij hebben goede developers, wij hebben goede developers, zij hebben er
een paar die minder zijn, wij zullen er een paar hebben die minder zijn, maar in weze zit daar
eigenlijk niet zoveel verschil tussen.
Sarah: Is er dan ook veel contact tussen jullie en Jboss?
Mr De Backer: Ja, dat is toch bijna dagelijks dat ik contacten heb ja. Omdat we ook vaak dat
salesproject samen doen.
Sarah: Zijn die mensen dan van België?
Mr De Backer: Ja, mijn aanspreekpunt is de Channelmanager, die dus eigenlijk instaat voor zijn
partners. En dan heb je één dame die vroeger channelmanager was maar die is nu sales eigenlijk.
Wat doet zij eigenlijk? Zij verkondigt Jboss of Red Hat, want ze doen de twee samen, Red Hat
XL
op infrastructuur niveau en Jboss op software application server niveau. Zij gaat bij de klanten,
als er rechtstreeks een vraag komt bij Jboss, dan gaat zij eigenlijk op pad en als de klant een
beetje overtuigd is en zegt “oké wij willen met Jboss verder gaan” dan gaat zij zeggen “kijk wij
leveren dat niet rechtstreeks, wij werken met een partner kanaal” en dan vraagt zij “zijn jullie al
met één of andere system integrator in contact?”, ja als ze al samenwerken met Realdolmen, dan
gaat da via hen, maar anders zegt ze “Ja, in België zijn er twee of drie grote partners die de Jboss
kennis in huis hebben” en dan heeft de klant de keuze om met ons contact te nemen of met de
andere contact op te nemen. Naar overheid toe, die werkt nog een beetje anders, die zitten vaak
met lastenboeken, die moeten dan minstens drie partijen aanspreken, dan wordt de vraag zowel
bij ons gelegd, als bij Realdolmen en nog iemand anders. Dan krijgen we alledrie de kans om te
gaan aanbieden.
Sarah: Men zegt soms dat men niet zo’n uitgebreid salesteam nodig heeft om open source
te verkopen, omdat klanten zelf bij de verkoper komen aankloppen, merk je dat?
Mr De Backer: Ja natuurlijk, het verkoopt omdat het zogezegd gratis is. Daar waar men nu veel
geld betaald voor licenties, dat weegt op hun IT, op hun budget, wetende dat Jboss toch wel
blijkbaar oké is, zeggen ze “kijk, kunnen we niet naar gratis gaan?” ja dat is altijd interessant.
Hoewel dat gratis natuurlijk niet meer bestaat. Maar dat doe je natuurlijk niet op één twee drie, in
realiteit is dat niet dat je de langs de ene kant de stekker uittrekt en de andere insteekt, dus dat is
in realiteit zeker niet zo het geval.
Sarah: Hoe zit uw relatie met de mensen van Jboss/Red Hat eigelijk in elkaar?
Mr De Backer: Wij hebben geregeld contacten, ieder jaar is er ook een partner summit, dat is nu
van 2 tot 5 mei in Valentia, dus daar mag ik dan ook naartoe. Er zijn ook technische sessies en
sales sessies.
Presentatie rond Jboss
Uitleg bij de presentatie van Xplore Group over Jboss:
(slide 3 en 4)Eerst is er het verhaal van Jboss.org. Je hebt hier een aantal platformen, application
platformen, een aantal projectjes. Dat zijn dan telkens projectjes waar nieuwe versies van zijn.
Wat gaat de enterprise dan doen? Zij gaan de meest mature, de beste versies ervan tussenuit
XLI
halen, in een Q&A process steken, die gaan documenteren, zien dat die veilige zijn,
configureren, updates geven, en daar gaan ze dan hun subscripties gaan op geven.
(slide 5)Dit is de nieuwste slide of hun portfolio eigenlijk, dat zijn die pakketjes of die
platformen waar ze mee werken en dan zie je dat de kostprijs stelselmatig omhoog gaat. Dit is
eigenlijk het standaard pakket of het meest bekende pakket, dat is het Jboss Enterprise
Application Platform. Daar heb je dus support op de application server, volledig JEE. Dit is het
Webplatform, dat is een stapje lager gaan, puur voor kleinere webapplicaties, dat is eigenlijk de
‘light’ versies van de Jboss Enterprise Application Platform. De Jboss Web Framework Kit is de
hele light versies, ja dat is op een Tomcat, echt puur voor Webdevelopers.
(slide 6)Ga je één stap verder, dat is het zelfde pakket, maar daar zit dan nog een portal bij. Weet
je wat een portaal is?
Sarah: neen…
Mr De Backer: Portal is eigenlijk één scherm waar je meerdere applicaties gaat in steken en dan
kan de administrator hiervan eigenlijk rechten gaan toekennen aan ieder applicatie. Dus dat is
dan één portaal met verschillende port ledjes, toegangspunten. Op die manier kan men zeggen
“die persoon heeft toegang tot die applicatie en die applicatie en gaat dan in zijn hoofdscherm
eigenlijk al zijn applicaties waartoe hij toegang heeft kunnen gaan zien. Een andere collega die
naast je zit kan bijvoorbeeld maar tot andere applicaties toegang hebben. Dat is dus eigenlijk een
portal. Dit is BRM Business Rules Management, dat is om de business mensen zelf eigenlijk te
kunnen gaan uittekenen met een rule. Die kunnen dan zelf eigenlijk in een tool rules gaan
tekenen. Dus die kunnen zelf in een process eigenlijk, dit is stap één... Bij een bank bijvoorbeeld,
als je geld wil gaan lenen voor een woning te kopen dan kan dat bijvoorbeeld een regel zijn dat
bij een bedrag van een lening kleiner dan 100 000 euro kan dat doorlopen, bij een bedrag tussen
de 100 000 en 150 000 euro gelden die voorwaarden,... Die regeling eigenlijk te gaan uittekenen,
high level heb je dus dat platform en die tools daarvoor en kan je dat daarvoor gaan gebruiken.
En dat is dan nog het SOA platform. SOA is eigenlijk het ordenen van uw applicaties, een ESB
zit daar bijvoorbeeld in. Je gaat dus uw applicaties, uw documenten en uw mensen ordenen. Een
ESB, Enterprise Service Bus kan je aanzien als een bus, waar je al uw applicaties schoon gaat
alligneren, daar waar je in een server omgeving een applicatie daar, een applicatie ginder hebt.
XLII
Die worden dan eigenlijk op één laag gezet, orchestreren eigenlijk, en die met elkaar in contact
gaan brengen, zodat die onderling allemaal met elkaar kunnen communiceren op één tussenlaag,
op een ESB. Is het een beetje duidelijk?
(Slide 7)Dat is nog een beetje het verhaal, welke pakketjes er allemaal bestaan.
(slide 8) Dit is dan het application platform, wat daar juist allemaal in zit.
(slide 9) Dit is het SOA platform, wat daar juist allemaal in zit.
(slide 10) Dat is dan het model van support.
(slide 11) Dat is Jboss operations network, is ook iets dat er nu bijkomt. Dat is vooral eigenlijk
naar de administrators. Dus diegenen die van systeem beheer zijn, de mensen die die applicatie
eigenlijk gaan beheren en die kunnen eigenlijk daar, die hebben eigenlijk ook één portaal waar ze
die applicaties kunnen gaan beheren naar performantie toe bijvoorbeeld. Er kan bijvoorbeeld bij
één applicatie te veel load zijn, als er te veel mensen tegelijkertijd op een applicatie bezig zijn,
kan die application server zeggen, stop, teveel op één applicatie server en dan kunnen ze gaan
zien om eventueel een aantal Jboss applications te gaan clusteren, naast elkaar te zetten en
eigenlijk om die een beetje te gaan monitoren. Daarvoor dient dat.
(slide 12) Dit is eigenlijk de inhoud van een subscriptie. Wat er allemaal in zit. Dus product
access, toegang tot de source code en de binary code, documentatie, updates die mogelijk zijn,
toegang tot patches, flexibiliteit, ja dus die zijn niet versie specifiek. Dus de oudere versies
blijven gesupporteerd. Customer support portal, dat is uw portaal waarop ze kunnen connecteren,
waar je toegang toe krijgt als klant om uw vragen te gaan stellen en uw alleurs te gaan belden. Ja
het support model, ja dat hangt er van af welke support je neemt, dus tot 24/7 het zwaarste.
Lange termijn stabiliteit, gedurende meerdere jaren kan je support hebben. Legal assurance, dat
is eigenlijk nog een beetje een eigenaardigheid, dat is eigenlijk om u als klant te gaan
beschermen tegen code die bijvoorbeeld, ik zeg nu maar... Je hebt twee concurrerende bedrijven
Toyota en Mazda en je hebt daar een developer die bepaalde codes gemaakt heeft tijdens zijn
uren bij Toyota, die smijt dat morgen op de community, die heeft daar eigenlijk stukken code bij
Toyota gemaakt en die gaat die nu ineens op de community smijten, die wordt daar bijvoorbeeld
ontslagen en steelt nog code bij Toyota en die komen terecht op de community. Die wordt door
XLIII
Jboss opgenomen in de Enterprise versie en Mazda gaat dan lijnen code gaan gebruiken die ooit
bij Toyota gemaakt geweest zijn. Nu komt Toyota dat bij wijze van spreken te weten dat ze bij
Mazda code gebruiken die eigenlijk door hun gemaakt is en dan gaan zij zeggen “zeg, jullie zijn
eigenlijk applicatie aan het gebruiken die in ons beheer is, want die is onze eigendom.” Ja
eigenlijk zegt Jboss ”die is op de community gesmeten, die is door ons gemanipuleerd, die zijn
door ons aangepast” zij gaan eigenlijk dat process dat Toyota aanspant t.o.v. Mazda
bijvoorbeeld, gaan zij Mazda gaan steunen, dus dat is eigenlijk de legal assurance.
(slide 13)Dit zijn dan de voordelen van met een Jboss Enterprise te gaan werken. Ja een lagere
TCO, dat heb ik al gezegd, een redelijk eenvoudig te consumeren portfolio. Je betaalt een prijs,
je hebt twee mogelijkheden. Je hebt het CPU model, Computer per Unit op de server en dat is
dan voor 4 CPU of voor 32 CPU, het zijn alleen de fysieke sockets die tellen, daar waar bij IBM
bijvoorbeeld moet je de cores gaan tellen, hangt het er van af op welke servers het draait, een
Intel, een andere... Dat model eigenlijk om de prijsberekenin te gaan doen, dat is verschrikkelijk.
Bij Jboss maakt het eigenlijk allemaal niet uit of het op een Window, Linux, Unix,... omgeving.
Dus je hebt hier uw application, draait onderliggend is dat eigenlijk het leukste voor hun dat het
op een Red Hat Linux zou draaien, maar het kan evengoed op Windows, Unix of een andere
Linux, vandaar.
Sarah: Kun je dan misschien ook zeggen wat de nadelen zijn aan open source?
Mr De Backer: Ja als je pure open source gaat doen, de .org versie dan ga je gewoon heel veel
tijd gaan steken in alle componenten te gaan zoeken, je hebt geen zekerheid dat de code, dat dat
wel werkt en dat dat veilig is. Ik zie weinig nadelen tussen een Jboss Enterprise of IBM of
Oracle. Ik denk dat daar in weze eigenlijk weinig verschillen tussen zijn. Dat denk ik niet. Ja we
zijn gewoon vertrouwd met IBM, ja IBM heeft natuurlijk een salesploeg, dat is meer dan één
voetbalploeg dus dat is op de markt al zo groot... Wat dat zij zeggen is “ja open source dat is niet
veilig, dat is niet secure, dat is niet goed getest,...”. Die verhalen dat ga je blijven horen. Ik heb
daar ook studies door IBM zogezegd, waar het verschil tussen IBM en Jboss wordt vergeleken en
waar Jboss dan zo wordt afgebroken,...Ja dat is marketing, ja wat mag je daar van geloven. Ik
denk in de realiteit of je nu op een Websphere of Jboss draait, ik denk dat daar in weze niet
zoveel verschil in is. Het hangt er een beetje van af met wat je juist bezig bent, in welke
omgeving dat je draait, maar in weze denk ik dat er weinig verschil is. Zij zeggen dan “Jboss dat
XLIV
is goed voor development, maar in een productie omgeving, dat is niet stabiel, dat is niet
goed,...”
Sarah: Wat is dan eigenlijk het verschil tussen production en development?
Mr De Backer: Development is eigenlijk daar waar je de applicatie nog aan het bouwen bent en
waar je nog code kan gaan aanpassen. Productie is eigenlijk, ja dan blijf je er in principe vanaf,
dus dan is iedereen daar op aan het werken en dan is dat voor alle eindgebruikers in gebruik en
dan wordt daar eigenlijk niets meer aan aangepast. In development ben je eigenlijk uw applicatie
aan het bouwen, dan ga je gaan testen, tijdens uw development fase doe je al testen, dan ga je
naar een testfase en dan in acceptatie of preproductie fase is dat eigenlijk dan ga je een beperkt
aantal eindgebruikers die applicatie laten gebruiken en als die in productie is dan is die klaar en
dan blijf je daar van af en enkel onderhoud gaan doen.
(slide 14) Ja, dat zijn dan de service dat wij dan bieden. Wat wij zoal doen, enerzijds dus
consulting, anderzijds doen wij ook analyse. Eigenlijk een project of een applicatie gaat door een
aantal fases. In het begin is dat eigenlijk gaan praten met de business, een analyse eigenlijk, daar
start je mee, ga je gaan praten met de business, wat wilt de eindgebruiker, wat willen ze nu
eigenlijk gaan bouwen? Hoe moet dat er uit zien? Wat is de bedoeling? Dan ga je een functionele
analyse gaan doen. Daarna ga je naar architectuur, doen we ook, we hebben ook een aantal
architecten in huis, die dan gaan bepalen, kijk hier is nu functioneel beschreven de applicatie die
we zouden gaan bouwen en dat moet dat en dat kunnen, dat is voor ons het belangrijkste, dat is
voor ons minder belangrijk. Een architect gaat dat dan technisch gaan bouwen, die gaat eigenlijk
een architectuur gaan opbouwen, zo en zo, die tools gaan we gaan gebruiken en dan ga je naar
development. Dan zijn het eigenlijk de mensen die code schrijven, die eigenlijk op basis van de
technische uitschrijving, dus eerst wordt het functioneel uitgeschreven en dan wordt het
technisch uitgeschreven. En dan ga je dat in development gaan schrijven eigenlijk. Verder doen
wij eigenlijk ook auditjes, dat gebeurt als er performantie problemen zijn of andere. Dat is dan
als er problemen zijn, als een applicatie niet goed draait, dan is dat vaak een dag of twee, drie dat
één van onze architecten naar een klant gaat, wat loopt er hier nu mis, wat kan er hier verbeterd
worden, wat is er hier niet goed gemaakt. Dat is dan al meer een audit. Dan projectmanagement,
we hebben een aantal project managers die het opbouwen gaan opvolgen en zien dat alles in
goed banen loopt.
XLV
Sarah: zijn dat dan de Jboss gecertificeerde mensen?
Mr De Backer: Ja als het om puur Jboss gaat, zijn dat de Jboss experten. Die dan eigenlijk bij
een aantal klanten die met performantie problemen zitten, dat ze bijvoorbeeld de load van het
aantal gebruikers hebben onderschat... Bijvoorbeeld een website of applicatie die wordt gebruikt
tijdens de verkiezingen, of een website die ineens heel veel bezocht wordt om te zien of die
applicatie dat aantal mensen aankan. Of bijvoorbeeld voor een concert van Michael Jackson, ja
dan wil iedereen een ticket bestellen en dan natuurlijk slagen al die servers tilt, want die zijn daar
niet voor gemaakt, die zijn er bijvoorbeeld op gemaakt dat er 10 000 mensen kunne op zitten
maar niet 100 000 mensen. Een applicatie wordt vaak gebouwd voor intern gebruik of extern
gebruik, maar denken ze, dat begint, voor x aantal zal dat voldoende zijn, maar dan wordt dat
bekender en bekender. Facebook in het begin zat ook maar een beperkt aantal mensen, nu zit half
de wereld daar op, dus om dat eigenlijk stabiel te kunnen houden, vaak gebeurt het dan dat ze
zien, how, we hebben hier problemen met het programma...
(Slide 16) Ja dit zijn hier een paar referenties, bij een aantal klanten, op Jboss.
Zo, als ik je eventueel nog verder kan helpen, of je in contact kan brengen met de mensen van
Jboss zelf, moet je het maar zeggen.
Sarah: Ja wel ik heb nog twee inteverwies, bij Realdolmen en Capgemini, dus daarna kan
ik nog zien...
Mr De Backer: Ah ja, ik denk dat Capgemini advanced partner is zeker. Ja tussen Realdolmen en
ons zal op zich weinig verschil zijn. Capgemini is eigenlijk meer een internationale structuur,
wat zij eigenlijk doen is projecten volledig in beheer gaan nemen, het is niet echt dat zij het
subscriptie model echt verkopen, zij gaan eigenlijk bij de klanten of de klant komt bij hun en ze
gaan een applicatie gaan bouwen, ze gaan dat op een Jboss doen en nadien zeggen ze tegen Jboss
‘by the way’ we hebben hier een applicatie geschreven, voor die klant en die wil daar nu ook
support op. Die hebben veel minder die wisselwerking of contact met Jboss. Van zodra dat ik een
piste heb bij een klant, dat zij op Jboss aan het werken zijn en interesse hebben, betrek ik Jboss
daar onmiddelijk bij.Voor mij de mensen van Jboss zijn eigenlijk mijn collega’s. Die weten dan
onmiddelijk eigenlijk met welke klanten ik bezig ben. Capgemini zit meestal al heel ver in het
XLVI
project en dan pas zegt we hebben nu support nodig, omdat dat eigenlijk niet hun corebusiness is.
Bij ons is dat ook wel bijkomend die subscripties.
XLVII
Bijlage 5: Uitgetypt interview Realdolmen Sarah: Misschien kunnen we eerst beginnen met een beetje meer informatie over het
bedrijf. Bijvoorbeeld hoe groot zijn jullie ongeveer, wat doen jullie allemaal?
Mr De Pelecijn: Ja oké dat is goed. Om te schetsen wat ik doe... Ik zal misschien kort onze
organisatie eens schetsen, dan weet je misschien beter waar ik juist werk, wat mijn rol is. Ik zal
het commerciële luik van onze organisatie uitleggen. Dus we hebben VP Sales & Markting en
daaronder heb je een salesstructuur en sales managers en account managers. Dat zijn hier teams
die opgedeeld zijn per sector. Dus je hebt “verticals” waar dat bijvoorbeeld “healthcare” in is,
industrie, enz ... en die account managers hebben elk dedicated klanten. Die hebben een lijst met
klanten waarop ze hun cijfer moeten behalen. Daarnaast heb je een business development
omgeving, ook terug met een aantal units, waarin dat ééntje infrastructuur is en één solutions,
dan heb je nog een aantal andere zoals PSA, ... Wel ik zit dus hier (infrastructuur en solutions).
Wij doen dus business development met drie collega’s. Ik doe alles wat data center is, dan is er
eentje dat Front End doet en nog eentje Managed Services. In die teams naast business
development zitten er ook nog een aantal solution sales, je hebt bv een BDMer, dat ben ik en dan
een aantal solution sales die dan horizontaal, afhankelijk van hoe je het tekent. Die gaan dan de
andere richting gaan werken. Dus een account manager heeft zijn vaste lijst, Dat zijn ‘zijn’
klanten en een solution sales, die gaat werken waar er klanten zijn. Ik doe dus business
development voor alles wat datacenter is. Datacenter, infrastructuur en services dat is alles wat in
de back office van een klant zit. Mijn collega die front end doet, doet alles wat met desktop te
maken heeft en met printing, dus alles wat de eindgebruiker onder zijn vingers krijgt. Bekijk je
het van desktop of vanuit back end?
Sarah: Wel, ik kijk nu wel voornamelijk naar back end, maar een vergelijking tussen de
twee is ook wel interessant.
Mr De Pelecijn: Wel ja je hebt de twee, als je de keten bekijkt, je hebt een eindgebruiker zoals ik,
in mijn firma ben ik een gebruiker, ik heb een pc, ik heb mijn applicaties in een netwerk in een
datacenter. In dat datacenter heb je servers en applicaties draaien. Heel die ketting heeft een
organisatie, die is even belangrijk maar in organisaties zoals de onze worden die apart benaderd,
waarom? Je hebt andere kennis nodig om een pc te verkopen dan om bijvoorbeeld een
datacenter. JBoss is dan echt de middelware om de applicaties te ontwikkelen die zich op een
XLVIII
ander niveau bevinden dan dit. Je hebt hier open source, desktop Linux en hier heb je ook
toepassingen die op Linux draaien. En Apache bijvoorbeeld, een webserver, die op Linux draait,
die draait hier, en hier kan je dan bijvoorbeeld open office gebruiken als eindgebruiker. Ik weet
niet waar je daar juist je focus legt? Weet je bijvoorbeeld hoe dat in zijn werk zit?
Sarah: Ik ben eigenlijk meer aan het kijken naar de economische kant van de zaak.
Mr De Pelecijn: Ja wel eigenlijk de reden waarom ik dat zeg is omdat ik aan het zoeken ben naar
wat je juist zoekt. Als we kijken naar de markt... Er is zo’n golf geweest, in België was die niet
zo sterk als in Nederland waarin dat bijvoorbeeld overheidsdiensten massaal kozen voor naar
open office te gaan, weg van Microsoft. In België zijn er een aantal die daar mee bezig zijn, maar
er is ook een grote die aan het terugkeren is.
Sarah: Hoe zit dat dan juist voor de klant? Open source, is dat goedkoper voor de klant?
Mr De Pelecijn: Ja, dat is eigenlijk een duaal verhaal. Belangrijk voor u is, als je Red Hat neemt
of JBoss, dat was vroeger apart maar dat is nu van Red Hat, heb je 2 versies, je hebt de .com en
de .org. Dat is heel belangrijk, bij Red Hat heb je bijvoorbeeld Fedora, dat is van Red Hat en dat
is de client die je gratis gebruikt, de echt open source, en dan heb je RHEL dat is de server
versie. Nu die bedrijven die in open source bezig zijn die supporteren heel die community van
ontwikkeling, maar wat ze eigenlijk gaan doen naar de business toe is een heel stabiele versie
maken en daar heel lang aan vast houden. Bij .org en .com bij JBoss zie je dat heel duidelijk.
Voor de klant is het goedkoop als hij de .org neemt, want dat is de versie die gratis is, goedkoper
dan bijvoorbeeld een andere middelware, maar geen support. Support is dan de goodwill van de
community en daar gaat de discussie over. Aan .org daar verdient JBoss niets aan. Wat doen ze
wel? Ze blijven dat supporteren, dat wordt ontwikkeld, maar daar halen ze hun centen niet uit.
Waar Red Hat zijn centen wel uit haalt dat zijn subscriptions voor support. De grootste
concurrent van JBoss is eigenlijk .org, dus dat is een beetje de logica en de moeilijkheid om dat
te gaan verkopen. Er zijn er namelijk heel veel die dat implementeren en de gratis versies
gebruiken, maar als dat business kritisch wordt, als uw business daar moet op draaien en op
betrouwen en je wilt support om een bug op te lossen, dan moet je eigenlijk naar die .com versie.
Sarah: Maar in vergelijking met andere middelware zoals WebSphere is JBoss
waarschijnlijk wel goedkoper?
XLIX
Mr De Pelecijn: Ja JBoss is goedkoper dan WebSphere. Dat klopt. Daar kan je nog op prijs
spelen, maar daar zit je eigenlijk met twee commerciële producten waar het ene goedkoper is dan
het andere. Is dat omdat het open source is, dat is een andere wending. Maar dat is inderdaad wel
een manier waarop dat WebSphere klanten vandaag aangevallen worden, omdat je daar een
business case hebt waarbij het goedkoper is.
Sarah: Als je dan als reseller bijvoorbeeld WebSphere verkoopt en je kijk naar JBoss, als
je marges als reseller dezelfde zijn, dan krijg je toch minder inkomsten?
Mr De Pelecijn: Ja dat klopt.
Sarah: Ja waarom kies je dan om reseller te worden van een open source product, dat is
dan eigenlijk wat ik wil weten.
Mr De Pelecijn: Ja, enerzijds hebben we dus JBoss, dat zit bij onze applicatie mensen, die de
applicaties ontwikkelen en Red Hat dus eigenlijk infrastructuur, zoals je Windows 2008 hebt, dat
is een operating systeem. Vanuit applicatie kant wordt er eerder gekeken naar de taal waarin
moet ontwikkeld worden bij de klant, als dat Java is gaat die productstack gekozen worden
afhankelijk van de klant. Wij doen zowel WebSphere als JBoss en wel nog een aantal andere,
maar er wordt eerder gekeken naar “wat heeft de klant, waar moet de klant naartoe” en op basis
daarvan wordt het product gekozen. Onze profit zit eigenlijk niet in de verkoop van die JBoss
subscripties, maar eigenlijk in de mensen die wij kunnen verhuren om die applicatie te schrijven.
Licenties zijn eigenlijk een enabler om onze mensen bezig te houden. In het bedrijfsleven wordt
er heel snel naar gekeken of het zin heeft om er al dan niet tijd in te steken. Open source voor
ideologie heeft geen plaats in een bedrijf.
Sarah: Dat zijn dan de gecertificeerde mensen die bij JBoss training hebben gevolgd?
Mr De Pelecijn: Ja da klopt ja, wij zijn partner voor zowel JBoss als voor Red Hat want dat zijn
twee aparte certificaten. Wij zijn premier partner, dat is het hoogste niveau. Dat wil zeggen dat je
zowel sales als techische mensen cursussen moet laten volgen en examens laten afleggen. Maar
dat is vrij klassiek met de andere vendors.
Sarah: Is dat dan een strategische keuze geweest om JBoss te verkopen, dus dat je dan op
die manier meer diensten kan aanbieden voor uw klanten?
L
Mr De Pelecijn: Ja, dus vanuit applicatiekant is het eigenlijk belangrijk, daar zit een heel team
van ontwikkelaars, die mensen moeten aan het werk zijn, heel simpel. Als die geen werk hebben
kosten die ons geld. Als een licentie niet verkoopt, kost ons dat geen geld, dat is wel een gemiste
deal, maar als uw mensen op de bank zitten, dan blijf je lonen betalen. Die moeten dus bezig zijn
met projecten. Bij ons heb je 2 grote teams, je hebt het Microsoft en het Java team, naar gelang
de ontwikkeling. Klanten kunnen in de Microsoft wereld of de Java wereld zitten, dus
afhankelijk daarvan... En daar is JBoss één van de strategische producten in heel die stack van
dingen die ze nodig hebben.
Sarah: Dus dan kan je wel zeggen dat je op deze manier JBoss en Red Hat niet met elkaar
kan vergelijken? Linux Red Hat is een operating system, daar heb je dan toch eigenlijk
geen inkomsten mee zoals bij het ontwikkelen van applicaties?
Mr De Pelecijn: Dan moet je echt zien... in onze wereld, wat wij doen is van “een klant heeft
infrastructuur nodig, heeft servers nodig, heeft storage nodig, heeft back up nodig”, dus alles om
die applicaties die ons collega’s maken te laten draaien. Dat moet in elkaar geknutseld worden,
dat moet goed werken dus die integratie, maar het is echt een andere insteek dan de applicaties.
Bij ons is services ook heel belangrijk, want daar kan je meer marge op draaien dan op
producten. Wij hebben ook soms discussies met software vendors, want één keer dat software
vendors een software versie hebben ontwikkeld hebben ze eigenlijk relatief weinig kosten
nadien. Elke licentie die zij daarna verkopen is voor hen winst, ja ook om kosten te dekken. Wij
echter verkopen software net zoals wij hardware verkopen. Wij hebben een aankoopprijs, uplift
en verkoopsprijs, dus ja voor die uplift, of het nu gaat om hardware of software, heel veel
verschil zit daar niet tussen. Omdat als je in competitie zit, iedereen vertrekt van dezelfde
aankoopprijs, je moet je dus differentiëren met welke uplift je neemt.
Sarah: Hoe kunnen jullie die uplift dan beter of winstgevender maken?
Mr De Pelecijn: Meestal heb je daar wel programma’s voor bij de constructeur, bij de software
vendors. Je moet een deal bekijken van “een klant heeft iets nodig” ofwel gaat hij shoppen (bij
verschillende resellers offertes aanvragen) en zegt hij “ik schrijf die, die en die aan” geef mij een
prijs. Dat is meestal het scenario waar je bij pc’s zit. Heel simpel een product waarin heel weinig
toegevoegde waarde zit, ja veel mogelijkheden heb je niet. Dus daa r werk je met uw marge. Als
LI
je in een groter project komt kan je u expertise laten gelden, dus kan je de klant helpen om de
oplossing te bepalen. Daarvoor zijn programma’s waar je kunt zeggen van kijk “wij hebben een
klant warm gemaakt voor Red Hat” dat je dat kunt registreren en je dan ook een stuk beschermd
bent tegenover uw competitie. Je hebt dan de presales gedaan en dan kan er iemand anders
komen en die biedt een lagere prijs, dan ben je uw deal kwijt. Dat is de uitdaging in onze sector.
Sarah: Dus de klant enthousiast maken voor een product en dan ook de deal kunnen
binnen halen?
Mr De Pelecijn: Ja dus stel je hebt een klant, los van welk product je koopt, maar je begint in een
initiële fase, je gaat samen een project ontwikkelen, door meetings, door technische demo’s enz.
Je bent dus 6 maand bezig, na die periode is dat rond en weet de klant wat hij wil kopen. Als hij
op dat moment competitie erbij haalt om de prijs te drukken, dan is het voor die competitie vrij
gemakkelijk. Want de klant zegt dan wat hij nodig heeft, wat moet die doen? Een offerte maken,
prijs geven en jij hebt heel dat traject gedaan en geïnvesteerd om die klant zover te krijgen. Dan
gebeurt het dat je als reseller al het werk hebt gedaan dat op het laatste de concurrentie er mee
weg loopt.
Sarah: Kan je dan in die zes maanden de diensten die je levert laten vergoeden?
Mr De Pelecijn: In infrastructuur projecten heel zelden, dat traject is een presales traject en dat
wordt heel zelden betaald. Bij applications gaat het anders omdat als een applicatie moet worden
geschreven, er een analyse moet worden gedaan en dat is meestal wel een betalende stap. Daar is
dat dan ook minder erg als iemand met uw deal gaat lopen, want het werk dat je hebt geleverd is
betaald. Bij ons (infrastructuur) is dat niet frequent dat er wordt betaald voor dat presales
gebeuren. Soms wel, dan gebeuren er studies, maar dat zijn dan niet door commerciële mensen,
maar technische mensen, systemengineers die dat dan effectief gaan uitwerken en dan krijgt de
klant een “deliverable”. Dat is effectief een document waar in staat van kijk “uw omgeving ziet
er zo uit, dat zijn de stappen die je kunt doen om naar die situatie te gaan”. Maar dan is er al op
voorhand met de klant bepaald van “dat is het doel, wij gaan daar zoveel dagen aan spenderen”
en dat is de prijs.
Sarah: Zijn dat dan de twee grote business units die je kunt onderscheiden? Infrastructuur
en ontwikkeling?
LII
Mr De Pelecijn: Goh, wij doen eigenlijk vanalles. Dus we doen ERP,… er zit vanalles in de
portefeuille. Ik denk dat we de meeste dingen wel doen. We zijn met 1600 mensen, dus we zijn
redelijk groot. We hebben een infrastructuur/solutions luik met de drie domeinen, managed
services, data centers solutions en front end. Dus wat wij verkopen kun je dan ook in managed
services doen, wij nemen een deel van de services voor de klant over. Dat gaat dan over
onderhoud, gezond houden van de infrastructuur tot het hoogste van de applicatie of het hele IT-
verhaal bij ons nemen van een klant. Een klant die zegt van “oké, het is niet mijn core business,
maar ik wil dat dat hier draait met een SLA. Zij betalen dan een fee per maand aan ons. Dus
eigenlijk heel die scope zit daar in. Dan hebben we enterprise communication, alles wat te maken
heeft met unified communication, voice, video, instant messaging, mail, presence dat is eigenlijk
waarbij je alles gaat integreren. Security, dat is alles wat met anti-virus, firewalling en dergelijke
te maken heeft. Netwerk, dus effectief de switches, de wireless, dat soort dingen, dat zit in
Enterprise Communications. Er zit hier ook telefonie tussen. We hebben NEC Philips
overgekocht, een paar jaar geleden dus dat zijn eigenlijk telefooncentrales. Dan heb je
professional services, PSA en die hier, dat is waar JBoss gaat tussenzitten. Er is een Microsoft
poot, daarnaast is er nog JAVA dan heb je nog twee aparte blokjes eentje die op Oracle
mainframe assistant I. Dan heb je alles wat met business analyse en project management te
maken heeft. Er is bijvoorbeeld ook nog springsource. Springsource is gekocht door die mannen
door Vmware, dus daar gaan we nu zien wat daar gaat uitkomen. Vmware zit bij mij, ons Java
mensen gebruiken ook heel veel springsource.
Sarah : Het is precies wel afhankelijk van organisatie tot organisatie hoe alles wordt
georganiseerd.
Een paar jaar geleden hadden we echt 2 poten, applicatie en infrastructuur en dat zijn 2
verschillende richtingen. Nu wordt dat geïntegreerd en worden daar synergiën gezocht. Maar dat
zijn aparte werelden. Als je dat hier ziet JSE, JEE en al die dingen, die mannen zijn dat gewoon.
Voor ons, infrastructuur mensen, is dat evengoed Chinees als omgekeerd.
Sarah : Dus, het belangrijkste voor jullie naar open source toe is de mogelijkheid om
diensten te genereren.
LIII
Mr De Pelecijn: Ja, dat klopt... In principe kunnen ons Java-mensen wel verder werken op de
.org. Als we ons systemengineers bekijken die bij ons in de organisatie zitten, dat zijn aparte
mensen dan de mensen die windows doen. Die spelen het liefst met de niet-commerciële versie.
Een opensource man is op zich niet-commercieel. Nu als je het businesswise wil doen moet je
effectief kijken naar support. Als je een bug hebt in een bedrijfskritische applicatie verwacht je
dat die opgelost is. Je ziet bijvoorbeeld bij Red Hat, die enterprise versie loopt altijd achter op
wat er in de community gebeurt. Bij JBoss is dat hetzelfde een .org gaat meer features hebben
dan de .com. Maar je bent niet zeker dat de features in de volgende release er terug gaan inzitten.
Dus als bedrijf, als je daar op ontwikkelt, moet je kiezen voor stabiliteit en dat is heel moeilijk
voor mensen die net van ’t school komen. Die mannen zijn allemaal open source minded, die
liggen niet echt wakker van de business kant van de zaken. Het is daarom dat je kunt zeggen dat
de .org de grootste concurrent is van de .com.
Sarah : Er wordt soms gezegd dat open source “vendor lock-in” vermijd. Je hebt namelijk
nog altijd de .org waar je kan op terugvallen.
Mr De Pelecijn: Moest JBoss wegvallen denk ik dat de .org ook zal verdwijnen, want het
grootste gedeelte van de mensen die daar zitten in te ontwikkelen staan effectief wel op de pay-
roll van JBoss zelf. Het linux verhaal bijvoorbeeld geeft je wel flexibiliteit, het is gemakkelijker
te porteren naar een andere flavour. Als je JBoss draaien hebt op Red Hat operatingsysteem kun
je die morgen op Suse zetten, dat is makkelijker om te porteren dan bij proprietaire software.
Maar effectief op een gegeven moment moet je toch wel kiezen en zeggen van we moeten naar
gesupporteerde versies als je in een bedrijf iets wilt doen.
Sarah : Ja dat heb ik nog al eens gehoord dat het vaak kan zijn bij propriatery producten
als je ergens iets installeert dat er dan gemakkelijk een probleem kan opduiken. Terwijl bij
open source heb je dan toch misschien minder snel problemen of kan je het gemakkelijker
oplossen.
Mr De Pelecijn: Ja, daar heb je een aantal stromingen binnen, heel het Javaverhaal is volledig
opensource en als je naar Microsoft gaat zit je daar effectief vast in die track. Als er enkel naar
de kosten van de licentie vs subscriptie wordt gekeken dan komt dat heel nauw in de buurt. Oké
JBoss is goedkoper dan WebSphere, maar bijvoorbeeld op Red Hat niveau betaal je uw
LIV
supscription, dat zal net iets goedkoper zijn dan windows, maar je betaalt ook wel, dat zijn geen
liefdadigheidsinstellingen, die moeten ook inkomsten genereren.
Sarah : hoe is jullie focus dan naar Red Hat toe ?
Mr De Pelecijn: We hebben een team die dat doet, dat technisch installeert en naar verkoop toe
hebben we daar vandaag onze solutionsales en datacenter verhaal. Die gaan zich op heel die
infrastructuur richten en het operationsysteem is daar maar een stukje van. Dus daar ligt vandaag
niet echt een focus op, je ziet dat ook aan onze cijfers. Het is niet eenvoudig, het is moeilijk om
daar iemand zijn brood mee te laten verdienen met enkel Red Hat te verkopen.
Sarah : Wat is dan de strategie van jullie bedrijf, zijn jullie solution providers ?
Mr De Pelecijn: Ja zeker. Op vlak van infrastructuur zorgen we bij de klant voor een oplossing.
Sarah : Dus als je solution provider bent, ben je ook reseller?
Mr De Pelecijn: Ja, dat is zeker zo. Dat is de meest basic vorm van partner in de IT.
Sarah : Zijn er dan eigenlijk bedrijven die puur reseller zijn ?
Mr De Pelecijn: Ja, je hebt er wel die enkel licenties verkopen.
Sarah : Dan zouden waarschijnlijk opensource bedrijven zich niet kunnen richten op deze
pure resellers ?
Mr De Pelecijn: Ja, neen, waarschijnlijk niet.
Sarah : Hoe lang verkopen jullie eigenlijk al Red Hat ?
Mr De Pelecijn: Ja, sinds we linux doen, dat zal al bijna een jaar of acht à 10 zijn.
Sarah : Hoe heb je dan juist de keuze gemaakt om ook open source en dan JBoss en Red
Hat in het bijzonder te verkopen? Maken jullie daar dan een business case rond?
Mr De Pelecijn: Ik zat zelf niet in de productkeuze, heel dat software verhaal is pas 2 jaar
geleden tot bij mij gekomen. Maar wat wij doen is: één we screenen de markt, wat de
oplossingen zijn. We gaan dan na of die oplossingen technisch valabel. Dan gaan we kijken van
LV
hoe zitten de partnerships ineen, hoeveel resellers zijn er al voor dat product, past dat in ons
gamma, dat is ook belangrijk. Dan kijk we van wie zit daar achter en hoe werk je er mee samen.
We doen vandaag Red Hat en SUSE op linux verhaal, SUSE is Novell. Vroeger waren wij een
grote Novell partner, aangezien dat wij met Novell as such, dat is een beetje doodgebloed in
België, dus heel het netware verhaal. Er was SUSE als open source en dan was er ook Novell die
ook een operatingsysteem had, concurrent aan microsoft. Netware dat was een heel mooi
product, maar is een beetje ten onder gegaan aan de marketing machine van Microsoft. Om zich
te redden hebben ze dan op het laatste SUSE gekocht en zitten ze nu in die open source wereld.
Nu, heel die organisatie is veranderd, dat zijn nu Nederlanders, wij doen in principe nog SUSE,
maar wij hebben daar zo goed als geen commercieel contact mee. Nu wordt er gemakkelijker
voor Red Hat gekozen SUSE, tenzij de klant zegt kijk wij zijn gestandaardiseerd op SUSE, oké
dan is het heel logisch dat wij de klant daar gaan supporteren. Voor onze technische mensen
maakt dat eerlijk gezegd weinig verschil uit of zij Red Hat of SUSE doen.
Sarah: En als je dan naar dat partnership van Red Hat kijkt, wat zijn daar dan zoal
belangrijke elementen?
Mr De Pelecijn: Ja zowel voor Red Hat als voor JBoss betalen wij een fee... Ik moet eerlijk
zeggen, ik heb zoveel producten in mijn scoop en Red Hat is daar eentje van, jammer genoeg
niet de grootste. Wat we wel doen is samen met Red Hat jaarlijks een business plan opstellen, dat
doen we wel. Vandaag is dat gecombineerd met het JBoss verhaal, voor Red Hat is dat hetzelfde.
We maken een gemeenschappelijk plan op, waar dat we dan wel accenten gaan leggen voor de
verschillende producten. Wat wij wel meestal binnen ons organisatie doen is, als we voor een
product gaan, gaan we meestal tot het hoogste niveau, zeker op technisch niveau gaan wij tot het
hoogste niveau opmat we daar ons kunnen onderscheiden.
Sarah: Expertise is wel belangrijk waarschijnlijk?
Mr De Pelecijn: ja, als reseller... ik denk niet dat wij dat voor producten zijn het laagste niveau.
Dus als wij instappen in een programma gaan wij zorgen dat we op het hoogste niveau geraken.
Dat zijn we voor producten zoals Vmware, voor Microsoft zijn we dat op tien niveau’s, ik denk
dat je er 12 kan halen met microsoft, op elk van die 10 zijn we het hoogste. Ook bij HP, voor
IBM is het iets minder, maar bij HP zijn we op het hoogste niveau. Dus wij proberen wel altijd
LVI
die competenties te halen, omdat je u daar één mee kan onderscheiden en twee projecten goed
afwerken. Als je niet weet hoe het product ineen zit, ja dan is het al niet echt een goed begin.
...
Om ons niveau te halen zijn wij verplicht om vier technische mensen op (technisch) Red Hat
niveau, sales heb je ook vier certified verplicht en voor JBoss zijn dat er ook vier, dan moet je
nog referenties hebben. dat heb je eigenlijk nodig voor dat partnership.
Sarah: Het eerste niveau is dan eigenlijk meer een instap niveau?
Mr De Pelecijn: Ja zo’n instap niveau, meestal moet je op de website een beetje klikken en dan
ben je partner en dan mag je het verkopen. Bij sommige vendors is dat moeilijker dan bij andere,
maar meestal hebben ze allemaal wel zo’n heel laag niveau.
Sarah: Bieden jullie ook een deel van de support aan de klant of is dat enkel voor JBoss?
Mr De Pelecijn: Als dat een applicatie is, zal er support zijn op die applicatie en daar is de motor
JBoss. Wij zullen verantwoordelijk zijn voor de totale applicatie, één keer dat wij zien dat het om
een JBoss probleem gaat zal die call geforward worden bij JBoss zelf. Daarvoor is het belangrijk
dat als we een applicatie doen, dat ons klanten naar die gesupporteerde versies gaan. Op een
gegeven moment kom je bijvoorbeeld in de knoei, is er een probleem, er is een bug, ja dan lopen
wij vast op de lagen daaronder en dan moet JBoss dat kunnen oplossen. Een klant dat met open
source zit, met de community versie, is afhankelijk van de goodwill van die mensen om dat op te
lossen, daar komt het eigenlijk op neer.
Sarah: dus dat is niet voor jullie die support?
Mr De Pelecijn: Neen, in principe als reseller ga je op een gegeven moment moeten terug vallen
op de support van uw constructeurs, ook in hardware, als er een probleem is, afhankelijk van wat
het probleem is. Dus eerste moet het probleem gedefinieerd worden, waar ligt het? Is het
software, hardware? Dikwijls is een probleem gewoon geknoei van een klant, dan kunnen wij dat
oplossen. Als dat dieper gaat, dan zit je vast en moet je naar second of third level support of moet
je naar engineering bij de constructeurs, of dat dan nu hardware of software is, en moeten zij dat
oplossen. En daar heb je met producten zoals Red Hat een garantie dat ze daar gaan achter
LVII
zoeken. Bij open source kun je op de community beroep doen en heel vaak gaat dat lukken, soms
gaat dat niet lukken.
Sarah: Ja en als je dan naar die partnerprogramma’s kijkt, wat is dan voor jullie
belangrijk? Is dat bijvoorbeeld marketing...
Mr De Pelecijn: Ja, marketing is belangrijk. Onze marketing acties worden meestal wel gefund
door de constructeurs. Wij voorzien in acties, voor JBoss voorzien wij nu bijvoorbeeld een actie
en dan passeren wij bij Red Hat en proberen wij marketing sponsoring te krijgen. Nu, in die
programma’s zit dat in, hun befaamde MDF, Marketing Development Fund, dit is wel een term
die je bij al die constructeurs terugvindt. Eigenlijk zit daar een simpel mechanisme achter, hoe
meer je verkoopt, hoe meer MDF dat je krijgt. Maar daar zijn terug alle softwarvendors net iets
anders, bij sommige krijg je gewoon uw MDF om te spenderen. Maar meestal is het principe van
gewoon je moet een actie samen met de mensen van Red Hat definiëren, dan moet je
goedkeuring krijgen en dan wordt er beslist of er sponsoring mogelijk is of niet. Dat is eigenlijk
een beetje het proces dat daarachter zit. Dus dat Fund zit eigenlijk vast bij een lokale organisatie,
dus hier is dat Belux. Er is een dame die beslist of je dat krijgt of niet, zo gaat dat.
Sarah: en de salessupport dan?
Mr De Pelecijn: Dat moet je zien in de zin van... Red Hat in België is drie man, je hebt een sales,
dan heb je een partner manager en dan heb je een presales. En vroeger was dat alleen die sales,
nu zijn er daar twee bij. De sales manager is territory sales, dat wil zeggen dat zij een lijst heeft
van klanten waarop dat zij werkt. Als wij op een klant werken die in haar lijst zit gaan wij met
haar samenwerken, gaan we kijken van hoe kunnen we die klant samen kunnen bewerken, uit de
twee kanten. Als het een andere klant is komt dat bij die partner manager die dat commercieel
gaat ondersteunen. Dus ofwel doen wij het werk, als we dat alleen kunnen doen we dat alleen.
Maar soms is het makkelijker om samen te werken, om Red Hat mee te krijgen naar een klant.
Dat is zo bij alle constructeurs. Ja, als je niet samen werkt... één plus één is drie (soms is dat min
twee...)
Sarah: dus op zich is er niet echt verschil tussen de open source constructeurs en de
traditionele proprietary vendor?
LVIII
Mr De Pelecijn: Neen, dat is dezelfde manier waarop met Microsoft wordt samengewerkt, het
verschil is gewoon dat Microsoft veel groter is. Dus veel meer mensen op de straat, ook veel
meer resellers die dat doen, daar zit het verschil.
Sarah: Kunnen die dan druk op jullie uitoefenen, omdat zij zoveel groter zijn?
Mr De Pelecijn: Dat is zoals een huwelijk... Je hangt van elkaar af, zeker als grote reseller, niet
als reseller met drie mensen. Met de grootte die wij hebben, hebben wij bij onze constructeurs
toch wel een stem. Dat is wel een luxe positie, wij hebben wel een stem, maar ja, je werkt samen,
ik bedoel... Dat is een economisch principe, hoe meer omzet je draait bij een vendor, hoe meer je
te zeggen hebt. Als zij u verliezen, dan hebben ze een probleem, maar als je veel omzet draait bij
een vendor, dan wil je die ook niet verliezen want dan heb je ook een probleem. Op een gegeven
moment zit je in een situatie waarvan je zegt “we hebben elkaar nodig” ook al word je eens
belazerd door de ene. We zijn dan wel een keer boos op elkaar maar je moet wel nog
samenwerken.
Sarah: Het is niet dat dat bij Red Hat gemoedelijker is ofzo?
Mr De Pelecijn: Ja hoe kleiner, hoe simpeler eigenlijk. Red Hat is een kleine organisatie. Als je
de omzet bekijkt van Microsoft t.o.v. Red Hat is dat peanuts in ons geval.
Sarah: Kun je misschien een aantal cijfers geven die het verschil weergeven tussen
Microsoft en Red Hat qua marges en omzet?
Mr De Pelecijn: Van Red Hat weet ik het wel, maar van Microsoft zou ik dat niet meteen kunnen
zeggen, dat zit bij iemand anders.
Sarah: Het is misschien ook interessant om te weten hoe het zit met open source en de
Belgische markt, omdat de meeste open source bedrijven toch uit Amerika komen?
Mr De Pelecijn: Ja, het is zelfs zo dat Belgische bedrijven die software ontwikkelen naar eerst
naar Amerika. Dus je hebt zo echt wel van die kleine start-up bedrijfjes die iets ontwikkelen met
de bedoeling om ooit opgekocht te worden, om te integreren in een groter bedrijf. Meestal gaan
die heel snel een bedrijf openen in The States, ook al is dat maar een bureau, omdat dat de enige
manier is. Dc protect, die waren afkomstig uit het Gentse en werden dan opgekocht door
LIX
Cymentic. Die waren ook op de lokale markt begonnen met wat referenties en dan in The States
geopend om dan te worden overgenomen. België is daar te klein voor.
Sarah: Maar de Belgische markt begint dan toch meer en meer open te staan voor open
source?
Mr De Pelecijn: Ja... Heel de Java stack is heel sterk aanwezig en dat gaat alleen maar groeien.
Vandaag op de Universiteiten zijn die meer met open source bezig dan dat ze met Microsoft
bezig zijn, gewoon omdat dat logischer is. Dus dat is een gevolg. Die mensen komen in het
bedrijfsleven, die gaan daar ook naar kijken. Langs de andere kant mag je Microsoft ook niet
onderschatten in heel die machine, dus dat zal wel een mix blijven van... Wat we duidelijk is als
je kijkt naar het Linux verhaal, Microsoft heeft daar geen last van. Het enige wat we zien is dat
Unix, dus de Unix flavours van de instructeurs, Solaris, AX, HPX van HP dat die markt
omschakelt naar Linux. Maar de windows servers, die gaan niet naar Linux. Vroeger was dat het
idee en daar werd veel energie in gestoken om die Windows server markt om te zetten naar
Linux server markt, maar dat is helemaal niet gelukt. Wat je wel ziet is van die mastodonten die
vandaag draaien op proprietary systemen, want die Unix flavors draaien ook op Unix machines,
die duur zijn, duur in onderhoud, dus dat zijn heel robuuste omgevingen, maar heel prijzig.
Vandaag is er wel een mechanisme dat die naar de minder dure servers gaan, de Intel servers met
Linux daar op en daar dan dezelfde stack opbouwen. Je moet Linux positioneren t.o.v. de Unix
servers. Voor Linux is de markt de Unix markt. De stap van iemand die Unix kent naar Linux is
eigenlijk vrij klein, dat is dezelfde manier van werken. Van Windows naar Linux voor een
technische mens is niet zo evident.
Sarah: Ja dus de TCO is waarschijnlijk wel lager als je naar open source gaat, maar daar
is voor de klant toch ook nog altijd een migratiekost aan verbonden?
Mr De Pelecijn: Dus je moet bijvoorbeeld zien, als je een klant hebt die WebSphere heeft en je
wilt die naar JBoss krijgen, dat is goedkoop, maar daar zit wel een stuk werk tussen om dat te
doen. Maar na die omzetting profiteer je wel van de lagere subscriptiekost.
Sarah: En hoe zit dat dan met bijvoorbeeld de ERP, CRM systemen?
LX
Mr De Pelecijn: Ja je hebt daar varianten, bijvoorbeeld voor een sharepoint heb je Alfresco, dat
is iets dat wij doen, we hebben mensen die in Alfresco bezig zijn.
Sarah: Dat is waarschijnlijk moeilijk Alfresco verkocht krijgen aan een Microsoft klanten?
Mr De Pelecijn: Ja dat zijn projecten, dat zit in die application sfeer, dat wordt als project
verkocht. Dat zie je wel dat bij klanten dingen binnenkomen, bijvoorbeeld bij Windows klanten
komt er een Linux server binnen, bijvoorbeeld voor een firewall, puur omdat die veel beter is en
omdat het concept anders ligt t.o.v. Microsoft. Naar security kan dat zin hebben. En zo zie je in
bedrijven wel puntoplossingen komen die op Linux gebaseerd zijn, omdat dat daar het beste op
draait. Dat is dan eerder een soort van black box. Je ziet wel in een Windows omgevingen hier en
daar een Linux server binnen sluipen.
Sarah: Maar je moet dan toch alles met elkaar kunnen laten werken?
Mr De Pelecijn: Die dingen zijn voldoende matuur, dat werkt allemaal goed met elkaar. Die
technische mensen krijgen dat wel allemaal met elkaar aan de praat.
LXI
Bijlage 6: Uitgetypt interview Capgemini Sarah: Misschien kunnen we eerst beginnen met een beetje meer informatie over het
bedrijf. Bijvoorbeeld hoe groot zijn jullie ongeveer, wat doen jullie allemaal?
Mr. Eggenstein: Capgemini is een internationaal consulting bedrijf, actief in iets meer dan 30
landen over heel de wereld. Het werknemersbestand telt iets van een 90 000 mensen, waarvan
iets meer dan één vierde in India vertoeft, dus ik denk een 20 à 25 000 mensen in India. Het is
een Europees bedrijf met hoofdzetel in Parijs. Dus het tweede grootste aantal werknemers
bevindt zich in Frankrijk dat zijn er een 20 000 tal en dan binnen Europa is het vooral Engeland
en Nederland die een grote rol spelen. De rest zit vooral in de Verenigde Staten, Noord Amerika
voornamelijk en dan heb je natuurlijk nog in een aantal landen zoals Nieuw Zeeland, Australië
en Zuid Amerika, maar dat is vrij beperkt. In België is het allemaal iets kleiner, België is ook een
kleiner land, daar zijn we momenteel met een 700 tal werknemers hier in Diegem als enige zetel.
Eigenlijk de structuur van dit bedrijf is net zoals Capgemini wereldwijd georganiseerd is. Elk
Capgemini land is op dezelfde manier gestructureerd, dus dat betekent dat er een CEO is en
daaronder heb je dan een aantal, wat wij noemen, disciplines. Algemeen zijn er vier eigenlijk, je
hebt de consulting discipline, dat is hier in België een 150 tal mensen, je hebt outsourcing dat is
een vergelijkbaar aantal, laat ons zeggen tussen de 100 à 150. Consulting kan IT-consulting zijn,
maar kan ook management-consulting zijn of fiscale-consulting, milieu-consulting, dus dat hoeft
niet IT gerelateerd te zijn. Outsourcing is het volledige overnemen van applicatie en
infrastructuur. Dan heb je nog twee disciplines, dat is Technology services en Financial services
en tot twee jaar geleden was dat één unit, Technology services, daar hebben ze een afsplitsing
gemaakt om specifiek op de financiële en verzekeringsmarkt te richten. Dus financial services is
eigenlijk hetzelfde dan Technology services, maar dan specifiek voor die markt. De mensen die
er werken en de kennis is eigenlijk hetzelfde als bij Technology services. Technology services is
eigenlijk professionele dienstverlening rond IT. Dat is voornamelijk op de applicatie markt
gericht, dus niet zozeer infrastructuur. Dus in België zijn we eigenlijk niet gericht op
infrastructuur, een beetje bij outsourcing, maar dat is beperkt. Dus voornamelijk applicatie
dienstverlening, dat gaat van mensen die bij de klant ter plaatse een bepaalde rol of kennis
aanbrengen tot volledig staffen en uitvoeren van IT projecten. Daar komt het eigenlijk op neer.
Technology services is een 450 tal mensen en Financial Services en 150 tal mensen. Ikzelf werk
LXII
voor Technology Services. Binnen Technology Services heb je een aantal, wat wij noemen,
service lijnen of domeinen of een aantal groeperingen van mensen die met een specifieke
technologie bezig zijn. Binnen TS is er enerzijds alles wat te maken heeft met legacy, dat is alles
wat niet JAVA of .NET ontwikkeling of Microsoft ontwikkeling is, dat beschouwen wij een
beetje als legacy. Dat gaat over mainframes, C, C++, een beetje van alle technologieën die de
laatste twintig jaar gebruikt geweest zijn. Dat is één groep, dat is toch nog een 80 tal mensen
groot. Dan heb je een groep die zich bezighoudt met wat wij noemen Business Intelligence, een
kleine groep, tien à vijftien mensen. Nog een groep die zich bezighoudt met Enterprise Content
Management, dat is ook vergelijkbaar qua aantal. Dan heb je een grote groep die zich bezig
houdt met het implementeren van ERP systemen, met name SAP is de grootste groep, dat is toch
een honderd tal mensen groot. Een groep die zich bezighoudt met GIS, Graphical Information
Systems, een tien tot vijftien mensen groot. Als laatste zijn er nog twee service lines eentje van
Microsoft technologiën en eentje rond JAVA en open source en die laatste daar ben ik dan mee
bezig. Java en Microsoft zijn vergelijkbaar qua aantal, een veertig à vijftigtal mensen groot. Ik
ben dus met Java en open source bezig en mijn rol is specifiek langs de delivery kant. Dat
betekent, dat ik een unit heb van mensen die de projecten effectief uitvoeren bij de klanten of
hier. De bedoeling is van die mensen aan te sturen, niet in het kader van een project maar wel de
competenties ontwikkelen, people-management te doen, maar ook nieuwe projecten zoeken,
klanten gaan zien om projecten te ontdekken en te verkopen. Dus dat is het eigenlijk in een
nutshell.
Sarah: En dan meer specifiek, om welke open source software gaat het hier dan?
Mr Eggenstein: Wel binnen open source heb je eigenlijk twee grote markten. Ten eerste is er
alles wat in de zin is van automatisering, rond bureautica, het grootste voorbeeld is dan Open-
Office als tegenhanger van Microsoft Office. Daarnaast zijn er een hele hoop zaken die vooral in
de systeem wereld worden toegepast dus in system engineering zoals scripting talen, een hele
hoop zaken die vooral niet echt zichtbaar zijn voor de eindgebruiker zoals server systemen,
operatingsystemen, Linux, dus al die zaken die meer naar de infrastructuur en technische kant of
bureautica of operatingsystemen, dat is één zaak. Dat is net die zaak waar we niet mee bezig zijn.
Waar wij binnen onze unit mee bezig zijn is open source software in het kader van applicatie,
dus het bouwen van nieuwe toepassingen, met behulp van open source software. Waarover gaat
LXIII
dat dan? Dat gaat over voornamelijk in de Java wereld of uitsluitend in de Java wereld, want je
hebt ook andere ontwikkelingstalen bijvoorbeeld php, perl, enz… Waar je ook webtoepassingen
mee kan gaan bouwen, maar die markt is niet echt de markt waarin wij actief zijn. Dus wij zijn
vooral met Java ontwikkeling bezig en daar met een aantal open source frameworks en applicatie
servers dus bijvoorbeeld Tomcat, JBoss van Red Hat die twee, en ook Apache maar dat is ook
van Tomcat, je hebt dan ook zaken van Sun zoals Glassfish, je hebt daar een aantal open source
application servers, de ene al wat beter dan de andere en van heel die groep richten we ons
voornamelijk op Red Hat JBoss, waarom? Omdat daar eigenlijk een groot bedrijf, Red Hat,
achter staat en dan komen we straks misschien tot het business model en hoe wij daar mee
omgaan. Maar dus voornamelijk die JBoss-stack en dan ook een aantal open source
ontwikkelingsframeworks zoals het springframework, zoals het Struts framework,… Dat is
specifiek naar java ontwikkeling, wat hebben we dan nog… ISF, Seam, dat is dan specifiek weer
naar JBoss gerelateerd. Dus er zijn een aantal Java frameworks, dat zijn building-blocks
waarmee men snel applicaties kan maken die dus vrij beschikbaar zijn, downloadbaar zijn op het
internet. Wij zetten die in om enterprise applicaties te gaan bouwen bovenop dan die open source
application servers. Is dat duidelijk? Als ik te snel ga moet je het zeggen…
Sarah: Neen dat is oké, wel ik ben reeds naar twee andere resellers geweest, namelijk
Xplore Group en Realdolmen en zij zijn ook voornamelijk met JBoss bezig (met betrekking
tot open source applicatieservers). Dat komt dan toch blijkbaar terug als een goed
product?
Mr Eggenstein: Ja wel ik heb ook tien jaar bij Realdolmen gewerkt en ook met JBoss bezig
geweest. Ik heb dus tien jaar hetzelfde gedaan maar dan bij Realdolmen.
Sarah: Zijn jullie dan ook reseller van WebSphere?
Mr Eggenstein: Ja dat is IBM. Ja want in die markt van application servers waren er tien jaar à
vijftien jaar geleden tien vijftien spelers op. Ik denk dat er elk jaar één weggevallen is, vandaag
de dag heb je nog twee grote commerciële spelers dat is IBM met Webspere en Oracle. Oracle
heeft zijn eigen application server, maar die zal nu uitgefaseerd worden omdat zij twee à drie jaar
geleden BEA systems hebben overgenomen en die hadden WebLogic op de markt. BEA met
WebLogic hadden een groot marktaandeel, ook een Amerikaans bedrijf, maar Oracle heeft die
LXIV
twee drie jaar geleden opgekocht. Dus nu heb je eigenlijk (als je zegt ik doe geen open source)
maar twee echte mogelijkheden voor applicatie servers en dat zijn IBM of Oracle. Je hebt
natuurlijk nog altijd een paar kleinere spelers, maar voor grote bedrijven… En IBM is eigenlijk
de marktleider, als je kijkt naar wie er WebSphere heeft, wel bijvoorbeeld Elektrabel, Toyota,
ING bank die hebben allemaal WebSphere, alle grote bedrijven… Dat is ook omdat IBM, die
mainframes verkocht en die bij die grote bedrijven stonden. Dan is dat van mainframe naar
webontwikkeling gegaan. WebSphere kan trouwens ook op een mainframe draaien, die kan zelfs
op de oude infrastructuur, nieuwe applicaties laten draaien.
Sarah: Hoe komt het dan waarom jullie voor JBoss hebben gekozen?
Mr Eggenstein: Die keuze is eigenlijk vrij eenvoudig. Het business model achter open source is
eigenlijk… in feite is er niet echt een business model. De mensen die open source op de markt
brengen, hebben niet als primair doel om daar geld uit te slaan. Wat is altijd het probleem
geweest en vandaag de dag nog altijd met open source? Om daar echt een doorbraak voor te
hebben in de markt. Het probleem dat (grote) bedrijven hebben is dat daar geen officiële support
voor beschikbaar is. Dus als je open source gebruikt ben je in principe aangewezen op de mensen
die het geschreven hebben of de mensen die in de community zitten als er problemen zijn. Nu
voor een groot bedrijf, voor bedrijfskritische toepassingen kun je niet zomaar al uw risico’s in de
handen van een groep mensen leggen die je niet kent. Dus het grote probleem is dat daar geen
echte commerciële support contracten achter zitten. Nu JBoss was eigenlijk het eerste bedrijf dat
op basis van open source (applicatieserver) software toch die commerciële support heeft
aangeboden. Ik spreek al van ongeveer tien jaar terug ondertussen. Toen was dat nog JBoss
apart, want ze zijn ook een vijftal jaar geleden overgenomen door Red Hat. Toen zijn zij daar
mee begonnen, zij hebben gezegd van “kijk, wij bieden u op basis van software die vrij
beschikbaar is op het internet toch een vorm van support. Je moet daar voor betalen, maar als er
dan problemen zijn kun je naar ons bellen. Dit is ons telefoonnummer, je betaalt zoveel, wij
helpen u zo snel,…” Eigenlijk is dat tot op heden volgens mij, buiten het Springframework, daar
is een bedrijf achter en dat is Springsource en die hebben nu ook een eigen application server op
de markt gebracht. Zij bieden daar een gelijkaardig model support contracten aan, maar dat is
nog maar recent en dat is volgens mij naast Red Hat de enige die dat doen op basis van open
source software, toch commerciële support. Dus de keuze als je een goede competitor wilt voor
LXV
Oracle en IBM en je wilt die support kunnen aanbieden, ja dan was er eigenlijk maar één
alternatief, dat was JBoss. Dat is dan puur vanuit het standpunt van de klant. Technisch gezien is
JBoss minstens zo goed als een WebSphere of WebLogic application server en eigenlijk qua
snelheid van ontwikkeling en de footprint dat zoiets heeft op uw infrastructuur is veel lichter dan
een WebSphere of een WebLogic. Dus je hebt er ook nog de TCO, zoals ze zeggen, in zo’n
omgeving is sowieso lager dan voor Weblogic of WebSphere omdat dat zeer grote zaken zijn.
Dat is vergelijkbaar met Office: de meeste mensen gebruiken maar tien procent van wat Office
eigenlijk kan. Met iets simpel zoals notepad kan je ook brieven schrijven. Het is eigenlijk die
vergelijking die je moet maken. De meeste mensen hebben maar notepad nodig, dus het heeft
geen zin om daar veel geld aan uit te geven of grote dingen te kopen. Dus JBoss, ook voor de
mensen die met Java ontwikkeling bezig zijn, kiezen meestal voor lightweight zaken, die
simpeler en eenvoudiger zijn en dezelfde kwaliteit, snelheid, robustheid, beveiliging bieden als
grotere systemen. Het was dus tweeledig, je had langs de commerciële kant of de bedrijven die
het moesten gebruiken vanwege het feit dat er support is en dan zijn er mensen die er moeten
ontwikkelen van “het is wel leuk, het werkt wel goed, het is snel, het is kwalitatief”.
Sarah: Heb je er dan eigenlijk voor gekozen omdat klanten het graag wilden hebben of heb
je ervoor gekozen vanwege een strategische overweging om bijvoorbeeld niet alleen IBM en
Oracle aan te bieden maar ook nog iets anders?
Mr Eggenstein: Wat je ziet bij alle klanten, bijna allemaal waar er vandaag Java ontwikkeling
wordt gedaan, zelfs die WebSphere of WebLogic hebben, in development activiteiten wordt
bijna altijd JBoss gebruikt. Waarom? Omdat iemand die met Java ontwikkeling bezig is komt
onmiddellijk in aanraking met open source. Als je dan naar een application server gaat, dan kom
je bijna onmiddellijk bij JBoss terecht. Dus wat je ziet in IT departementen bij grote bedrijven,
dus ook bijvoorbeeld bij Elektrabel en Toyota, wat doen die mensen die Java ontwikkelen? Die
ontwikkelen dat op JBoss. Dat is gratis, dat werkt goed, dat is lightweigt. Het moment dat ze dan
effectief zaken in productie gaan zetten, dan gaat dat naar WebLogic of WebSphere. De dag dat
wij die klanten kunnen overtuigen dat de kwaliteit van JBoss hetzelfde is, dat zij goede support
kunnen krijgen, kan het zijn dat die mensen zeggen, oké wij stoppen met WebLogic en
WebSphere en we doen verder met JBoss. We sluiten een contract af. Bijvoorbeeld hebben we
bij ***, die hadden Oracle application server, zij gebruikten daar JBoss in ontwikkeling en op
LXVI
een dag hebben zij de licenties van Oracle stopgezet en gebruiken ze nu JBoss in hun
productiesysteem. Er zijn dus een heel aantal grote klanten die naar JBoss migreren en zeker de
laatste twee jaar is die markt echt wel toegankelijk geworden voor open source. Dat komt deels
doordat de TCO, van die zaken veel lager ligt dan van commerciële systemen en dat in het kader
van besparingen proberen ze licenties weg te knippen. Daar is JBoss dan de perfecte kandidaat
voor om IBM of Oracle te gaan vervangen.
Sarah: Maar het is waarschijnlijk toch niet zo eenvoudig om zomaar van de ene
applicatieserver naar de andere over te gaan? Daar zal toch ook wel een kost aan
verbonden zijn?
Mr Eggenstein: Ja dat is juist. Het is natuurlijk niet zo eenvoudig om van het ene naar het andere
over te gaan. Wat is het probleem? Wat doen commerciële application servers of vendors van die
software? In principe zoals je misschien weet, zijn er Java standaarden, ISS noemen ze dat. Dat
zijn eigenlijk Java specifications die eigenlijk democratisch tot stand zijn gekomen binnen de
Java community daar zijn natuurlijk bedrijven die daar een invloed op hebben, maar het proces is
in principe democratisch en niet gebonden aan een leverancier. Leveranciers van application
servers die moeten die specificaties implementeren om dus compatible te zijn met Java software.
Nu wat doen die? Die zijn natuurlijk wel compatible maar op een bepaald moment
implementeren/gebruiken die toch bepaalde specificaties die zij zelf als vendor hebben
ontwikkeld. Daardoor zie je dat in de praktijk al die software die ontwikkeld is op WebSphere en
Oracle in vele gevallen proprietry API’s gebruiken die door IBM of Oracle in kwestie
ontwikkeld zijn. Als die software daar wordt afgenomen en op JBoss wordt gezet, dan werkt dat
niet meer. In dat geval doen wij een soort van migratie studie of een business case om te kijken
wat de invloed daarvan is. Dus de licentie die je niet meer moet betalen, dat is redelijk snel
berekend. Maar dan kan je misschien goedkopere infrastructuur onder JBoss zetten, dus dat is
ook een besparing. Dan kan die infrastructuur vervangen worden. Maar dan komt er natuurlijk de
kost van al die applicaties op een bepaald moment over te brengen naar JBoss en daar zit meestal
de grootste kost eigenlijk als je zo’n operatie doet. Zeker in het geval dat bepaalde zaken
specifiek van die leverancier gebruikt zijn bij de ontwikkeling. Dat moet dan ongedaan gemaakt
worden en meer generiek in de Java standaarden gezet worden. Dat kan soms wel (van geval tot
geval) het verschil maken tussen we gaan het doen en het gaat ons geld besparen of we doen het
LXVII
misschien beter niet, want uiteindelijk gaat het ons nog meer kosten dan daarvoor. Of het risico
is te groot dat als die applicatie wordt verzet, dat het niet meer in orde kan worden gebracht. Dan
hebben we een ander probleem.
Sarah: Het is dus zo dat jullie dan een marge krijgen op de subscripties of licenties die je
verkoopt voor die application servers? Maar voor JBoss zal dat dan waarschijnlijk lager
zijn dan voor de proprietry vendors?
Mr Eggenstein: Ja dat is inderdaad zo.
Sarah: Ik heb dan ook begrepen dat het voor resellers, die dan eigenlijk solution providers,
integrators of consultant zijn, dat de diensten die ze kunnen verkopen de belangrijkste
bron van inkomsten is. Wat voor diensten kan je dan eigenlijk aanbieden?
Mr Eggenstein: Ja, dat is inderdaad, als je kijkt naar referral fees of de marges, of hoe je het ook
wilt noemen zeker zowel bij IBM, Oracle als JBoss (bij IBM en Oracle zijn die bedragen
weliswaar groter) zijn die altijd verwaarloosbaar in functie van het totale project dat wij
verkopen. Als wij morgen een nieuwe toepassing bouwen voor Elektrabel, ik zeg zomaar iets, en
dat moet op WebSphere, wel wat gebeurt er, meestal hebben zij al de nodige licenties. Dus zo
een aanschaf van een application server licentie dat is meestal iets dat zij al gedaan hebben. Het
gebeurt zelden dat wij application server licenties verkopen omdat die klant die nog niet had.
Klanten die vandaag met IT bezig zijn die hebben al websites die hebben al internet applicaties,
dat moet ergens op draaien, dus meestal hebben die al licenties. Dat is al een eerste punt. En zo’n
licentie dat vormt eigenlijk de basis voor zo’n infrastructuur. Dat is vergelijkbaar met wanneer je
tegen een klant zou zeggen “ik ga een applicatie komen ontwikkelen en ik kom die dan
installeren” en dan zegt die klant “ja, maar ik heb eigenlijk geen pc”. Ik bedoel, iedereen heeft
een pc, zo is dat hetzelfde met application servers, iedereen heeft een application server. Wat er
in het beste geval kan gebeuren is dat die licenties onvoldoende zijn, dat er bijkomende licenties
moeten gekocht worden omdat er meer gebruikers gaan op aangesloten worden. Het kan ook wel
zijn dat er bepaalde features of software gaat gebruikt worden van die vendor die nieuwe licentie
modellen vereist. Ons doel is niet licenties verkopen, wij zijn geen licentie verkoper, wij zijn
diensten verkoper. Wat we wel doen is projecten verkopen, alle elementen aanbieden en dus
infrastructuur of applicatie software, applicatie server software is daar een onderdeel van, maar
LXVIII
dat is geen doel op zich. Het feit dat ze het al hebben en dat de marges beperkt zijn, maakt dat
het voor ons niet echt interessant is. Dat is natuurlijk wel mooi meegenomen. In functie van het
totale project, voor een nieuw project, laat ons zeggen de verhouding doorgaans zeventig procent
diensten en dertig procent licenties is. Dat is dan nog in het beste geval voor de vendor. Meestal
is het 80/20 of 90/10 zelfs. Dat is een gezonde situatie, het kan ook omgekeerd zijn, dat een klant
één miljoen uitgeeft aan licenties en honderdduizend euro aan diensten, dat kan, maar meestal
klopt daar ergens iets niet. Ofwel heeft die een doos gekocht waar alles al in zat, dat kan
natuurlijk. Eigenlijk zijn dat bouwstenen dat je koopt en je moet daar effectief nog iets mee
maken. Dus meestal is het honderdduizend euro licenties en negenhonderdduizend diensten, dat
lijkt mij realistischer. Als je een pc koopt, als je daar niks mee doet, daar werken wel dingen out
of the box, maar je moet toch wel eerst iets installeren, je moet iets configureren, je moet iets
juist zetten vooraleer je die pc echt kunt gebruiken. Het is niet zo dat je die gewoon uitpakt en
dat het allemaal werkt. Hetzelfde is dat met applicatie ontwikkeling. Je moet een aantal
bouwstenen kopen of infrastructuur kopen, maar meestal moeten daar nog een heel aantal
diensten aan te pas komen vooraleer dat het effectief een toepassing wordt die klaar is voor een
eindgebruiker.
Sarah: Kan je dan misschien een categorisatie maken van die diensten?
Mr Eggenstein: In het kader van een totaal project?
Sarah: ja, ik kan me dat zo niet echt voorstellen wat dat juist allemaal inhoudt.
Mr Eggenstein: Als wij dus een project verkopen, ik zeg zomaar iets *** wil dat zijn klanten via
internet voor hun stand van hun gas en elektriciteitsmeters een ander adres kunnen opgeven. Die
klant verhuist bijvoorbeeld en die weet binnen een maand zit die op een nieuw adres en die wil
zijn mijn meterstanden enzovoort overzetten op dat nieuw adres, zodat je daarvoor niet naar ***
moet gaan. De klant wil dat gewoon via het internet kunnen doen. Je moet dan een applicatie
ontwikkelen die dat mogelijk maakt. Dat is een echte internet applicatie en om dat te bouwen
gaan daar heel wat stappen aan vooraf. Eerst en vooral moet er een behoefteanalyse of behoefte
studie gebeuren: wat wil die klant, wat is high level (die meterstanden verhuizen via internet),
maar wat betekent dat dan? Wel wie zijn de klanten? Zijn dat particulieren, zijn dat kleine
bedrijven, grote bedrijven? Via internet, betekent dat dan alleen via een pc of ook een Iphone, of
LXIX
via weet ik wat. En dat moet dan verder geanalyseerd worden. Dan moet er een detailanalyse
gebeuren om te bepalen hoeveel schermen er moeten zijn, welke knoppen er op dat scherm
moeten komen, welke gegevens moeten er ingevoerd worden, vanwaar komen die
klantgegevens, vanwaar komen die metergegevens,… Dat zijn dus een hele hoop functionele en
technische analyses. Neem dat die behoeftestudie 5 tot 10 procent van het budget is. Dan is er die
functionele en technische analyse, dat 40 tot 50 procent van het totale budget kan inhouden. Dat
is in principe papier produceren, waar opstaat wat je gaat doen, maar dan wel in detail. Niet
zomaar een A4, dat kunnen boeken zijn of fardes vol, dat is te zien hoe groot het is. Pas daarna
heb je het effectief ontwikkelen en gaan dus ontwikkelaars of developers effectief in een
bepaalde technologie, die toepassing gaan ontwikkelen. Neem dat het dan nog eens 40 procent
van het budget is of 50, dat is allemaal afhankelijk van hoe groot en hoe complex alles is. En dan
heb je nog 10 tot 20 procent voor testen, installaties, hardware dat moet geconfigureerd worden,
en een application server installeren. Pas dan komen we tot die diensten waar jij op doelt, dat is
dan het opzetten van een omgeving, dat betekent dat er infrastructuur moet zijn, er moet een
opleidingssysteem zijn, er moet een application server zijn, er moet een verbinding zijn met
internet, er moet eventueel security zijn, er moet een heldap aan gekoppeld worden om de
gebruikers accounts aan te maken en passwoorden te geven enzovoort. Er zit nog een heel
infrastructuur en netwerk luik achter, dat meestal ook niet door ons gedaan wordt. Dat kan ofwel
door de klant zelf, ofwel huren zij daar andere mensen voor in. Dat is niet de business van
Capgemini. Bij Realdolmen bijvoorbeeld doen ze dat wel. Daar probeerden ze van A tot Z alles
te doen. Wij bij Capgemini doen voornamelijk behoeftestudie, functionele en technische analyse
en ontwikkeling, eventueel testen en de rest laten wij aan de klant of aan andere partijen over.
Sarah: Hoe zit dat dan met die ontwikkeling van die applicatie? Dat is dan niet iets dat die
bedrijven zelf binnenshuis doen? Wat JBoss aanbiedt bestaat uit twee delen zeker?
Enerzijds de support wanneer de applicatie wordt ontwikkeld en dan anderzijds wanneer
de applicatie effectief in productie gaat.
Mr Eggenstein: Ja ik zal trachten het een beetje duidelijker te maken. Een klant kan eender welk
van al die voorgaande activiteiten die ik beschreven heb zelf doen door eigen mensen of
uitbesteden, of de hulp inroepen van een leverancier (reseller) zoals Capgemini of een ander
bedrijf. Nu het feit of dat wordt gedaan ter plaatse bij een klant of hier of in India, dat staat daar
LXX
nog los van. Ook de vraag wie heeft er uiteindelijk de eindverantwoordelijkheid over het project
(de klant zelf of Capgemini), dat is ook nog iets dat kan beslist worden. Of dat wij dan allemaal
naar de klant gaan, of dat het hier in onze lokalen gebeurt, of dat de klant de
verantwoordelijkheid heeft over het project of wij, dat kan allemaal nog beslist worden. Nu om
terug te komen op uw vraag rond ontwikkelingsomgeving en productieomgeving. Wat JBoss
aanbiedt is inderdaad enerzijds een tool of een ontwikkelingsomgeving gebaseerd op Eclipse,
wat ook open source is, waar zij een aantal voor-geconfigureerde plugins hebben. Ik denk dat die
ontwikkelingsomgeving gratis is, maar je kan daar ook support voor krijgen en dat je daar een
support contract kunt voor afsluiten voor als dat niet werkt of als je daar een probleem mee hebt,
dan kan je daar ook voor bellen. Dan hebben ze hun application server, dus de omgeving waar je
dan de ontwikkelde software gaat op zetten. Dat kan in development zijn om te testen, om te zien
of het werkt. Dat kan ook in productie als het dan af is en het beschikbaar is voor de
eindgebruikers. Dat zijn inderdaad twee componenten en dan hebben ze daar nog frameworks
tussen die je kan gebruiken in ontwikkeling waarvoor je ook support kan krijgen. Dat zijn dus
buildingblocks waarmee je sneller kan software maken, voor al die zaken bieden zij volgens mij
support contracten aan. Nu je kan zeggen ik wil enkel die productieomgeving, ik wil enkel die
ontwikkelingsomgeving, ik wil heel de boel, ik wil zelfs met Red Hat, die brengen dus Linux en
Unix op de markt, niet alleen met een application server, ook de onderliggende operating
systemen support voor hebben en eventueel nog de hardware die eronder zit. Zij bieden dus
eigenlijk alle soorten support aan in verschillende combinaties dat je zou willen kopen. Is dat iets
duidelijker?
(Sarah: Ja ik denk dat dat wel duidelijk is.)
Sarah: Is dat soms een voordeel voor jullie dat de broncode gratis ter beschikking is? Biedt
dat meer flexibiliteit?
Mr Eggenstein: Goh, is dat echt een voordeel… Wel ik denk tijdens de ontwikkeling zelf, dus als
het project in ontwikkelingsfase zit, dat het niet zoveel voordeel biedt. Het is vooral als het
project opgeleverd is en in productie staat en er komen problemen dat je dan eigenlijk de vrijheid
hebt om zelf tot op het laagste niveau naar die buildingblocks kan gaan kijken. Indien er tijdens
de ontwikkeling en productie een probleem blijkt te zijn met één van die buildingblocks dan heb
je op dat moment echt de mogelijkheid om die buildingblock open te doen, en te zien wat er
LXXI
allemaal in zit. Dan kan je nagaan waarom iets niet werkt, daar is misschien een bug in en dat
kan je dan oplossen op uw eigen initiatief. In het geval van proprietaire software zoals Oracle of
IBM dan moet je dus beginnen bij uw support contract en zeggen “zeg, wij denken dat er hier
een probleem is met één van uw spulletjes en dan zeggen die ja dat is niet waar, dat is
waarschijnlijk uw infrastructuur, of uw dit of uw dat, of de manier waarop…” Meestal komt de
gebruiker/klant dan op een lange wachtlijst terecht, tenzij die heel veel betaalt, en dat die eist om
een bevoorrechte behandeling te krijgen. Dan springt er iemand op een vliegtuig, die komt naar
hier, die komt meteen zien wat het probleem is. Maar dat kost dus veel, dat zijn alleen de zeer
grote bedrijven die zich dat kunnen veroorloven.
Sarah: Dus dat gaat dan over de relatie tussen de klant en de leverancier, jullie zitten daar
niet tussen?
Mr Eggenstein: neen, wij zitten daar niet tussen. Dus een klant heeft WebSphere gekocht en die
heeft verschillende software die met die WebSphere kwamen gebruikt en in productie blijkt er
een probleem te zijn met iets dat echt aan die WebSphere gerelateerd is. Als die een goed
contract heeft, dan belt die en zegt die van “ik heb hier een probleem”. Als die veel betaalt, dan
wordt dat binnen een paar uur opgelost, als die weinig betaalt, dan kan dat zijn dat dat na een
maand nog altijd niet opgelost is. In open source zeg je gewoon van “kom, we gaan kijken
waaraan het ligt en het zelf oplossen”. Dus op dat moment is dat een voordeel.
Sarah: Dan heb ik ook nog een vraag over leads. Klanten hoe komen die tot jullie?
Mr Eggenstein: Wat er gebeurt met leveranciers zoals Oracle, IBM en Red Hat, zij doen altijd
twee zaken tegelijkertijd. Enerzijds hebben zij meestal zelf een salesteam of resalesteam. Dat is
zeker zo bij IBM die rechtstreeks naar onze klanten gaat. IBM zal dus rechtstreeks naar *** gaan
en zeggen “zeg ben je niet geïnteresseerd in WebSphere, want bla bla bla”. Die grote klanten
gaan dat waarschijnlijk niet bij een reseller of een integrator kopen, die gaan daarvoor IBM
benaderen omdat ze zeker willen zijn dat ze de klant hebben. Op hetzelfde moment proberen ze
ons natuurlijk te pushen. Zij willen dat wanneer wij bij een klant binnenkomen (en die wilt Java
doen), dat wij dan IBM zouden aanraden/verkopen en niet Red Hat (of Oracle). Dus daar
proberen ze met die referral fees (en die partnerprogramma’s) ons te belonen als we WebSphere
zeggen en niet Oracle (of Red Hat). Hetzelfde voor Oracle en Red Hat, die doen dat op dezelfde
LXXII
manier. Als het om een grote klant gaat, die rechtstreeks bij hen komt, dan zullen zij dat
waarschijnlijk zelf doen. Maar als het gaat om een kleine klant, dan gaat dat om een licentie van
tienduizend euro, dan gaan ze waarschijnlijk een partner zoeken in hun ecosysteem van partners
en dat doorverwijzen naar een partner. Dan zeggen ze tegen de partner “zeg, we hebben hier
bedrijf x aan de lijn gehad, die willen dat kopen, ga daar eens naartoe”, dan gaan we daar
naartoe… En welke partner ze dan bellen, dat hangt er dan vanaf, van welke partner zij denken
dat het meeste kans zal hebben om hun software te verkopen. Als wij bijvoorbeeld consequent
Red Hat zeggen als wij ergens binnen gaan, dan gaan zij waarschijnlijk niet naar ons bellen. Dan
zeggen ze “als we die gasten sturen, dan kopen ze nog iets anders”. Dus dat is een beetje een
subtiel spel van wie kent wie en wie is er voorstander van dat en wie is er meer voorstander van
dat. Dus dat is heel moeilijk om te zeggen waar de leads juist vandaan komen. Soms komen ze
van de vendor, soms komen ze ook van ons. Het kan zijn dat onze sales mensen ergens komen en
zeggen “zeg die wil Java ontwikkeling doen, wat gaan we voorstellen?” En dan kijken wij van
“oké wat heeft die klant al?”. Die heeft misschien al alles van Oracle, behalve application server,
wel dat is het misschien nuttig dat hij dat dan ook koopt en niet met iets anders begint. Of je kan
hebben dat een klant totaal tegen commerciële dingen is. Dan is het misschien beter dat je iets
voorstelt zoals Red Hat, dat open source is. Wij bellen dan naar die vendor en vragen hen dan
“wil jij meekomen, we hebben hier een lead, wil jij daar bij zijn? Of doen we dat zelf”. Dus dat
is altijd een afweging, met wat maak je het meeste kans enzovoort. Als je bij een groot bedrijf
gaat, dan moet je daar niet beginnen over Red Hat, want die willen alleen maar IBM. Natuurlijk
als integrator is het niet gemakkelijk… Soms gaan wij bij een klant, en zeggen zij dat ze niet
tevreden zijn van IBM, terwijl dat wij een goede relatie hebben met IBM. Moeten wij dan gaan
zeggen “ja, IBM dat trekt ook wel op niets, wat dacht je nu, je moet Oracle of Red Hat nemen”.
Dan heb je binnen de kortste keren IBM aan de lijn…” Wat heb jij gezegd?!” Zie je? Dat is altijd
een beetje “tricky” hoe je dat doet en hoe je dat aanpakt. Want op andere deals werk je dan
samen met IBM, dus je kan ze ook niet zomaar de rug toekeren. We hebben onlangs een project
gedaan en daar zaten we in competitie met IBM en wij waren met Red Hat. IBM zei dan ook
“als je niet samenwerkt met ons, dan heb je kans dat je het project zal verliezen”. Uiteindelijk
hebben wij toch gewonnen van IBM (met JBoss) terwijl we bij een andere klant misschien met
IBM tegen Red Hat bezig zijn. Dus… Wat wij altijd willen en voor zorgen dat is dat de klant
inhoudelijk of kwalitatief het beste heeft wat voor hem ook het beste is, in de gegeven
LXXIII
omstandigheden: wat heeft hij al, wat heeft hij eigenlijk nodig, hoeveel geld heeft hij, bla bla bla.
Dus het moet ook economisch verantwoord zijn. Wij gaan niet aan iemand een Rolls Royce
verkopen, terwijl die eigenlijk een Polo nodig heeft, dat doe je niet, ethisch gezien. Die klant
heeft misschien wel het geld ervoor en die kan dat wel uitgeven, maar die kan dan achteraf
zeggen “zeg, maar ik had toch beter zoiets simpel kunnen kopen”. Je kunt dat één keer doen
maar geen twee keer, maar dan ben je niet meer professioneel.
Sarah: Hoe zit dat dan met die referral fees? Dat is iets dat je bij alle drie die vendors
hebt?
Mr Eggenstein: Ja, zij hebben dus allemaal een partnerprogramma, dat als je zoveel licenties en
zoveel leads opneemt en dat effectief omzet in licenties, dan krijg je op het einde van de maand
zoveel bonus of marge of … Dus zij proberen u natuurlijk te vergoeden als je licenties van hun
verkoopt. Want hun business is gewoon licenties verkopen, zij verkopen daar meestal geen
diensten voor. Zij laten dat aan ons over. De software vendors verwachten dat wij hun licenties
verkopen en dan mogen wij de diensten doen.
Sarah: Maar de support is wel voor de leverancier?
Mr Eggenstein: Ja, meestal in zo’n licentie contract is dat een licentie omdat je de software mag
gebruiken, maar dat kan ook een jaarlijkse licentie kost zijn waar dan support in zit en dat je ook
als er nieuwe versies komen van het product, recht hebt om die te installeren enz. Dus een
licentie is een ruim begrip. Het contract met zo een leverancier omvat meestal een stuk het
gebruik van de software, recht hebben op nieuwe versies, patches, fixes enzovoort, eventueel het
onderhoud, wel dat noemen ze is meestal voor een maintenance fee. Waar je dan eigenlijk voor
betaalt: als er een nieuwe versie uitkomt dat je die mag installeren, als er patches zijn, dat je die
mag toepassen enzovoort. Dat is het dus eigenlijk qua licenties, je hebt altijd een stuk gebruik en
een stuk onderhoud en onderhoud is dan nieuwe versies, fixes en patches.
Sarah: Hoe zit dat eigenlijk met die partnerprogramma’s? Is dat een voordeel als je daar
deel van uitmaakt. Je ziet dat het wel veel voorkomt binnen de IT-wereld.
Mr Eggenstein: Ja, uiteindelijk op het einde van de dag is iedereen partner van iedereen…
Eigenlijk moet je dat bijna bezien dat als je geen partner bent, dat je niet goed bezig bent. Dus als
LXXIV
wij zeggen, “ja met IBM daar gaan wij geen enkele relatie mee aangaan als Capgemini”, dan
zeggen uw klanten “dat kan toch niet?! Een groot bedrijf, hoe komt het dat jullie daar geen
partner van zijn?”. Zeker tussen grote bedrijven, het hangt allemaal af van de schaal van het
bedrijf. Grote bedrijven, die partneren met grote bedrijven, dat is gewoon zo. En grote bedrijven
die zullen er altijd voor zorgen dat andere grote bedrijven bevoordeeld worden t.o.v. kleinere
bedrijven die ook partner zijn. Dus als Realdolmen, die 2000 mensen heeft en Capgemini die 90
000 mensen heeft, als die alle twee partner zijn van IBM, de dag dat er een grote deal is dan
zullen ze eerder geneigd zijn om naar Capgemini te bellen. Omdat Capgemini meer volk heeft
dat hun technologie kent, omdat die meer kans hebben om een project te verkopen, omdat die
klant waarschijnlijk ook van een groter bedrijf wil kopen enzovoort. Dus dat is zo een
ecosysteem dat eigenlijk een beetje natuurlijk groeit. Als wij bij een groot bedrijf komen en zij
zeggen “je kent die toch? IBM” en wij zeggen “neen, wij kennen die niet, nog nooit van
gehoord”, ja dan kan je daar geen zaken doen, dat kan je niet maken. Onze grootste partner is
IBM, waarom? Omdat IBM een groot bedrijf is dat bij de negentig of vijfennegentig procent van
onze klanten aanwezig is. Onze klanten, dus Capgemini klanten, dat zijn daarom niet de klanten
van Realdolmen. Die hebben misschien een KMO om de hoek, dat niet onze klant is. Een KMO
gebruikt misschien niet IBM, maar die gebruikt misschien Oracle of Red Hat of nog iets anders.
Zie je, je komt daar automatisch, als bedrijf zit je in een bepaald ecosysteem, waar je moet in
meespelen. Je moet gewoon die partnerships hebben, anders kom je gewoon niet aan de bak. Dus
dat partnerprogramma, ik zou mij daar niet te veel op blindstaren. Die partnerprogramma’s zijn
maar een extra incentive om meer met die vendor samen te werken, maar voor grote bedrijven en
grote projecten, dat geld dat je daar mee verdient als partner is verwaarloosbaar. Moest ik
morgen een Java project gaan verkopen of dat dat nu IBM, Oracle of Red Hat is, dat gaat mij
echt mijn zaken bijna niet maken. Bij IBM ga ik, als reseller, veel meer geld krijgen omdat we
daar een betere relatie mee hebben, dan met Red Hat, omdat de marges groter zijn en omdat de
software ook duurder is en de projecten ook groter zijn. Dat is dus allemaal relatief, ik zou daar
niet teveel op blindstaren.
Sarah: Maar waarom zou je dan ook JBoss verkopen als je zegt dat je zo een goed relatie
hebt met IBM?
LXXV
Mr Eggenstein: Ja dat is de vraag die IBM ons ook altijd stelt. “Waarom werk je niet alleen met
ons? Waarom werk je nog met andere?”. Wel omdat als integrator zijn wij er in de eerste plaats
om de klant te dienen en elke klant is anders. Elke klant heeft zijn eigen mogelijkheden en
beperkingen, behoeften, middelen en ook gewoon puur psychologisch. Als je een CEO bij een
klant hebt en die zegt “ik geloof niet in open source” of een CEO die zegt “ik ben absoluut tegen
IBM” en jij zegt “maar wij doen alleen maar IBM”. Dan zegt die “sorry, maar dan koop ik bij
iemand anders”. Dat kun je eigenlijk niet maken. Wij zijn niet hier om tegen een klant te zeggen
“je moet dat of dat kopen”, wij zijn hier als objectieve integrator. Wij leveren onze diensten en
geven advies zo goed mogelijk in eerste instantie in functie van wat de klant ons vraagt en wat
wij denken dat een goede oplossing is. Zowel kwalitatief inhoudelijk, als financieel. Dus om te
zeggen van “ik werk alleen maar met IBM...” Er zijn natuurlijk bedrijven die dat wel doen,
bijvoorbeeld kleinere bedrijven. Goed oké dat is een keuze, dat is dan een bepaald deel van de
markt of klanten waar je tegen zegt “sorry, maar bij u komen we niet, want jij doet geen IBM”.
Dat is perfect mogelijk hé, want dat is een bepaalde keuze.
Sarah: Heeft dat impact op wat je doet, het feit dat je open source doet of niet?
Bijvoorbeeld die behoefte analyse, die detail analyse...
Mr Eggenstein: Neen, het enige wat ik daarover kan zeggen is, het voordeel dat ik nog zie van
open source is dat het puur technologisch gezien sneller evolueert. Zij zijn altijd een stap voor op
wat de commerciële vendors kunnen aanbieden, technologisch dan. Waar ik mee wil zeggen is
dat als je een bedrijf hebt dat technologisch innovatief wil zijn en met de laatste nieuwe
technologieën wil werken dat je meer kans hebt dat je dat met open source gaat kunnen doen dan
met WebSphere of met Oracle. Dat komt omdat die bedrijven altijd een beetje afwachten tot als
een bepaalde technologie of framework voldoende matuur is, totdat dat een beetje stabiel zijn en
de meeste bugs uit zijn alvorens dat ze dat beginnen te commercialiseren. Terwijl open source is
gewoon een ander model, daar willen ze juist meestal het laatste nieuwe omdat dat de meeste
mogelijkheden biedt.
Sarah: Heb je dan ook vaak klanten die zeggen “ah dat is open source, dus dat is gratis”
Mr Eggenstein: Ja de voornaamste reden voor de klant is nog altijd het kostenaspect en omdat ze
zeggen “oké er is geen licentie die we moeten betalen”. Natuurlijk in de realiteit is dat
LXXVI
gedeeltelijk waar, maar dat is meestal maar een deel van het hele verhaal. (i.e. Subscripties voor
ondersteuning, updates, bugfixes,…)
Sarah: In het begin heb je ook gezegd dat jullie ook Business Intellegence en zo doen, heb
je daar dan ook open source producten in?
Mr Eggenstein: Ja, daar bestaan effectief open source producten in, maar eigenlijk doen we dat
niet. Ik krijg regelmatig ook de vraag van onze vrienden van bijvoorbeeld Business Intelligence
van “zeg wat denken jullie van die of die open source software die als concurrent is van hun
commerciële BI tools” Maar ja eigenlijk zijn we daar niet echt mee bezig. En ik geloof ook niet
dat die markt zal groeien. Ik weet eigenlijk niet waarom die markt niet groeit. Om de één of
andere reden blijkt dat niet echt door te dringen.
Ik had hier nog een presentatie die ik hier gedaan had rond open source. Dus je ziet hier, wat is
open source, want dat is dan ook nog voor sommigen niet echt duidelijk. Want je hebt
verschillende open dingen. Dus het gaat hier over bijvoorbeeld Open Office, het verschil is dat je
geen licentie vergoedingen moet betalen, dat je mag kopiëren, aanpassen en opnieuw verder
verdelen. (Dus het gaat daar over) Het gaat dus niet over open standaarden of over YouTube,
open methodologiën, want dat bestaat ook.
Capgemini heeft in 2008 een onderzoek gedaan over het gebruik van open source software in de
markt en je hebt hier twee assen. Dus je hebt enerzijds het niveau, waar het over infrastructuur
gaat en system engineering en scripting talen enzovoort. Of anderzijds kan het gaan over een
Business Application, bijvoorbeeld een boekhoudprogramma en alles wat daartussen in is,
middelwaren en applicatie integratie. Dat is één as en een andere as bepaalt dan of het gaat om
iets dat juist opkomt of iets is dat al op een zeker niveau is (bepaalde maturiteit) om te gebruiken.
En wat zie je dus dat operating systemen en applicatie servers en al die zaken mature software is,
dat op het niveau van infrastructuur en hetzelfde vindt je terug op het niveau van development
platformen, development tools en hier heb je dan eigenlijk application servers. (dat verschuift
eigenlijk naar boven en naar rechts.) Dat is dan ook hetgeen waar wij mee bezig zijn, die
application servers, development tools, enzovoort. Wat zie je dan op het vlak van bijvoorbeeld
open office automation, dat het dus wel qua business application belangrijk is voor hun dagelijks
gebruik maar dat het toch nog niet echt op het niveau ligt zoals Microsoft Office. Bijvoorbeeld
LXXVII
BI toepassingen dat is helemaal nog technologisch op punt. Dat heeft wel zeer veel business
toegevoegde waarde, maar dat zit technisch toch nog niet waar JBoss bijvoorbeeld zit. Dus dat
zal nog een heel lange tijd duren voor dat opschuift, als het ooit opschuift. Het is niet gezegd dat
het ooit zal opschuiven. Dit is dan ook een grafiek van Gartner, die maken van die rapporten.
Wat je hier kan zien, dat is zo’n typische curve in IT. Dus in het begin wordt er veel tam tam
rond gemaakt, dat wordt opgeblazen tot dat dan invalt zoals een pudding en dan komen er
bepaalde dingen terug uit. Wel wat komt er dan effectief terug op een niveau, dat zijn IT services
voor open source software, wat wij bijvoorbeeld doen, Linux, open source Java IEE application
servers, JBoss, open source frameworks, zoals Spring, maar bijvoorbeeld open source database
management systeem, zoals MySql, open office, dat zijn zaken die er uit kunnen komen maar dat
kan ook niet. Terwijl hier zijn een aantal zaken waar wij mee bezig zijn, die wel degelijk
omhoog zullen gaan, die zitten al een stuk verder op die curve. Naast JBoss hebben we ook wel
al eens projecten gedaan met een content management systeem, dat was met Alfresco. We
hebben ook al projecten gedaan met MySQL en met andere content management systemen. Dus
je ziet Red Hat en JBoss, Alfresco, Spring, dat zijn zo de zaken waar we mee werken. We
hebben zelfs een support center in Nederland, wat dat eigenlijk doet is... Je hebt dus al die
vendors van open source software die al dan niet bepaalde support aanbieden contractueel of
niet. Capgemini heeft daar eigenlijk een dienst tussengezet, zodat niet de klant maar Capgemini
rechtstreeks s naar Red Hat belt. De klant belt dan naar ons en wij verzorgen de uitlevering. Wij
zijn dus een soort van tussenpartij, om te zeggen van “je vertrouwt open source niet” alhoewel
dat er support contracten zijn “weet je wat, wij zullen een contract maken bij ons en wij zorgen
dan wel dat het bij de leverancier in kwestie geregeld wordt” en dat noemen we “open source
software partner” en dat is in Nederland actief.
Sarah: Heb je dan al een partnership met bijvoorbeeld Alfresco of Pentaho?
Mr Eggenstein: Ja, niet in België, maar ik denk wel in Nederland. Ik denk dat ze in Nederland
met al die (wijst naar een slide) een partnership zelf hebben. Dat zijn niet echt partnership, dat
zijn meer afspraken om support te leveren aan klanten, waar wij die software gebruiken in hun
ontwikkeling.
Sarah: Want in de partnershipprogramma’s zit vaak specifieke support voor de partner
zelf.
LXXVIII
Mr Eggenstein: Ja, voor de integratoren ja, dat klopt. Wij hebben een contract met Red Hat, waar
als wij software gebruiken bij een klant en we hebben daar een probleem mee, dat wij dan
eigenlijk in de plaats van de klant op onze naam bellen en dat wij redelijk snel geholpen worden,
dat zit inclusief in dat partnerprogramma. Dus stel dat wij morgen met JBoss iets maken en er is
een probleem mee en die klant heeft nog geen contract met Red Hat, dan kunnen wij bellen “zeg
wij zijn hier bezig bij een klant ***, in ontwikkeling maar die klant heeft nog geen contract en
we gaan hier een applicatie maken. Die klant gaat waarschijnlijk achteraf support kopen, kunnen
wij nu al bepaalde dingen laten oplossen op onze account?” Dat zit dan bij in dat partnership, dat
is wel een voordeel. Daarom zeggen wij ook tegen klanten, als we met Red Hat werken, wij zijn
advanced partner van Red Hat en wij hebben recht op support en binnen de zoveel tijd komt er
iemand af als wij een probleem hebben. Op die manier weet die klant toch wel van Capgemini is
toch gebackt door Red Hat als er echt een probleem is. Het punt met al die dingen is, dat bestaat
allemaal, maar dat maakt niet echt een verschil meer, vandaag in de markt. Het is eerder als je
het niet hebt, dan heb je een probleem. Want als jij bij een klant bent en die moet kiezen Red Hat
en het is met Capgemini of Realdolmen en Realdolmen zegt “wij hebben een partnership, zie
eens wat daar allemaal in zit en we werken al zo lang met Red Hat” en wij zeggen “wij hebben
niks” dan zal die klant ook met Realdolmen gaan, want die zullen dat dan wel beter doen.
Meestal in de praktijk komen wij samen en hebben alle twee dezelfde voordelen, dus dat kunnen
ze dat niet echt gebruiken als voordeel. Daar moet je zeker niet vanuit gaan dat het een verschil
maakt. Het is eerder van als je het niet hebt dat je in de problemen komt. Eens dat iedereen het
heeft maakt het ook geen verschil meer. Dat is zoals die ISO certificaten, ISO 9000 de eerste
bedrijven die het hadden die konden daar mee uitpakken: “zeg wij hebben dat, een anderen
hebben dat niet” maar als iedereen het heeft, is het een probleem als jij het niet hebt. Dan zijn er
negen die het hebben en één niet, dus die valt er dan sowieso al af. Zo is dat ook met die
partnerships, eigenlijk heeft iedereen bijna een partnership. Tenzij je zegt van “ik doe alleen
Oracle. Dus mijn business draait op Oracle, ik zoek alleen klanten die Oracle willen, al mijn
mensen kennen alleen maar Oracle. Voilà dat is mijn keuze, ik profileer mij zo in de markt”. Dat
is ook een keuze, dan weet de klant: dat is met die, dat is Oracle. Dus wij hebben bijvoorbeeld in
de gemeente ***, die hebben besloten om van Microsoft weg te gaan, en we hebben daar open
office geïmplementeerd. We hebben ook voor opleiding van eindgebruikers gezorgd enzovoort.
LXXIX
***, die hadden Oracle application server en daar hebben wij de migratie gedaan. Die besparen
nu jaarlijks honderdduizend euro aan licenties.
LXXX
Bijlage 7: Uitgetypt interview Red Hat Sarah: Ik ben reeds bij drie verschillende resellers van JBoss geweest: Realdolmen, Xplore
Group en Capgemini.
Mr Rentmeesters: Inderdaad nu je die drie opnoemt, dat zijn wel drie grote partners van Red Hat.
JBoss behoort tot Red Hat, dat is één groot bedrijf. Dus wij (Red Hat) hebben JBoss overgekocht
een aantal jaar geleden, in 2006, we zijn ondertussen al een paar jaar verder. Ik heb daarjuist bij
Realdolmen met Carlos De Pelecijn gesproken, dat is niet echt een JBoss man. Heb je bij
Realdolmen met Carlos gesproken?
Sarah : Ja…
Ja oké open source. De vraag is, wat heb je nodig van informatie…
Sarah: Ik heb hier een model, dat zou moeten weergeven wat er gebeurt tussen het Open
Source bedrijf, de Reseller en de finale klant. Misschien kunnen we daar eerst eens naar
kijken.
Mr Rentmeesters: Ik zal eens een tekeningetje maken, dan kan je dat bijhouden. Uw model was
bijna juist.
Dus hoe werken we binnen Red Hat? Maar veel bedrijven, heel veel producten werken op die
manier. Open Source is natuurlijk heel breed. Wat eigenlijk ook belangrijk is voor uw eindwerk
is het verschil tussen open source software en proprietary software. Er zijn veel definities van,
hoe dat dat model in mekaar zit, hoe je dat moet gaan bekijken. In feite het grote verschil tussen
de twee kan worden uitgelegd met de volgende analogie. Er moet een muur worden gemetst, dat
is het programma en de stenen zijn de bouwstenen die worden ontwikkeld door developers. Op
een gegeven moment is er een developer die op een dag niet goed wakker is of die nog niet
genoeg ervaring heeft en die laat eigenlijk een gat in die muur. Dat is een onvolmaaktheid, dat
wordt wel of niet opgemerkt, dat zien ze wel of niet (de developer zelf of zijn baas). Of het is
misschien te veel werk om het aan te passen en ze maken daar één grote .exe van bijvoorbeeld.
Dan is dat niet meer zichtbaar, want niemand weet nog dat die onvolmaaktheid in die “muur” zit.
En je kunt wel zeggen, er zijn wel mensen die dat weten en die pleisteren dat wat toe. Je hebt dan
wel mensen die dat eens checken en dat is dan uw security breach. Je hebt bijvoorbeeld
LXXXI
Microsoft secutity hot fixes hebt, dat is voor hier een nieuwe baksteen in te zetten. Hoe werkt dat
nu met open source software? Er wordt ook een muur gebouwd met allemaal bouwstenen, maar
open source software is eigenlijk software die gepubliceerd wordt. Als er een developer is en die
maakt een fout, en die laat daar ook een gat open, dan gaan er mensen zijn die dat onmiddellijk
gaan zien vermits dat dat gepubliceerd wordt. Dat is een open boek, en men kan op tijd
opmerken dat er iets niet klopt. Daarvoor is open source software alleszins beter dan closed
source software. Iedereen kan zien dat daar een gat is en iemand gaat dat proberen dichten. Een
developer gaat ook niet willen dat zijn naam daar onder staat.
Als je wilt gaan werken met eindklanten, dat is moeilijk, omdat dat veel energie vraagt.
Eindklanten die hebben dikwijls kleine bestellingen, die vragen veel ondersteuning, dat is heel
arbeidsintensief, dus waar hebben wij dan voor gekozen binnen Red Hat, maar bij heel veel
andere bedrijven is dat juist hetzelfde verhaal, om te werken met resellers. Resellers zoals
Realdolmen, Capgemini,... zij doen het meeste van die zaken, zoals administratie en zij sturen
dat naar ons door bij bestellingen. Nu de Resellers zelf vragen ook heel veel energie. Dus wat
doen wij en ook nog anderen zoals Alfresco, daar zit een tussenstap tussen, de distributie is dat.
Onze distributeur is Distrologie, die verkopen dus nooit aan eindklanten (onze producten
verkopen ze in elk geval nooit aan eindklanten). Zij pakken ook weer de moeilijke problemen op,
of de day-to-day business, zij verwerken de orders. Wij zijn een klein bedrijf, binnen Red Hat
zelf werken we ongeveer met een 3200 mensen wereldwijd, waarvan drie mensen customer
placement in België. Maar we hebben wel 25 miljoen subscriptions servers operationeel over
heel de wereld. Dat zijn 25 miljoen systemen en 3200 mensen die daar achter...
Sarah: Je moet dan waarschijnlijk veel omzet hebben om winst te maken?
Mr Rentmeesters: Ja, dat valt wel mee. Het gaat hier natuurlijk om software het is geen
hardware, we hebben geen aankoop van hardware, tenzij cd’tjes en doosjes, maar eigenlijk doen
we dat niet meer graag. Maar voor de rest hebben we geen aankopen, we hebben wel materiële
assets maar die gebruiken we voor ons wagenpark,... maar wij moeten niet zoals een constructeur
grondstoffen aankopen. En het ontwikkelen van de software doen we ook niet zelf. Dus we
werken sowieso met een distributeur. Wij verkopen subscripties en dat is een abonnement. De
meeste open source bedrijven, vermits de software gratis is, kunnen niets verdienen op de
software, dus moet je uw geld ergens anders verdienen. Wij verdienen aan het subscriptie model.
LXXXII
Als de klant een abonnement wil aankopen, moet hij dat aankopen bij de reseller en die bestelt
dat op zijn beurt bij de distributeur en die bestelt op zijn beurt bij ons. Wij leveren rechtstreeks
uit aan de eindklant. Vermits wij met software werken, krijgen zij een soort van sleutel. De
schakels (reseller en distributeur) komen daar niet meer tussen, zij krijgen wel een mail van oké
dat is uitgeleverd aan de klant, maar in feite krijgen ze dat niet meer in handen.
Sarah: Komt dat dan rechtstreeks op jullie rekening terecht?
Mr Rentmeesters: De reseller gaat factureren aan de eindklant, Distrologie factureert aan de
reseller en wij factureren aan Distrologie. Zo is het model hier in België. In andere landen zoals
Nederland en Beglië hebben ze een aantal global accounts vastgelegd. Global accounts zijn de
hele grote accounts KLM, Shell, Bayer… Die heel grote bedrijven die kopen wel rechtstreeks bij
ons aan. Dus dan wordt de factuur rechtstreeks naar Bayer gestuurd en zij bestellen rechtstreeks
aan ons. Het reseller kanaal is zeer belangrijk voor ons. Ongeveer 65% van de omzet die wij
draaien is afkomstig van resellers.
Sarah: Is dat dan wereldwijd, of in België?
Mr Rentmeesters: In België is dat 100%, enkel via partners. De Benelux organisatie is een
veertig tal mensen groot, in België zijn er drie mensen die customer facing zijn. Dat ben ik die
verantwoordelijk is voor het kanaal, dus voor alle reseller, OEM partners, ISV partners (bv
Adobe of Agfa). Dat is ook voor een stuk EMEA12, dat wordt vanuit Duitsland beheerd. Dus dat
is mijn verantwoordelijkheid. Er is nog iemand die verantwoordelijk is voor alle grote klanten,
dus dat zijn de 30 à 35 grootste klanten van België. Ook alles wat fulfilment is, gaat via het
kanaal. Dus Red Hat zal niet snel iets rechtstreeks aan een eindklant verkopen.
Sarah: Dus dat is voor zowel JBoss als Red Hat?
Mr Rentmeesters: Ja daar is geen verschil tussen. Puur technisch gezien zit er geen verschil
tussen het model dat gebruikt wordt. Want wat is het topic van uw thesis? Hoe het model van
partner, reseller enzoverder in elkaar zit? Hoe je een open source product naar de markt brengt?
Dan maakt het geen verschil uit. Er zijn binnen Red Hat drie grote zuilen, enerzijds heb je JBoss
wat middleware is. Heel moeilijk om uit te leggen aan mensen die niet met informatica bezig
12 Europe, the Middle East en Africa
LXXXIII
zijn. Er is het infrastructuur stuk, dus eigenlijk het OS (Operating System) zoals Microsoft. En
dan heb je nog een “virtualization” stuk, dus alles wat “virtualization” van systemen is. Dat zijn
de verticals die we kennen op technisch gebied. Wat verkopen we met Red Hat: subscriptions
voor JBoss en Red Hat en certificaties van die global learning services, nu noemt dat Red Hat
learning en certifications. Dat gaat over opleiding en training.
Sarah: Dus dat is dan voor een reseller bijvoorbeeld?
Mr Rentmeesters: Dat is niet bepaald, dus daar mag een reseller naartoe gaan maar ook een
eindklant.
Sarah: Want in die partnerprogramma’s zie je dus ook dat partners korting krijgen om
training te volgen.
Mr Rentmeesters: Ja, zij krijgen dus korting als ze training volgen maar dat is omdat zij een
totaal partnership hebben. In België werken we met kortingen bij aankoop. Omdat we drie
verschillende tiers van partnerships hebben. Dan is er GLS, Global Learning Services, dat zijn
mensen die op cursus gaan voor Red Hat Certified Engineer of JBoss administrator. Dat is voor
eindklanten, maar als jij dat wilt doen, mag je dat gerust doen. Anderzijds zijn er ook nog de
professional services, wij hebben ook nog een services organisatie, bijvoorbeeld als een klant
diensten wil afnemen dan hij die bij ons bestellen en gaan wij die rechtstreeks uitvoeren. Voor de
subsctipties in België gaat dat altijd via het kanaal. Voor de learning services kan men
rechtstreeks bij ons bestellen als de klant heel groot is of via het kanaal. Voor de professional
services kan hij rechtstreeks bij ons bestellen of via het kanaal. Dus dat zijn die drie
verschillende.
Een vierde partner waar je mee had kunnen spreken is Econocom. Je hebt wel met drie goede
bedrijven gesproken, want het zijn alle drie bedrijven die vooral geïnteresseerd zijn in handjes
verkopen. Dus die willen mensen detacheren. Als zij een project kunnen verkopen waar iemand
negen maand aan vast zit, dan is dat gewoon negen maand constant facturatie, je moet daar niet
over nadenken. Je moet op het einde van de maand die factuur doorsturen naar de eindklant.
Daar zijn ze vooral in geïnteresseerd. Nu moet je gaan zien, heel veel producten die verkocht
worden, zoal Red Hat (dus het operating system), JBoss,… dat zijn lege dingen. Ik bedoel daar
zit niks in. Als je JBoss downloadt je bent daar niks mee, tenzij je daar een applicatie mee maakt,
LXXXIV
dan kan je er wel dingen mee doen. Dat is het grote verschil eigenlijk. Voor een partner is het pas
interessant om producten te verkopen als hij ook zijn diensten daar kan aan koppelen. Daarvoor
dat ik zeg dat het goed is dat je met die drie partners gesproken hebt. Waarom is dat? Capgemini
is een system integrator. System integrators zijn van oudsher influencers. Die hebben een aantal
oplossingen, tuurlijk willen ze winst maken en dus hun diensten verkopen, maar die gaan naar de
markt toegaan met een bepaalde oplossing, architectuur. Dat kan een oplossing op basis van
JBoss zijn of eventueel WebSphere of WebLogic. Ze zouden dat kunnen doen voor bijvoorbeeld
de NMBS of andere overheidsdiensten. Daar wordt naar gekeken, kleinere bedrijven gaan
zeggen, dat is wel interessant wat een system integrator doet. Want als die system integrator dat
doet zal dat wel niet slecht zijn. Daarom dat het influencers zijn. Dan heb je Xplore en
Realdolmen (dat zijn geen global system integrator), die hebben enkel een vestiging in België.
Realdolmen heeft ook wel vestigingen in Nederland en Luxemburg. Globaal gezien doen die een
groter aantal bedrijven dan Capgemini, die hebben een veel breder scala aan projecten dat die
doen. Want Capgemini hebben 10 of 12 klanten en met die 12 klanten proberen ze zoveel
mogelijk te doen. Realdolmen daarentegen heeft 3000 klanten en die doen misschien 50 à 60
projecten op een jaar, waar Capgemini misschien 4 (grote) projecten per jaar doet Het verschil
tussen Xplore en Realdolmen is dat Xplore enkel applicatief werkt, die doen alleen maar
programmeren. Xplore zitten bij de Cronos groep en dat is een octopus van 80 of 90 bedrijfjes
(daar is niet aan uit te kunnen). Realdolmen was vroeger eigenlijk een pc-boer, een box-mover
zoals ze dat noemen. Die namen een doos van HP en plakten daar een sticker op van Realdolmen
en werd dat terug geshipt naar de klant, dat was hun werk. Zij hebben dus een ander soort insteek
van die diensten. Dan komen we bij die vierde, dat is Econocom, die hebben een heel goede
license desk pc-ware is ook zo’n bedrijf. Bedrijven met een license-desk zijn eigenlijk bedrijven
die geen technische mensen hebben, die ook meestal geen hardware verkopen. Het enige wat die
eigenlijk moeten doen is zeggen van “ah je hebt zoveel subscripties nodig” die maken daar een
offerte voor op, sturen dat door en nemen heel lage winstmarges. Want hun team is heel klein,
die hebben geen mensen op de bank zitten omdat er niet voldoende projecten zijn, die hebben
geen technische mensen die opleiding moeten volgen,… Die nemen heel lage marges en dan zie
je dat bv-bijvoorbeeld pc-ware een heel aantal grote contracten heeft, voor grote
overheidsinstellingen. Econocom doet dat ook, die hebben een aparte afdeling die enkel met
licensing bezig is. Dat zijn eigenlijk de verschillende stappen die er zijn. Dat is op het gebied wie
LXXXV
doet wat. Dan heb je nog een stap lager en dat zijn de echte pc-boeren. En dat is een soort van pc
winkeltje, of drie à vier mensen die een bvba oprichten. Toch kan dat een partner zijn voor ons
zijn die soms heel belangrijk. Want die verkopen ons idee, maar evengoed als die groot worden
tot zo een license desk of als er nog services moeten worden aangekocht zoals Realdolmen of
Xplore, of als het echt een heel groot project wordt bij Capgemini. Realdolmen, Xplore en
Capgemini zitten wel op hetzelfde niveau van expertise, die kunnen evenveel doen.
Dus nu heb ik het verhaal van de Reseller/System Integrator gedaan. De resellers dat zijn de
mensen die de subscripties en diensten verkopen, zij doen dat allemaal. Van alle resellers zijn er
effectief maar een aantal die effectief implementaties doen en dat zijn dan Realdolmen, Xplore
en Capgemini. Daaronder heb je de gewone resellers, dat zijn de pc-ware, de insiders, en
Econocom. Dat is het echte partnerkanaal. Dan heb je nog het ISV, dat zijn de Independent
Software Vendors. Die kopen uw product, die geven dat een ander uiterlijk, die voegen daar
extra functionaliteiten aan toe en die verkopen dat verder, maar dan wel met hun plakker er op.
Dus hoe moet je dat bekijken: als je bijvoorbeeld een wagen koopt, dan zijn er mensen die kopen
hun motor bij BMW, hun chassis kopen ze bij... hun banden kopen ze bij Michelin en die maken
daar één grote wagen van en die verkopen ze dan onder een andere naam. Dat mag. Zij (ISV’s)
betalen dan een fee om die technologie te gebruiken, maar wij zijn daar voor de rest weinig bij
betrokken, zij geven zelf support op die omgeving, zij geven zelf updates en upgrades. Dat is een
ISV, die onze technologie, de runtime (het bruikbaar deel) zoals ze dat noemen, gebruiken ze. Je
hebt bv bij uw thuis Wifi staan, die router die je hebt staan, daar zit een Linux operationsystem
op, en die hebben dat ook ergens gekocht en daar werd ook voor betaald. Per gechipt toestel,
word daar voor betaald op één groot contract. Er zijn dan ook nog de echte OEM’s die eigenlijk
onze subscripties verkopen, maar die zelf de support op geven. Die verkopen product als zijnde
een Red Hat of JBoss subscription, maar krijgen heel veel korting omdat ze een stuk van de
support zelf doen.
Sarah: Als je een nieuwe partner wilt overtuigen om jullie producten te verkopen hoe ga je
dat doen? Dus als je als reseller minder inkomsten verkrijgt uit een open source product,
waarom ga je dan naast bijvoorbeeld WebSphere ook JBoss verkopen?
Mr Rentmeesters: Ja, wie stuurt de reseller aan... Dus de reseller die zit eigenlijk gevangen
tussen twee vuren, die heeft dan enerzijds wij (softwarebedrijven), wij willen dat zij onze
LXXXVI
technologie verkopen en anderzijds zitten ze dan met de klant. Dus de klant die vindt
kostenreductie heel belangrijk, dus de kosten moeten naar beneden gaan. Als de klant een offerte
krijgt en die ziet daar IBM WebSphere en dat is 500 000 euro en die krijgt een ander offerte van
een ander bedrijf en daar staat JBoss op en dat is 150 000 euro en die hebben uiteindelijk beiden
hetzelfde eindresultaat, wat gaat die klant dan zeggen? Die moet niet lang nadenken dan. Een
kwalitatief goede producten afleveren is dan ook belangrijk. Onze (Red Hat) concurrenten
bevinden zich op verschillende niveau’s, maar onze grootste concurrent is dikwijls het .org
verhaal. Dat zijn onze grootste concurrent. Er is natuurlijk ook WebSphere en WebLogic, maar
we hebben sinds 6 jaar geleden rond Oracle (WebLogic) niets nieuws gehoord hé.
Sarah: Kan je dat eigenlijk zeggen wat jullie marktaandeel is binnen die drie?
Mr Rentmeesters: Neen, dat kan ik zo niet direct zeggen.
Sarah: JBoss lijkt het wel goed te doen in de markt, dat is wel populair toch?
Mr Rentmeesters: Ja, maar hoe komt dat? Dat is door het .org verhaal. Het .org verhaal is gratis
te downloaden. Er wordt gezegd dat elke 4 seconden een versie wordt gedownload van het
internet. Dat is voor een ontwikkelaar, die thuis iets wil maken voor zichzelf of ook bedrijven.
Bedrijven die een nieuwe applicatie nodig hebben zien dat als ze moeten kopen bij oracle het hen
10 000 kost voor een licentie en JBoss kunnen ze gratis afhalen. Je hebt dan min of meer
dezelfde functionaliteiten. Dat is vergelijkbaar met skiën of snowboarden, Mercedes of BMW,
wat is het beste? En dan moet je begrijpen hoe die community eigenlijk werkt, hoe je van een
community versie naar een enterprise versie gaat. Dat is belangrijk, omdat resellers er moeten
van overtuigd zijn dat ze met de enterprise versie moeten werken. Want dat is dikwijls de vraag,
“waarom zouden wij die enterprise versie moeten verkopen, want wij kunnen hier toch al
ontwikkelen op .org” Daarom moet je kijken naar hoe dat subscriptie model, certificaten en de
support in elkaar zit. Als je bijvoorbeeld JBoss.org hebt, dan heb je geen support. Als je dat dan
koppelt met een SAP omgeving en je hebt daar problemen mee, heb je geen support en kan je
ook niet naar SAP bellen. Dat zijn allemaal pros om met de enterprise versie te werken. Maar
zegt de reseller dan, en er zijn een aantal resellers die daar zeer goed in zijn, “een community
versie leeft altijd 6 maand of een jaar voorop, dus daar zitten nieuwe functionaliteiten in die nog
niet in de enterprise zitten”. Zij zeggen ook vaak ze die functionaliteiten willen. Maar waar kies
LXXXVII
je dan, voor het laatste van het laatste en het nieuwste van het nieuwste of wil je iets dat
gesupporteerd is. Aan de enterprise versie werken 70 quality assurance engineers die enkel maar
testen, en kijken of alles werkt. Of heb je liever dat uw eigen mensen het zelf testen en eventueel
tegen problemen aanlopen en op het internet een oplossing moeten gaan zoeken. Wat is dan de
verhouding tussen wat dat dan kost en als je de enterprise versie gaat gebruiken waar je support
e.d. bij hebt.
Sarah: Zie je dan een verschil met relatie tussen de verschillende partners
Mr Rentmeesters: Neen, dat is een vertrouwensrelatie dat je hebt. Kijk wat is heel belangrijk,
want eigenlijk alles draait om de eindklant. De relatie met uw partners en de relatie met uw klant
zijn twee verschillende dingen. Enerzijds hebben we onze territory sales, die verkoopt de
producten, die heeft rechtstreeks contact met eindklanten. Eindklanten die houden er van om met
vendors te spreken, want een eindklant is daardoor gecharmeerd. Maar als je als reseller zoals
bijvoorbeeld Realdolmen belt naar een klant, dan zijn die dikwijls niet erg enthousiast. Maar als
Red Hat belt naar een eindklant, dan is het meteen in orde om bij de klant langs te gaan, want die
voelen zich ergens wel gecharmeerd. Dat is omdat Red Hat een internationaal bedrijf is, dat 65%
van de commerciële Linux infrastructuur in handen heeft. Je begint dan gesprekken op te starten,
dan achteraf op een bepaald moment vraagt die klant met welke partner zij dat kunnen doen. Dan
kom je terug op dat partnership level dat de resellers hebben of hoe goed hun relatie is met de
klant of hoe goed ze partner kennen. Xplore doet heel veel in JBoss, Capgemini is goed in JBoss
net als Realdolmen. Je komt bijvoorbeeld binnen bij de NMBS, een grote klant, dan zeg je van
die drie partners hebben we en vermeld je niet “pc-materialen Pierre” van een klein dorp, neen,
dan neem je een partner die dat aankan. Wat belangrijk is om te weten, je hebt drie soorten
partnerships hé: Ready, Advanced en Premier.
Ja we zijn hier eerst met dat model begonnen, misschien moeten we dat eerst afmaken. Dus de
reseller maakt voor de klant een offerte, de reseller vraag dan eerst een offerte aan de distributeur
en zij bellen dan naar ons. Soms vragen ze dat direct aan ons als het moeilijk is, maar dat is niet
vaak. Dus dan wordt er telkens een offerte doorgestuurd. Zij doen daar al hun marges bij. Als
alles goed gaat wordt er een bestelling opgemaakt door de reseller die dan bestelt bij de
distributeur die dan bestelt bij Red Hat. Ik zal het uilevering noemen.
LXXXVIII
Sarah: Dat is dan de support?
Mr Rentmeesters: Neen de uitlevering, dat is uw subscriptie zelf. Uitlevering is altijd bij ons,
naar het Red Hat network van de klant. Dus als het een nieuwe klant is wordt er voor hem een
Red Hat network ID aangemaakt, dat zijn klantgegevens, contactpersoon... Als hij al één heeft
wordt dat bij de bestelling doorgegeven. Zij hebben daar dus al een marge op genomen
enzoverder (zie figuur) Ik weet niet hoe diep je moet gaan want het OEM en ISV kanaal zit
anders in elkaar. Dus hoe zit ons reseller kanaal zelf in elkaar? We hebben drie soorten van
partnerships. Die eerste die moeten aan geen voorwaarden voldoen, die moeten gewoon iets
aanvinken op het internet, hun gegevens invullen en je bent vertrokken. En zij krijgen een
bepaalde korting bij onze distributeur. Je hebt ook mensen/bedrijven die geen partnership
hebben. Dus je moet geen partnership hebben om bij een distributeur aan te kunnen kopen en dan
krijgen zij bijvoorbeeld 10% marge op de listprijs. Er is ook nog een tweede kanaal. Dus dat van
daarjuist dat is het gewone, dat is het distributie kanaal. Een tweede is order via web en hier
wordt geen marge toegekend en ook geen kortingen toegekend. Zij betalen gewoon de
eindgebruiker listprijs zoals die op het web terug te vinden is. Als je dan gaat kijken naar het
ready, advanced en premier partnerlevel wordt er korting toegekend. Nu wat is dan het verschil
tussen die advanced en business partner. Zij moeten 2 system engineers hebben, die een officieel
examen hebben gedaan. Zij moeten ook 2 sales hebben, dus wij hebben ook een officiele sales
track en 2 references. Die references dat zijn klanten waar de reseller een project heeft gedaan.
Bij het premier level heb je 4 system engineers nodig, 4 sales die moeten gecertificeerd zijn en 4
references. Het spreekt vanzelf dat de ready partners niet op het web staan, tenzij ze minstens 1
customer references hebben ingegeven, het zijn minder belangrijke partners. Die advanced en
premier zijn wel zichtbaar op het internet en in overheidsopdrachten kan het soms wel zijn dat,
voor lastenboeken, moet je bijvoorbeeld 4 gecertificeerde mensen hebben.
Sarah: Kan je dat dan nog eens uitleggen met die listprijs en die korting.
Mr Rentmeesters: Dus bijvoorbeeld listprijs is 100 euro, dan moet de ready partner die 15%
krijgt 85 euro betalen aan de distributeur en zij moeten dan ook een lagere prijs aan Red Hat
betalen. De klant moet dan 100 euro of misschien iets minder betalen, en ze zullen misschien nog
een of ander kost extra worden aangerekend, dat weet ik niet. En dat is natuurlijk wat moeilijk
om duidelijk te maken wat het verschil is tussen advanced en premier. De premier partner kan
LXXXIX
daar spelen op certificaties. Voor ons is dat ook belangrijk. Als een klant aan ons vraagt “met
wie moeten we samenwerken” dan gaan wij eerder een premier partner dan een partner met een
lager level aanraden. Omdat die premier partner ook aan ons een commitment toont. Als je 4
system engineers opleidt (vereiste voor premier partner), dan kost dat geld. Want je moet je
werknemers aan 2600 euro de man op cursus sturen + je bent die 4 werknemers 5 dagen kwijt.
Op die dagen brengen die niets op, dat kost dus een pak geld aan de reseller.
Sarah: Wie is er dan juist premier en advanced van de drie dat ik heb geïnterviewd?
Mr Rentmeesters: Capgemini is advanced business partner, maar die zullen wel premier worden,
Realdolmen is premier voor infrastructuur en JBoss. Xplore die gaan premier partner worden op
JBoss en Open Future die zijn premier partner op infrastructuur.
Sarah: Als je dan een lead binnen krijgt hoe ga je dan kiezen welke partner je neemt?
Mr Rentmeesters: Ja het eerste dat we vragen aan die klant is “met welke partner werk je al
samen?” en als die zeggen met (pc-boer) “Jean uit Zwevezelle”, dan willen we dat gerust doen.
Tenzij het natuurlijk in een omgeving is waarvan we weten dat ze beter zullen geholpen worden
met een grote partner.
Sarah: Hoe zit dat juist met referral fees, werken jullie daar mee?
Mr Rentmeesters: Die korting waarover ik daarjuist sprak is up-front. Up-front korting heet dat.
Dus ze kunnen dat dadelijk al aftrekken van de belastingen. Nu een aantal partijen, die zijn
eigenlijk niet zo geïnteresseerd in subscripties verkopen. Die zijn vooral geïntereseerd in handjes
verkopen. Die doen bijvoorbeeld een heel voortraject met pre-sales en klanten bezoeken (en dit
en dat). Bijvoorbeeld bij een overheidsinstelling, deze zijn verplicht om minstens drie offertes te
vragen. Dus de reseller doet heel veel inspanningen en hoe laat hij zich vergoeden voor deze
inspanningen? Door natuurlijk marge te nemen op de aankoopprijs die hij moet betalen. Als er
een partner is die helemaal niets gedaan heeft, die geen kosten heeft gemaakt, die moet zoveel
marge niet pakken. Dus wat zegt die dan in plaats van 10% marge te nemen, die nemen maar 3%
marge en een overheidsinstelling neemt de laagste prijs. Dus jij hebt daar dan jaren gewerkt en
jaren bij die klant bezig geweest en demo’s gegeven... en dan komt dat project er en is er iemand
anders die de deal kan verzilveren met een lagere marge. Dat klopt niet hé. Wat hebben ze dan in
XC
het leven geroepen, dat is een referral fee. Nu komt er iets anders bij dat, is lead registratie. De
reseller kan een lead registreren en later, wanneer een andere partner deze deal wint, kan de
reseller dan van Red Hat toch nog een procent van de verkoopwaarde van dat product krijgen
(dat staat wel nog niet op punt).
Sarah: Hoe stellen jullie dat partnerprogramma op, kijken jullie daarvoor naar andere
vendors?
Mr Rentmeesters: Die partner programma’s zijn natuurlijk wereldwijd opgesteld. Zeker EMEA13
wide zijn dat ongeveer dezelfde regels, maar daar wordt wel van afgeweken. De channelmanger
van het specifieke land kan soms wel afwijken van een aantal dingen. Er wordt niet zozeer
gekeken naar hoe anderen daarmee werken, maar je komt soms wel op ideëen. Het leadregistratie
systeem is nu nieuw in het leven geroepen en dat is enkel geldig voor advanced en premier
business partners. Zij kunnen op voorhand zeggen van “kijk wij zijn hier met dat project bezig”
en dan krijgen ze achteraf extra korting. Dat is natuurlijk ook iets dat anderen hebben. Back
rebate schema’s dat bestaat al veel langer. Is dat dan afgekeken? Ik denk dat niet. Maar ons
systeem werkt helemaal anders dan bijvoorbeeld IBM. Ook onze gecertificeerde mensen zijn
anders dan van andere partijen. Er zullen wel overeenkomsten zijn, maar het is toch nog
specifiek naar de producten toe of naar de technologie die je biedt.
Sarah: Dus dat is toch afhankelijk van het soort technologie dat je verkoopt ?
Mr Rentmeesters: Neen niet echt... Je mag niet vergeten dat Red hat vroeger een technologisch
bedrijf was. Tot 1993 was de winst van Red Hat het verkopen van koffietassen en t-shirts, daar
kwam de winst van Red Hat vandaan. En dan zijn ze commercieel veel harder gaan meedoen en
ook wel het verkopen van services. We zijn eigenlijk pas veel harder beginnen groeien als we
subscriptions zijn beginnen verkopen, dat is voor ons belangrijk.
Een partnership is iets dat tweeledig werkt. Een partnership is belangrijk voor ons. Wij stellen
een aantal eisen aan de partners, zoals we daarjuist hebben besproken. Dan weten we ook dat
binnen het bedrijf zelf technische kennis zit. Ze hebben dan ook twee referenties opgegeven en
dan wetren wij dat zij weten hoe onze dingen werken. We weten dan dat zij daar ervaring in
hebben en omdat ze sales mensen hebben weten we eigenlijk dat ze onze producten kunnen 13 Europe, the Middle East and Africa
XCI
positioneren. Dat is eigenlijk de effort (moeite) die een partner aan ons laat zien van kijk eens we
willen er iets voor doen. Dus door het opleiden van mensen, sales en technische gezien, willen
zij laten zien dat zij kennis hebben over ons producten. Dan komt het er natuurlijk ook op aan
om het advanced business partner niveau te gaan verkopen bij onze eindklant zelf. Want als een
eindklant vraagt “wie moeten we inschakelen” en wij sturen een advanced of een premier,
(afhankelijk van...) dan weten we dat die mensen ten minste een beetje kennis hebben, dat we
daar niet iemand naartoe sturen die misschien eventueel helemaal geen kennis heeft van het
product.
Sarah : Mentaliteit rond open source is waarschijnlijk toch een belangrijk gegeven voor
jullie?
Mr Rentmeesters: (Dat is een van de grootste...) Ja ik heb het daarjuist gezegd, de .org is een van
onze grootste concurrenten. Maar dat begint wel te veranderen, wat je bijvoorbeeld ziet, in
Nederland is het al veel harder aan het gaan, veel sneller, meer uitgebreid. Ik ga een voorbeeld
geven, als je in België een lastenboek hebt, een groot lastenboek, een Europees lastenboek, dan
is de overheid verplicht om ten minste één open source oplossing te vragen. In België wordt dat
wel gedaan, maar wordt dat afgeketst. In Nederland zijn ze dat ook verplicht, maar als ze het niet
kiezen, moeten ze verantwoorden waarom ze het niet gekozen hebben, dat is toch nog een stapje
verder. Ik zal nu niet zeggen dat dat in België ook zal gebeuren, maar je ziet dat meer en meer de
adoptie... als je nu weet van bijvoorbeeld HP, is 20% van de servers die verkocht worden, met
een Linux operating system op. En dat was 10 tot 15 jaar geleden zeker en vast niet het geval.
Dus de adoptie gaat wel omhoog. Maar inderdaad, als ik iedere keer als iemand zegt van “open
source dat is toch gratis” een euro zou krijgen... De software zelf is wel gratis, maar alles wat
daar rond zit is niet gratis. Professionele ondersteuning is niet gratis, de documenten daar rond
zijn niet gratis, certificatie wat heel belangrijk is, is niet gratis. Want een bedrijfkritische
applicatie zoals bijvoorbeeld tax-on-web moet goed werken (dat is trouwens een open source
oplossing). Als tax-on-web stil valt, dat is dan meestal rond mei en juni zeker, dan gaan er veel
moord en brand roepen, en zullen er veel kranten van vol staan over het informatica beleid van
het ministerie van financiën. Als ze dan support hebben, dan hebben ze tenminste een stok achter
de deur. Dus dat zijn allemaal dingen die meespelen. Dat en er zijn er nog hé. Misschien nog iets
belangrijk voor partners en klanten, dat is intellectual property. Stel u voor dat Capgemini een
XCII
oplossing verkoopt voor een aantal servers bij een klant. Je kent het community verhaal? Dus uit
die verschillende projecten en broncode wordt een versie gedirigeerd die wat smaller is en daar
zit al wat meer project in en dan gaat dat naar quality assurance en dan gaat dat over naar
applicaties. Stel nu voor dat er één iemand bij Oracle of Sap of Microsoft werkt die ergens iets
ontwikkeld heeft voor zijn Oracle, en die gooit dat in de community van JBoss. Uiteindelijk
beland dat misschien in de JBoss.com, maar vermits dat allemaal open is kan iedereen dat
gewoon lezen. Op een gegeven moment kan je wel hebben dat Oracle zeg, “maar wacht eens wij
hebben wel een patent op dat stukje code, je mag dat zomaar niet gebruiken, nu moet elke
gebruiker van JBoss 1000 euro betalen voor elke geïnstalleerde server”. Dat is iets waar wij in
een subscriptie tegen beveiligen. Wij betalen dan de gerechtskosten. Voor ons is dat belangrijk,
voor de klant is dat belangrijk, maar ook voor de partner is dat belangrijk. Dat de partner
inderdaad ziet, de producten die verkocht worden onder subscriptie, daar mag je zeker van zijn
dat dat goede producten zijn. Wanneer je een huis zou laten bouwen dan wil je ook niet dat de
metser zou zeggen, “ja maar dat was slechte cement we gaan uw huis moeten afbreken en terug
opbouwen.” Je moet daar tegen gewapend zijn.
Als een reseller voor open source kiest, heeft dat soms te maken met ideologie en dat zijn de
‘verkeerde’ mensen. Omdat ideologische mensen nogal vaak terug durven grijpen naar het .org
verhaal. Dat is er maar het subscription model is belangrijk voor de business kant. Er zijn drie
verschillende soorten mensen in een bedrijf. Je hebt de business mensen, de developers en je
hebt de operations. Developers die willen snel vooruit gaan, die willen het nieuwste van het
nieuwste, die willen proberen, die willen snel gaan, die willen tricks,... Operations die willen
stabiliteit, die willen niet ’s nachts moeten komen omdat een server down is, die willen dat dat
altijd blijft draaien, die willen dat dat stabiel is, dat ze makkelijke support krijgen. Die hebben
dus een andere invalshoek. En dan heb je business, die wilt dat dat makkelijk aanpasbaar is, dus
als ze andere eisen stellen aan de software dat dat makkelijk en snel aanpasbaar is, dat dat
goedkoop is, dat ze flexibl daar kunnen mee werken. Dus dat zijn drie verschillende
invalshoeken die je moet benaderen als partner. Capgemini die kan dat voor een stuk wel,...
Sarah: Waarom zou je dan voor een proprietry vendor gaan als je voor JBoss kan gaan?
Mr Rentmeesters: Eén uw adoptie door de markt, dat is één. En twee, Stel u voor dat je als
partner met IBM werkt, je hebt dus jaren dure software verkocht aan klanten en dat levert een
XCIII
miljoen per jaar op aan licenties. Dan ga je daar niet tegen een klant zeggen “en nu hebben we
iets gezien en dat kost u maar 150 000 euro”. Wat gaat die klant dan zeggen “dus jij hebt tien
jaar van mij geprofiteerd?!”… ja, dat is een heel moeilijk verhaal.
Sarah: Krijgen die resellers dan ook niet vaak de reactie van klanten dat ze iets over JBoss
hebben gelezen en dat ze daar dan willen voor gaan?
Mr Rentmeesters: Ja dus het bottom up, top down verhaal... maar dus... Dit (operations?) is
eigenlijk onze klant, die willen met die dingen, die willen stabiliteit...dus... maar dat is wel
helemaal onze klant (die drie eenheden, operations, business en developers). Dat is hetzelfde met
onze developers, als jij met een open source verhaal komt in een bedrijf, dan zie je heel dikwijls
dat de developers die kant doen, en dat de business zegt “ja maar TCO is belangrijk” en dan
komen ze samen en dan gaan ze ergens hun weg hier wel vinden, eventueel. Als hier natuurlijk
een microsoft of IBM of Oracle zit en die zegt van “luister, dat is niet stabiel, ik bedoel dat is
open source hé (negatieve toon)” en dat is wat wij eigenlijk proberen te veranderen, door te
zeggen van “ja wij horen hier ook tussen” (tussen Microsoft, IBM en Oracle).
Ken je Gartner? Die hebben zo magical quadrants, most interesting, most adopting... en JBoss
staat hier ergens (4de quadrant), al vierde jaar in een rij, en IBM staat hier ergens en Microsoft
staat hier. Maar wij staan er wel al vier jaar.
Wat je eens op Youtube moet opzoeken dat is Jan Wildeboer, dat is een open source evangelist.
Als je wilt kan ik u ook nog in contact brengen met klanten die met open source werken, want
dikwijls weten zij niet dat daar nog een distributeur tussen zit. Voor een klant hoeft dat ook niet.
Die weten dat niet en die hoeven dat dikwijls ook niet te weten.