Open Source Software Businessmodellen

UNIVERSITEIT VAN AMSTERDAM

Open Source Software Businessmodellen

Thesis Bachelor Informatiekunde Programma Business Information Systems Universiteit van Amsterdam Faculteit Natuurwetenschappen, Wiskunde en Informatica Faculteit Economie en Bedrijfskunde J.P.J. (Jeroen) Hannink Studentnummer: 0160660 [email protected] Datum: 25-08-2008 Begeleider: B.J. Smit


2


Samenvatting Commercie en open source software lijken in eerste instantie moeilijk verenigbaar. Echter niets is minder waar. Er zijn businessmodellen ontstaan en getest, waarmee het mogelijk is om een open source project tot een commercieel succes te maken. In dit onderzoek is gekeken naar de eigenschappen van commerciële open source software businessmodellen en hoe zij zicht verhouden tot elkaar en de omgeving waarin zij worden ingezet. Om iets over omgevingsfactoren te kunnen zeggen is gebruik gemaakt van het organisatiemodel van Robert Keidel. Deze driehoek beslaat een krachtenveld tussen de variabelen autonomie, coöperatie en controle. Aan de hand van literatuuronderzoek en casebeschrijvingen worden zeven businessmodellen gedefinieerd: optimization businessmodel, dual license businessmodel, consulting businessmodel, subscription businessmodel, patronage businessmodel, hosted businessmodel en het embedded businessmodel. Voor elk van deze modellen zijn aansprekende praktijkvoorbeelden aangehaald, die de eigenschappen en mogelijkheden van de respectievelijke modellen illustreren. Tenslotte worden de zeven businessmodellen, aan de hand van hun eigenschappen geplaatst in het organisatiemodel van Keidel. Hierbij wordt gekeken naar de eigenschappen van de afzonderlijke modellen en hun invloed op de variabelen autonomie, coöperatie en controle. Keywords Open source, propriëtaire software, businessmodel, softwarelicentie, linux, Keidel

3


Voorwoord I love deadlines. I like the whooshing sound they make as they fly by. Douglas Adams, auteur (1952 - 2001) Het onderzoek dat voor u ligt is tot stand gekomen in het kader van de Bachelor thesis opdracht, zoals die verstrekt wordt door de opleiding Informatiekunde, programma Business Information Systems aan te Universiteit van Amsterdam. Het was in 2003, het begin van mijn opleiding Informatiekunde, dat ik voor het eerst bewust in aanraking kwam met open source software: Mandrake Linux. Dit besturingssysteem werd op een oude PC gezet om “eens mee te klooien”. Vandaag de dag wordt er nog steeds “geklooid”, zij het met een ander Linux smaakje: Ubuntu Linux. Vanaf het eerste moment dat ik echt begreep hoe het open source principe werkte heeft het me gefascineerd. Hoe is het toch mogelijk dat een grote groep geëngageerde mensen over de gehele wereld – vaak letterlijk onbekenden van elkaar – zulke geweldige producten kunnen maken? Aangezien de commerciële open source software businessmodellen in opmars zijn en een duidelijk overzicht van de mogelijkheden ervan niet voorhanden is, besloot ik er mijn Bachelor Thesis onderwerp van te maken. Nu dat het onderzoek is afgerond, ligt hier – mijns inziens – een mooi overzicht van de verschillende businessmodellen. Uiteraard is deze scriptie niet geheel door eigen inzichten tot stand gekomen. Veel dank ben ik verschuldigd aan mijn scriptiebegeleider Bas Smit. Het kwam nogal eens voor dat ik een deadline heb gemist, echter stond Bas altijd klaar om het verhaal weer op het goede spoor te krijgen. Onze gedeelde interesse in open source software en alles wat daarbij hoort zorgde er meer dan eens voor dat de gesprekken soms wat afdwaalden, iets wat ik als een welkome afwisseling heb ervaren. Beste Bas: dat biertje gaat er zeker komen! Dank je wel!

Jeroen Hannink 25-08-2008

4


Inhoudsopgave SAMENVATTING

3

VOORWOORD

4

1.0 ONDERZOEKSOPZET

8

1.1 Inleiding

8

1.2 Probleemstelling

8

1.3 Methode

9

1.4 Relevantie

9

2.0 GESCHIEDENIS OPEN SOURCE SOFTWARE

10

2.1 Multics

10

2.2 Van Unics tot Unix

10

2.3 BSD

10

2.4 De Unix Wars

11

2.5 The Open Group

12

2.6 GNU

12

2.7 GNU GPL

12

2.8 Linux

13

2.9 De Kathedraal en de Bazaar

13

2.10 Linux en GNU

14

2.11 Van Broncode naar Distributies

14

2.12 Open source software

15

2.13 Open Source Definitie

15

2.14 Licenties

16

2.15 Definities

17

2.16 Conclusie

17

3.0 WAAROM OPEN SOURCE?

18

3.1 Aandacht voor open source

18

3.2 Motivatie

18

5

Open Source Software Businessmodellen 3.3 Kostenmodellen: propriëtair vs. open source

23

3.5 Strategische mogelijkheden OSS

24

3.6 Conclusie

24

4.0 OPEN SOURCE ALS BUSINESSMODEL

25

4.1 Platformen

25

4.2 Doelstelling open source project

26

4.3 Markt- en productanalyse

27

4.4 Licentiekeuze

29

4.5 Conclusie

31

5.0 OPEN SOURCE SOFTWARE BUSINESSMODELLEN

32

5.1 Optimization businessmodel

32

5.2 Dual license businessmodel

32

5.3 Consulting businessmodel

33

5.4 Subscription businessmodel

33

5.5 Patronage businessmodel

34

5.6 Hosted businessmodel

34

5.7 Embedded businessmodel

34

5.8 Conclusie

35

6.0 OPEN SOURCE BUSINESSMODELLEN IN DE PRAKTIJK

36

6.1 Optimization businessmodel

36

6.2 Dual license businessmodel

36

6.3 Consulting businessmodel

37

6.4 Subscription businessmodel

38

6.5 Patronage businessmodel

39

6.6 Hosted businessmodel volgens Google

39

6.7 Embedded businessmodel

40

6.8 Conclusie

41

7.0 ORGANISATIE EN STRATEGIE: EEN MODEL

42

7.1 Inleiding

42

6

Open Source Software Businessmodellen 7.2 Fouten en falen

44

7.3 Generieke organisatiestructuren

46

7.4 Conclusie

47

8.0 BUSINESSMODELLEN EN DRIEHOEKEN

48

8.1 Keidel vs. optimization businessmodel

48

8.2 Keidel vs. dual license businessmodel

49

8.3 Keidel vs. consulting businessmodel

50

8.4 Keidel vs. subscription businessmodel

51

8.5 Keidel vs. het patronage businessmodel

52

8.6 Keidel vs. hosted businessmodel

53

8.7 Keidel vs. embedded businessmodel

54

8.8 Conclusie

55

9.0 CONCLUSIE

56

9.1 De coöperatiebias

56

9.2 Leegtes

57

9.3 Uitbijters: hosteden patronage strategie

57

9.4 Tot slot

58

BRONVERMELDING

59

Bezochte websites

60

APPENDICES

61

Appendix A: Open Source Definition, versie 1.9

61

Appendix B: Linux distributies

64

Appendix C: Investeringen in open source software sinds 2000

65

7


1.0 Onderzoeksopzet 1.1 Inleiding Open source software (OSS) wordt in toenemende mate gebruikt als alternatief voor commerciële software (ook wel propriëtaire- of gesloten-bron software). Niet alleen de consument, maar ook het bedrijfsleven profiteert van deze opmars. Commerciële licenties staan onder druk en het vendor lock-in effect van commerciële marktleiders wordt geringer. Naast financiële voordelen zijn er ook voordelen op het gebied van ontwikkeling en organisatie-inrichting. Steeds meer IT ondernemingen ontplooien dan ook open source software projecten, die hun propriëtaire producten vervangen of complementeren. Zodoende profiteren zij van de positieve karaktereigenschappen van OSS en de financiële voordelen van commerciële activiteiten. Het commerciële karakter van de ondernemingen lijkt op het eerste gezicht moeilijk verenigbaar met het vrije en open karakter van de open source (OS) wereld. Echter, er is in de loop van de jaren een aantal businessmodellen ontstaan die dit mogelijk maakt. De focus van deze scriptie ligt bij deze businessmodellen.

1.2 Probleemstelling De probleemstelling die in deze scriptie centraal staat is die omtrent de ontplooiing van OSS activiteiten door commerciële softwareproducerende IT bedrijven. Om uiteenlopende redenen die in deze scriptie besproken zullen worden, willen steeds meer van dit soort ondernemingen open source software projecten ontplooien. Wanneer ondernemingen een OSS product in de markt zetten, zal dit product direct of indirect geld moeten opbrengen en dus rendabel moeten zijn. Men spreekt dan van de sustainability van een product. Open source en commercie lijken op het eerste gezicht tegenpolen. Dat is ook niet zo vreemd, aangezien ze dit jarenlang geweest zijn. Pas met de opkomst van het internet en de personal computer (PC), begin jaren negentig van de vorige eeuw, ontstonden de eerste samenwerkingsvormen. Ondernemingen die op een rendabele wijze ontwikkelings- en productiegewijs in zee willen met open source, zullen daarvoor, zoals zal worden aangetoond, een aantal aanpassingen in hun organisatiestructuur en bedrijfsvoering moeten doorvoeren. Problematisch hierbij is dat er een keur aan businessmodellen is, echter vaak zonder dat er rekening gehouden wordt met het karakter van de onderneming en de omgeving waarin een dergelijk model wordt ingezet. 1.2.1 Doelstelling In deze scriptie zullen de businessmodellen besproken worden die het proces van productie en verkoop van open source softwareproducten binnen commerciële ondernemingen op rendabele wijze faciliteert. Vervolgens wordt aan de hand van praktijkvoorbeelden gekeken hoe de businessmodellen zich in de realiteit houden. Het organisatiemodel van Keidel is het meest geschikt om de businessmodellen een plaats in het organisatiespectrum te geven. Tenslotte wordt aan de hand van deze gegevens een conclusie getrokken over de positie van de businessmodellen in Keidels driehoekige organisatiemodel.

8


De doelstelling van deze scriptie laat zich als volgt samenvatten: Het doen van een literatuuronderzoek naar de businessmodellen die de ontplooiing van OSS projecten door commerciële IT bedrijven mogelijk maakt. Hierbij wordt specifiek gekeken naar de positie van deze modellen in het organisatiemodel van Keidel. 1.2.2 Vraagstelling De vraagstelling, bestaande uit een hoofdvraag en deelvragen, zal hieronder worden toegelicht. 1.2.2.1 Hoofdvraag Naar aanleiding van de hierboven genoemde probleemstelling kan de hoofdvraag in dit onderzoek als volgt worden geformuleerd: Hoe verhouden commerciële open source software businessmodellen zich tot de omgeving waarin ze worden ingezet? 1.2.2.2 Deelvragen • Wat is open source software? • Wat is de motivatie achter open source software productie en distributie in een commerciële omgeving? • Hoe ziet, in het algemeen, een businessmodel voor software productie en exploitatie eruit? • Welke specifieke businessmodellen zijn er om open source software rendabel te produceren en te exploiteren? • Wat zijn de eigenschappen van het organisatiemodel van Keidel?

1.3 Methode Deze scriptie is tot stand gekomen aan de hand van literatuurstudie. Voor deze literatuurstudie is informatie en theorie aangaande het onderwerp verzameld en gefilterd op relevantie. Vervolgens wordt met behulp van een aantal casebeschrijvingen en het organisatiemodel van Keidel bepaald hoe de businessmodellen zich verhouden tot elkaar en de omgeving waarin ze worden ingezet.

1.4 Relevantie Het fenomeen open source software heeft sinds de jaren negentig flink aan terrein gewonnen. Niet alleen de consument maakt tegenwoordig veelvuldig gebruik van de software, ook het bedrijfsleven ziet het nut in de van de open bron. Naast het gebruik van OSS, is ook de productie er van erg aantrekkelijk. Steeds meer (grote) commerciële ondernemingen investeren in de productie van OSS. Er is een aantal modellen dat door deze ondernemingen gehanteerd kan worden om OSS op een verantwoorde, rendabele wijze te ontplooien. In de bestaande literatuur is niet of nauwelijks een totaaloverzicht terug te vinden van de bestaande modellen en hun impact op de onderneming. Deze scriptie vult die leegte op door een dergelijk overzicht te presenteren.

9


2.0 Geschiedenis open source software In dit hoofdstuk zal de ontstaansgeschiedenis, alsmede de groei van open source software worden beschreven, met alle facetten die daarbij komen kijken. Er zal antwoord worden gegeven op de eerste deelvraag uit de vraagstelling: “Wat is open source software?”

