UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2009 – 2010
Open source software business model (OSS): study and analysis of commercial OSS business model and innovation ecosystems
Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Sarah Govaert onder leiding van Prof. Dr. Ir. Frank Gielen
UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2009 – 2010
Open source software business model (OSS): study and analysis of commercial OSS business model and innovation ecosystems
Masterproef voorgedragen tot het bekomen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur
Sarah Govaert onder leiding van Prof. Dr. Ir. Frank Gielen
Permission Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Sarah Govaert
I
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.
II
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
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
2.
Open Source Software .................................................................................................................. 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
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 2.4 3.
Soorten Partnerships ........................................................................................................... 38
De Open Source Gemeenschap ................................................................................................... 40
ONDERZOEKSVRAAG EN METHODOLOGIE ........................................................................ 45 3.1
Onderzoeksvraag......................................................................................................................... 45
III
3.2
4.
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
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
5.
Methodologie .............................................................................................................................. 45
Interview Red Hat ..................................................................................................................... 102
4.5.1
Het Partnerlandschap ........................................................................................................ 102
4.5.2
Eindklanten en Partners .................................................................................................... 103
4.5.3
Financieel Model............................................................................................................... 105
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
IV
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
V
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
VI
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
VII
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 ITindustrie 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 1
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.
2
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
3
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 4
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)
5
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 6
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 7
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)
8
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)
9
•
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)
10
•
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
11
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. 12
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 13
infrastructuursoftware en is hoofdzakelijk gericht op specifieke behoeften van de eindgebruiker. (Messerschmitt & Szyperski, 2005) Voor sommige applicaties is het nodig dat er controle is op de toegang tot de applicaties. Dit heeft betrekking op de mogelijkheid om te bepalen wie de toestemming heeft om een applicatie te gebruiken, de mogelijkheid om te identificeren wie probeert om toegang te krijgen tot de applicatie en de mogelijkheid om toegang te weigeren tot de applicatie. Herbruikbare software componenten kunnen deze functies implementeren die dan kunnen worden geïntegreerd in meerdere applicaties. Deze softwarecategorie wordt middleware genoemd en is een laag die wordt toegevoegd aan de bestaande infrastructuur die onder de applicatielaag ligt. (Messerschmitt & Szyperski, 2005) Er zijn een aantal uitdagingen specifiek voor de software industrie en een aantal termen belangrijk voor software die kort worden besproken: •
De beschikbaarheid van complementaire producten heeft een invloed op de waarde van software. Besturingssystemen zoals Windows, Mac OS, Linux zijn voorbeelden van infrastructuursoftware. Een bepaalde applicatiesoftware zoals een tekstverwerker kan beschikbaar zijn op een besturingssysteem zoals Windows maar niet op Linux. Dit vormt een beperking voor het gebruik van deze applicatie, onafhankelijk van de kwaliteit van de applicatie zelf. De beschikbaarheid van complementaire producten is belangrijk. De waarde van een besturingssysteem zal dus niet alleen afhangen van de kwaliteit, maar ook van de beschikbaarheid van applicaties. (Messerschmitt & Szyperski, 2005) (Schilling, 2008)
•
Een andere uitdaging voor de software industrie is industriecoördinatie. De infrastructuur van vele verschillende softwarebedrijven moet kunnen samenwerken, applicaties moeten kunnen samenwerken met infrastructuur en applicaties moeten ook op complexe manieren samenwerken voorbij de grenzen van de verschillende organisaties. (Messerschmitt & Szyperski, 2005)
•
“Netwerk externalities”: Software is typisch een markt met “netwerk externalities”. Dit wil zeggen dat de baten bij het gebruik van een bepaald goed stijgen met het aantal andere gebruikers van hetzelfde product. De waarde van een bepaald product stijgt dus
14
met toenemende grootte van het netwerk van gebruikers. (Schilling, 2008) (Messerschmitt & Szyperski, 2005) •
“Installed base”: De “installed base” is het aantal gebruikers van een specifieke technologie. (Schilling, 2008)
•
“Switching” kosten: De kosten die men heeft wanneer men van producent wil veranderen. Dit resulteert in “vendor lock-in” dat een competitief voordeel is voor een bepaalde producent. (Messerschmitt & Szyperski, 2005)
1.2.2 De Software Waardeketen De software waardeketen bestaat uit drie grote onderdelen: de productie of het programmeren, marketing, verkopen (distributie) en diensten. Er kan een onderscheid worden gemaakt tussen de waardeketen voor gestandaardiseerde software en de waardeketen voor op maat gemaakte software. (Ghosh, Glott, Krieger, & Robles, 2002) Figuur 2: Software waardeketen Software
Software
ontwikkeling documentatie
Software verpakking
Marketing en sales
Productie/programmering
Implementatie en/of integratie
opleiding
Applicatieondersteuning management
Diensten
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:
15
‐
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)
16
Tabel 1: Negen bouwstenen van een bedrijfsmodel pilaar
bouwsteen
omschrijving Geeft een allesomvattend overzicht van de producten Value Proposition product en diensten van een bedrijf Beschrijft het segment van klanten waaraan het Doelgroep bedrijf waarde wil bieden Beschrijft de verschillende middelen van een bedrijf Distributiekanaal klanten interface om tot de klant te komen Beschrijft de linken die een bedrijf vestigd met de Relaties verschillende klantensegmenten Value Configuration Beschrijft de organisatie van activiteiten en middelen Beschrijft de vaardigheden die nodig zijn om het Core Competency bedrijfsmodel uit te voeren management van Beschrijft het netwerk van cooperatieve infrastructuur overeenkomsten met andere bedrijven die nodig zijn Partnernetwerk om op efficiente wijze waarde te bieden en te commercializeren Beschrijft de monetaire gevolgen van de middelen Kostenstructuur gebruikt in het bedrijfsmodel financiele aspecten Beschrijft de manier waarop een bedrijf geld verdiend Inkomstenmodel via verschillende inkomstenstromen 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.
17
•
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 18
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)
19
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)
20
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)
21
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
22
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
23
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) 24
•
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)
25
•
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 26
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)
27
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 28
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)
29
•
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 ITindustrie. 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.
30
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)
31
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 32
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
Leeroriëntatie
Prestaties
+ + Intensiteit van de relatie
+
+
Coöperatie
+ + Levensduur van de relatie
Tevredenheid van de kanaalleden
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) 33
Leeroriëntatie Partners moeten leren van elkaar om op die manier de kerncompetenties van elkaar over te nemen zodat ze samen één gemeenschappelijk strategisch voordeel worden. Op deze manier kunnen partners onderling van elkaar leren en ervaringen met elkaar delen. Dit verbetert de kerncompetenties van de strategische alliantie en coöperatie tussen de verschillende partijen. De leeroriëntatie wordt gemeten aan de hand van de waarde die een bedrijf hecht aan leren als een voordeel op lange termijn. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006) Levensduur van relatie De levensduur van de relatie heeft zowel betrekking op de effectieve lengte van de relatie als de verwachting dat de relatie zal verder worden gezet of het verlangen om de relatie verder te zetten. Literatuur is het erover eens dat langdurige relaties meer voordelen bieden en winstgevender zijn. Er is al bewezen dat hoe langer partners elkaar kennen en elkaar vertrouwen, ze ook meer bereid zijn om veranderingen te aanvaarden. Dit geldt vooral voor industriële markten omdat een partnership vaak hoge investeringen vereist en op die manier worden de afhankelijkheden tussen partijen en de barrières om uit de relatie te stappen hoger. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006) Intensiteit van de relatie In de context van exportkanalen kan intensiteit van de relatie worden gedefinieerd in termen van verwantschap. Intensiteit kan ook worden benaderd in termen van continuïteit van de relatie. Een andere bron definieert dit als de atmosfeer of klimaat van de relatie. De intensiteit van een relatie tussen partners heeft dus ook een invloed op de samenwerking tussen koper en verkoper. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006) Prestaties In dit model worden prestaties gedefinieerd als de mate waarin het gedrag van de internationale distributiepartner bijdraagt tot de objectieven van de producent. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006)
34
Tevredenheid van de kanaalleden Traditioneel wordt tevredenheid van kanaalleden beschouwd als een bepalende factor die de moraal van de kanaalleden en de motivatie om deel te nemen aan collectieve activiteiten beïnvloedt. Zelfs wanneer een bedrijf de mogelijkheid heeft om macht uit te oefenen, zou dit op een positieve manier moeten gebeuren ten voordele van de tevredenheid van kanaalleden. (Mehta, Polsa, Mazur, Xiucheng, & Dubinsky, 2006) Tevredenheid van kanaalleden kan worden gedefinieerd als een positieve gevoelstoestand die voortkomt uit een beoordeling van alle aspecten van de relatie van een bedrijf met een ander bedrijf. Hierbij zijn er twee aspecten van belang namelijk de economische en de nieteconomische 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. 35
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)
36
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 37
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, 38
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 39
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 40
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)
41
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 42
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) 43
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 nietevidente 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.
44
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)
45
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:
2
•
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
Dat is de bedrijfsversie van de OSS Linux geproduceerd door Red Hat.
46
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) 47
•
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.
48
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)
49
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 50
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:
51
•
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.
52
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)
53
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)
54
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.
55
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
RH - M iddlewa re
RH - In fr
astructu ur
Tabel 2: open source partnerprogramma’s - algemene voordelen
VOORDELEN algemene voordelen welkom pakket toegang tot een partnernetwerk / partnerforum mogelijkheid tot deelname aan een sales- of marketingcampagne nieuwsbrief/regelmatig informatie vermelding in partnerlijst vermelding in een voorkeurslijst succesverhalen/case study toegang tot commercieel product voor intern gebruik Roadmap mogelijkheid tot deelname aan evenementen en sponsoring (gezamenlijke) persberichten
1/2/3
1/2/3
2
1/2/3
1/2/3 1/2 1/2/3
2/3
2/3
1/2/3
1/2/3
1/2/3
1/2/3 1/2 1/2/3
1/2/3
2/3
2/3 1/2/3
2/3
1/2/3
6
2
3 3
1/2 2/3
2/3
1/2
1/2 1/2/3
3
1/2
1/2/3
1/2 1/2/3
7 3
1/2 2/3 2/3
1/2/3
1/2
3 1/2/3
2 1/2
2/3
4
4 3
Legende 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
56
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)
opleidingsvoordelen (verkoop- en 1/2/3 technische)opleiding productopleiding (via internet) 1/2/3 verkoopsopleiding (via 1/2/3 internet) korting op opleidingen 2/3
1/2/3
1/2/3
1/2/3
2/3
1/2/3
1/2/3
5 2
1/2/3 1/2 2/3
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
RH - M iddlewa re
RH - In fr
astructu ur
Tabel 3: open source partnerprogramma’s - opleidingsvoordelen
1/2 1/2/3
1/2 2/3
1/2
4 2/3
7
Legende 1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
De opleidingsvoordelen hebben betrekking op opleiding of certificaten die te koop zijn bij het OSS bedrijf. Het kan gaan om product-, technische- en verkoopsopleiding die wordt aangeboden of een korting voor opleidingen of certificaten. Het meest populaire, te vinden bij zeven van de acht OSS bedrijven, is de korting voor opleiding.
3
De frequentie van de elementen staan tussen haakjes
57
verkoopsvoordelen marge kortingen referral vergoedingen toegang tot een sales team/ sales materiaal, tools en ondersteuning lead distributie/lead partnermanager
2/3
2/3 1
1/2/3 1/2/3
1/2/3 2/3 3
2/3 3
1/2/3 2/3
2/3 2/3
3
2/3
1/2
Frequen tie
Digium
MySQL
Pentaho
1/2/3
1/2
2/3
SugarC RM
Acquia
Alfresc o
RH - M iddlewa re
RH - In fr
astructu ur
Tabel 4: open source partnerprogramma’s - verkoopsvoordelen
2 2 2 3 2
2/3 2/3
5 6
Legende 1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Bij de verkoopsvoordelen is er slechts één element dat zes keer voorkomt in de acht partnerprogramma’s en één element dat vijf keer voorkomt. Er zijn dus minder gelijkenissen tussen de verschillende elementen bij de verkoopsvoordelen. Het eerste element is de beschikbaarheid van een partnermanager die bij zes partnerprogramma’s pas wordt aangeboden op een hoger niveau dan het eerste. Het tweede element is het toegewezen krijgen van (gekwalificeerde) leads. De categorie “marge en korting” kan worden samengenomen en komt dan voor in vier van de acht programma’s. Deze categorie kan dan worden beschouwd als (een deel van) de financiële vergoeding voor de reseller. Elementen die minstens 2 maal gevonden worden, zijn4:
4
•
Referral vergoeding (2)
•
Toegang tot een verkoopsteam (2)
•
Toegang tot verkoopsmaterialen, verkoopstools en verkoopsondersteuning (2)
De frequentie van de elementen staan tussen haakjes
58
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)
marketing voordelen (product marketing) collateral en campagnes product demonstratie (niet om te verkopen) templates en richtlijnen voor campagnes/marketing materiaal gebruik van partnerprogramma logo partnerprogramma certificaat Marketing Development Fund
1/2/3
1/2/3 1/2 1/2/3
1/2/3
1/2/3 1/2
1/2/3
1/2/3 1/2
1/2/3
1/2/3 1/2 1/2/3
1/2/3
1/2/3
3
3
1/2/3
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
RH - M iddlewa re
RH - In fr
astructu ur
Tabel 5: open source partnerprogramma’s – marketing voordelen
2/3
2/3
7
2/3
2/3
5
2/3
4
1/2/3
6
2/3
3
2/3
4
1/2/3
3
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)
59
technische ondersteuning technische ondersteuning toegang tot kennis korting op professionele diensten technische (pre-)verkoop ondersteuning (via internet)
1/2/3 1/2/3
1/2/3
2/3
2/3
2/3
2/3
1/2/3
2/3 2/3
1/2 2/3
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
RH - M iddlewa re
RH - In fr
astructu ur
Tabel 6: open source partnerprogramma’s – technische ondersteuning
3 5 2
3
2/3
4
Legende 1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Technische ondersteuning is een categorie die bij drie van de acht partnerprogramma’s niet kan worden teruggevonden namelijk deze van Alfresco, SugarCRM en MySQL. De drie elementen die kunnen worden gevonden zijn5:
5
•
Toegang tot kennis (5)
•
Korting op professionele diensten (3)
•
Technische (pre)verkoop ondersteuning (eventueel via internet) (4)
De frequentie van de elementen staan tussen haakjes
60
VEREISTEN invullen van een partnerprogramma aanvraagformulier en profiel aanvaarden van de partnerprogramma overeenkomst jaarlijkse deelnamevergoeding jaarlijkse minimum inkomsten doelen minimum aantal abonnementen, hoeveelheid inkomsten minimum aantal getrainde mensen (verkoop of technisch)
1/2/3
1/2/3
1/2/3
1/2/3 1/2
2/3
2/3
2/3
2/3
1/2/3 2/3
minimum aantal gecertificeerde 2/3 mensen jaarlijks (12 maandelijks) 2/3 bedrijfsplan actieve participatie in gefocuste marketing 3 programma's minimum aantal succesverhalen van klanten jaarlijks 2/3 voorleggen
1/2/3
1/2/3
Frequen tie
Digium
MySQL
Pentaho
2/3
1/2/3
3
1/2/3
6
2
5
1/2/3 2/3
2/3
SugarC RM
Acquia
Alfresc o
RH - M iddlewa re
RH - In fr
astructu ur
Tabel 7: open source partnerprogramma’s – vereisten
3 1/2/3
2/3
3
2
2/3
2/3
2/3
4
2/3
2/3
3
3
2/3
3
2/3
1/2/3
3
Legende 1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Wat betreft de vereisten vermeldt Alfresco enkel een bepaalde certificatieprocedure die moet worden gevolgd. MySQL vermeldt enkel een partnervergoeding die moet worden betaald op het 61
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)
0 0 $ 980 $ 3200 $ 980 $ 3200
2
3
3
0 $ 2000 4000 $ 6000 * $ 12000
3
2
Digium
MySQL
Pentaho
SugarC RM
3
Acquia
3
Alfresc o
RH - M iddlewa re
aantal partnerniveaus partnervergoeding per niveau 1 2 3
RH - In fr
astructu ur
Tabel 8: open source partnerprogramma’s – partnerniveaus en –vergoedingen
3
0 $ 2999
Legende *
Onderhandelbaar
62
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 63
productteam aanwezig zijn en een aantal gecertificeerde of opgeleide mensen. Voor de reseller is dit een niet te verwaarlozen investering. Intensiteit van de relatie Er wordt niet meteen verwezen naar de intensiteit van de relatie in de partnerprogramma’s. Wat er wel op kan wijzen dat de intensiteit van de relatie hoger zal zijn naarmate de reseller een hoger partnerniveau bereikt is de beschikbaarheid van een partnermanager. Prestaties Dit kan niet worden afgeleid uit de partnerprogramma’s. Tevredenheid van de kanaalleden Dit is een factor die wel kan teruggevonden worden in de partnerprogramma’s. De tevredenheid van de kanaalleden wordt beïnvloed door de voordelen die worden aangeboden. •
Administratie: dit heeft te maken met de manier waarop vragen en problemen van de reseller worden behandeld.
•
Diensten ondersteuning: de reseller kan in de partnerprogramma’s een grote verscheidenheid aan marketing-, verkoopsondersteuning en technische ondersteuning krijgen.
•
Beloningen: de referral vergoeding is een voorbeeld van een beloning voor de reseller die een nieuwe klant kan aanwerven.
•
Vergoedingsbeleid van producent: dit is het geheel van marges, kortingen en andere financiële
voordelen
die
de
reseller
kan
krijgen.
Daartegenover
staat
de
partnervergoeding die door de reseller moet worden betaald. Aan de hand van dit conceptueel model van coöperatie zien we dat de elementen van de partnerprogramma’s die werden geïdentificeerd kunnen bijdragen tot betere samenwerking en beter prestaties van het distributiekanaal.
64
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 $)
65
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:
6
•
Member (gratis)
•
Advanced (gratis)
Tussen haakjes staan het aantal elementen in elke categorie.
66
•
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.
67
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.
68
Sales force .com
Suga rCRM
Tabel 9: SugarCRM vs. Salesforce.com – algemene voordelen
VOORDELEN algemene voordelen welkom pakket toegang tot een partnernetwerk / partnerforum mogelijkheid tot deelname aan een sales- of marketingcampagne nieuwsbrief/regelmatig informatie vermelding in partnerlijst vermelding in een voorkeurslijst succesverhalen/case study toegang tot commercieel product voor intern gebruik Roadmap mogelijkheid tot deelname aan evenementen en sponsoring (gezamenlijke) persberichten verkopen van technologieën
1/2/3
1/2/3
2/3
3 1/2/3 2/3 3 1/2/3 2/3
1/2/3
1/2/3 2/3 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.
69
opleidingsvoordelen (verkoop- en technische)opleiding productopleiding (via internet) verkoopsopleiding (via internet) korting op opleidingen korting op certificaten
Sales force .com
Suga rCRM
Tabel 10: SugarCRM vs. Salesforce.com – opleidingsvoordelen
1/2/3
De opleidingsvoordelen zijn zowel voor SugarCRM en Salesforce.com beperkt. Enkel SugarCRM vermeld dat de partner toegang heeft tot verkoops- of technische opleiding.
verkoopsvoordelen marge kortingen referral vergoedingen toegang tot een sales team/ sales materiaal, tools en ondersteuning lead distributie/lead referral/qualified leads lead/deal registratie partnermanager
Sales force .com
Suga rCRM
Tabel 11: SugarCRM vs. Salesforce.com – verkoopsvoordelen
1/2/3
2/3 2/3 1/2/3 2/3
1/2/3 1/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
70
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.
marketing voordelen (product marketing) collateral en campagnes product demonstratie (niet om te verkopen) templates en richtlijnen voor campagnes/marketing materiaal gebruik van partnerprogramma logo partnerprogramma certificaat Marketing Development Fund distributie via een online marktplaats
Sales force .com
Suga rCRM
Tabel 12: SugarCRM vs. Salesforce.com – marketing voordelen
1/2/3 1/2/3
1/2/3
3 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.
71
technische ondersteuning technische ondersteuning toegang tot kennis korting op professionele diensten technische (pre-)verkoop ondersteuning (via internet) gratis licenties onbeperkte ontwikkelings- en testomgevingen
Sales force .com
Suga rCRM
Tabel 13: SugarCRM vs. Salesforce.com – technische ondersteuning
1/2/3 1/2/3
1/2/3 1/2/3
toolkit voor ontwikkeling en codebibliotheken
1/2/3
technische discussie fora technische support van de gemeenschap
1/2/3 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.
72
VEREISTEN minimum klantentevredenheidscijfers invullen van een partnerprogramma aanvraagformulier en profiel aanvaarden van de partnerprogramma overeenkomst jaarlijkse deelnamevergoeding jaarlijkse minimum inkomsten doelen minimum aantal abonnementen, hoeveelheid inkomsten minimum grootte van team minimum aantal getrainde mensen (verkoop of technisch) minimum aantal gecertificeerde mensen jaarlijks (12 maandelijks) bedrijfsplan actieve participatie in gefocuste marketing programma's jaarlijkse sponsoring minimum aantal succesverhalen van klanten jaarlijks voorleggen
Sales force .com
Suga rCRM
Tabel 14: SugarCRM vs. Salesforce.com – vereisten
1/2/3
1/2/3 1/2/3 1/2/3 1/2/3
1/2/3
1/2/3
2/3 2/3
1/2/3
2/3 2/3 1/2/3
2/3
Legende 1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
Het aantal vereisten ten opzichte van het aantal voordelen voor partners is groter bij SugarCRM dan bij Salesforce.com. Voor Salesforce.com zijn er twee vereisten die niet in de lijst van de OSS partnerprogramma’s staan, namelijk verplicht een minimum klantentevredenheidscijfer en verplicht jaarlijkse sponsoring. Er moet geen partnervergoeding worden betaald door partners van Salesforce.com, maar zij moeten er zich wel toe verbinden om te proberen een minimum omzet te behalen. Beide bedrijven hebben nog twee andere elementen gemeen namelijk verplicht een minimum aantal succesverhalen voorleggen en een minimum aantal gecertificeerde mensen in huis hebben. 73
aantal partnerniveaus partnervergoeding per niveau 1 2 3 jaarlijkse minimum inkomsten 1 2 3
3
Sales force .com
Suga rCRM
Tabel 15: SugarCRM vs. Salesforce.com – partnerniveaus en –vergoedingen
3
$ 2000 $ 6000 $ 12000 $ 10 000 $ 100 000 $ 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.
74
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.
75
•
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
76
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 77
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. 78
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 79
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 80
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
81
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ë
82
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/
83
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. 84
3. Financiële Stromen en Partnerprogramma Realdolmen is “premier partner” van Red Hat voor zowel Red Hat Linux Enterprise als JBoss Red Hat. Voor beiden wordt jaarlijks een partnervergoeding betaald. Jaarlijks wordt er samen met Red Hat een bedrijfsplan opgesteld, er wordt een gemeenschappelijk plan opgesteld voor zowel Red Hat als JBoss. Bij Realdolmen is het steeds de bedoeling dat als zij voor een bepaald product kiezen ze tot het hoogste partnerniveau gaan. Zeker op technisch vlak trachten zij zich daar te onderscheiden door verder te gaan tot op het hoogste technische niveau. Zij streven er steeds naar die competenties te halen zodat zij zich daar mee kunnen onderscheiden en projecten zo goed mogelijk kunnen afhandelen. Er kan ook worden geconcludeerd dat het eerste niveau een soort instapniveau is dat voor bijna iedereen toegankelijk is en dat men kan toetreden door een aantal zaken op de website aan te klikken en in te vullen. Wanneer dieper wordt ingegaan op de partnerprogramma’s worden een aantal onderdelen even toegelicht. Er is steeds een marketing gedeelte in de partnerprogramma’s waardoor een reseller voor bepaalde acties die hij organiseert ondersteuning kan krijgen. Een term die men kan terugvinden bij de meeste softwarebedrijven is “Marketing Development Fund”. Bij de ene moet men het project voorstellen en kan men zo financiering bekomen, bij anderen krijgt de reseller een vast jaarlijks bedrag dat kan worden besteed. In België zijn er voor de verkoopsondersteuning van Red Hat een drietal mensen. Er is iemand verantwoordelijk voor de verkopen, er is een partnermanager en er is iemand die verantwoordelijk is voor alles wat te maken heeft met presales. De verkoopsverantwoordelijke heeft een vaste lijst klanten waarmee wordt gewerkt. Wanneer de reseller bij een klant werkt die op deze lijst staat, wordt er samen met deze verantwoordelijke gewerkt. Wanneer het om een andere klant gaat zal de partnermanager voorzien in commerciële ondersteuning. Het is mogelijk dat de reseller beslist om het werk alleen te doen maar het is soms makkelijker om samen met de mensen van Red Hat in een team te werken. Dit is een systeem dat werkt bij alle softwarebedrijven. Hieruit blijkt dan ook dat er op zich niet veel verschil is tussen de partnerprogramma’s van verschillende softwarebedrijven. Het enige grote verschil dat er is, heeft betrekking op de grootte van het softwarebedrijf. Microsoft werkt bijvoorbeeld op dezelfde manier als een kleiner bedrijf 85
zoals Red Hat, maar is veel groter. Er zijn dus ook veel mensen betrokken en meer resellers die ook partner zijn met Microsoft. De vraag is dan ook of Microsoft gebruik maakt van zijn grootte en macht om druk uit te oefenen op resellers. Maar het is beter de vergelijking te maken met een huwelijk. Beiden, zowel het softwarebedrijf als de reseller, hangen van elkaar af. Zeker wanneer het gaat om een reseller van de grootte van Realdolmen. Zij hebben wel degelijk een stem bij het softwarebedrijf. Hoe meer omzet een reseller bij een softwarebedrijf heeft, hoe luider zijn stem is en als zij de reseller verliezen hebben zij een probleem en omgekeerd als de reseller het softwarebedrijf verliest heeft de reseller ook een probleem. Soms zijn er wel eens problemen, maar blijven samenwerken is voor beiden een voordeel. 4. Keuze en Strategie Realdolmen heeft ongeveer 8 jaar geleden gekozen om samen te werken met Red Hat. Het team dat toen voor Red Hat heeft gekozen, heeft bepaalde procedures uitgevoerd die men steeds moet verrichten wanneer een bepaald product of technologie wordt overwogen. Eerst gebeurt er een doorlichting van de markt, om na te gaan wat de verschillende mogelijkheden zijn. Dan wordt er geëvalueerd of deze oplossingen technisch waardevol zijn. Daarna wordt er gekeken hoe de partnerships juist werken, hoeveel resellers er reeds zijn voor de technologie. Er wordt ook nagegaan of deze oplossing wel past in het productgamma en men onderzoekt wie er juist achter het product staat en hoe daarmee wordt samengewerkt. Voor het kiezen van een applicatieserver wordt er eerst gekeken naar de taal waarin de applicatie moet worden ontwikkeld bij de klant. Als er voor de programmeertaal Java wordt gekozen zal men afhankelijk van de klant voor een bepaalde applicatieserver kiezen. Men gaat dan na wat de klant zoal heeft, waar de klant naartoe wil of moet en op die manier wordt er voor een bepaalde applicatieserver gekozen. Realdolmen doet dus JBoss, WebSphere en nog een aantal andere. Het verkopen van licenties is niet het belangrijkste voor Realdolmen. Wat belangrijk is, is de mogelijkheid om mensen te verhuren om applicaties te schrijven. Licenties of abonnementen voorzien eerder in de mogelijkheid om de mensen aan het werk te zetten en diensten te verkopen. OSS vanuit ideologie heeft geen plaats in een bedrijf. Bij de keuze voor JBoss was het belangrijk om het team van Java ontwikkelaars in overweging te nemen. Als het team van ontwikkelaars bij Realdolmen niet aan het werk is, dan kost dat geld want die mensen kosten de reseller geld of zij 86
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.
87
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 88
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. 89
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 90
gezet, deze applicatie niet meer werkt. Er moet dus een migratiestudie worden gedaan om na te gaan in welke mate dit een invloed zal hebben op de migratie. De migratiestudie zal een aantal zaken analyseren om na te gaan wat het verschil in TCO zal zijn na de migratie. Ten eerste wordt nagegaan wat het effect is van het wegvallen van de licentiekosten voor de huidige software in vergelijking met de abonnementskosten voor JBoss. Ten tweede wordt er ook nagaan of het mogelijk is om goedkopere infrastructuur te gebruiken in vergelijking met de huidige infrastructuur. Als laatste wordt een analyse gemaakt van de kost die wordt gemaakt bij het overbrengen van de applicaties naar JBoss en daar zit meestal de grootste kost als zo’n operatie wordt uitgevoerd. Dit is zeker zo in het geval dat er bepaalde API’s werden gebruikt die specifiek ontwikkeld zijn bij één bepaald softwarebedrijf. De beslissing die moet worden genomen om al dan niet te migreren wordt dan ook vaak op basis van deze laatste genomen. Voor Capgemini is het niet echt een voordeel dat de broncode van JBoss vrij beschikbaar is. Voor klanten is het vooral een voordeel wanneer een applicatie in productie staat en er problemen opduiken. Men heeft dan namelijk de vrijheid om zelf tot op het laagste niveau van het systeem te gaan en te kijken waar het probleem zit om het op te lossen. Vaak is het zo dat wanneer er problemen zijn, de klant naar het softwarebedrijf moet gaan om het probleem te rapporteren. Bij sommige softwarebedrijven kan het lang duren vooraleer de klant wordt geholpen of er kan zelf een discussie ontstaan over de oorzaak van het probleem. 3. Financiële Stromen en Partnerprogramma Klanten kunnen op verschillende manieren in contact komen met de producten van een bepaald softwarebedrijf. Het softwarebedrijf heeft vaak een eigen sales- of presalesteam dat rechtstreeks naar bedrijven gaat en hen tracht te overtuigen om hun product te kopen. Een groot bedrijf dat geïnteresseerd is in WebSphere zal zijn aankoop ook niet doen via een reseller of integrator, maar die zal daarvoor IBM rechtstreeks benaderen. Een softwarebedrijf zoals IBM zal tegelijk de resellers aanmoedigen om bij klanten IBM te verkopen. De resellers worden door middel van referral vergoeding aangemoedigd en beloond wanneer een reseller bijvoorbeeld WebSphere kan verkopen. Referral vergoedingen worden betaald door zowel IBM, Oracle als Red Hat.
91
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 92
voor een reseller komt voort uit de diensten die gebaseerd zijn op een bepaalde technologie, maar komt niet uit de financiële vergoedingen binnen zo’n partnerprogramma. In de partnerprogramma’s zit er ook ondersteuning voor de resellers of system integratoren. Wanneer resellers aan een project werken bij een specifieke klant die nog geen ondersteuning heeft van het softwarebedrijf, kan de reseller de hulp inroepen van het softwarebedrijf in kwestie om problemen op te lossen. Wanneer Capgemini dan bij een klant komt om een project op te starten kunnen zij tonen dat ze bijvoorbeeld “advanced” partner zijn van JBoss Red Hat en dat zij ondersteund worden door JBoss Red Hat en dus recht hebben op ondersteuning binnen een bepaalde tijdsspanne wanneer er zich een probleem voordoet. Het is dus belangrijk voor een softwarebedrijf dat, wanneer alle andere softwarebedrijven ondersteuning aanbieden in hun partnerprogramma, je zelf ook ondersteuning aanbiedt aan partners. 4. Keuze en Strategie Voor Capgemini zijn dan de diensten die zij kunnen verkopen een belangrijke bron van inkomsten, zoniet zouden zij JBoss niet in hun aanbodpakket hebben. Maar over het algemeen geldt dat inkomsten uit marges en referral vergoedingen in functie van het totale project dat aan een klant wordt verkocht verwaarloosbaar zijn. Het is ook zo dat wanneer zij als “solution provider” een nieuwe toepassing moeten bouwen voor een klant, deze klant meestal al een licentie heeft, voor bijvoorbeeld WebSphere of JBoss. Het gebeurt dus zelden dat Capgemini een licentie voor een bepaalde applicatieserver verkoopt. In het beste geval kan het gebeuren dat de huidige licenties onvoldoende zijn. Dan moeten er bijkomende licenties worden gekocht omdat er meer gebruikers op aangesloten worden of omdat er meer functionaliteiten nodig zijn die nieuwe of meer licenties vereisen. Het verkopen van licenties is niet de core business, wel het verkopen van diensten. Voor Capgemini is de verhouding in een project doorgaans zeventig procent diensten en dertig procent licenties. Er kan een vergelijking worden gemaakt met een pc. Als men een pc aankoopt, zijn er wel een aantal dingen die direct werken, maar vaak moet men toch eerst een aantal dingen installeren, configureren... vooraleer de pc in gebruik kan worden genomen. Hetzelfde geldt voor een applicatieserver, eerst worden de bouwstenen of infrastructuur gekocht maar vooraleer de
93
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 94
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.
95
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.
96
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. 97
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.
98
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
99
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:
(10/05/2010)
100
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 101
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 102
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 103
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
104
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.
105
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.
106
Figuur 5: Financieel model Red Hat
Softwarebedrijf
Distributeur Diensten
Reseller Diensten
Betaling (-korting)
Eindklant Diensten
Betaling (-korting)
Partner voordelen Partner fee, training fee
Betaling
Uitlevering + support
Legende Dienstenstroom Financiële stroom
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 107
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.
108
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 109
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 110
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 111
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.
112
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
. (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.
VII
de Goede, P. (2010). Van een gedegen partnerstrategie profiteert iedereen. Opgehaald van . (27/04/10) Dixon,
J.
(2009).
The
Bees
and
the
Trees.
Opgehaald
van
. (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 . (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.
VIII
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
.(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. 10941104. 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 . (10/05/2010) Oracle. (2010a). Oracle and Sun. Opgehaald van . (24/04/2010) Oracle.
(2010b).
Sun
Customers
Oracle
Plans
To.
Opgehaald
van
. (24/04/2010) IX
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
. (25/04/2010) Pcmag.
(2010b).
Definition
of
managed
services.
Opgehaald
van
Pcmag.
(2010c).
Definition
of
OEM.
Opgehaald
van
. (25/04/2010) Pcmag.
(2010d).
Definition
of
reseller.
Opgehaald
van
. (25/04/2010) Pcmag.
(2010e).
Definition
of
solution
provider.
Opgehaald
van
. (25/04/2010) Pcmag.
(2010f).
Definition
of
systems
integrator.
Opgehaald
van
. (25/04/2010) Pcmag.
(2010g).
Definition
of
VAR.
Opgehaald
van
. (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.
X
Raymond,
E.
(1999b).
The
Magic
Cauldron.
Opgehaald
van
. (27/04/2010) Red Hat. (2010). Opgehaald van . (10/05/2010) Riehle, D. (2009). The Commercial Open Source Business Model. Opgehaald van . (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
. (25/04/2010) Software Top 100. (2009). Global Software Top 100 – Edition 2009. Opgehaald van . (24/04/2010) TechTarget.
(2008a).
OEM.
Opgehaald
van
. (25/04/2010) TechTarget.
(2008b).
VAR.
Opgehaald
van
. (25/04/2010) The
Eclipse
Foundation.
(2010).
About
the
Eclipse
Foundation.
Opgehaald
van
. (23/04/2010) The VAR Guy. (2009). The VAR Guy's Open Source 50 Disrupting and Redefining the IT Channel. Opgehaald van . (30/04/10)
XI
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 . (23/04/2010) Wilson, R. (2009d). The Apache License (v2) – An Overview. Opgehaald van . (23/04/2010) Wilson, R. (2009a). The GNU General Public License v2 – An Overview. Opgehaald van . (23/04/2010) Wilson, R. (2009b). The GNU Lesser General Public License v2.1 – An Overview. Opgehaald van . (23/04/2010) Wilson, R. (2009c). The Modified BSD License – An Overview. Opgehaald van . (23/04/2010) Wilson, R. (2009e). The Modified BSD License – An Overview. Opgehaald van . (23/04/2010) Wilson, R. (2009c). The Mozilla Public License – An Overview. Opgehaald van . (23/04/2010)
XII
Bijlage 1: Referenties Partnerprogramma’s Acquia (10/05/2010) Alfresco (10/05/2010) Digium (10/05/2010) IBM (10/05/2010) Microsoft (10/05/2010) MySQL (10/05/2010) Oracle (10/05/2010) Pentaho (10/05/2010) Red Hat (10/05/2010) SugarCRM (10/05/2010) Salesforce.com (10/05/2010)
XIII
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
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
Listing in Alfresco Website Catalog
Y
Y
Preferred Partner Listing
Y
Y
Use of Alfresco Logo
Y
Y
Access to Marketing Material
Y
Y
Enterprise Edition for internal education, testing, demos. Number of supported deployments.
Go-To-Market Benefits
XIV
R Press Release
Joint
Joint
Access to Alfrescoo Sales team ms
Y
Y
Joint Allfresco/Parttner Sales Campaigns C
Y
Y
Access to Hosted Alfresco A Neetwork for Demonstrati D ions and Evvaluations
Y
Y
Joint Coollateral
Y
Y
Joint Webinar W
Y
Y
Events - Co-Exhibiting & Spoonsorship Opportunitie O s
Y
Y
Partner Sales and Marketing M T Training
Y
Y
Resell royalty r on 11st line supp port
15%
20%
Sales Benefits B
30%
Resell royalty r on 11st & 2nd linne support Requirrements Abide by b Alfresco Network Certification C n Proceduress
Y
Y
Pentah ho: Reselleer Benefitss The Penntaho Reselller Partner Program is designed prrimarily forr organizatioons in emerrging geograpphies or whoo sell to speecific and taargeted verttical industries and wannt to capitalize on the demandd for Pentahho solutions in their targ get market. The prograam providess many beneefits in terms of visibility and a awaren ness, businesss developm ment, trainin ng, and disccounts. Marketting and Bu usiness Devvelopment
Gold Silvver Bronzee
Listing on Pentahoo.com partneer directory y
XV V
Press reelease suppoort
Program m support - content, speeaker, clien nt, and prom motion (depeending on thhe program m) and co-m marketing
Hands-o on Channell Sales manaager supporrt (>$50k neet deal)
Partnerr Enablement
Gold Silv ver Bronzee
Pentaho o sales mateerial and too ols
Step-by y-step on-bo oarding
Access to Pentaho Partner Porrtal
Evaluattion copies of o Enterprisse Edition for fo approvedd opportunitties
Annual agreement
Access to the Enterrprise Edition Forum
Consulttative Suppo ort (5 cases annually) - Customer Support Portal
Access to the Pentaaho Knowleedge Base
Access to Recorded Pentaho Web W Based Training seessions
Access to the Pentaaho Presales Technolog gy Demonsstration Porttal
XVII
Access to pre-releaase versionss of the Penttaho Produccts
Productt roadmap pplanning
2-day custom funcctional/pre-ssales trainin ng at Orland do headquarrters for up tto four ressources
(Pre) Saales Engineering suppo ort (approvaal by Pentahho, case by case) c
Software and Disccounts
Gold Silv ver Bronzee
Referraal fee (Pentaaho responsiible for salees process)
Discoun nt on Pentah ho productss
10%
20% 15% %
Internall use licensee, 6 CPU's BI B suite (no ot for resale))
Training discount
20% 10% %
Now th hat you havee a strong understandin u ng of the benefits conttact us abouut becoming g a Partner, making g sure to posst your area of interest in the comm ments field.
XVIII
Bijlage 3: Analyse Partnerprogramma’s
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
Middle ware Red Ha t-
Red Ha t-
Infrastr uctuur
Tabel 1
VOORDELEN algemene voordelen welkom pakket toegang tot een partner netwerk partner forum product marketing collateral en campagnes nieuwsbrief/regelmatig informatie vermelding in partnerlijst vermelding in een voorkeurslijst succesverhalen/case study toegang tot commercieel product voor intern gebruik Roadmap deelname aan een raadscollege mogelijkheid tot deelname aan evenementen en sponsoring (gezamenlijke) persberichten opleidingsvoordelen verkoops- en technische partner seminaries opleidingen productopleiding (via internet) verkoopsopleiding (via internet) korting op opleidingen korting op certificaten
1/2/3 1/2/3 1/2/3 1/2/3
1/2/3
1/2/3
2/3
1/2/3
2 6 1
2/3
2/3
4
1/2/3
3
1/2 1/2/3 1/2/3 1/2/3 1/2/3 1/2/3 1/2/3 1/2 1/2/3 1/2 2/3 2/3 2/3 1/2/3 1/2
2/3
1/2 1/2
1/2/3
1/2 2
6 3 3
2/3
1/2
4
3
1/2 1/2/3
1/2/3
1/2 1/2/3
2 1 1/2
4
2/3
3
1/2/3 1/2/3
2 1/2/3
1/2/3 1/2/3 1/2/3 1/2/3 1/2 2/3 2/3 1/2 1/2/3 1/2
1/2/3
2/3
2/3
1/2/3 1/2 1/2
2/3
4 2 4 7 1
XVIII
marketing voordelen product demonstratie (niet om te verkopen) templates en richtlijnen voor campagnes/marketing materiaal gebruik van partnerprogramma logo gebruik partnerprogramma logo met specialisatie kenmerk fysieke plaat die partnership level en specialisatie representeert partnerprogramma certificaat
1/2
1/2/3 2/3
2/3 1
1/2/3 1/2/3 1/2/3 2/3
2/3
1/2/3
2/3
1/2/3
2/3
3 1 2
1/2 1/2 2/3
1/2/3 2/3
2/3
3 2/3
3 3
2/3
2/3
2 2 2 2
1/2/3 2/3
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
Red Ha t-
Middle ware
Infrastr uctuur Red Ha t-
verkoopsvoordelen marge kortingen referral vergoedingen jaarlijkse vernieuwing van abonnementen toegang tot een sales team sales ondersteuning sales materiaal en tool lead distributie/lead referral/qualified leads lead/deal registratie mogelijkheid tot deelname aan een sales campagne partner manager speciaal bod verzoek samenwerking met consulting departement webinar verkoopscollateral
5 1 2
2/3
2/3
3
2/3
6 2 2
1/2
1/2/3 1/2/3 1/2
2/3
1/2/3 1/2/3 1/2 1/2/3 1/2/3 1/2 1/2/3
1/2/3
1/2/3
1 1
2/3
5
2/3
4
1/2/3
6
2/3
2/3
2
2/3
2/3
2
1/2/3 1/2/3
2/3
3
XIX
1/2 1/2/3 3
3
technische ondersteuning technische ondersteuning toegang tot kennis 1/2/3 1/2/3 korting op professionele 2/3 2/3 diensten professionele ondersteuning bij 2/3 ontwikkeling technische pre-verkoop 2/3 2/3 ondersteuning (via internet) 2/3 pre-verkoop contract 2/3
1/2/3 3
2/3
2/3
1/2/3 1/2/3
VEREISTEN invullen van een partnerprogramma 1/2/3 1/2/3 aanvraagformulier en profiel aanvaarden van de partnerprogramma 1/2/3 1/2/3 overeenkomst certificatie procedures volgen 1/2 jaarlijkse deelnamevergoeding 2/3 2/3 2/3 jaarlijks minimum inkomsten 2/3 2/3 doelen minimum aantal abonnementen, 2/3 hoeveelheid inkomsten minimum jaarlijkse inkomsten 1/2/3
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
Red Ha t-
Middle ware
Infrastr uctuur Red Ha t-
collateral Marketing Development Fund deelname aan een gezamenlijk marketingprogramma
3 4 1
2/3 2/3
1/2 2/3
3 5 2 1
3
2/3
4 2
1/2/3
1/2/3
2/3
1/2/3
3
1/2/3
5 1 5
2
1/2/3 1/2/3
3 1/2/3
3 1
XX
aantal partnerniveaus partnervergoeding per niveau 1 2 3 Legende
1/2/3 2/3
1
2/3
2
2/3
1
2/3
2/3
2/3
2/3
2/3
2/3
3
3
3
3
2/3
2 2/3
3 1
2/3
1/2/3
3
1/2/3
1 2/3
3
3
0 0 $ 980 $ 3200 $ 980 $ 3200
4 3
2/3 2/3
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Red Ha t-
Alfresc o
Middle ware
Infrastr uctuur Red Ha t-
minimum grootte van team minimum aantal getrainde verkoopsmensen minimum aantal technisch getrainde mensen minimum aantal gecertificeerde mensen jaarlijks (12 maandelijks) bedrijfsplan voorspelling actieve participatie in gefocuste marketing programma's minimum aantal aanwezigen bij een jaarlijkse master klas minimum aantal succesverhalen van klanten jaarlijks voorleggen minimum aantal tevreden klanten of tevredenheidcijfer aankopen van demo materiaal
2
3
3
0 $ 2000 $ 4000 $ 6000 * $ 12000
3
2
1
3
0 $ 2999
*
onderhandelbaar
1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
XXI
Frequen tie
1/2/3 1/2 1/2/3
Digium
1/2/3
MySQL
1/2/3
Pentaho
1/2/3
SugarC RM
Acquia
Alfresc o
Red Ha t-
Middle ware
Red Ha t-
Infrastr uctuur
Tabel 2
VOORDELEN algemene voordelen welkom pakket toegang tot een partnernetwerk / partnerforum mogelijkheid tot deelname aan een sales- of marketingcampagne nieuwsbrief/regelmatig informatie vermelding in partnerlijst vermelding in een voorkeurslijst succesverhalen/case study toegang tot commercieel product voor intern gebruik Roadmap mogelijkheid tot deelname aan evenementen en sponsoring (gezamenlijke) persberichten opleidingsvoordelen (verkoop- en technische)opleiding productopleiding (via internet) verkoopsopleiding (via internet)
2
2/3
2/3
1/2/3
1/2/3
1/2/3
1/2/3 1/2 1/2/3
2/3
1/2/3
2/3
2/3
1/2/3
2/3
6
2
3 3
2/3
2/3
1/2 1/2/3
1/2 1/2/3
1/2/3
1/2/3
1/2/3
1/2/3
1/2/3
1/2/3 1/2
1/2
4
3
1/2 1/2/3
1/2/3
3
1/2
1/2/3 1/2
7
3 1/2/3
1/2 2/3
1/2/3
2 1/2
4
2/3
1/2/3
3
2/3
1/2/3
5 2
1/2
4
XXII
verkoopsvoordelen marge kortingen referral vergoedingen toegang tot een sales team sales materiaal, tools en ondersteuning lead distributie/lead referral/qualified leads partnermanager marketing voordelen (product marketing) collateral en campagnes product demonstratie (niet om te verkopen) templates en richtlijnen voor campagnes/marketing materiaal gebruik van partnerprogramma logo partnerprogramma certificaat Marketing Development Fund technische ondersteuning technische ondersteuning toegang tot kennis korting op professionele diensten technische (pre-)verkoop ondersteuning (via internet)
2/3
2/3
1/2 1/2/3
2/3
1/2/3 1/2/3
2/3
2/3
1/2/3
2/3
3
3
2/3
2/3
1/2/3
1/2/3
1/2/3 1/2 1/2/3
1/2/3
1/2/3 1/2
1/2/3
1/2/3 1/2
1/2/3
1/2/3 1/2 1/2/3
1/2/3
1/2/3
3
3
2/3
2/3
2/3
2/3
1/2
7
2 2 2 3 2
2/3
5
3
2/3
6
2/3
2/3
7
2/3
2/3
5
2/3
4
1/2/3
6
2/3
3
2/3
4
2/3
3 5
3
1/2/3
Frequen tie
Digium
2/3
2/3
1/2/3
1/2/3 1/2/3
1/2
2/3 1 1/2/3
1/2/3
MySQL
Pentaho
2/3
1/2/3
1/2
2/3
SugarC RM
Acquia
Alfresc o
Red Ha t-
Middle ware
Infrastr uctuur Red Ha t-
korting op opleidingen
2/3 2/3
1/2
2 3
2/3
4
XXIII
2/3
2/3
2/3
2/3
1/2/3 2/3
1/2/3
2/3
1/2/3
3
1/2/3
6
2
5
1/2/3 2/3
1/2/3
Frequen tie
Digium
1/2/3 1/2
MySQL
1/2/3
Pentaho
1/2/3
SugarC RM
1/2/3
Acquia
Alfresc o
Red Ha t-
Middle ware
Infrastr uctuur Red Ha t-
VEREISTEN invullen van een partnerprogramma aanvraagformulier en profiel aanvaarden van de partnerprogramma overeenkomst jaarlijkse deelnamevergoeding jaarlijks minimum inkomsten doelen minimum aantal abonnementen, hoeveelheid inkomsten minimum aantal getrainde mensen (verkoop of technisch) minimum aantal gecertificeerde mensen jaarlijks (12 maandelijks) bedrijfsplan actieve participatie in gefocuste marketing programma's minimum aantal succesverhalen van klanten jaarlijks voorleggen
3 1/2/3
3
2/3
2/3
2/3
2/3
2/3
2/3
2/3
2/3
3
3
3
2/3
3
2/3
2/3
1/2/3
3
2 2/3
4
XXIV
3
2
Frequen tie
Digium
MySQL
Pentaho
SugarC RM
Acquia
Alfresc o
Middle ware Red Ha t-
Infrastr uctuur Red Ha t-
aantal partnerniveaus 3 3 2 3 3 partnervergoeding per niveau 1 0 0 0 $ 2000 2 $ 980 $ 3200 $ 4000 $ 6000 3 $ 980 $ 3200 * $ 12000 Legende
3
0 $ 2999
*
onderhandelbaar
1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
XXV
Sales force .com
Suga rCRM
Tabel 3
VOORDELEN algemene voordelen welkom pakket toegang tot een partnernetwerk / partnerforum mogelijkheid tot deelname aan een sales- of marketingcampagne nieuwsbrief/regelmatig informatie vermelding in partnerlijst vermelding in een voorkeurslijst succesverhalen/case study toegang tot commercieel product voor intern gebruik Roadmap mogelijkheid tot deelname aan evenementen en sponsoring (gezamenlijke) persberichten verkopen van technologieën opleidingsvoordelen (verkoop- en technische)opleiding productopleiding (via internet) verkoopsopleiding (via internet) korting op opleidingen korting op certificaten verkoopsvoordelen marge kortingen referral vergoedingen toegang tot een sales team
1/2/3
1/2/3
2/3
3 1/2/3 2/3 3 1/2/3 2/3
1/2/3
1/2/3 2/3 1/2/3
1/2/3
1/2/3
2/3
XXVI
marketing voordelen (product marketing) collateral en campagnes product demonstratie (niet om te verkopen) templates en richtlijnen voor campagnes/marketing materiaal gebruik van partnerprogramma logo partnerprogramma certificaat Marketing Development Fund distributie via een online marktplaats technische ondersteuning technische ondersteuning toegang tot kennis korting op professionele diensten technische (pre-)verkoop ondersteuning (via internet) gratis licenties onbeperkte ontwikkelings- en testomgevingen
2/3 1/2/3 2/3
Sales force .com
Suga rCRM
sales materiaal, tools en ondersteuning lead distributie/lead referral/qualified leads lead/deal registratie partnermanager
1/2/3 1/2/3 3
1/2/3 1/2/3
1/2/3
3 1/2/3
1/2/3 1/2/3
1/2/3 1/2/3
toolkit voor ontwikkeling en codebibliotheken
1/2/3
technische discussie fora technische support van de gemeenschap
1/2/3 1/2/3
VEREISTEN minimum klantentevredenheidscijfers invullen van een partnerprogramma aanvraagformulier en profiel aanvaarden van de partnerprogramma overeenkomst jaarlijkse deelnamevergoeding jaarlijks minimum inkomsten doelen
1/2/3
1/2/3 1/2/3 1/2/3
XXVII
aantal partnerniveaus partnervergoeding per niveau 1 2 3 jaarlijkse minimum inkomsten 1 2 3
1/2/3
Sales force .com
Suga rCRM
minimum aantal abonnementen, hoeveelheid inkomsten minimum grootte van team minimum aantal getrainde mensen (verkoop of technisch) minimum aantal gecertificeerde mensen jaarlijks (12 maandelijks) bedrijfsplan actieve participatie in gefocuste marketing programma's jaarlijkse sponsoring minimum aantal succesverhalen van klanten jaarlijks voorleggen
1/2/3
1/2/3
2/3 2/3
1/2/3
2/3 2/3 1/2/3
2/3
3
3
$ 2000 $ 6000 $ 12000 $ 10 000 $ 100 000 $ 300 000
Legende 1/2
voordelen voor partnerniveau 2 zijn groter dan partnerniveau 1 of vereisten voor partnerniveau 2 zijn strenger dan partnerniveau 1
XXVIII
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,
XXIX
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 XXX
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?
XXXI
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 XXXII
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 XXXIII
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 XXXIV
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 XXXV
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 XXXVI
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? XXXVII
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? XXXVIII
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 XXXIX
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 XL
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. XLI
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 XLII
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 XLIII
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. XLIV
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
XLV
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.
XLVI
Bijlage 5: Uitgetypt interview Realdolmen Sarah: Misschien kunnen we eerst beginnen met een beetje meer informatie over het bedrijf. Bijvoorbeeld hoe groot zijn jullie ongeveer, wat doen jullie allemaal? Mr De Pelecijn: Ja oké dat is goed. Om te schetsen wat ik doe... Ik zal misschien kort onze organisatie eens schetsen, dan weet je misschien beter waar ik juist werk, wat mijn rol is. Ik zal het commerciële luik van onze organisatie uitleggen. Dus we hebben VP Sales & Markting en daaronder heb je een salesstructuur en sales managers en account managers. Dat zijn hier teams die opgedeeld zijn per sector. Dus je hebt “verticals” waar dat bijvoorbeeld “healthcare” in is, industrie, enz ... en die account managers hebben elk dedicated klanten. Die hebben een lijst met klanten waarop ze hun cijfer moeten behalen. Daarnaast heb je een business development omgeving, ook terug met een aantal units, waarin dat ééntje infrastructuur is en één solutions, dan heb je nog een aantal andere zoals PSA, ... Wel ik zit dus hier (infrastructuur en solutions). Wij doen dus business development met drie collega’s. Ik doe alles wat data center is, dan is er eentje dat Front End doet en nog eentje Managed Services. In die teams naast business development zitten er ook nog een aantal solution sales, je hebt bv een BDMer, dat ben ik en dan een aantal solution sales die dan horizontaal, afhankelijk van hoe je het tekent. Die gaan dan de andere richting gaan werken. Dus een account manager heeft zijn vaste lijst, Dat zijn ‘zijn’ klanten en een solution sales, die gaat werken waar er klanten zijn. Ik doe dus business development voor alles wat datacenter is. Datacenter, infrastructuur en services dat is alles wat in de back office van een klant zit. Mijn collega die front end doet, doet alles wat met desktop te maken heeft en met printing, dus alles wat de eindgebruiker onder zijn vingers krijgt. Bekijk je het van desktop of vanuit back end? Sarah: Wel, ik kijk nu wel voornamelijk naar back end, maar een vergelijking tussen de twee is ook wel interessant. Mr De Pelecijn: Wel ja je hebt de twee, als je de keten bekijkt, je hebt een eindgebruiker zoals ik, in mijn firma ben ik een gebruiker, ik heb een pc, ik heb mijn applicaties in een netwerk in een datacenter. In dat datacenter heb je servers en applicaties draaien. Heel die ketting heeft een organisatie, die is even belangrijk maar in organisaties zoals de onze worden die apart benaderd, waarom? Je hebt andere kennis nodig om een pc te verkopen dan om bijvoorbeeld een datacenter. JBoss is dan echt de middelware om de applicaties te ontwikkelen die zich op een XLVII
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? XLVIII
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? XLIX
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 L
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? LI
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 ITverhaal 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.
LII
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 payroll 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 LIII
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
LIV
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 LV
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 LVI
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?
LVII
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 LVIII
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?
LIX
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.
LX
Bijlage 6: Uitgetypt interview Capgemini Sarah: Misschien kunnen we eerst beginnen met een beetje meer informatie over het bedrijf. Bijvoorbeeld hoe groot zijn jullie ongeveer, wat doen jullie allemaal? Mr. Eggenstein: Capgemini is een internationaal consulting bedrijf, actief in iets meer dan 30 landen over heel de wereld. Het werknemersbestand telt iets van een 90 000 mensen, waarvan iets meer dan één vierde in India vertoeft, dus ik denk een 20 à 25 000 mensen in India. Het is een Europees bedrijf met hoofdzetel in Parijs. Dus het tweede grootste aantal werknemers bevindt zich in Frankrijk dat zijn er een 20 000 tal en dan binnen Europa is het vooral Engeland en Nederland die een grote rol spelen. De rest zit vooral in de Verenigde Staten, Noord Amerika voornamelijk en dan heb je natuurlijk nog in een aantal landen zoals Nieuw Zeeland, Australië en Zuid Amerika, maar dat is vrij beperkt. In België is het allemaal iets kleiner, België is ook een kleiner land, daar zijn we momenteel met een 700 tal werknemers hier in Diegem als enige zetel. Eigenlijk de structuur van dit bedrijf is net zoals Capgemini wereldwijd georganiseerd is. Elk Capgemini land is op dezelfde manier gestructureerd, dus dat betekent dat er een CEO is en daaronder heb je dan een aantal, wat wij noemen, disciplines. Algemeen zijn er vier eigenlijk, je hebt de consulting discipline, dat is hier in België een 150 tal mensen, je hebt outsourcing dat is een vergelijkbaar aantal, laat ons zeggen tussen de 100 à 150. Consulting kan IT-consulting zijn, maar kan ook management-consulting zijn of fiscale-consulting, milieu-consulting, dus dat hoeft niet IT gerelateerd te zijn. Outsourcing is het volledige overnemen van applicatie en infrastructuur. Dan heb je nog twee disciplines, dat is Technology services en Financial services en tot twee jaar geleden was dat één unit, Technology services, daar hebben ze een afsplitsing gemaakt om specifiek op de financiële en verzekeringsmarkt te richten. Dus financial services is eigenlijk hetzelfde dan Technology services, maar dan specifiek voor die markt. De mensen die er werken en de kennis is eigenlijk hetzelfde als bij Technology services. Technology services is eigenlijk professionele dienstverlening rond IT. Dat is voornamelijk op de applicatie markt gericht, dus niet zozeer infrastructuur. Dus in België zijn we eigenlijk niet gericht op infrastructuur, een beetje bij outsourcing, maar dat is beperkt. Dus voornamelijk applicatie dienstverlening, dat gaat van mensen die bij de klant ter plaatse een bepaalde rol of kennis aanbrengen tot volledig staffen en uitvoeren van IT projecten. Daar komt het eigenlijk op neer. Technology services is een 450 tal mensen en Financial Services en 150 tal mensen. Ikzelf werk
LXI
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 OpenOffice 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 LXII
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 LXIII
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 LXIV
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 LXV
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 LXVI
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 LXVII
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 LXVIII
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 LXIX
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 LXX
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 LXXI
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 LXXII
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 LXXIII
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?
LXXIV
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 LXXV
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 LXXVI
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. LXXVII
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.
LXXVIII
***, die hadden Oracle application server en daar hebben wij de migratie gedaan. Die besparen nu jaarlijks honderdduizend euro aan licenties.
LXXIX
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 LXXX
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. LXXXI
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
LXXXII
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, LXXXIII
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 LXXXIV
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 LXXXV
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 LXXXVI
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.
LXXXVII
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 LXXXVIII
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 LXXXIX
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
XC
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 XCI
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 XCII
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.
XCIII
