Open Source Software business model OSS - study and...

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.


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.


• “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)


• “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)


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


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


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


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)


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


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)


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


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.


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.


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


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


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


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.


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.


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.


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


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


1/2/3 1/2/3 1/2 2/3 4


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


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


1/2/3 1/2/3 1/2/3 3


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


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


2/3 2/3 2/3 2/3 4


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


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


1 0 0 0 $ 2000 02 $ 980 $ 3200 $ 4000 $ 6000 $ 29993 $ 980 $ 3200 * $ 12000

Legende

* onderhandelbaar


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


2/3 2/3 2/3 3


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


1/2/3 1/2/3 1/2 2/3 4


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


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


1/2/3 1/2/3 1/2/3 3


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


2/3 1/2/3 1/2/3 3

minimum aantal getrainde mensen (verkoop of technisch)

2/3 2/3 2


2/3 2/3 2/3 2/3 4


2/3 2/3 2/3 3

actieve participatie in gefocuste marketing programma's

3 3 2/3 3


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


1 0 0 0 $ 2000 02 $ 980 $ 3200 $ 4000 $ 6000 $ 29993 $ 980 $ 3200 * $ 12000

Legende

* onderhandelbaar


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


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


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


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


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


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.

Open Source Software business model OSS - study and...

Documents

Transcript of Open Source Software business model OSS - study and...