2.1 Multics De geschiedenis van open source software gaat terug tot de jaren zestig van de vorige eeuw (Bretthauer. 2002). Uit een samenwerking tussen Bell Labs (destijds de research en development afdeling van AT&T), het Massachusetts Institute of Technology (MIT) en General Electric, ontstond het besturingssysteem genaamd Multics (Multiplexed Information and Computing Service). Het ontwikkelingsteam van Multics bestond uit onder andere Ken Thompson (later bekend geworden als de geestelijk vader van Unix), Dennis Ritchie (later bekend geworden vanwege de door hem ontwikkelde programmeertaal C) en Fernando Corbató, een grote naam op het gebied van time sharing besturingssystemen (http://en.wikipedia.org/wiki/History_of_Open_Source). Corbato ontving in 1990 de Turing Award, een jaarlijks uit te reiken prijs voor een belangrijke bijdrage aan de “computing community”. Thompson en Ritchie gingen hem voor in 1983. (http://en.wikipedia.org/wiki/Fernando_J._Corbató http://en.wikipedia.org/wiki/Ken_Thompson_%28computer_programmer%29).

2.2 Van Unics tot Unix Aangezien het Multics project in meerdere opzichten uit de hand begon te lopen – de ontwikkeling nam teveel tijd en geld in beslag en het besturingssysteem werd te omvangrijk – besloot Bell Labs het project eind jaren zestig op te heffen. Multics werd overgenomen door Honeywell, die het product met wisselend succes in de markt zette. Thompson miste de Multics omgeving en begon zelf een besturingssysteem te ontwikkelen dat hij Unics (Uniplexed Information and Computing Service) – later Unix – noemde. Collega en goede vriend Dennis Ritchie legde in die periode de laatste hand aan zijn C programmeertaal. Het is belangrijk om te beseffen dat tot die tijd besturingssystemen in assembly (een zogenaamde low level programmeertaal) werden geschreven, om computers zo efficient mogelijk te laten werken. Thompson en Ritchie beseften echter dat computers steeds krachtiger werden, waardoor het voor het eerst mogelijk was om een besturingssysteem in C te schrijven. Dit maakte halverwege de jaren zeventig de weg vrij voor het eerste porteerbare besturingssysteem: Unix (vierde editie). Portabiliteit wil zeggen dat het besturingssysteem architectuuronafhankelijk te gebruiken is en de software op verschillende soorten systemen draait. Buiten het feit dat Unix binnen korte tijd zeer veel gebruikt werd bij Bell Labs, was – en is – Unix zeer populair in academische omgevingen. Universiteiten en onderzoeksinstituten konden vrij goedkoop licenties verwerven om Unix te mogen gebruiken. Overige, commerciële licenties waren veel duurder.

2.3 BSD In 1975 keerde Thompson tijdens een sabbatical jaar terug naar de Universiteit van Californie, Berkely, om daar les te geven. Hier ontstond een samenwerking met onder andere Bill Joy. Het was 10


Joy die in 1977 de eerste versie van de Berkely Software Distributie (BSD) vrijgaf. BSD is tegenwoordig een open source variant van Unix, met daarin de verbeteringen en modificaties die op Berkely werden ontwikkeld. BSD bevat geen originele code meer van Unix, alles werd volledig herschreven, hetgeen de deur opende voor de open source stap. Eind jaren zeventig werd de software voor een nominaal bedrag verkocht aan houders van een Unix licentie van Bell Labs. Nadat Bell Labs eind jaren zeventig werd opgesplitst en de licenties van Unix steeds duurder werden, sprong BSD in het gat dat Bell Labs achterliet en ging het BSD uitgeven met een open source licentie (de zogenaamde BSD licentie) (Bretthauer, 2002).

2.4 De Unix Wars Halverwege de jaren tachtig begon AT&T (als eigenaar van het vroegere Bell Labs en derhalve Unix) Unix commercieel te promoten. AT&T kwam er echter al snel achter dat de markt verzadigd was van allerlei aangepaste Unix klonen. Er brak een periode aan die de boeken in is gegaan als de “Unix wars”. AT&T ging een samenwerking aan met Sun Microsystems, een samenwerking onder de noemer “Unix International” (UI), teneinde Unix beter commercieel te kunnen exploiteren.

Figuur 1: Unix varianten (http://en.wikipedia.org/wiki/Image:Unix_history.en.svg)

In reactie hierop richtte de “Gang of Seven” – bestaande uit Apollo Computers, Groupe Bull, Digital Equipment Corporation (DEC), Hewlett-Packard (HP), IBM, Nixdorf Computer en Siemens AG, later sloten Philips en Hitachi zich aan – de Open Software Foundation (OSF) op om aan de greep van Unix International op de ontwikkeling van standaarden in Unix te ontkomen (http://en.wikipedia.org/wiki/Unix_wars).

11


2.5 The Open Group Unix International en de Open Software Foundation beseften halverwege de jaren negentig dat de grootste dreiging niet van elkaar uitging, maar van een relatief nieuwe speler op de softwaremarkt: Microsoft. In 1994 fuseerden de OSF en UI waarbij de naam Open Software Foundation behouden bleef. Twee jaar later, in 1996 fuseerde de OSF met de certificerings- en promotie-instantie voor open standaarden, X/Open, tot de The Open Group (TOG) (http://en.wikipedia.org/wiki/The_Open_Group).

2.6 GNU In 1971 solliciteerde Richard Stallman, software ontwikkelaar, en voortrekker van het “vrije software principe”, bij het MIT Artificial Intelligence Lab. Hier werkten hij en zijn collega’s voornamelijk met vrije software, die zij optimaliseerden door de broncode door meerdere personen te laten nakijken: open source softwareontwikkeling avant la lettre. Als begin jaren tachtig het Lab wordt opgeheven en de meeste collega’s gaan werken bij commerciële softwarebedrijven, besluit Stallman, als tegenreactie en op morele gronden, het GNU (GNU’s Not Unix) project te starten. Het doel van dit project is het ontwikkelen van GNU, een besturingssysteem bestaande uit vrije software dat compatible is met Unix (aangezien dit het meest gebruikte besturingssysteem was in die tijd). Het woord “vrij” heeft in deze zin betrekking op “vrijheid” en niet op “prijs”. Als gebruiker/ontwikkelaar van GNU software zijn er vier vrijheden (Bretthauer, 2002): • De software voor elk gewenst doeleinde gebruikt worden; • De software mag aangepast worden naar eigen wensen, aangezien de broncode beschikbaar is; • De aangepaste software mag geherdistribueerd (tegen een vergoeding of gratis); • De aangepaste softtware mag gedistribueerd worden, opdat de community kan profiteren van deze aanpassingen. In 1984 verlaat Stallman MIT om eventuele claims van de Universiteit op GNU te voorkomen. Wel mag hij gebruik blijven maken van de daar aanwezige IT faciliteiten. Een jaar later, in 1985, richt Richard Stallman de Free Software Foundation (FSF) op. De FSF ondersteunt en promoot het recht van computergebruikers om vrije software te gebruiken, te bestuderen, te kopieren, aan te passen en te herdistribueren. De stichting doet dit in het bijzonder voor het GNU besturingssysteem (Stallman, 1999).

2.7 GNU GPL Eind jaren tachtig ontwikkelt Stallman de eerste versie van de GNU General Public License (GNU GPL, of kortweg GPL). Dit is een universele licentie die men kan toepassen op software, ongeacht het karakter. Hierdoor wordt het mogelijk voor verschillende software projecten om onderling broncode uit te wisselen en bijvoorbeeld elkaars functies te gebruiken. De eerste versie van de GPL was gebaseerd op afzonderlijke licenties die Stallman had gecreëerd voor zijn GNU Emacs editor, GNU Debugger (GDB) en GNU Compiling Collection (GCC). Deze afzonderlijke licenties bleken echter niet compatible met elkaar. De GPL is viraal. Dat wil zeggen dat modificaties van de originele software en software die gelinkt is aan de GPL software ook onder de GPL moet vallen. Kort vooruitlopend op de volgende hoofdstukken is een probleem met een combinatie van OSS met propriëtaire software te voorzien. Anno 2008 is de GPL toe aan zijn derde versie (Stallman, 1999). 12


2.8 Linux Op 26 augustus 1991 liet een Finse student, genaamd Linus Benedict Torvalds, het volgende bericht achter op de nieuwsgroep comp.os.minix: “Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things). I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-) Linus ([email protected]) PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.” Torvalds had eerder Minix ontdekt, een besturingssysteem gebouwd door Professor Andrew Tanenbaum van de Vrije Universiteit te Amsterdam. Minix is een zeer eenvoudig besturingssysteem, gebaseerd op Unix en ontwikkeld voor educatieve doeleinden. Torvalds zag veel mogelijkheden voor verbetering en vroeg Tanenbaum in 1991 om toestemming de Minix broncode te gebruiken en aan te passen. Tanenbaum weigerde en Torvalds besloot derhalve zelf een Minixachtig systeem te schrijven, waarvan hij op 26 augustus 1991 melding maakte. De naam Linux werd voorgesteld door een systeembeheerder op de Universiteit van Helsinki. Torvalds wilde zijn creatie aanvankelijk Phreax noemen. Halverwege september 1991 werd versie 0.01 uitgebracht, vrij te downloaden vanaf de FTP server van de Universiteit van Helsinki. Vanaf versie 0.02 (december 1991), riep Torvalds geïnteresseerden op mee te helpen aan de ontwikkeling van Linux: “Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you finding it frustrating when everything works on minix? No more allnighters to get a nifty program working? Then this post might be just for you :-) ...” (Moody, 2002) Zo ontstaat, parallel aan het onstaan van Linux, ook de Bazaar-stijl software ontwikkelingsmethode, waarmee open source software in het algemeen, en Linux in het bijzonder, zo snel heeft kunnen groeien (Raymond, 2001).

2.9 De Kathedraal en de Bazaar Naar aanleiding van zijn observaties van het Linux project en zijn eigen Fetchmail (mailserver software) project beschrijft Eric S. Raymond in zijn essays (gebundeld in het boek: The Cathedral & The Bazaar. Musings on Linux and open source by an accidental revolutionary, 1999) twee ontwikkelingsmethoden: • Kathedraal-stijl ontwikkeling: de broncode wordt met elke release (het uitbrengen van een nieuwe stabiele versie van een programma) vrijgegeven. De code die tussen twee releases wordt ontwikkeld is voorbehouden aan een kleine groep ontwikkelaars. Deze software 13


ontwikkelingsmethode wordt ook toegepast bij propriëtaire software. De broncode wordt dan uiteraard niet gepubliceerd. • Bazaar-stijl ontwikkeling: De broncode is te allen tijde toegankelijk voor het publiek, aangezien het actief ontwikkeld wordt door een grote groep vrijwilligers. Het internet speelt hier een cruciale rol als communicatiemiddel. Het open en transparante karakter van de Bazaar-stijl leidt tot een groot voordeel wat Raymond omschrijft als “Given enough eyeballs, all bugs are shallow.”. Hij noemt dit fenomeen ook wel de “Wet van Linus”. Wanneer er veel programmeurs deelnemen aan de ontwikkeling en deze ontwikkeling in alle openheid plaatsvindt, worden zogenaamde “bugs” (fouten in het programma), sneller opgespoord en verholpen. Een voorwaarde hiervoor is dat de software vaak gereleased wordt.

2.10 Linux en GNU Linus Torvalds creëerde in zeer korte tijd een enorm momentum rondom de ontwikkeling van Linux. Feitelijk bestaat Linux uit de kernel, de softwarelaag die er voor zorgt dat hardware kan communiceren met applicaties (zie Fig. 2), en de GNU software, in de begindagen grotendeels geschreven door Richard Stallman. Stallman startte begin jaren negentig met zijn eigen ontwikkeling van een kernel (genaamd HURD), het laatste stuk software wat zijn GNU besturingssysteem mistte. Echter liep Stallman al snel achter de feiten aan: Torvalds’ Linux kernel ontwikkeling had veel meer aanhangers. Stallman heeft later toegegeven dat het aan Torvalds te danken is geweest dat zijn GNU software zo enorm populair is geworden.

Figuur 2: Kernel (http://en.wikipedia.org/wiki/Image:Kernel.png)

2.11 Van Broncode naar Distributies Er zijn in het algemeen twee manieren om Linux te installeren op een PC: • De Linux kernel en broncode van de gewenste software compileren; • Gebruik maken van een zogenaamde Linux distributie, waarin alle software pregecompileerd wordt aangeleverd (de zogenaamde binaries). Een distributie is een verzameling pre-gecompileerde software (een kernel plus applicaties) die wordt aangeboden onder één noemer, vergelijkbaar met een merknaam. Patrick Volkerding was in 1993 een van de eersten die een dergelijke distributie uitgaf: Slackware. Ook deed hij iets wat tot 14


dat moment onmogelijk werd geacht. Hij bood namelijk commerciële ondersteuning in de vorm van de verkoop van CD-ROM's, handleidingen en boeken. Voorbeelden van op dit moment populair zijnde distributies zijn: Red Hat, Suse, Ubuntu, Debian, Gentoo, Slackware, Mandriva, etc. In Appendix B is een overzicht te vinden van alle tot op heden bekende distributies.

2.12 Open source software Hoewel het principe achter open source software al jaren bestond, werd pas in 1998 de term “open source” geschikt bevonden om het principe te duiden. Een jaar eerder bracht Eric S. Raymond zijn bundel essays getiteld “The Cathedral and The Bazaar”, uit. In zijn essays beschrijft Raymond het systeem van gedistribueerde “peer-reviewing” (met het internet als katalysator) bij softwareontwikkeling: de eerder genoemde Bazaar-stijl. Mede naar aanleiding van deze, inmiddels beroemd geworden, essays, besloot Netscape in 1998 om de broncode van de Netscape Navigator browser openbaar te maken. Een werkgroep, waarin Raymond ook deelnam, begeleidde Netscape in dit traject. Om associaties met de ideologische term “free software” en de FSF van Richard Stallman te vermijden, werd de term “open source” in het leven geroepen. Niet veel later zag het Open Source Initiative (OSI) het levenslicht. Het OSI heeft als doelstelling de open source software op een pragmatische en marktvriendelijke manier te promoten en te ondersteunen. Het instrument dat het OSI daarvoor tot zijn beschikking heeft is de Open Source Definition (OSD). De OSD bestaat uit tien regels waaraan een softwareproject moet voldoen, wil het het certificaat “open source” krijgen. Zowel de Free Software Foundation als het Open Source Initiative kan overigens niet genoeg benadrukken dat er een wezenlijk verschil is tussen de twee organisaties. Stallman (FSF) omschrijft dit verschil treffend als volgt: “As one person put it, “Open source is a development methodology; free software is a social movement.” For the open source movement, non-free software is a suboptimal solution. For the Free Software movement, non-free software is a social problem and free software is the solution.” (http://www.gnu.org/philosophy/free-software-for-freedom.html) – of – “Open source is a development methodology; free software is a social movement.” (http://www.gnu.org/philosophy/open-source-misses-the-point.html) Het begrip dat in deze scriptie gehanteerd zal worden is “open source” zoals beschreven door het OSI in de Open Source Definitie. De term “free software” van Stallman’s FSF is in het kader van dit schrijven te moralistisch en gaat in op zaken die, met betrekking tot het onderwerp van deze scriptie, minder relevant zijn.

2.13 Open Source Definitie De OSD is het manifest voor vrije en open software. Alle open source softwarelicenties moeten voldoen aan de volgende punten (http://www.free-soft.org/mirrors/www.opensource.org/docs/osddutch.php): 1. Vrije herdistributie: De licentie mag geen enkele partij beperken in het verkopen of weggeven van de software als een component van een softwaredistributie die is samengesteld uit programma's uit meerdere verschillende bronnen. De licentie mag geen aandeel in de opbrengst of andere honorarium eisen voor zo'n verkoop. 2. Broncode: Het programma moet de broncode bevatten en moet de distributie van zowel broncode als in gecompileerde vorm toestaan. Als een vorm van het product wordt verspreid 15


zonder broncode, moet er een duidelijke manier worden aangegeven waarop de broncode tegen redelijke kosten kan worden verkregen – bij voorkeur gratis van het Internet te halen. De broncode moet de vorm hebben waarin de programmeur het bij voorkeur zou aanpassen. Opzettelijk vertroebelde broncode is niet toegestaan. Tussenvormen zoals uitvoer van een preprocessor of vertaler zijn niet toegestaan. 3. Afgeleide werken: De licentie moet aanpassingen en afgeleide werken toestaan, en moet toestaan dat deze worden verspreid onder dezelfde voorwaarden als de licentie van de originele software. 4. Integriteit van de broncode van de auteur: De licentie mag de verspreiding van de aangepaste broncode alleen beperken als de licentie de verspreiding van "patch files" met de broncode toestaat met als doel het programma aan te passen als het gebouwd wordt. De licentie moet verspreiding van software die met aangepaste broncode is gebouwd expliciet toestaan. De licentie kan eisen dat afgeleide werken een andere naam of een ander versienummer dragen dan de originele software. 5. Geen discriminatie van personen of groepen: De licentie mag geen enkel persoon of groep van personen discrimineren. 6. Geen discriminatie van toepassingsgebieden: De licentie mag niemand verbieden het programma te gebruiken voor een bepaald toepassingsgebied. Het mag het gebruik van het programma door bedrijven of voor genetisch onderzoek bijvoorbeeld niet verbieden. 7. Verspreiding van licentie: De rechten die aan het programma zijn verbonden moeten van toepassing zijn voor iedereen naar wie het programma wordt geherdistribueerd, zonder de verplichting voor die partijen om een additionele licentie uit te voeren. 8. licentie mag niet specifiek zijn voor een product: De rechten die aan het programma zijn verbonden mogen niet afhankelijk zijn van een speciale softwaredistributie waar het programma deel van uitmaakt. Als het programma uit die distributie wordt gehaald en wordt gebruikt of verspreid binnen de voorwaarden van de licentie van het programma, moeten alle partijen naar wie het programma is geherdistribueerd dezelfde rechten hebben als zijn toegekend in combinatie met de originele softwaredistributie. 9. De licentie mag andere software niet beperken: De licentie mag geen beperkingen plaatsen op andere software die samen met de gelicenseerde software is verspreid. De licentie mag bijvoorbeeld niet eisen dat alle software die op hetzelfde medium wordt verspreid open-source moet zijn. 10. De licentie moet technologie-neutraal zijn: Geen van de bepalingen van de licentie mag slaan op een bepaalde technologie of interface-stijl. De originele Engelse versie van de Open Source Definition is terug te vinden in Appendix A. Bovenstaande Nederlandse versie is een directe vertaling die niet is goedgekeurd door het OSI.

2.14 Licenties Om te garanderen dat OSS ook daadwerkelijk vrij en open blijft zijn er zogenaamde open source licenties in het leven geroepen. Open source licenties worden bepaald aan de hand van de hierboven genoemde Open Source Definitie. Elke licentie die gecertificeerd wordt als “open source licentie” voldoet aan alle tien punten van de OSD. In feite is een open source licentie een copyright licentie, waarbij het recht om software te mogen kopiëren intact is gelaten (copyleft). Tevens staan deze licenties het toe om de software waarop ze van toepassing zijn aan te passen en te herdistribueren, gratis of tegen een vergoeding. Het eerder besproken Open Source Initiative is de instantie die de inhoud van de OSD bepaalt, alsmede de licentie onderhoud en aanpast wanneer nodig. In tegenstelling tot de software waarop ze van toepassing zijn, zijn de licenties zelf niet open source. Zo is het bijvoorbeeld wel toegestaan om de GPL te kopiëren en te verspreiden, maar aanpassen van de inhoud is strikt verboden. Dit is uiteraard bepaald om ongewenste wijzigingen in de 16


licentievoorwaarden te voorkomen. Momenteel erkent het OSI 59 open source licenties, waaronder: Gnu Public License (GPL), (New) BSD License, Mozilla Public License, PHP License, Apache License, GNU Library/Lesser Public License (LGPL), etc. (http://www.opensource.org/licenses/alphabetical).

2.15 Definities Het voorgaande in acht nemend – en antwoord gevend op de eerste deelvraag – kan worden gesteld dat open source en commerciële software zich als volgt laten definiëren: • Open source software: “Open source is a software licensing model where the source code of the software is typically made available royalty-free to the users of the software, under terms allowing redistribution, modification and addition, though often with certain restrictions. [...] Open source programs are often, though not exclusively, developed through a collaborative effort in which a number of persons contribute elements of the final software. [...]” (Hiong 2005) • Commerciële software: “Commercial Software” is the model where the software developed by a commercial entity is typically licensed for a fee to a customer [...] The commercial entity often provides support, training, updates and other similar services needed by customers to efficiently use that software. The source code of the software may be made available to certain users of the software through special licensing or other agreements, but is usually not distributed to the general public, and may not be copied or modified except in a manner provided for in such agreements.” (Hiong 2005)

2.16 Conclusie Sinds het ontstaan in de jaren zestig is open source software van ver gekomen. Dankzij de komst en publieke acceptatie van het internet als communicatie- en informatiemiddel heeft de open source beweging een sterke groei doorgemaakt, vooral sinds het begin van de jaren negentig. Het belangrijkste en meest bekende open source project is Linux, in 1991 opgestart door Linus Torvalds, vandaag de dag onderhouden door duizenden mensen. Door de snelle groei en verspreiding van OSS werd de vraag naar juridische afbakening steeds groter. Dit leidde tot het ontstaan van de Open Source Definitie, aan de hand waarvan open source licenties worden gecertificeerd. Deze open source licenties sluiten financiële vergoeding voor de open source software niet uit, wat mogelijkheden biedt voor de commerciële exploitatie ervan.

17


3.0 Waarom open source? Waarom brengen commerciële softwareontwikkelaars open source producten op de markt? Zoals zoveel zaken in het internettijdperk is de populariteit van open source te danken aan een combinatie van hype en daadwerkelijke innovatie (Weber, 2004). In dit hoofdstuk zal worden besproken wat de redenen en motivaties van bedrijven zijn om aan open source projecten deel te nemen. De deelvraag die in dit hoofdstuk wordt beantwoord is: Wat is de motivatie achter open source software productie en distributie in een commerciële omgeving?

3.1 Aandacht voor open source Hoe is open source software in het vizier gekomen bij commerciële softwareproducenten? Deze toenemende aandacht voor de productie en commerciële exploitatie van de open-bron software is te danken aan drie factoren (Lerner, Tirole, 2000): • De snelle verspreiding van open source software. Open source producten als Linux en Apache hebben in relatief korte tijd een groot deel van de markt weten te veroveren op hun propriëtaire concurrenten (respectievelijk Windows en IIS, beiden van Microsoft); • De toenemende mate van investeringen in de sector. Grote bedrijven (zoals Hewlett Packard, IBM, Sun, etc.) en investeerders (met name venture capitalists) investeren substantiële bedragen in de open source community (Appendix C). Zo heeft onder andere het bedrijf Red Hat, dat een eigen distributie van het besturingssysteem Linux ontwikkelt en commercieel ondersteunt in het begin van deze eeuw een succesvolle beursgang gemaakt; • Innovaties in organisatiestructuur. De OS ontwikkelingsmethode, waarbij men gedecentraliseerd te werk gaat, is een drijvende kracht achter nieuwe innovatieve organisatiestructuren. Buiten deze externe, niet direct beheersbare factoren zijn er drie verschillende klassen van motivatie die bedrijven en individuen aanzetten tot deelname aan OSS productie. Deze klassen zijn te verdelen in drie categorieën (Bonaccorsi, Rossi, 2003): sociaal, economisch en technologisch. Een potentiële OSS producent maakt altijd zijn keuze voor deelname aan het OSS productieproces op basis van een combinatie van deze categorieën. Omwille van het non-technologische karakter van deze scriptie zal de factor technologie niet apart besproken worden. Wel komt deze factor aan bod binnen de bespreking van de overige twee factoren. In de volgende paragrafen wordt stil gestaan bij de motivatie van het individu en de onderneming.

3.2 Motivatie Een groot deel van de motivatie van bedrijven om open source projecten te ontplooien ligt besloten in de motivatie van de werknemers, de individuen. In de nu volgende paragrafen wordt zowel de motivatie van het bedrijf, als de motivatie van het individu besproken. 3.2.1 Motivatie individuen De redenen voor een individuele programmeur om deel te nemen aan een open source software project, zijn tweeledig: de intrinsieke en extrinsieke motivatie (Bonaccorsi, Rossi, 2003). Intrinsieke 18


motivatie is een vorm van motivatie die in economische termen “non-pecuniary” (Bonacorssi, Rossi, 2003) wordt genoemd. Dit houdt in dat er geen financieel gewin is, maar dat deelname op zichzelf een bepaalde voldoening geeft. Extrinsieke motivatie daarentegen, resulteert in direct, danwel indirect, financieel gewin. Intrinsieke motivatie: • Intellectuele stimulatie van de deelname aan een project. Voor veel programmeurs is het deelnemen aan een nieuw project een uitdaging voor het intellect. Deelname wordt gezien als een avontuur; • Open source software ontwikkeling zien als een kunstvorm. Er zijn programmeurs die programmeren als een kunstvorm zien. Hoe eleganter de code, hoe beter; • Hervonden creativiteit. Wanneer programmeurs de overstap maken van een commercieel softwarebedrijf, met een centraal geleide werkwijze en deadlines, naar een open source project, ervaren ze een gevoel van hervonden creativiteit; • Het bestrijden van de gezamenlijke vijand. Hoewel deze motivatie niet altijd opgaat, zien veel programmeurs de gesloten bron software als het kwaad dat moet worden bestreden met kwalitatief betere open source variant; • De filosofische overtuiging uitdragen dat software altijd vrij en open moet zijn. Dezelfde overtuiging die wordt uitgedragen door de Free Software Foundation van Richard Stallman; • Altruïsme. Hoewel deze motivatie niet geldt voor programmeurs die zich dag en nacht kostenloos inzetten voor OSS, is er een groot gedeelte van de OS programmeer-hobbyisten dat zich op geheel onzelfzuchtige wijze inzet voor anderen (Lerner, Tirole, 2000). Extrinsieke motivatie: • Signalling incentives. Dankzij het transparante karakter, niet alleen van de open source software, maar ook van de OSS markt, kan een programmeur eenvoudig laten zien wat zijn talenten zijn. Signalling incentives bestaan uit twee factoren: o Egoboost (Raymond, 2001). Iedereen in de markt weet (of kan op zijn minst uitzoeken) wie er verantwoordelijk is voor het maken van een open source softwareproduct. Een programmeur zal hierdoor in aanzien stijgen bij zijn collega’s; o Vooruitzicht op een (betere) carrière. Bedrijven die op zoek zijn naar talent, zullen de open source markt gebruiken om te kijken wie er boven het maaiveld uitsteekt. Heb je als programmeur talent en wordt je opgemerkt door een (groot) bedrijf, dan is de kans groot dat je daar een baan krijgt aangeboden. Signalling incentives worden sterker naarmate (Lerner, Tirole, 2000): • De bekendheid van de programmeur en het project bij relevant publiek groter wordt; • De impact van het project groter is; • De impact van het project iets zegt over het talent van de programmeur. Naast de signalling incentives is er nog een aantal redenen om deel te nemen aan een OSS project: • “Scratching a personal itch” (Raymond, 2001). Programmeurs zijn geneigd om software zo aan te passen dat het voldoet aan hun persoonlijke wensen. Deze motivatie ontstaat meestal uit ergernis over (het ontbreken van) een bepaalde functie in een softwarepakket. Heeft deze aanpassing een grote impact en bedient het een groot publiek, dan spreekt men van “Filling an unfilled market”; • Financiële vergoeding. Mocht er een bepaalde financiële vergoeding zijn voor de deelname een aan OSS project, dan zal een programmeur hier uiteraard ook door gemotiveerd worden. 19


3.2.2 Motivatie bedrijven De commerciële wereld van gesloten broncode en propriëtaire software is sinds het einde van de jaren negentig behoorlijk opgeschrikt door het succes van open source software. Veel bedrijven zien OSS als een nieuwe, innovatieve manier om software te produceren en tegelijkertijd ook als mogelijkheid voor de ontwikkeling van uitdagende en nieuwe businessmodellen. In deze paragraaf wordt de motivatie besproken die gebaseerd is op kosten- en prijsvoordelen die behaald kunnen worden met de productie en verkoop van OSS. Er zijn twee soorten open source te onderscheiden (Riehle, 2007): • Community open source: wordt onderhouden door een grote groep (community) vrijwilligers. Er is niet een duidelijke eigenaar van het project aan te wijzen. De community bepaalt welke ontwikkelingen de software moet ondergaan en welk traject er gevolgd wordt; • Commerciële open source: wordt ontwikkeld door – en is eigendom van – een zogenaamde “for-profit” organisatie. De rechten van het project liggen bij deze organisatie en zij bepaalt de ontwikkelingsstrategie en te volgen trajecten. Zakelijke consumenten in de IT wereld zijn doorgaans op zoek naar totaaloplossingen: “solutions” (Riehle, 2007). Een dergelijke solution bestaat uit een zogenaamde “IT-stack” (Figuur 3) van hardware, software en services. De consument wil graag met één partij zaken doen die alle drie de lagen van de stack als één pakket kan aanbieden. Wanneer zo’n aanbieder (een “system integrator”) niet zelf de hardware en software in productie heeft, zal hij deze inkopen. De bovenste laag van services levert hij zelf en daar zit voor hem de dan ook de marge. Een aanbieder die voor zijn producten gebruik gaat maken van OSS, behaalt dankzij het uitblijven van licentiekosten voor propriëtaire software, een winstvoordeel (Figuur 3b). Tevens vergroot hij zijn afzetmarkt door middel van flexibele prijzen (Figuur 4b). De winst die een aanbieder maakt is afhankelijk van de eenheden uit de IT-stack die hij zelf produceert en de eenheden die hij moet inkopen. De focus ligt hierbij meestal op de services-laag, die de hardware- en softwarelaag moet integreren. Doordat de harden software wordt ingekocht, wordt een deel van de winst gedeeld met de leveranciers hiervan. Een aanbieder van solutions zal derhalve altijd op zoek gaan naar zo voordelig mogelijk in te kopen hardware en software. Open source software biedt in dit geval een uitkomst, aangezien het goedkoper is dan de propriëtaire tegenhanger. Figuur 4 toont de overstap die een system integrator maakt van propriëtaire software naar open source software. Aangezien er geen licentiekosten zijn, kan er op de software laag extra winst worden gemaakt. In tegenstelling tot wat men zou vermoeden wordt deze kostenbesparing niet altijd doorberekend naar de klant. Dit heeft twee redenen (Riehle, 2007): • Een consument/klant bestelt een totaalpakket van hardware, software en services en niet de afzonderlijke diensten; • Grote solutions projecten zijn vaak zo complex dat er een natuurlijke barrière is om deze markt te betreden. Concurrentie is derhalve niet erg groot. De aanbieder kan het zich gewoonweg permitteren. Door de overstap naar open source software betreedt de aanbieder een grotere afzetmarkt. Er vanuit gaande dat hardware en software worden ingekocht, bestaat de prijs die hij aan zijn klanten doorberekend uit de servicekosten plus de marge. De bovenste laag uit de figuren 3 en 4 is dus 20


variabel. Afhankelijk van deze prijs is er een bepaalde afzet op de “customer demand curve”. Figuur 4b, de situatie met OSS, geeft aan dat de aanbieder meer speelruimte heeft als het gaat om de flexibiliteit van zijn prijzen. Dankzij deze speelruimte verschuift het punt op de vraagcurve naar rechts, hetgeen resulteert in meer afzet. De situatie waarin OSS gebruikt wordt is nog positiever voor de aanbieder wanneer hij zelf ook de hardware en/of software (open source dus) produceert. In dat geval heeft hij marges op alle drie de lagen uit het model. De system integrator heeft over het algemeen het liefst dat alle software open source is. In dat geval is namelijk het bedrag dat voor software betaald wordt door de klant volledig bij te schrijven als opbrengst voor de servicelaag. Het zou dan wel moeten gaan om community OSS, aangezien commerciële OSS een lock-in creëert, waarbij een consument afhankelijk wordt gemaakt van het product van een bepaalde aanbieder. Daarnaast kan alleen community OSS een zuivere marktwerking garanderen, waarbij reële prijzen tot stand komen

Figuur 3: Vraagcurve IT solutions (Riehle, 2007)

21


Figuur 4: Marge en bereik (Riehle, 2007)

Afgezien van de voordelen van kostenbesparing op licenties en de daar uit volgende prijsconcurrentie ten opzichte van een commerciële marktleider, is er nog een viertal voordelen te onderscheiden voor bedrijven die deelnemen aan OSS productie (Lerner, Tirole, 2000). 1. Standaardisatie IT componenten. Deelname aan het standaardiseringproces van open source IT componenten is zeer aantrekkelijk voor een onderneming. In de relatief jonge markt van de open standaarden wordt nog steeds erg veel ontwikkeld. Met een inbreng in dat proces is het mogelijk om de standaard een bepaalde kant “op te sturen”, die aantrekkelijk is voor de onderneming. Tevens zullen software en standaarden zo beter op elkaar aansluiten, hetgeen de ontwikkelingskosten van een bepaald project zal doen verminderen. 2. Complementeren/compatibiliteit. OSS kan door commerciële softwaremakers gebruikt worden om hun bestaande propriëtaire software te complementeren, of er voor te zorgen dat beide softwareproducten compatible zijn. Zo kan een onderneming er voor zorgen dat haar software relevant blijft, ook op de open source markt. 3. Customization en bug fixing. Productiekosten zijn lager als de gefixde bugs ook de programmeur en het bedrijf helpen. Kostenreductie wordt op deze manier direct gelinkt aan de openheid van de broncode. 4. Alumni effect. Het voordeel van werken met open standaarden en open software is dat de ontwikkelaars vaak al getraind zijn in het gebruik ervan. Komend van universiteiten en onderzoeksinstellingen waar vaak exclusief met OSS wordt gewerkt, kennen de meeste programmeurs alle “ins en outs” van de software en methoden die gehanteerd worden bij de ontwikkeling commerciële OSS. Op deze manier worden op indirecte wijze kosten bespaard op opleiding van het personeel. Een ander voordeel van de ervaren programmeur, is dat er minder snel beginnersfouten zullen worden gemaakt.

22


3.3 Kostenmodellen: propriëtair vs. open source In de voorgaande paragrafen en hoofdstukken is aangehaald dat OSS in productie en distributie een goedkopere oplossing is dan propriëtaire software. Is dat eigenlijk wel zo? 3.3.1 Situatie propriëtaire software In de commerciële softwaremarkt liggen de hoogste kosten bij de ontwikkeling en de distributie van de eerste versie van een softwareproduct. Daarna nemen de gemiddelde productie- en distributiekosten af en stijgt de winst per eenheid die wordt verkocht. De additionele kosten van de productie van een extra eenheid is laag. Het bedrijf dat deze investering heeft gedaan verdient zijn geld dus terug met stijgende en continuerende verkoop. Wanneer een markt voor een bepaald softwareproduct volwassen is, zal (Riehle, 2007): • • • •

De investering voor het onderhouden en doorontwikkelen van dat product hoog zijn; De barrière om toe te treden tot deze markt hoog zijn; De speler (spelers) op deze markt een gevestigde naam hebben (macht!); Het prijsniveau van het softwareproduct stabiel zijn.

De eerste twee punten uit de bovengenoemde situatieschets doen vermoeden dat er in een dergelijk geval sprake is van een monopolie of een oligopolie, waarbij respectievelijk één bedrijf c.q. een klein aantal bedrijven de markt beheerst. Kleinere ondernemingen die in dezelfde markt zitten opereren meestal in de niches. De marktleider stelt een prijsniveau waarbij het zijn winst maximaliseert. Deze prijs is standaard voor elke klant en zal niet afnemen naarmate er meer van het product verkocht wordt (Figuur 5b). De prijs is niet direct afhankelijk van de kosten die gemaakt moeten worden om de software te ontwikkelen, onderhouden en distribueren. De marktleider hoeft concurrentie niet te vrezen, aangezien de investeringen die nodig zijn om te markt te betreden een te grote barrière zijn.

Figuur 5: Verschillen in kosten en verkoopprijzen (Riehle, 2007)

23


Figuren 5a en 5c laten een overzicht zien van de gemiddelde kosten per eenheid voor propriëtaire software en open source software. Beiden hebben een vergelijkbaar verloop. Het onderscheid wat hier moet worden gemaakt is dat de kosten in Figuur 5a voor rekening van één onderneming zijn en dat de kosten in Figuur 5c gedeeld worden door alle ondernemingen die deelnemen aan de ontwikkeling van het product. Figuren 5b en 5d laten de verkoopprijs per eenheid zien die aan de klant wordt doorberekend. Opvallend daarbij is dat de verkoopprijs in een open source omgeving, onderhavig aan marktwerking, een dalend verloop heeft, naarmate er meer van een product verkocht wordt. De prijs van een eenheid propriëtaire software wordt kunstmatig hoog gehouden. 3.2.2 Situatie open source software In de OSS markt is geen sprake van een toetredingsbarrière. Men ontwikkelt een product en kiest vervolgens een licentie die verkoop toestaat. Er wordt hier eigenlijk geen software verkocht – die is immers open source en vrij toegankelijk – maar services zoals ondersteuning en onderhoud. Omdat iedereen kan toetreden tot de OSS markt is de concurrentie erg sterk. Het prijsniveau bestaat uit de kosten plus marge en is afhankelijk van de hoogte van de kosten. Als de marge te hoog is, zullen concurrenten ontstaan die een lagere prijs vragen voor hun product. Is de marge echter te laag, dan is het niet rendabel om in de markt te blijven opereren en zullen ondernemingen zich er uit terugtrekken. Prijsvariatie treedt ook op door de betrokkenheid van ondernemingen bij een OSS project. Bedrijven die meer investeren in een project (code, geld, tijd) kunnen een hogere prijs aan hun klanten berekenen, aangezien zij gespecialiseerder zijn.

3.5 Strategische mogelijkheden OSS Naast een kostenvoordeel biedt open source software ook strategische voordelen. De prijsafhankelijkheid van de kosten is een groot voordeel van OSS. Wanneer een onderneming goedkoper weet te produceren, door op kosten te besparen, kan een meer competetieve prijs gevraagd worden aan de klant. Met dergelijke lagere prijzen zal de afzet stijgen. Propriëtaire software kent een dergelijk prijsafhankelijkheid niet en zal daarom niet in staat zijn om zo flexibel met verkoopprijzen om te gaan. Hier ontstaat voor ondernemingen die een open source product maken een mogelijkheid om bij een marktleider langszij te komen. De risico’s en initiële investeringen zijn kleiner, zodat de barrière die voor een commerciële (gesloten bron software producerende) onderneming gelden, niet – of in mindere mate – aanwezig zijn. In feite biedt dit mogelijkheden voor elk bedrijf dat niet de marktleider is in een bepaalde softwarecategorie. Bovenstaande wil echter niet zeggen dat het voor elke open source software onderneming mogelijk is om de marktleider van zijn troon te stoten. Onder andere de sterke bescherming van (intellectuele) eigendomsrechten, in combinatie met kapitaal, lock-in-effect en allerlei overige (juridische en financiële) tactieken maken dat een commerciële onderneming zich weerbaar kan opstellen.

3.6 Conclusie Het vrije karakter van open source software doet vermoeden dat het niet in aanmerking komt om strategisch ingezet te kunnen worden in de softwaremarkt. Echter; niets is minder waar. Dankzij kostenvoordelen bij de productie van de software kan een softwareproducent flexibele prijzen bieden aan zijn klanten. Dit in tegenstelling tot de “fixed price” strategie van grote commerciële marktleiders. Redenen op sociaal, economisch en technologisch gebied motiveren zowel bedrijven als individuen om bij te dragen aan de ontwikkeling en verkoop van open source software. 24


4.0 Open Source als businessmodel Ongeacht het karakter van een softwareproject zal een producent, alvorens de markt te betreden, een gedegen plan moeten hebben met betrekking tot de exploitatiestrategie, ofwel het businessmodel. In dit hoofdstuk zal worden gekeken naar de algemene ingrediënten voor een dergelijk model en welke keuzes er gemaakt moeten worden. In het volgende hoofdstuk wordt vervolgens een overzicht gepresenteerd van de verschillende mogelijkheden die zo’n business model biedt: de zeven businessmodellen die commerciële productie en exploitatie van open source software mogelijk maken. Een aantal vragen waar een producent antwoord op moet hebben, voordat hij de markt betreedt met zijn softwareproduct is (Behlendorf, 1999): • • • •

Welk platform gebruikt de software? Wat is de doelstelling van de software? Wat wordt er aangeboden en is er vraag naar? (markt/productanalyse) Welke licentie wordt er gebruikt?

De antwoorden op bovenstaande vragen zullen in de conclusie van dit hoofdstuk worden samengevat tot een antwoord op de derde deelvraag: Hoe ziet, in het algemeen, een businessmodel voor software productie en exploitatie eruit?

4.1 Platformen Een platform is een collectie van software met vaste routines en regels, die aan de basis staat van elk softwareproduct. Een softwareproduct is gemaakt voor één specifiek platform, of voor meerdere platformen (men spreekt in dat geval van een “cross-platform-software”). Een voorbeeld van zo’n platform is Win32, voor het Windows besturingssysteem. Wanneer een product ontwikkeld wordt voor Windows, dan wordt de Application Programming Interface (API) gebruikt van het Win32 platform. Zonder al te diep op de technische details in te gaan kan een API als volgt gedefinieerd worden: “Een Application Programming Interface (API) is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma […]” (http://nl.wikipedia.org/wiki/Application_Programming_Interface). In feite definieert een platform de software die er voor geschreven is (Behlendorf, 1999). Zo draait de bekende internetbrowser Internet Explorer, niet op de besturingssystemen Mac OSX (van Apple) of Linux, maar alleen op Microsoft Windows. Een voor de hand liggend businessmodel is er één waarbij een onderneming geld verdient aan de eigendom van een platform. In een dergelijk geval kan het evengoed mogelijk zijn dat het derden wel is toegestaan software te maken voor dit platform. Op een platform kan dus copyright rusten, hetgeen betekent dat het niet mag worden verspreid of aangepast, zonder toestemming van de eigenaar (dit is het geval met Microsofts Win32). Er zijn echter ook publieke platformen, waar geen copyright op rust en waarvoor geen specifieke eigenaar aan te wijzen is. Een voorbeeld hiervan is de Common Gateway Interface (CGI), een webserver protocol dat door de jaren heen ontwikkeld is door de gemeenschap (community). Het bovengenoemde businessmodel heeft vooral op de korte termijn voordelen. Er wordt een softwareproduct ontwikkeld op een propriëtair platform en de klant betaalt per installatie. Tot zover 25


lijkt alles goed te gaan. Echter ontbreekt het hier aan een lange termijn visie die ontwikkeling van het product en afzet in de toekomst garandeert. Dankzij het propriëtaire karakter van de software is het niet mogelijk voor externe bedrijven om deel te nemen aan de ontwikkeling ervan. Denk bijvoorbeeld aan Mircosoft Windows. Dit besturingssysteem wordt volledig door Microsoft ontwikkeld. Andere softwarebedrijven, hoewel capabel en wellicht in het bezit van betere technologieën, mogen dankzij de gesloten bron en een loopgravenstelsel aan licenties en copyrights daar niet aan deelnemen. Daarnaast worden klanten door de jaren heen steeds afhankelijker van een platform. Bij het uitkomen van een nieuw (beter) product zal de consument elke keer de beslissing moeten nemen om bij het platform te blijven, dan wel over te stappen naar een nieuw platform. Dit dilemma is gebaseerd op marginaal hogere kosten, waarbij het platform behouden blijft, of behoorlijk hogere kosten, waarbij gewisseld wordt van platform. Een dergelijke switch kan op de lange termijn echter wel voordelig uitpakken. Aangezien dit een keuze is die een gebruiker niet regelmatig wil maken zal hij platformafhankelijkheid (ook wel vendor lock-in) willen voorkomen. Het baseren van producten en dienstverlening op gestandaardiseerde platformen, draagt bij aan de stabiliteit van het eindproduct. Een goed voorbeeld hiervan is het internet, dat een vast en te overzien aantal standaarden kent, waarmee ontwikkelaars uit de voeten kunnen. Zou het internet gebaseerd zijn op een groot aantal obscure en propriëtaire standaarden, dan was het maar de vraag geweest of het een groot succes was geworden.

4.2 Doelstelling open source project Een bedrijf dat een open source project wil starten, zal zich moeten afvragen op welk platform het open source product betrekking heeft en in hoeverre het bedrijf er bij gebaat is dat platform in bezit te hebben, of daar invloed op uit te oefenen (Behlendorf, 1999). Voorbeeld (Behlendorf, 1999): Een onderneming is gespecialiseerd in het maken van databases. Het databaseproduct draait op meerdere besturingssystemen. Naast de database zelf verkoopt het bedrijf allerlei extra's zoals grafische beheertools, ontwikkelingstools, etc. Support wordt op jaarbasis verschaft en upgrades aan het databasesysteem worden tegen betaling geleverd aan de klant. Daarnaast heeft het bedrijf een consultancy tak die de software implementeert bij klanten. Een overzicht van de omzet is als volgt:

Figuur 6 - Mogelijke onderdelen omzet softwarebedrijf

26


• • • • • • •

Verkoop databasesoftware: 40% Support: 15% Consultancy: 10% Verkoop ontwikkelingstools: 10% Verkoop grafische beheertools: 10% Verkoop extra features t.b.v. de databasesoftware: 10% Verkoop handleidingen, etc.: 5%

Een overgang van de databasesoftware naar het open source domein lijkt in eerste instantie niet verstandig, aangezien het 40% van de omzet bedraagt. Het kan echter ook anders uitpakken. De aanvullende producten op de databasesoftware zullen verkocht blijven worden, ongeacht of de database open source is of niet. Een voordeel van de overstap naar de open source variant van de database is dat meer klanten met het product in aanraking komen. Stel dat in de nieuwe situatie de database twee keer zoveel gebruikt wordt. Blijft de verkoop van de overige producten en diensten op een gelijk niveau, zal er, ondanks het kosteloos verstrekken van de database, een omzetstijging plaatsvinden van 20% (oude situatie is 100%, nieuwe situatie is 2*(100%-40%) = 120%). Naast een omzetstijging is het in een open source scenario waarschijnlijk dat de software sneller wordt ontwikkeld en dat eventuele fouten sneller worden opgespoord en verholpen door de gebruikerscommunity. Innovaties komen voort uit gebruikers die hun aanpassingen aan de software weer ter beschikking stellen aan het project. Zoals eerder besproken, leidt dit tot kostenbesparingen op de ontwikkeling en het onderhoud. De onderneming hoeft zich in dit scenario geen grote zorgen te maken over concurrentie. In een markt waarin deze databasesoftware al een tijd bestaat zijn zullen er ongetwijfeld ook concurrenten zijn die er complementerende producten voor hebben gemaakt (denk bijvoorbeeld aan handleidingen, how-to's, extra modules, etc.). De openbaarmaking van de broncode van de databasesoftware zal niet leiden tot een verslechtering van de concurrentiepositie aangezien de onderneming, als producent van de database, de beste naam in de markt heeft om complementerende diensten en goederen te verzorgen. Er zijn echter niet alleen voordelen. Om een, van nature, gesloten bron project open te maken kan het noodzakelijk zijn de organisatie waarin dit project wordt ontwikkeld anders in te richten. Tevens zal de broncode geheel nagelopen moeten worden en voorzien worden van commentaar en documentatie, zodat deze straks ook begrijpelijk is voor de community. Tenslotte zijn er de juridische kosten van de begeleiding naar het open source domein (zoals onderzoek naar de juiste keuze open source licentie, etc.).

4.3 Markt- en productanalyse Het kan voor een bedrijf zeer aanlokkelijk zijn om een open source project te zien als een manier om snel een groot publiek te bereiken, of om de ontwikkeling van een lopend (en meestal uitgemolken) softwareproduct uit handen te geven. Echter zijn dit niet de beweegredenen die aan de basis staan van succesvolle OSS trajecten. Een gedegen markten productanalyse is noodzakelijk, wil een overstap naar de open source wereld slagen. Ten eerste zal bepaald moeten worden hoe het eigen product in de markt staat ten opzichte van concurrerende producten (open source, danwel commercieel). Daarbij moet het hele softwarespectrum bekeken worden, niet alleen de grote spelers. Ten tweede is het verstandig om het eigen product in onderdelen te bekijken en te bepalen welke onderdelen er commercieel uitgebuit kunnen worden, en welke onderdelen er “ge-open sourced” worden. Daarbij is het ook mogelijk om de verschillende onderdelen te koppelen. 27


Het kan voor een ontwikkelaar niet altijd duidelijk zijn op welk gebied er ruimte is om een open source project te ontplooien. Hiervoor zijn echter wel aanwijzingen uit de markt te verkrijgen. Zoals eerder beschreven is het voor een OSS project van belang dat het in beweging blijft. Zodra er niet meer actief gereleased wordt, het leiderschap van het project valt weg, of er is onenigheden over de visie op de ontwikkeling van de software, dan laat de community van een dergelijk project het meestal ook vrij snel afweten. Dit zijn vaak de momenten dat er een zogenaamde “fork” plaatsvindt. Een fork is een nieuw softwareproject dat is afgescheiden van een origineel project. Zodoende ontstaat eigenlijk een nieuw project, op de grondvesten van een ander project. Dit nieuwe project gaat dan verder onder een eigen naam, nieuwe voortrekkers en een schare gebruikers die de originele software de rug toekeert (Raymond, 2001). Zeker in de open source wereld is het ontstaan van een fork een controversiële aangelegenheid, die meestal gepaard gaat met het nodige moddergooien. Wanneer een open source software project momentum verliest kan het voor een softwareproducent een mooi moment zijn om een eigen open source alternatief de markt te laten betreden en de aandacht van de gebruikers te trekken. Buiten het feit dat dit een mooie buitenkans is om een project te lanceren, is de vraag naar het product natuurlijk de meest belangrijke factor om in kaart te brengen. De vraag naar software kan erg voor de hand liggen in een open source omgeving. In een situatie waarbij een commercieel product tussen twee of meerdere open source lagen in zit, wordt de roep om een publiek alternatief voor die commerciële laag groter. In andere woorden: open source heeft een hekel aan een (commercieel) vacuüm (Behlendorf, 1999). Voor bijna elk commercieel software product is er tegenwoordig een open source alternatief. Wanneer een softwareproducent overweegt aan een open source software project deel te nemen (of op te starten), kan hij er voor kiezen om zich bij een gelijkwaardig project aan te sluiten. Zo worden tijd, kennis geld en code door de diverse deelnemers aan het project gedoneerd. Dit levert de volgende voordelen op (Behlendorf, 1999): • • •

Hogere kwaliteit van het product; Marketingtechnische voordelen (populair); Bijdragen aan de ontwikkeling van platformen en standaarden.

Ondanks deze voordelen zal eerst bepaald moeten worden of het uitvoeren van een dergelijk project acceptabel is. Daarbij zal voornamelijk de nadruk moeten worden gelegd op de licentievorm van het project: • Komen de licentievoorwaarden overeen met de gestelde doelen voor het project? • Is het mogelijk om code te doneren aan het project onder de geldende licentievoorwaarden? • Blijven de ontwikkelaars gemotiveerd met de geldende licentievoorwaarden? Zo niet, is het dan mogelijk om de licentie te wijzigen naar een vorm, waarbij de motivatie groter is? Daarnaast is het van belang een paar zaken met betrekking tot samenwerking en de opzet van het project helder te krijgen: • Is de te doneren code algemeen genoeg om van waarde voor het project en zijn gebruikers te zijn? • Is de samenwerking met de overige ontwikkelaars goed en kunnen de overige ontwikkelaars ook goed met elkaar overweg? Leiding geven aan een open source software project is niet zo eenvoudig als het misschien in eerste instantie lijkt. Het tevreden houden van programmeurs vergt veel aandacht. Zo zien ze graag hun mening over de opzet van het project en de architectuur van de software terug in de uitvoering 28


ervan. Datzelfde geldt uiteraard voor stukken code die door de verschillende programmeurs worden geschreven. Het kan voorkomen dat de ontwikkeling van een project parallel plaatsvindt, waarbij meerdere programmeurs zich bezig houden met hetzelfde stuk code. Als leider van een softwareproject, moet dus de keuze voor implementatie van een van deze codevarianten gemaakt moeten worden. Andere programmeurs moeten dan worden teleurgesteld (Behlendorf, 1999, Raymond, 2001).

4.4 Licentiekeuze Zoals al eerder duidelijk is geworden, is er in het open source spectrum een behoorlijk aantal licenties dat men van toepassing kan laten zijn op de ontwikkelde software. Het maken van een keuze voor een specifieke licentie is vaak een ingewikkeld karwei, waarbij de hulp van een ervaren juridisch adviseur dan ook niet geschuwd dient te worden. In deze paragraaf zullen kort de drie meest voorkomende licentietypes besproken worden, die interessant kunnen zijn voor commerciële doeleinden: de GNU General Puplic License (GPL), GNU Lesser General Public License (LGPL) en BSD License. De Artistic License wordt bijna altijd in combinatie met een andere licentie gebruikt (dual licenses), daarom wordt deze licentie hier buiten beschouwing gelaten. Onderstaand overzicht wordt met regelmaat gepubliceerd door het Open Source License Resource Center, onderhouden door Black Duck Software.

Figuur 7 – Actuele overzichtstabel (augustus 2008) gebruik open source licenties (http://www.blackducksoftware.com/oss)

29


4.4.1 GNU General Public License De GNU General Public License is een licentie die het de gebruiker van de software – waarop de licentie van toepassing is – toestaat de software te wijzigen, (her)distribueren of zelfs te verkopen, zolang de originele ontwikkelaars van de software worden genoemd en de software altijd de GPL blijft houden, zodat degenen aan wie de software gedistribueerd wordt, dezelfde rechten krijgen. Daarnaast is het verplicht om de broncode openbaar te maken. Zo worden wijzigingen als het ware terug gegeven aan de community en de originele ontwikkelaars. Zelfs in de situatie waarin nieuwe delen aan de software zouden worden toegevoegd, dan stelt de GPL dat het ook daarop van toepassing is. Men zou kunnen zeggen dat de GPL een virale licentie is, waarbij alle wijzigingen en toevoegingen aan de software automatisch onder de GPL vallen (http://www.gnu.org/licenses/oldlicenses/gpl-2.0.html). Uit de bovenstaande tabel kan worden opgemaakt dat er verschillende versies van zowel de GPL als LGPL zijn. Versie 2.0 van de GPL en versie 2.1 van de LGPL zijn op dit moment veruit het populairst. Dit heeft twee redenen. Ten eerste werd versie 3.0 van beide licenties (beiden door de Free Software Foundation ontwikkeld en onderhouden) op 29 juni 2007 uitgegeven. Het overstappen op een nieuwe licentie is een uiterst nauwkeurig proces en dat vergt nu eenmaal tijd. Ten tweede is versie 3.0 van beide licenties niet onomstreden (Asay, 2008). • Digital Rights Management (DRM). DRM is een elektronische beveiliging op software, die het de gebruiker onmogelijk maakt om kopieën te maken. Versie 3.0 van de GPL stelt dat DRM niet gebruikt mag worden op code waarop de licentie van toepassing is. Dit kan echter een probleem zijn bij software projecten waar bijvoorbeeld een leverancier eist dat DRM juist wel gebruikt wordt. • Patent rechtszaken. In 2007 sloten Microsoft en Linux ontwikkelaar Novell een strategisch verbond. Dit verbond was op zijn minst opmerkelijk te noemen, aangezien Microsoft van mening is dat Linux inbreuk maakt op een aantal van Microsofts patenten. Later maakte Microsoft bekend dat het gebruikers van Novell producten niet gaat vervolgen in verband met deze vermeende patent inbreuken. Ook kondigde Microsoft aan dat andere Linux gebruik wel ten prooi kunnen vallen aan de grillen van Microsoft. GPL versie 3.0 wil de dreiging van dit soort rechtszaken opheffen door een aantal regels op te stellen waar een organisatie die de GPL versie 3.0 gebruikt zich aan moet houden. Uiteraard is dit vanuit een business oogpunt zeer beperkend. • Teruggeven aan de community. In de GPL (zowel versie 2.0 als 3.0) staat dat eventuele wijzigingen aan de ontwikkelaars en community teruggegeven moeten worden, mits deze wijzigingen gedistribueerd worden. In versie 3.0 van de GPL wordt geprobeerd om deze situatie helemaal af te dichten. Een goed voorbeeld in dit geval is Google. Google gebruikt erg veel aangepaste GPL software, dat het niet distribueert. Volgens versie 2.0 is het dus niet verplicht om het terug te geven. Het product dat Google maakt en aanbiedt aan zijn klanten is een webservice waarmee gezocht en gevonden kan worden op het internet. GPL versie 3.0 zegt hiervan dat zij deze services distribueren en derhalve verplicht zijn om de wijzigingen die zij aan de GPL software hebben gemaakt terug te geven. Uiteraard roept deze licentiewijziging veel tegenstand op. 4.4.2 GNU Lesser General Public License De GNU Lesser General Public License werd origineel bedoeld voor zogenaamd software libraries (een collectie van routines en subroutines waarop software draait en ontwikkeld wordt) en wordt vaak omschreven als een combinatie van de GPL en BSD licenties. In feite werkt de LGPL 30


hetzelfde als de GPL, met het verschil dat de LGPL niet viraal is. Alle software die gelinkt is aan LGPL software wordt niet verplicht om ook onder deze licentie te vallen. Zo kan software met een LGPL gebruikt worden in een programma met een andere licentie. Zo’n programma mag zelfs onder welke licentie dan ook gedistribueerd worden. Zelfs voor software libraries wordt vaak aangeraden de normale GPL te gebruiken. Echter kan de aanwezigheid van het virale aspect uit deze licentie, plus de hevige concurrentie van vergelijkbare software libraries er voor zorgen dat een GPL library uit de markt gedrukt wordt. In een dergelijk geval wordt dan de LGPL toegepast (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html). 4.4.3 BSD License De BSD licentie wordt vandaag de dag onder andere gebruikt voor verschillende Apple software producten en, uiteraard, de BSD gebaseerde besturingssystemen zoals NetBSD, FreeBSD en OpenBSD. Deze licentie staat een gebruiker van de software toe om de software aan te passen en er mee te doen wat hij wil (dus ook (her)distribueren en verkopen). De enige voorwaarde is dat de originele ontwikkelaars van de software genoemd worden in bijvoorbeeld een README bestand dat meestal bij dit soort software te vinden is. Zo kan het voorkomen dat open source software met een BSD licentie geheel of gedeeltelijk terug is te vinden in een commercieel software product. Voor ondernemingen die een bestaand open source project overnemen of sponsoren kan dit een hele praktische oplossing zijn. Enerzijds wordt de onderneming geholpen door de community met het doorontwikkelen van de software. Anderzijds is er de mogelijkheid om de software ook commercieel te exploiteren. Het nadeel van deze licentie is het feit dat het nergens verplicht wordt om wijzigingen openbaar te maken of terug te geven aan de originele ontwikkelaars en de community. Zo kan het voorkomen dat er gebruikers zijn die belangrijke wijzigingen maken aan de software, zonder dat deze wijzigingen gedeeld worden.

4.5 Conclusie In dit hoofdstuk is gekeken naar de mogelijkheden van open source software als een business model. Elke onderneming, of het nou een commerciële of open source software producten exploiteert, maakt een aantal keuzes die het businessmodel beïnvloeden. Hierbij is het bij een open source softwareproject van belang om te bepalen welke invloed je als ontwikkelaar of distributeur op een bepaald platform kunt uitoefenen. Ook doelstellingen met betrekking tot het productspectrum spelen een grote rol. Uiteraard kan hierbij een markten productanalyse niet achterblijven. Tenslotte wil een startende open source onderneming een passende software licentie die voldoet aan de huidige en toekomstige omstandigheden.

31


5.0 Open source software businessmodellen In dit hoofdstuk zal dieper worden in gegaan op het open source businessmodel, waarvan de basisonderdelen in het vorige hoofdstuk zijn besproken. Er zal hier worden gezocht naar een antwoord op de vraag: Welke specifieke businessmodellen zijn er om open source software rendabel te produceren en te exploiteren? Er zal zijn zeven generieke businessmodellen die een onderneming kan gebruiken om een open source project commercieel te ontplooien (Koenig, 2004) (Lawton, 2008) (Hohensohn, et al, 2003): • • • • • • •

Optimization businessmodel Dual license businessmodel Consulting businessmodel Subscription businessmodel Patronage businessmodel Hosted businessmodel Embedded businessmodel

5.1 Optimization businessmodel Bij dit business model staat het principe van de stacks, zoals besproken in hoofdstuk 3, centraal. Een stack bestaat doorgaans uit de combinatie van hardware, software en services. Echter kan een dergelijke opstelling ook uit willekeurige combinatie van één of meerdere van de drie genoemde factoren bestaan. Bij een optimalisatiemodel wordt er altijd uitgegaan van één laag (in dit geval een OSS laag) die zo aan te passen is – te configureren is – , dat de andere lagen uit de stack optimaal functioneren. Deze configureerbare laag van open source software kan beschouwd worden als een commodity en zal voor de aanbieder in de regel niet erg winstgevend zijn (Koenig, 2004). De aangrenzende lagen, van bijvoorbeeld hardware of overige software, zijn dat echter wel. Zoals aangetoond in figuur 4 uit hoofdstuk 3, kan een aanbieder van dergelijke producten zijn marge vergroten door een configureerbare OSS laag in zijn product te verwerken.

5.2 Dual license businessmodel Bij een dual license model, biedt een softwarebedrijf twee of meerdere versies van zijn product aan. Hierbij gaat het meestal om een gratis variant, met enkele restricties en een uitgebreide betaalde variant. De betaalde variant kent meestal extra features en ondersteuning vanuit de producent. De restricties die op de gratis versie van de software van kracht zijn, verplichten dat aanpassingen, die aan de software gedaan worden, gedistribueerd moeten worden – ook in broncodevorm. Hierdoor wordt het voor derde partijen onmogelijk om op basis van de OSS een eigen commercieel product te maken. Er is bij een dual license model geen sprake van een geïntegreerde licentie, die de lading van beide versies van de software dekt. In het algemeen is er bij de vrije (gratis) variant sprake van de in hoofdstuk 2 besproken GNU General Public License (GPL). De uitgebreide – en betaalde – variant krijgt doorgaans een standaard commerciële licentie mee.

32


De vraag die nu rijst is waarom een producent voor het weggeven van een deel van zijn software zou kunnen kiezen. De keuze voor een vrije en gratis versie van een softwareproduct, draagt bij aan een snelle verspreiding en acceptatie van de software. Daardoor wordt de concurrentiepositie versterkt ten opzichte van commerciële alternatieven. Een grotere gebruikersgroep, die door de GPL licentie in staat wordt gesteld de broncode te bekijken en te wijzigen, draagt bij aan een snellere doorontwikkeling en verbetering van het product. Ook mag een gebruiker de software voor eigen, intern, gebruik aanpassen en gebruiken, iets wat onder commerciële licenties verboden is. De dual license model levert inkomsten op uit de complementaire producten en diensten, zoals onderhoud, training, consulting, extra features, etc. Dit staat lijnrecht tegenover de commerciële softwareproducenten die veel geld investeren in het werven en houden van klanten. Dit business model kan gebruikt worden om een marktpositie te verwerven en te behouden (Koenig, 2004).

5.3 Consulting businessmodel In de afgelopen decennia heeft er binnen veel IT afdelingen en software producerende ondernemingen een verschuiving plaatsgevonden van het (door)ontwikkelen van software, naar het bieden van ondersteuning en services. Zoals bij het vorige businessmodel is aangetoond, leent OSS zich uitstekend voor een servicegericht business model. Of het nu OSS betreft of niet, investeringen in softwarelicenties blijven tegenwoordig ver achter bij investeringen in consulting en dienstverlening (Koenig, 2004).

5.4 Subscription businessmodel Bij dit business model betaalt de gebruiker van de software per een bepaalde termijn een bepaald bedrag. In ruil hiervoor ontvangt hij ondersteuning op de software die hij gebruikt. Een opmerkelijke kanttekening die hier bij moet worden gemaakt is dat de software voor iedereen vrij te gebruiken en gratis verkrijgbaar is. Het verschil in ondersteuning zit tussen gebruikers zonder abonnement en gebruikers met abonnement is het niveau van ondersteuning. Deze ondersteuning bestaat uit drie niveaus: • Consumenten zonder abonnement: een eindgebruiker zonder abonnement, die wel gebruik maakt van de software kan nergens aanspraak op maken. Hij krijgt alleen ondersteuning in de vorm van meest kritieke updates (i.v.m. veiligheid, etc.). • Consumenten met abonnement: een eindgebruiker met abonnement heeft recht op updates, patches en klantenservice. • Businesses: een businessgebruiker, wiens abonnementsgelden vaak hoger zijn dan die voor de reguliere consument, heeft recht op updates, patches en – veel belangrijker – ondersteuning bij implementatie en configuratie van de software. Daarnaast wordt er bij business gebruikers veel aandacht besteed aan training en opleiding. Voor veel bedrijven die gebruik maken van OSS is deze abonnementsvorm een uitkomst als het aankomt op aansprakelijkheid en verantwoordelijkheden met betrekking tot zogenaamde “missioncritical” systems. Deze systemen zijn verantwoordelijk voor het (voort)bestaan van een bedrijf en wanneer er besloten wordt dat deze systemen vervangen worden door OSS alternatieven, dan moet de aansprakelijkheid voor dergelijke systemen goed geregeld zijn.

33


5.5 Patronage businessmodel Waarom zou een softwarefabrikant tijd, moeite, ontwikkelaars, geld en code aan een open source project besteden? Veel bedrijven die op welke wijze dan ook bijdragen aan een open source project doen dat vanwege het feit dat zij betrokken kunnen zijn bij de (door)ontwikkeling van standaarden en platformen en daarnaast de mogelijkheid hebben om “opgesloten” markten open te breken. Met een bijdrage aan een onafhankelijk OSS project, verwacht een bedrijf dat er om dat project een bepaald momentum ontstaan van gebruikers en standaarden die het project, en dus in zekere zin het bedrijf, trouw blijven. Zoals al vaker vermeld, speelt ook het feit dat een enthousiaste gemeenschap rondom een softwareproject veelal verantwoordelijk is voor een snelle ontwikkeling en verbetering van een softwareproject. Een andere optie is het reduceren van een bepaalde laag uit de softwarestack (zie hoofdstuk 3) tot een commodity (een algemeen verkrijgbaar gestandaardiseerd goed). Hiermee wordt de concurrentie met het commerciële alternatief voor deze laag direct benadeeld. De “patron” (hoeder) kan in zo’n geval op de overige lagen (hardware, services, overige software) zijn winst behalen. Om te slagen met een patronage businessmodel, moet een bedrijf echter meer doen dan alleen een bijdrage leveren (hetzij in tijd, geld, code of ontwikkelaars). Leiderschap en continuïteit zijn zeer belangrijk (Koenig, 2004).

5.6 Hosted businessmodel Het interne gebruik van open source software staat bij dit model centraal. Bedrijven kunnen open source software gebruiken en doorontwikkelen voor eigen, intern, gebruik, zonder dat ze verplicht zijn om deze aanpassingen te delen. Het werkelijke product dat aan de consument wordt aangeboden is gebaseerd op deze open source laag, en wordt meestal aangeboden in de vorm van services. Vaak merkt (of weet) de eindgebruiker weinig tot niets van het bestaan van deze OSS basislaag. Het voordeel voor de producent is dat hij gebruik kan maken van een reeds bestaand product, dat hij naar eigen wensen kan uitbreiden en doorontwikkelen. Vanwege het feit dat de producent de open source laag niet commercieel inzet of verspreidt, hoeft hij, dankzij de GPL, zijn aanpassingen niet wereldkundig te maken. Dit businessmodel levert dus grote voordelen op met betrekking tot ontwikkelingskosten en stabiliteit van de open source softwarelaag (Koenig, 2004).

5.7 Embedded businessmodel In steeds meer elektronische gebruiksvoorwerpen, zoals DVD spelers, PDA’s, mobiele telefoons, mediaspelers, etc. wordt open source software gebruikt. Producenten die voor dit soort apparaten OSS gebruiken kunnen vertrouwen op een relatief eenvoudig uit te breiden softwarepakket met ruime ondersteuning. Daarnaast kan aanzienlijk bespaard worden op ontwikkelingskosten. De meerwaarde van een commercieel product is in deze markt nihil, aangezien een open source variant geen enkele functionaliteit ontbeert ten opzichte van propriëtaire software.

34


5.8 Conclusie Zoals in dit hoofdstuk besproken is, is er een aantal manieren waarop open source software commercieel ontplooid kan worden. Open source kan in een commerciële omgeving gebruikt worden om hogere omzetten te genereren, concurrentievoordelen te behalen, en nieuwe producten en services te ontwikkelen. Een aantal van de in dit hoofdstuk genoemde modellen vertonen gelijkenissen met business modellen in de commerciële softwaremarkt, terwijl anderen heel specifiek gebruik maken van de nieuwe mogelijkheden die open source software biedt. Vanwege het jonge karakter van het fenomeen commerciële open source software is het uiteraard heel goed mogelijk dat er in de toekomst meer businessmodellen bijkomen of dat bestaande businessmodellen verdwijnen. Dat is geheel afhankelijk van de ontwikkelingen op het OSS terrein en de drive waarmee naar nieuwe mogelijkheden wordt gezocht die open source software op een rendabele manier commercieel kunnen maken.

35


6.0 Open source businessmodellen in de praktijk Dit hoofdstuk verschaft inzicht in de praktijk van de eerder genoemde open source businessmodellen. Veel van de organisaties die in dit hoofdstuk worden genoemd hanteren meerdere open source businessmodellen. Ter illustratie van de mogelijkheden van elk van de afzonderlijke businessmodellen is steeds gezocht naar de meest duidelijke en uitgesproken voorbeelden. Dat een bedrijf bij één van de businessmodellen wordt genoemd, wil dus niet zeggen dat het exclusief van dat businessmodel gebruik maakt.

6.1 Optimization businessmodel IBM is het grootste informatietechnologiebedrijf ter wereld. IBM heeft vestigingen in meer dan 70 landen waar in totaal zo’n 350.000 mensen werken voor klanten in zo’n 174 landen (http://www.ibm.com/ibm/nl/organisatie.html). Het bedrijf is gespecialiseerd in het ontwikkelen van hardware, software en services. Daar waar voor de eeuwwisseling de nadruk lag op de ontwikkeling en verkoop van harden software, is de bedrijfsvoering anno 2008 voornamelijk toegespitst op integrerende services die beide factoren met elkaar verbinden. Al bijna 10 jaar is IBM een van de grootste spelers in de open source software omgeving. Met de opkomst van Linux als besturingssysteem, en de acceptatie ervan door klanten van IBM, zag het bedrijf de potentieel van Linux als een besturingssysteem dan geschikt was (of kon worden gemaakt) voor alle IBM hardware platformen. De ondersteuning van IBM ten opzichte van Linux zorgde voor acceptatie van het open source besturingssysteem onder de brede klantenkring: “Linux is veilig en stabiel zijn, aangezien IBM erachter staat”. Anno 2008 neemt IBM deel aan meer dan 150 verschillende open source projecten, waaronder de Apache webserver software, de Eclipse ontwikkel omgeving en het besturingssysteem Linux (Pezzini, 2008). IBM hanteert een aantal open source businessmodellen, waaronder het patronage businessmodel, het subscription businessmodel en het hier besproken optimization model. Veel softwareproducten die IBM in ontwikkeling heeft, bestaan uit open source onderdelen. Zo bestaat de Lotus productiviteitssuite voor een deel uit het open source Eclipse en OpenOffice.org en heeft de Websphere Application Server onderdelen van Apache in zich. Met deze OSS lagen in de eigen software stack, heeft IBM de mogelijkheid om klanten op maat gemaakte producten te bezorgen met een hogere “pricing power” (Koenig, 2004). Zie ook hoofdstuk 3, figuur 4 voor een grafisch overzicht van de mogelijkheden van een OSS laag in de (software) stack. Overige open source businessmodellen die IBM gebruikt: consulting, subscription, patronage

6.2 Dual license businessmodel Trolltech, dat eerder dit jaar werd overgenomen door Nokia, is een bedrijf dat zich richt op de ontwikkeling van cross-platform software. Dit is software die zowel op (bijvoorbeeld) mobiele apparaten als desktop computers te gebruiken is. Cross-platform software is, zoals de naam doet vermoeden niet voor een specifiek platform ontwikkeld. Trolltech heeft twee van zulke cross-platform software producten: Qt en 36


Qtopia: 1. Qt is een cross-platform applicatie framework voor desktop en embedded (zoals mobile apparaten) omgevingen. Dit framework wordt gebruikt door meer dan 5000 bedrijven die het implementeren in hun eigen producten (waaronder Adobe, Google, Siemens, NASA, Disney, etc.). Veel Linux gebruikers zullen Qt kennen als een belangrijke vereiste voor de KDE desktopomgeving (http://trolltech.com/products/qt/) 2. Qtopia is een user interface en applicatie platform voor consumenten elektronica, en mobiele apparaten (http://trolltech.com/products/qtopia/) Het businessmodel van Trolltech voor het Qt framework, bestaat uit de dual license aanpak. Dit stelt het bedrijf in staat om het product voor zowel commerciële als open source doeleinden aan te bieden. In ruil voor de voordelen die een ontwikkelaar ontleent aan Trolltech software bij de ontwikkeling van zijn eigen software, wordt hij verplicht om één van de volgende dingen te doen (http://trolltech.com/company/about/businessmodel): 1. Bijdragen aan de ontwikkeling van de Trolltech producten door een commerciële licentie te kopen. Die bijdrage bestaat hier dus uit een financiële injectie in Trolltech. Hiermee wordt tegelijkertijd het recht verworven om de eigen ontwikkelde software onder een licentie naar keuze te distribueren 2. Bijdragen aan de open source community die zich rond Trolltech begeeft door de eigen ontwikkelde software onder een open source licentie (GPL versie 2 of 3) te plaatsen. Hierdoor hebben alle gebruikers het recht om de broncode van de software in te zien, wijzigingen te maken en te herdistribueren. Trolltech maakt gebruik van een dual license business model aangezien het met de verkoop van commerciële licenties in staat is om fulltime personeel in dienst te hebben dat zich bezighoudt met de ontwikkeling van de software en het verlenen van ondersteuning. Aan de open source kant profiteert het bedrijf van de besproken communityvoordelen op het gebied van softwareontwikkeling (http://trolltech.com/company/about/businessmodel). Overige open source businessmodellen die Trolltech gebruikt: geen

6.3 Consulting businessmodel Hewlett-Packard (HP) is een Amerikaans technologiebedrijf dat zich bezig houdt met de ontwikkeling en verkoop van hardware (servers, desktop computers, laptops, printers en randapparatuur), software en services. In hoofdstuk 2 werd al beschreven hoe HP al vanaf het begin deelneemt aan de open source software gemeenschap (paragraaf 2.4 De Unix Wars). Naast het aanbieden en ondersteunen van diverse OSS producten – HP heeft een eigen open source middleware (middleware is een softwarelaag die overige lagen in staat stelt om met elkaar te communiceren) stack – biedt HP ook consultancy services voor het uitzetten van een open source omgeving bij de klant. De specifieke services die HP op dit gebied aanbiedt zijn: ontwerp, bouw, migratie, integratie en onderhoud van verschillende open source oplossingen. HP vat dit samen in de volgende onderdelen (http://h20219.www2.hp.com/services/cache/390920-0-0-225-121.html): • Open source consulting services: Het evalueren van de huidige staat van de IT infrastructuur en de organisatie. Daarnaast worden omgevingen aangeduid waar open 37


• • • •

source software voor verbetering kan zorgen. Vervolgens vindt de planningsfase plaats, waarin een nieuwe architectuur, of onderdelen daarvan, ontwikkeld worden. Ook wordt een compatibiliteitsanalyse met betrekking tot specifieke open source- en bestaande software gemaakt. Tenslotte kan HP het opleiden en trainen van personeel verzorgen. Deployment services: Het verschaffen van ondersteuning bij de implementatie en uitvoering van de nieuwe software. Application development services: Het verschaffen van ondersteuning bij het testen en migreren van bestaande applicaties naar de nieuwe omgeving. Management and support services: Het verschaffen van ondersteuning op management niveau en het verlenen van support volgens vooraf vastgrlrgfr service level agreement. Security services: Het verlenen van ondersteuning op het gebied van veiligheid.

Op deze wijze profiteert Hewlett-Packard van open source software, zonder dat het actief een bijdrage aan de ontwikkeling en productie ervan hoeft te leveren. Overige open source businessmodellen die HP gebruikt: optimization, subscription, patronage

6.4 Subscription businessmodel SugarCRM, opgericht in 2004, bedient momenteel meer dan 900 betalende klanten. Het bedrijf produceert een open source Customer Relationship Management pakket dat gebruikt kan worden in elke organisatie. In 2004, bij de oprichting van het bedrijf richtte SugarCRM zich voornamelijk op het midden- en kleinbedrijf (MKB), die zich de commerciële CRM pakketten niet konden veroorloven (Goulde et al, 2007). Daarom werd een alternatief ontwikkeld dat wel betaalbaar was. Van meet af aan was het de bedoeling om het project als open source in de markt te zetten. Het achterliggende businessmodel is gebaseerd op subscriptions: abonnees. Het staat bedrijven vrij om de SugarCRM software te downloaden en te gebruiken. Wil men echter ondersteuning, uitbreidingen en updates, dan zal er betaald moeten worden. De ontwikkelaars van SugarCRM kozen voor het open source model vanwege de communityvoordelen met betrekking tot doorontwikkeling en verspreiding van de software. Daarnaast kunnen potentiële klanten, zonder daarvoor te hoeven betalen, proberen of de software inderdaad is wat ze er van verwachten (Goulde et al, 2007). Het businessmodel van SugarCRM is uiteen te splitsen in twee delen (Goulde et al, 2007): 1. Ten eerste biedt SugarCRM extra features en ondersteuning op de CRM software. Vooral voor grote bedrijven met grote verantwoordelijkheden is een dergelijke ondersteuning onontbeerlijk. Deze abonnementsvorm op ondersteuning, etc. is voor SugarCRM een grote bron van inkomsten. 2. Ten tweede werpt SugarCRM – als bedrijf – zich ook op als leider van het project door ervoor te zorgen dat de ontwikkelaars tevreden blijven en genoeg uitdaging in het project blijven zien. Hiervoor is SugarExchange in het leven geroepen. Dit is een onderdeel van de SugarCRM website waar ontwikkelaars hun bijdrages kunnen delen of zelfs verkopen. Zo kunnen specifieke oplossingen en uitbreidingen, zonder tussenkomst van SugarCRM uitgewisseld worden tussen gebruikers en ontwikkelaars. Overige open source businessmodellen die SugarCRM gebruikt: geen

38


6.5 Patronage businessmodel Sun Microsystems werd opgericht in 1982. Het bedrijf produceert een diversiteit aan software, systemen, services en “microelectronics”. Daarmee bedient Sun alle markten; van consumenten elektronica tot ontwikkeltools tot ’s werelds grootste datacenters. De bekendste merken die Sun voert zijn Java, OpenSolaris, MySQL en de UltraSPARC processor (http://www.sun.com/aboutsun/company/index.jsp). Op het gebied van open source software is Sun Microsystems een uitzonderlijk bedrijf. Geen enkele andere grote IT onderneming van hetzelfde kaliber heeft zoveel van de eigen producten ondergebracht in het open source software model. Bedrijven als IBM, Oracle en BEA hebben een grote groei doorgemaakt op OSS terrein, maar Sun Microsystems stelt bijna al zijn producten onder open source licenties beschikbaar, van OpenSolaris (besturingssysteem) tot Java (Driver et al, 2008). Met bijna alle producten in het open source spectrum, is Sun hevig afhankelijk van de mogelijkheden om nieuwe en bestaande klanten te upgraden. Hierbij wordt dan de bestaande open source software geüpgrade naar een commerciële variant met meer functies, mogelijkheden, services en ondersteuning. Sun Microsystems is op directe en indirecte wijze verantwoordelijk voor de leiding van (en deelname aan) een aantal open source software projecten. Hierbij valt te denken aan het office pakket OpenOffice.org, het besturingsysteem OpenSolaris en de verschillende implementaties van Java software (Java Micro Edition, Java Standard Edition en Java Enterprise Edition) (Driver et al, 2008). Daarnaast heeft Sun in januari 2008 de databasesoftware producent MySQL overgenomen, een overname waar ongeveer 1 miljard dollar mee gemoeid is (http://www.mysql.com/news-andevents/sun-to-acquire-mysql.html). Met de acquisitie van MySQL zal Sun deze software gaan integreren met de reeds bestaande productlijnen om zo een stevige positie op de databasemarkt te veroveren. Zonder eigenaar of hoofdontwikkelaar te zijn, heeft Sun ook een flink aantal deelnemingen uitstaan in de ontwikkeling van OSS projecten. Hierbij valt te denken aan de ontwikkeling van de GNOME desktopomgeving en het X.org systeem (Driver et al. 2008). Sun Microsystems is op open source gebied een grote speler die leiding geeft aan een groot aantal projecten. Dit doet het niet alleen door code, tijd en geld te doneren, maar ook door zich actief als leider van dergelijke projecten op te werpen. Naast het vervullen van een leiderschapsrol zijn er ook veel projecten waarbij Sun actief deelneemt aan de ontwikkeling ervan. Overige open source businessmodellen die Sun gebruikt: optimization, dual license, subscription

6.6 Hosted businessmodel volgens Google Google, ’s werelds bekendste zoekmachine werd in 1998 opgericht door Larry Page en Sergey Brin. Deze twee studenten aan Stanford University, bedachten een principe waarmee eenvoudig en snel relevante informatie uit enorme hoeveelheden data gefilterd kon worden (http://www.google.com/corporate/history.html). Google is tevens één van de bekendste bedrijven die het hosted businessmodel hanteren.. Google maakt uitgebreid gebruikt van open source software. Met name voor de core business, de zoekmachine, worden veel open source producten ingezet. Hoewel de exacte gegevens niet bekend zijn, wordt 39


alom aangenomen dat het datacenter van Google is opgebouwd rond een aangepaste versie van Ubuntu Linux (Prentice, 2008). Het voornaamste voordeel voor Google van het gebruik van OSS is het kostenvoordeel. Met een serverpark waarvan wordt aangenomen dat het misschien wel uit een paar miljoen machines bestaat wordt enorm veel bespaard op licentiekosten. Als al deze machines software met een commerciële licentie zouden draaien, dan was het bedrag dat periodiek aan de licentieverstrekker moet worden afgedragen zelfs voor Google substantieel geweest. Er is nog een manier waarop Google profiteert van de voordelen van open source software. Voor intern gebruik mag Google open source software aanpassen naar eigen wensen. Als het hier OSS betreft die onder de GNU GPL valt, én Google distribueert de wijzigingen niet, dan staat het bedrijf volledig in zijn recht. Zo worden, voor gebruik in de datacenters die de zoekmachine ondersteunen, zélf harde schijf drivers geschreven en aangepast. De uitzonderlijke positie waarin Google (en gelijksoortige bedrijven) zich met het hosted businessmodel bevindt is het feit dat dit soort bedrijven zich niet direct bezig houdt met de open source code en programma’s, maar juist met content die door deze programma’s en code gegenereerd wordt. Google was het eerste bedrijf dat een commercieel succes wist te maken van het zoekmachine principe. De zoekopdrachten van de bezoekers werden direct gekoppeld aan advertenties. Iemand die op zoek is naar informatie over een vakantiebestemming loopt grote kans een advertentie over reisverzekeringen te zien te krijgen. Google is geen software producent en distributeur in de klassieke zin van het woord. Ja; het ontwikkeld open source software. Maar dan wel voor eigen gebruik. De winst voor Google zit verscholen in de geoptimaliseerde content die mede dankzij de open source software aan de bezoekers kan worden aangeboden (Prentice, 2008). Omdat Google zich niet direct met software productie bezighoudt, hoeft het zich op dat gebied ook niet druk te maken over eventuele concurrentie. Het bedrijf kan in alle rust de mogelijkheden van open source software onderzoeken. Overige open source businessmodellen die Google gebruikt: patronage

6.7 Embedded businessmodel Voor een voorbeeld van het embedded businessmodel in de praktijk moet niet direct naar softwareproducenten gezocht worden, maar naar hardwareproducenten. Zij profiteren het meest van een open source product waarop de door hun gefabriceerde hardware draait. In dit geval is Asus een goed voorbeeld. Asus is een Taiwanees technologiebedrijf dat een breed spectrum aan computeronderdelen maakt. Het bedrijf is actief op drie markten: computers, communicatie en consumentenelektronica. Eind 2007 gaf Asus het P5E3 Deluxe moederbord uit, waarop een chip zit die het mogelijk maakt dat binnen vijf seconden na opstarten een Linuxomgeving wordt geladen waarin een browser beschikbaar is. Deze geïntegreerde oplossing wordt Express Gate genoemd. Zo heeft de gebruiker van de computer de keuze om het besturingssysteem te laden (zoals Windows of een volledige versie van Linux) of de beknopte Linuxomgeving (http://tweakers.net/nieuws/49699/asus-voorzietmoederbord-van-linux-browser-en-skype.html). Dit kan handig zijn om bijvoorbeeld snel iets op te zoeken op het internet. Zonder dieper op deze technologie in te gaan, kan gesteld worden dat Asus het voornemen had om 40


deze technologie aan te bieden. Daarvoor heeft het bedrijf onderzoek gedaan naar de technische mogelijkheden. Hierbij is uiteindelijk een Linuxvariant gekozen die de computer binnen 5 seconden van een werkbare omgeving moest voorzien. Het voordeel voor Asus in deze situatie is dat Linux, als open source software, een uitermate geschikte kandidaat is om aangepast te worden naar de specificaties van het P5E3 Deluxe moederbord. Daarbij zijn geen licentiekosten en ontwikkelingskosten voor commerciële softwarepakketten gemoeid geweest. Overige open source businessmodellen die Asus gebruikt: geen

6.8 Conclusie In dit hoofdstuk is een overzicht van praktijkvoorbeelden van open source software businessmodellen gepresenteerd. Wat opvalt is dat de grote ondernemingen die in de bovenstaande praktijkvoorbeelden zijn genoemd, zoals IBM, HP, Sun en Google meerdere businessmodellen hanteren. Afhankelijk van de verschillende producten die ze maken en markten die bedient worden kan een bedrijf dus kennelijk een specifiek businessmodel inzetten. De kleinere ondernemingen, zoals Trolltech en SugarCRM uit de voorbeelden, zijn vaak afhankelijk van één specifiek product en een kleinere marktomvang. Dit soort bedrijven kan het zich permitteren om zich te concentreren op een bepaald businessmodel. Alle businessmodellen, die in het vorige hoofdstuk besproken zijn en waarvan in dit hoofdstuk praktijkvoorbeelden zijn gegeven, hebben gemeen dat ze een onderneming in staat stellen om open source software op een rendabele manier commercieel te maken.

41


7.0 Organisatie en strategie: een model In dit hoofdstuk zal gezocht worden naar een geschikt model om verder in dit onderzoek te kunnen gebruiken. Om antwoord te kunnen geven op de hoofdvraag – Hoe verhouden commerciële open source software businessmodellen zich tot de omgeving waarin ze worden ingezet? – zal een model gezocht moeten worden waarmee karakteristieken van de organisatie, omgeving en te volgen strategie vastgelegd en vergeleken kan worden. Gezien het jonge karakter van de open source software wereld met de daarbij benodigde bewegingsruimte, is het van belang dat het gebruikte model niet teveel beperkende factoren kent en het de gebruiker een zekere mate van vrijheid geeft. Deze vrijheid staat de onderzoeker toe om op een later moment de verschillende businessmodellen met het organisatiemodel te kunnen integreren. Er is een aantal modellen dat gebruikt kan worden om organisatievormen te definiëren. Voor veel organisatiekundigen ligt het voor de hand om de zeven organisatieconfiguraties van Henry Mintzberg te gebruiken. In dit geval zijn deze configuraties juist erg beperkend. Daar komt bij dat Mintzberg zijn onderzoek en ontwikkeling van de organisatie typologieën gestaakt lijkt te hebben, waardoor hedendaagse organisatievormen (zoals bijvoorbeeld een netwerkorganisatie) niet aan bod komen. Daarnaast leggen de configuraties van Mintzberg behoorlijk wat beperkingen op als het gaat om de inrichting van een organisatie omgeving. De gebruiker van Mintzbergs model zit vast aan de vijf organisatieonderdelen (Mintzberg, 2003) : 1. 2. 3. 4. 5.

Strategische top; Middenniveau; Uitvoerende kern; Ondersteunende staf; Technostructuur.

Een model dat in het kader van dit onderzoek goed zou kunnen functioneren is het organisatiemodel van Robert Keidel. Keidel veronderstelt dat alle omstandigheden waarin een organisatie kan verkeren een bepaalde balans is tussen drie factoren: autonomie, coöperatie en controle. Het model legt geen restricties op het gebruik ervan in combinatie met de businessmodellen uit de voorgaande hoofdstukken. Niet langer op de zaken vooruit lopend volgt nu de deelvraag die in dit hoofdstuk centraal staat: Wat zijn de eigenschappen van het organisatiemodel van Keidel?

7.1 Inleiding Keidel stelt dat een het ontwerp en de indeling van een organisatie en haar strategieën gezien kan worden als een doelbewust gevormde relatie. Deze relatie is constant onderhevig aan veranderingen, aangezien de omgeving waarin ze verkeert ook constant veranderd. Vervolgens stelt Keidel dat het ontwerp van organisaties uit drie variabelen bestaat, omdat er drie manieren zijn waarop mensen zich, zonder conflict, tot elkaar kunnen verhouden. Deze variabelen zijn autonomie, coöperatie en controle (Keidel, 1995).

42


Figuur 8 – Organisatie ontwerp volgens Keidel

Zoals gezegd zijn er drie manieren waarop twee of meerdere individuen, teams, divisies, etc. zich tot elkaar kunnen verhouden. Ten eerste kan er een samenwerkingsvorm bestaan (coöperatie). Ten tweede een hiërarchische verhouding, waarbij er een bovenliggende en een onderschikte rol bestaat (controle). Tenslotte is er autonomie, waarbij redelijk afzonderlijk van elkaar geopereerd kan worden. Let vooral op de manier waarop de cirkels bij de drie hoekpunten van de driehoek zich tot elkaar verhouden. Hieruit wordt in een oogopslag duidelijk om welke variabele het gaat. De wereld en de natuur zijn driehoekig (“triangular”) opgebouwd. Dit is een veronderstelling die Keidel doortrekt in zijn theorievorming rond organisaties en haar strategieën. Door een driehoekig ontwerp van een organisatie wordt men in staat gesteld om een organisatie te balanceren – en continu te herbalanceren – tussen de drie variabelen autonomie, coöperatie en controle bestaan (Keidel, 1995). Dit continu inrichten van de organisatie en het eventueel bijstellen van de strategieën, vindt plaats in een spanningsveld tussen de drie variabelen. Hoewel de mens een voorkeur lijkt te hebben voor het evenwicht, zal verder in dit hoofdstuk worden aangetoond dat een perfect evenwicht tussen autonomie, coöperatie en controle, niet altijd de beste situatie is voor een organisatie. In Figuur 9 wordt het spanningsveld tussen de variabelen in kaart gebracht.

Figuur 9 – Spanningsveld tussen de factoren autonomie, coöperatie en controle

43


• Autonomie vs. Controle: de afweging tussen deze twee factoren laat zich het best vergelijken met het personeel op de vloer, versus het management op kantoor. Het personeel is dagelijks in contact met de klant en het product en kan haarfijn aanvoelen wat individuele wensen zijn. Het management daarentegen houdt de grote lijnen in de gaten. • Controle vs. Coöperatie: bij dit dilemma moet een afweging worden gemaakt tussen het consistentie- en innovatieniveau. Valt het zwaartepunt naar de “controlehoek” uit dan zal consistentie de overhand genieten boven innovatieve ontwikkelingen die in de “coöperatiehoek” meer aan bod komen. Keidel (1995) noemt hierbij het voorbeeld van McDonalds, de onderneming die overal ter wereld een hamburger kan serveren die er overal hetzelfde uitziet, ruikt en smaakt. Het controle aspect zorgt hier voor strikt vastgelegde voorschriften met betrekking tot het maken van de hamburger. Hier kan onder geen enkele voorwaarde van worden afgeweken. Dit gaat uiteraard ten koste van de flexibiliteit van het personeel en de bedrijfsvoering. • Coöperatie vs. Autonomie: het veld tussen coöperatie en autonomie bepaalt de keuze van de organisatie voor het individu of voor de groep. Bij een keuze voor de groep, zijn de individuele prestaties moeilijk te meten. Omgekeerd geldt dat bij een keuze voor het individu, spontane groepsacties minder aanwezig zullen zijn (Keidel, 1995). Bij geen van de genoemde dilemma’s is er sprake van een goede of foute keuze of een goede of foute voorkeur voor één van de factoren. Er kan alleen sprake zijn van een specifieke keuze voor een specifieke situatie. Alleen de realiteit kan uiteindelijk aantonen of de goede keuzes zijn gemaakt. Een van de belangrijkste punten die Keidel in zijn model heeft opgenomen is dat de factoren autonomie, coöperatie en controle geen constanten zijn. Sterker nog, ze zijn inwisselbaar voor elke gewenste (doch overeenkomstige) factoren. Een lijstje: Autonomie Omgeving Vrijheid Klant Effectiviteit Etc.

Coöperatie Mensen Delen Medewerker Intentie Etc.

Controle Systemen Discipline Aandeelhouder Efficiëntie Etc.

Een ontwerp met drie variabelen lijkt eenvoudig gemaakt. Toch baseren managers vaak hun beslissingen op één a twee variabelen, waarbij een derde compleet uit het oog wordt verloren. Neem bijvoorbeeld de afweging tussen effectiviteit (“de juiste dingen doen”) en efficiëntie (“de dingen juist doen”). Bij een beweging van één van de variabelen in de verkeerde richting, zal de ander ook automatisch uit het spoor lopen. Met een derde variabele, intentie (“waarom doen we dingen?”) is dit gevaar een stuk minder, aangezien voor elke (nieuwe) situatie moet worden bekeken of – en zo ja, waarom – iets aangepast moet worden (Keidel, 1995).

7.2 Fouten en falen Waar mensen werken en mensen beslissingen nemen, worden fouten snel gemaakt. Zelfs een model met “maar” drie variabelen kent punten die beter vermeden kunnen worden. Keidel (1995) onderscheidt drie manieren waarop managers en organisaties kunnen falen: 1. Teveel nadruk leggen op de topprioriteit; 2. Te weinig nadruk leggen op de laagste prioriteit; 3. Het opereren zonder prioriteiten.

44


Figuur 10 – Drie posities die beter vermeden kunnen worden

Deze drie fouten kunnen als volgt worden uitgewerkt (Keidel, 1995): • Teveel nadruk op autonomie: In deze situatie krijgt het individu (of de individuele afdeling of departement) zoveel macht binnen een organisatie, dat het in staat is de organisatie naar eigen wensen te manipuleren. Er ontstaat een “iedereen voor zichzelf” situatie. • Teveel nadruk op coöperatie: De situatie waarin teveel nadruk ligt op coöperatie is niet een voor de hand liggende. Echter komt het voor dat een organisatie ten onder gaat aan een teveel aan samenwerking. Een bedrijf kan niet zonder een bepaalde leidinggevende structuur. • Teveel nadruk op controle: Bij een sterke nadruk op controle ontstaat er een situatie, waarin alleen nog maar vraag is naar leiders en personeel dat geleid wil worden. Coöperatie en autonomie hebben in dit geval een minimale toegevoegde waarde. Het credo dat bij deze situatie past is: “Leidt, volg, of ga weg!” • Te weinig nadruk op autonomie: Het individu wordt niet erkend binnen de organisatie. Alle behaalde resultaten worden opgedragen aan de organisatie als geheel. • Te weinig nadruk op coöperatie: Organisatie ontwerp wordt door managers vaak gezien als een verdeling tussen controle en autonomie, zonder dat daar coöperatie aan te pas komt. • Te weinig nadruk op controle: Elke organisatie heeft structuur nodig. Bij het uitzetten van een organisatiestructuur speelt controle een grote rol. Het ontbreken van hiërarchische structuren in een organisatie leidt tot een onoverzichtelijke situatie. • Ongedifferentieerd ontwerp: Het uitzetten van een organisatievorm met drie variabelen houdt niet in dat al de variabelen gemaximaliseerd moeten worden. Integendeel, in een gezonde organisatie komen alle drie de variabelen aan bod, hetzij niet allemaal even sterk. Zo wordt er geen enkele variabele uit het oog verloren. Een organisatie waarin alle variabelen maximaal zijn, heeft geen prioriteiten. Dergelijke organisaties bestaan echter wel. Dit zijn zogenaamde matrix organisaties.

45


7.3 Generieke organisatiestructuren Het ontwerp van een organisatiestructuur en/of strategie in het model van Keidel is afhankelijk van drie factoren. Elke organisatie moet een bepaalde volgorde – of prioriteit – geven aan de factoren autonomie, coöperatie en controle. Zo ontstaat een bepaalde verhouding tussen deze variabelen, aangezien ze afhankelijk van elkaar zijn. Ongeacht de prioriteiten is het niet aan te raden om één van de variabelen te vergeten of niet te behandelen. Alle variabelen zijn belangrijk. In de vorige paragraaf lag de nadruk op de grijze gebieden waaraan weinig werkbare situaties ten grondslag liggen. In deze paragraaf zal de focus liggen bij de witte gebieden, de generieke organisatiestructuren. Figuur 11 geeft een overzicht weer van verschillende organisatievormen, zoals die in Keidels driehoek passen. Uit het onderstaande figuur wordt duidelijk dat organisatievormen in de witte cirkels overeen komen met de hoek waar ze in staan. Bijvoorbeeld de autonomiehoek. Hier staan vormen die veelal uit losstaande onderdelen bestaan. Neem bijvoorbeeld de scheiding van markten en producten. Een onderneming kan er voor kiezen verschillende markten te bedienen met verschillende producten. Deze markten en producten hebben in wezen niks met elkaar te maken, echter behoren ze tot hetzelfde bedrijf. In de controlehoek staan organisatievormen die een centrale regeling van processen kennen. Ook vindt er verticale integratie van de waardeketen plaats. Zaken als Research en Development (R&D), inkoop, productie, verkoop en aftersales, kunnen centraal geregeld en gecombineerd worden.

Figuur 11 – Generieke organisatievormen in Keidels driehoek

46


Tenslotte is er de coöperatiehoek, waarin team-achtige groepen de dienst uit maken. Samenwerking staat aan deze kant van de driehoek centraal. In het midden van de driehoek staat de matrix organisatie. Dit organisatieontwerp probeert om de controle en autonomie kanten van het model met elkaar te verenigen, waarbij managers naar beide kanten verantwoording af moeten leggen – aan de ene kant bijvoorbeeld naar een functionele (controle) baas, en aan de andere kant naar een product/markt (autonomie) baas. Om een dergelijke rapportage structuur werkende te krijgen is er van alle partijen vrijwillige samenwerking nodig. Mocht deze samenwerking al bestaan, dan loopt de organisatie het gevaar om in een situatie te raken waarbij geen prioriteit bestaat met betrekking tot de variabelen (Keidel, 1995). Keidel vergelijkt deze situatie met de eigenschap van een helikopter die ooit eens omschreven is als een machine waarvan elk onderdeel het geheel uit elkaar wil trekken.

7.4 Conclusie In dit hoofdstuk is het organisatiemodel van Robert Keidel besproken. Dit driehoekige model met de bijbehorende drie variabelen kan niet alleen gebruikt worden voor het ontwerpen van een organisatiestructuur. Met enkele aanpassingen, zoals bijvoorbeeld het inwisselen van de drie variabelen voor vergelijkbare alternatieven, wordt het model evengoed gebruikt om een bepaalde strategie uit te stippelen. Keidel veronderstelt dat alle facetten binnen een organisatie bestaan uit drie variabelen die met elkaar in een bepaalde balans verkeren. Een gelijke voorkeur voor alle drie de variabelen is mogelijk, maar niet in alle situaties even wenselijk. Het belangrijkst is dat er in de overeenkomst tussen de variabelen geen enkele variabele vergeten wordt. In het volgende hoofdstuk zullen de zeven businessmodellen die eerder benoemd zijn, een positie in het driehoekige organisatiemodel van Keidel krijgen. Voor elk van de businessmodellen zal er een balans van de drie variabelen zijn, die de plaats van het model in de driehoek bepaalt.

47


8.0 Businessmodellen en driehoeken Centraal in dit hoofdstuk staat de positionering van de verschillende open source software businessmodellen in het organisatiemodel van Keidel. Figuur 10 uit het vorige hoofdstuk laat de gebieden zien die beter vermeden kunnen worden. Deze gebieden zijn in de onderstaande figuren blauw gekleurd en zullen buiten beschouwing worden gelaten bij het plaatsen van de businessmodellen. De businessmodellen zullen een voor een kort worden samengevat. Vervolgens wordt onderbouwd waarom voor een bepaalde positie in de driehoek is gekozen.

8.1 Keidel vs. optimization businessmodel

Figuur 12 – Keidel vs. optimization businessmodel

8.1.1 Samenvatting optimization businessmodel De plaatsing van het optimization businessmodel in het vlak tussen controle en autonomie laat zich als volgt verklaren. Bij dit businessmodel wordt gebruik gemaakt van de mogelijkheden die een software stack biedt. Met een open source software laag in de stack, die naar elke situatie aan te passen is, wordt de producent in staat gesteld om de overige lagen te optimaliseren. 8.1.2 Positieverklaring Een bedrijf dat het optimization businessmodel hanteert zal een bepaalde mate van controle willen uitoefenen op de samenstelling van de software stack die het aanbiedt. Ook moet er beslist worden welke open source software er in de stack gaat en hoe deze software wordt aangepast. Dit zijn allemaal controle issues die in de linkerhoek van de driehoek thuishoren. Daar tegenover stelt dit businessmodel dat de overige lagen van de softwarestack min of meer onaangetast blijven. Vaak bestaan deze lagen uit eigen, propriëtaire software. Hiermee is autonomie vertegenwoordigd. De derde variabele, coöperatie, komt tot uitdrukking in het feit dat er een klant in het spel is, naar wiens 48


wensen de configureerbare softwarelaag wordt aangepast. In dit geval weegt de controle variabele het zwaarst, aangezien dit businessmodel staat of valt met de aanwezigheid en hoedanigheid van een configureerbare open source softwarelaag in de softwarestack.

8.2 Keidel vs. dual license businessmodel

Figuur 13 – Keidel vs. dual license businessmodel

8.2.1 Samenvatting dual license businessmodel Bij dit businessmodel wordt verondersteld dat de software twee licenties heeft, of dat er twee versies van de software zijn: een open source- en een commerciële variant. De open source software is in dit geval gratis verkrijgbaar, maar kent geen ondersteuning en features die wel worden aangeboden in de commerciële variant. 8.2.2. Positieverklaring Dit businessmodel benadrukt de positieve eigenschappen van zowel de open source, als de commerciële licentietypes. Aan de ene kant is er de mogelijkheid voor de community om de broncode in te zien en er voor de zorgen dat problemen sneller verholpen worden, wat de ontwikkeling ten goede komt. Anderzijds is zijn er de inkomsten die verbonden zijn aan de verkoop van commerciële licenties. Dit businessmodel is exact in het midden tussen controle en coöperatie geplaatst. Het coöperatie aspect komt tot uitdrukking in de aanwezigheid van de open source licentie. Daar tegenover staat de commerciële licentie, hetgeen een verband met de controlehoek legt. Er is moeilijk een connectie te maken met de autonomie variabele, vandaar dat de positie van dit businessmodel zo ver naar buiten ligt.

49


8.3 Keidel vs. consulting businessmodel

Figuur 14 – Keidel vs. consulting businessmodel

8.3.1 Samenvatting consulting businessmodel Waar vroeger in de IT sector de nadruk lag op de ontwikkeling en verkoop van software en hardware, wordt tegenwoordig veel meer aandacht besteed aan services. Hieronder vallen ook consultancy werkzaamheden.. Een IT consultant kan, zonder tijd en moeite in de ontwikkeling van software te steken, wel adviezen uitbrengen op het gebied van open source software. 8.3.2 Positieverklaring Aangezien een consultant altijd afhankelijk is voor zijn werkzaamheden van de klant, is dit businessmodel diep in de coöperatiehoek geplaatst. Alles in dit businessmodel is er op gericht om samen met een klant tot een passende oplossing te komen. De overige twee variabelen zijn daarbij minder voor de hand liggend.

50


8.4 Keidel vs. subscription businessmodel

Figuur 15 – Keidel vs. subscription businessmodel

8.4.1 Samenvatting subscription businessmodel In de situatie waarin een subscription businessmodel wordt gebruikt, stelt een producent een open source softwareproduct gratis en vrij ter beschikking aan alle gebruikers. Gebruikers die ondersteuning willen in de vorm van updates en ondersteuning kunnen hiervoor een abonnement afsluiten. Het meest rendabel zijn de grote bedrijven die overwegen grote systemen door het OSS product te vervangen. Bij dit soort operaties moeten ondersteuning en verantwoordelijkheden geregeld worden. Ook in dit soort omvangrijke situaties, biedt dit businessmodel een uitkomst. 8.4.2 Positieverklaring De overeenkomsten van het subscription model met de dual license model wordt duidelijk uit het feit dat de positie van beide businessmodellen in de driehoek bijna identiek zijn. De positie van het subscription businessmodel heeft een voorkeur voor de coöperatiehoek. Een bedrijf dat dit model hanteert is voor zijn inkomsten voornamelijk afhankelijk van de klanten die een abonnement afsluiten. Een goede samenwerking met de markt is dus noodzakelijk voor het voortbestaan van de onderneming. Het controleaspect is komt tot uitdrukking door het feit dat een bedrijf dat voor zijn omzet een sterke afhankelijkheid heeft van zijn klanten heel duidelijk wil hebben welke klant welke service heeft afgesloten.

51


8.5 Keidel vs. het patronage businessmodel

Figuur 16 – Keidel vs. patronage businessmodel

8.5.1 Samenvatting patronage businessmodel Een bedrijf dat zich intensief bezighoudt met het doneren van tijd, geld, code en leiderschap aan een open source project, wordt ook wel de hoeder van dat project genoemd: de patron. Deze hoeder bepaald de richting waarin een project zich begeeft, maakt beslissingen over door te voeren veranderingen en, heel belangrijk, hij wordt door de community ook als leider van het project geaccepteerd. Als projectleider heeft een onderneming de macht om het project een bepaalde – voor hem gunstige – kant op te sturen. 8.5.2 Positieverklaring Het patronage businessmodel heeft een lichte voorkeur voor de controlehoek. De overige variabelen zijn echter ook ruimschoots vertegenwoordigd. Aangezien de patron, als leider van het project beslissingen neemt over de richting waarin de ontwikkelingen van de software zich moeten begeven, wil hij controle hebben over de status van het project. Tevens is coöperatie belangrijk. Ondanks het feit dat de patron zich intensief inzet bij de ontwikkeling van het project, werkt hij niet alleen. Een goed contact met de overige ontwikkelaars is onontbeerlijk voor een OSS project om te slagen. Het kan voorkomen dat gedurende de ontwikkeling van open source software de leiding op een gegeven moment een beslissing neemt die niet bij alle gebruikers (of ontwikkelaars) in goede aarde valt. In dat geval kan er een fork (afsplitsing) in het project ontstaan. Opmerkelijk is dat in zo’n geval de leiding meestal nooit op haar beslissingen terugkomt en daarmee een autonome houding aanneemt.

52


8.6 Keidel vs. hosted businessmodel

Figuur 17 – Keidel vs. hosted businessmodel

8.6.1 Samenvatting hosted businessmodel Bij een hosted strategie maakt een onderneming gebruik van open source software voor eigen intern gebruik. Aangezien de software alleen voor intern gebruik is, wordt het bedrijf niet verplicht eventuele wijzigingen en doorontwikkelingen aan de software terug te geven aan de community. Zoals in het praktijkvoorbeeld van Google (paragraaf 6.6) duidelijk werd, kan dit een heel krachtig businessmodel zijn. 8.6.2 Positieverklaring De positie van het hosted businessmodel is te verklaren door de onafhankelijkheid van de community. Een bedrijf dat het hosted model hanteert is vrij om open source software aan te passen naar de eigen wensen. Zo lang de software voor intern gebruik wordt aangewend, is de onderneming volgens de meeste open source licenties niet verplicht om eventuele doorontwikkelingen ervan te delen met de community. Hierdoor creëert het bedrijf een autonome en onafhankelijke positie in de open source wereld.

53


8.7 Keidel vs. embedded businessmodel

Figuur 18 – Keidel vs. embedded businessmodel

8.7.1 Samenvatting embedded businessmodel Het embedded businessmodel gaat in de meeste gevallen uit van een situatie waarbij een producent van bepaalde hardware (meestal zijn dat consumentenelektronica, zoals mobiele apparaten, DVD spelers, etc.) op zoek is naar software die deze hardware kan aandrijven. Steeds vaker worden hiervoor open source oplossingen gebruikt en ontwikkeld. Met het gebruik van OSS kan zo’n hardware fabrikant buigen op de ervaringen van (meestal) een grote community. Hiermee kan worden bespaard op ontwikkelingskosten. 8.7.2 Positieverklaring De voorkeur voor het businessmodel naar de coöperatiehoek kan worden verklaard door het feit dat wanneer een fabrikant van embedded systemen een samenwerking aangaat met de open source wereld om zo tot een passende oplossing voor zijn producten te komen. Toch blijft een kleine mate van autonomie ontstaan. Waarschijnlijk zal de fabrikant zich enigszins afzijdig opstellen ten opzichte van de doorontwikkeling van de software. Zijn enige interesse is dat zijn producten goed en stabiel werken.

54


8.8 Conclusie In dit hoofdstuk zijn de zeven businessmodellen waarmee een onderneming open source software op een rendabele wijze kan exploiteren geplaatst in het organisatiemodel van Keidel. Daarbij de eigenschappen van de businessmodellen vertaalt naar een combinatie van variabelen en een bijbehorende positie in de driehoek. Een totaaloverzicht van alle businessmodellen in één driehoek ziet er als volgt uit:

Consulting Subscription Dual license Embedded

Optimization

Patronage

Hosted

Figuur 19 – Totaaloverzicht van de Businessmodellen in het organisatiemodel van Keidel

Uiteraard valt hier op dat de commerciële open source businessmodellen een voorkeur lijken te hebben voor het gebied aan de coöperatie kant. De controle- en autonomie kant daarentegen lijken sterk ondervertegenwoordigd in het totaaloverzicht. Wat hier de redenen van zijn zal in het, nu volgende, laatste hoofdstuk worden besproken.

55


9.0 Conclusie De open source software wereld is een jonge en voor een deel onontgonnen omgeving. In deze omgeving vinden allerlei interessante ontwikkelingen plaats. Een van deze ontwikkelingen is de combinatie van commercie met open source software. Er zijn zeven businessmodellen die een organisatie kan hanteren als het open source software rendabel wil distribueren. In dit onderzoek is een overzicht gepresenteerd van deze commerciële open source businessmodellen. Daarbij ging vooral de interesse uit naar de plaatsing van deze modellen ten opzichte van elkaar en de omgeving waarin zij zich bevinden. Uiteraard zijn er aan het einde van dit onderzoek nog een aantal open einden en wellicht ook een aantal vragen. In dit hoofdstuk wordt aandacht besteed aan het resultaat van de positionering van de zeven businessmodellen in de organisatiedriehoek van Keidel. Uit Figuur 18 van het vorige hoofdstuk, mag worden opgemaakt dat de businessmodellen zich grotendeels aan dezelfde kant van het organisatiemodel bevinden. Tevens zijn er in hetzelfde model behoorlijk wat leegtes, die wellicht opgevuld kunnen worden.

9.1 De coöperatiebias Nu alle businessmodellen in Keidels driehoek zijn geplaatst valt het op dat de een groot deel van de modellen zich bevindt aan de coöperatiekant van Keidels organisatiemodel. Aan de hand van een analyse van de modellen die deze bias vertonen zal verklaard worden waar de voorkeur voor de coöperatie variabele vandaan komt. 9.1.1 Coöperatiebias consulting businessmodel Ongeacht of het open source- of commerciële software betreft; een consultant is in grote mate afhankelijk van zijn klanten. Samen met de klant gaat een consultant op zoek naar een geschikte oplossing voor de aanwezige problemen. In de consultancy is het niet ongewoon dat de consultant zijn werkzaamheden intern bij een klant uitvoert. Een goede samenwerking met de omgeving is cruciaal voor een goede uitvoering van het consulting businessmodel. 9.1.2 Coöperatiebias embedded businessmodel Bij het gebruik van een embedded businessmodel is coöperatie voor de hand liggend. Neem een hardwarefabrikant die voor zijn producten op zoek is naar besturingssoftware. Uiteraard wil hij zijn ontwikkelingsbudget verstandig uitgeven. Door in contact te treden met de verschillende ontwikkelaars van embedded open source producten, maakt de hardwarefabrikant gebruik van een ruime ervaring die van pas kan komen bij de ontwikkeling van de besturingssoftware van consumentenelektronica. Het embedded businessmodel heeft niet een exclusieve bias voor de coöperatiekant. Als de hardwarefabrikant eenmaal zijn apparatuur heeft voorzien van de door hem gewenste software, zal hij zich waarschijnlijk niet langer op het open source toneel begeven. 9.1.3 Coöperatiebias subscription businessmodel Een organisatie die gebruik maarkt van het subscription businessmodel onderhoudt een intensief 56


contact met zijn klanten. Zij zorgen voor een groot deel voor de omzet door voor ondersteuning een abonnementsvorm af te sluiten. Ook hier is geen sprake van een exclusieve bias. De organisatie die het subscription model hanteert zal volledige controle willen houden op de richting waarin de ontwikkelingen van de open source variant van zijn software zich begeeft.

9.2 Leegtes Figuur 18 toont ook een aantal opvallende leegtes. Alle businessmodellen die commerciële open source software mogelijk maken en die op dit moment bekend en getest zijn, zijn in dit onderzoek besproken. Het is dus niet zo dat er wellicht nog meer businessmodellen bekend zijn, die in dit onderzoek buiten beschouwing zijn gelaten. Naar de precieze redenen voor het uitblijven van businessmodellen op de witte, lege locaties in het model van Keidel kan op dit moment alleen gegist worden. Dit is echter wel een onderwerp dat in vervolgonderzoek aan bod zou kunnen komen. In het kader van dit onderzoek, met bijbehorende scope, moet helaas geconcludeerd worden dat er op dit moment niks zinnigs gezegd kan worden over de leegtes in het gecombineerde driehoek-businessmodel figuur.

9.3 Uitbijters: hosteden patronage strategie Het inmiddels veel besproken Figuur 18 uit hoofdstuk 8 laat twee opvallende businessmodellen zien, die niet direct omgeven worden door overige businessmodellen. Het gaat hier om het hosteden patronage businessmodel. 9.3.1 Hosted businessmodel uitbijter Het hosted businessmodel veronderstelt een situatie waarin een onderneming gebruik maakt van open source software die het optimaliseert voor eigen, intern gebruik. De omzet in een dergelijke organisatie is sterk afhankelijk van de resultaten die de geoptimaliseerde software boekt. Het gebruik en ontwikkeling van de open source software is sterk op de eigen organisatie en omgeving gericht, vandaar een haast exclusieve bias richting de autonomie variabele. 9.3.2 Patronage businessmodel uitbijter De positie van het patronage businessmodel is niet echt een uitbijter te noemen. Echter is dit model wel één van de twee modellen die buiten de coöperatiecirkel in de top van Keidels driehoek valt. In een patronagemodel is er een leidinggevende organisatie aan een open source software project. Deze leidinggevende bepaald de richting waarin de ontwikkelingen van het project zich begeven. De voorkeur voor de controle variabele komt hiermee duidelijk naar voren. Anderzijds zal de leidinggevende organisatie moeten zorgen voor een omgeving en infrastructuur waarin ontwikkelaars met elkaar in contact kunnen komen. Hiermee wordt de positie van dit businessmodel toch iets hoger geplaatst, richting de coöperatie variabele.

57


9.4 Tot slot Nu de meeste vragen beantwoord zijn en het einde van dit onderzoek in zicht is, rest nog een antwoord op de hoofdvraag: Hoe verhouden commerciële open source software businessmodellen zich tot de omgeving waarin ze worden ingezet? Het beste antwoord op deze vraag is een verwijzing naar de hoofdstukken vijf tot en met acht. Hierin zijn de eigenschappen van de businessmodellen en de het organisatiemodel van Keidel opgenomen. Het ultieme resultaat van deze hoofdvraag is Figuur 18 uit hoofdstuk acht. In één oogopslag is vast te stellen waar de businessmodellen zich thuisvoelen, en waar zij opereren in een omgeving die gedefinieerd wordt door drie variabelen: autonomie, coöperatie en controle.

58


Bronvermelding Asay, D. (2008), The General Public License Version 3.0: Making or Breaking The FOSS Movement?, MTTLR.org Behlendorf, B. (1999), Open ource as a Business Strategy, in: Dibona, C., Ockman, S., en Stone, M., Open Sources: Voices from the Open Source Revolution, O'Reilly and Associates, blz.149-170. Bonaccorsi, A., Rossi, C. (2003) Altruistic individuals, selfish firms? The structure of motivation in Open Source software. Bonaccorsi, A., Rossi, C. (2003), Why Open Source software can succeed, Elsevier. Bretthauer, D. (2002), Open Source Software: A History, Information and Technology Libraries. Driver, M. (2007), Evaluating IBM, Microsoft, Oracle and SAP Open-Source Software Strategies, Gartner Inc. Driver, M., Feinberg, D., Weiss, G., Open Source at Sun Microsystems, 2008, Gartner Inc. Fitzgerald, B. (2006), The Transformation of Open Source Software, MISQ. Goulde, M, Albornoz Mulligan, J., Koetzle, L., Daniels, M. (2007), SugarCRM Finds The Sweet Spot In Customer Relationship Management, Forrester Research Inc. Gustafson, P., Koff, W. (2004), Open Source: Open for Business, CSC. Hiong, S. (2005), Open Source and Commercial Software, an In-depth Analysis of the Issues, Business Software Alliance. Hohensohn, H., Hang, J. (2003), Product - and Service Related Business Models for Open Source Software, Tagungsband Net.Objectdays. Keidel, R (1995), Seeing Organizational Patterns, Berret-Koehler Publishers Inc. Koenig, J. (2004) Seven open source business strategies for competitive advantage, IT Manager’s Journal. Krishnamurthy, S. (2003), An Analysis of Open Source Business Models, in Feller, J, Fitzgerald, B, Hissam, S, and Lakhani, K. (2005), Perspectives on Free and Open Source Software, MIT Press. Lawton, M. (2008), Industry Developments and Models, IDC's Worldwide Open Source Software Business Models Taxonomy, 2008, IDC. Lerner, J., Tirole, J. (2000), The Simple Economics of Open Source. Mintzberg, H. (2003), Mintzberg over Management, de Wereld van Onze Organisaties, Uitgeverij Business Contact. Moody, G.. (2002), Rebel Code, Lunix and the Open Source Revolution, Penguin Books.

59


Perens, B. (1999), The Open Source Definition, in: Dibona, C., Ockman, S., en Stone, M., Open Sources: Voices from the Open Source Revolution, O'Reilly and Associates Pezzini, M. (2008), Open Source at IBM, 2008, Gartner Inc. Prentice, B (2008), Open Source at Google, 2008, Gartner Inc. Raymond, E. (2001), The Cathedral & The Bazaar, Musings on Linux and Open Source by an Accidental Revolutionary, O’Reilly. Riehle, D. (2007) The Economic Motivation of Open Source Software: Stakeholder Perspectives, IEEE Computer Society. Stallman, R. (1999) The GNU Operating System and the Free Software Movement, in: Dibona, C., Ockman, S., en Stone, M., Open Sources: Voices fromthe Open Source Revolution, O'Reilly and Associates, blz.53-71. Weber, S. (2004) The Success of Open Source, Work Design Collaborative. West, J. (2003), How open is open enough? Melding proprietary and open source platform strategies, Elsevier.

Bezochte websites http://en.wikipedia.org/wiki/History_of_Open_Source http://en.wikipedia.org/wiki/Fernando_J._Corbató http://en.wikipedia.org/wiki/Ken_Thompson_%28computer_programmer%29 http://en.wikipedia.org/wiki/Unix_wars http://en.wikipedia.org/wiki/The_Open_Group http://www.gnu.org/philosophy/free-software-for-freedom.html http://www.gnu.org/philosophy/open-source-misses-the-point.html http://www.free-soft.org/mirrors/www.opensource.org/docs/osd-dutch.php http://www.opensource.org/licenses/alphabetical http://www.blackducksoftware.com/oss http://www.gnu.org/licenses/old-licenses/gpl-2.0.html http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html http://www.ibm.com/ibm/nl/organisatie.html http://trolltech.com/products/qt/) http://trolltech.com/products/qtopia/) http://trolltech.com/company/about/businessmodel http://www.sun.com/aboutsun/company/index.jsp http://www.google.com/corporate/history.html http://tweakers.net/nieuws/49699/asus-voorziet-moederbord-van-linux-browser-en-skype.html http://h20219.www2.hp.com/services/cache/390920-0-0-225-121.html

60


Appendices Appendix A: Open Source Definition, versie 1.9 1 - Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. Rationale: By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn't do this, there would be lots of pressure for cooperators to defect. 2 - Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. Rationale: We require access to un-obfuscated source code because you can't evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy. 3 - Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications. 4 - Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations. Accordingly, an open-source license must guarantee that source be readily available, but may 61


require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source. 5 - No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any opensource license from locking anybody out of the process. Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself. 6 - No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it. 7 - Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. Rationale: This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement. 8 - License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. Rationale: This clause forecloses yet another class of license traps. 9 - License Must Not Restrict Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. Rationale: Distributors of open-source software have the right to make their own choices about their own software. Yes, the GPL is conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed. 62


10 - License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface. Rationale: This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called "click-wrap" may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or re-used portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.

63


Appendix B: Linux distributies

Figuur: Overzicht van alle Linux distributies die tot op heden bekend zijn

64


Appendix C: Investeringen in open source software sinds 2000

Figuur: Investeringen in open source software van Q1 2000 t/m Q1 2007

Na de inzinking in de jaren 2001 tot en met 2003 (het knappen van de “internetbubbel”) begonnen investeringen in de open source softwaremarkt aan te trekken. Het niveau van de investeringen zit, anno 2007 op een gemiddelde van ongeveer 100 miljoen Dollar per 11 projecten. Dit overzicht laat overigens alleen de investeringen zien van zogenaamde “venture capitalists” (durfkapitalisten die veelal investeren in startende ondernemingen). Deze venture capitalists willen in het algemeen het hoge beleggingsrisico beperken door gediversificeerd hun geld uit te verspreiden. Een exact “perproject-bedrag” is dan ook niet nauwkeurig uit het figuur af te leiden.

65

Open Source Software Businessmodellen

Recommend Documents