Community Source
Coach:
Dr. P. van Baalen
Meelezer:
Dr. I. Bogenrieder
Het delen van broncode in een gesloten software-innovatienetwerk
Ivo van Doesburg 177970
Community Source Het delen van broncode in een gesloten software-innovatienetwerk
Naam auteur:
Ivo van Doesburg
Studentnummer:
177970
Faculteit:
Bedrijfskunde
Specialisatie:
Informatiemanagement
Coach:
Dr. P. van Baalen
Meelezer:
Dr. I. Bogenrieder
Datum:
1 september 2005
Voorwoord Een wijs man, of een wijze vrouw - pin me er niet op vast, heeft ooit eens gezegd dat je pas bovenaan de berg kunt zien hoe je het beste naar de top had kunnen klauteren. Deze man wordt nog veel geciteerd, ook nu weer. Dit is het eerste verband tussen bergbeklimmen en een scriptie schrijven, maar er zijn er meer! Zo is zowel een scriptie schrijven als bergbeklimmen een vrij eenzame bezigheid. Het grote publiek merkt er niets van totdat het einddoel bereikt is en het of een belabberde of een uitmuntende prestatie was. En soms gaat het zowel bij bergbeklimmen als bij het schrijven van een scriptie gruwelijk mis en bij beide kan dat te maken hebben met de gebruikte apparatuur. In de gevallen dat het niet gruwelijk mis gaat is hoogstwaarschijnlijk dank verschuldigd aan naasten. Iedereen die mij in de afgelopen tijd heeft bijge-
Falende apparatuur
staan met intellectuele, emotionele en materiële steun wordt bij deze van harte bedankt, ik heb het goed kunnen gebruiken! Ik heb heel wat geklaagd tijdens het schrijven van deze scriptie, maar terugkijkend op deze leerzame tijd denk ik toch: “Ik zou het zo niet weer doen!”
Ivo van Doesburg Klaaswaal, 30 augustus 2005
<1
Inhoudsopgave Voorwoord
1
Inhoudsopgave
3
1. Inleiding
7
1.1
Aanleiding
8
1.2
Doelstelling
9
1.3
Vraagstelling
9
1.4
Onderzoeksgebied en aanpak
9
1.4.1
Onderzoeksgebied
9
1.4.2
Onderzoeksaanpak en -opzet
10
1.5
Wetenschappelijke en bedrijfskundige relevantie
2. Software
11 13
2.1
Technisch perspectief
13
2.2
Kennisperspectief
14
2.2.1
Expliciet maken van taciete kennis
15
2.2.2
Het delen van broncode
16
2.3
Economisch perspectief
16
2.4
Conclusie
17
3. Open source
19
3.1
Opbouw van het hoofdstuk
19
3.2
Definitie van open source
20
3.2.1
Vrije herverspreidbaarheid
20
3.2.2
Vrijheid
21
3.2.3
Openheid
21
3.3
Licenties
21
3.4
De open-sourcegemeenschap
22
3.4.1
3.5
Rollen
Open source vanuit economisch perspectief
23
25
<3
3.6
Motivatie voor participatie
26
3.7
Commerciële open source participatie
27
3.8
Niveau één: motieven voor gebruiken van OSS
28
3.8.1
Vrijheidseigenschappen
29
3.8.2
Kwaliteitseigenschappen
30
3.8.3
Kosten
32
3.9
Niveau twee: motieven voor exploiteren van OSS
33
3.10
Motieven voor bijdragen aan OSS
35
3.10.1
Economische motieven
35
3.10.2
Technologische motieven
37
3.10.3
Sociale motieven
37
3.11
Niveau drie en vier: motieven voor initiëren van OSS
3.11.1
Marketingstrategie
38
3.11.2
Ontwikkelingsstrategie
40
3.11.3
Concurrentiestrategie
41
3.12
Nadelen voor initiatoren van commerciële OSS-ontwikkeling 43
3.13
Conclusie
4. Motivatie voor samenwerken
44 45
4.1
Samenwerking in een strategische alliantie
45
4.2
Software-innovatie
47
4.3
Risico
48
4.4
Conclusie
48
5. Vormen van samenwerken 5.1
Organisatorisch perspectief
49 49
5.1.1
Het netwerkperspectief
49
5.1.2
Netwerkclassificaties
50
5.1.3
Netwerkabstractie
51
5.1.4
Het gesloten software-innovatienetwerk
51
5.2
Technisch perspectief
53
5.2.1
Application programming interfaces
53
5.2.2
Conclusie
54
6. Analyse
4>
38
55
6.1
Begripsbepaling van het delen van broncode
55
6.2
Aanpak
56
6.3
Interdependenties in open source
57
6.3.1
Kenmerken
57
6.3.2
Gevolgen
58
6.3.3
Adoptie
60
7. Gevalstudie TeamSoft
63
7.1
Methodologie
63
7.2
Inleiding
64
7.2.1
Het product
64
7.2.2
Technologie
64
7.3
Conditional Open Source
65
7.4
Partnernetwerk
65
Typen partners
66
7.4.1
7.5
Innovatiedeling in het netwerk
68
7.5.1
Opleiding
68
7.5.2
Kennisoverdracht en -uitwisseling
68
7.5.3
Bescherming intellectuele eigendom
69
7.6
Voordeel open broncode ten opzichte van gesloten broncode 69
8. Interdependenties in community source
71
8.1
Vergelijking conditional open source en community source
71
8.2
Vergelijking community source en open source
72
8.2.1
Kenmerken
72
8.2.2
Gevolgen
74
8.2.3
Adoptie
75
9. Beoordeling resultaat
79
9.1
Voor- en nadelen voor de partner
79
9.2
Voor- en nadelen voor de gebruiker
81
9.3
Voor- en nadelen voor de auteursrechthebbende
82
10. Discussie en aanbevelingen
85
11. Referenties
87
12. Bijlage: The Open Source Definition
97
13. Bijlage: SugarCRM
101
14. Bijlage: Interview TeamSoft
103
<5
1
Inleiding
De laatste jaren is het fenomeen open source software (OSS) sterk in opkomst. Voor consumenten is dit het meest merkbaar doordat een groot aantal computerprogramma’s gratis zijn te
downloaden van internet. Voorbeelden hiervan zijn de web-browser Mozilla Firefox, het officeprogramma OpenOffice en het besturingssysteem Linux. Voor softwareontwikkelaars zijn opensourceprogramma’s interessant omdat de broncode van deze programma’s met iedereen gedeeld wordt. Ze is niet alleen in te zien, maar ook te wijzigen en verder te verspreiden. Voor softwareontwikkelaars betekent dit onder meer dat ze de werking van deze programma’s naar eigen inzicht aan kunnen passen. Dit delen van broncode was in de eerste jaren van softwareontwikkeling heel gebruikelijk. Software werd in deze tijd voornamelijk uitgevoerd door wetenschappers en ingenieurs, werkzaam bij universiteiten of bedrijfslaboratoria. In de onderzoekscultuur waar zij deel van uit maakten was het vanzelfsprekend de software die ze geschreven hadden te delen met anderen. (Von Hippel en Von Krogh, 2003)
Sinds de commercialisering van softwareont-
Desalniettemin gebeurt het steeds vaker dat
wikkeling in het begin van de jaren tachtig is
door softwareproducenten toch meer openheid
het delen van broncode niet meer gebruikelijk.
wordt gegeven, vaak onder druk van klanten
Commerciële softwareproducenten beschou-
of de overheid. Zo laat Microsoft, een fervent
wen de broncode van hun software als hun
tegenstander van het open-sourcefenomeen,
meest kostbare bezit. Concurrenten, afnemers
met haar Shared Source Initiative bepaalde derde
en soms zelfs het eigen personeel mogen onder
partijen onder strikte voorwaarden delen van
geen beding de broncode inzien. Met de bron-
haar broncode inspecteren. De roep van klan-
code in handen kunnen concurrenten immers
ten om meer openheid is goed te begrijpen ge-
de technologie in hun eigen producten verwer-
zien de toenemende afhankelijkheid van com-
ken en raakt de uitvinder een mogelijk concur-
putersystemen. Voor sommige klanten is het
rentievoordeel kwijt. Klanten kunnen met de
onacceptabel dat ze geen enkel inzicht hebben
broncode buiten de originele ontwikkelaar om
in de interne werking van software waarvan ze
de software aanpassen aan hun wensen, of kun-
afhankelijk zijn.
nen dit laten doen.
<7
Omdat bedrijven slechts beperkte middelen, kennis en competenties hebben gebeurt het dat kansen voor hun producten verwaarloosd of niet onderkend worden. Om de benodigde middelen, kennis en competenties te verkrijgen wordt in sommige gevallen samenwerking
1.1
Aanleiding
Sinds begin 1998 werk ik bij Outdare Internet Services in Rotterdam, waar ik me bezig houd met het programmeren van webapplicaties op basis van open-sourceproducten.
gezocht met andere bedrijven. Voor software-
In februari 2000 heb ik een eerste versie van
bedrijven is dit niet anders. Door bijvoorbeeld
het door mij ontwikkelde programma Tunez op
samen te werken met andere softwarebedrijven
sourceforge.net geplaatst, een ontwikkelings-
kunnen producten op elkaar afgestemd wor-
platform voor open-sourceprojecten1. Tunez is
den, zodat de waarde van deze producten stijgt
een webapplicatie die het mogelijk maakt voor
voor de gebruikers. Door samen te werken met
meerdere gebruikers te stemmen voor de mu-
een brancheorganisatie kan geleerd worden wat
ziek die ze op dat moment willen horen. De
de behoeftes van bedrijven in die branche zijn
stemmen beïnvloeden de speellijst die één voor
en kan het productenaanbod daar op afgestemd
één wordt afgelopen door het programma dat
worden. Door samen te werken met een bedrijf
de muziek afspeelt. De enthousiaste reacties en
dat software voor andere bedrijven implemen-
feedback van mensen die Tunez uitprobeerden
teert kan de afzet vergroot worden en kan meer
hebben erg geholpen in de verdere ontwikkeling
geleerd worden over de behoeftes van klanten.
van Tunez. Niet lang na de introductie kwamen
Bij samenwerking zoals in deze voorbeelden
andere ontwikkelaars met compleet nieuwe
wordt doorgaans de broncode van de software
functionaliteit zoals andere stemsystemen, in-
niet gedeeld met de partner of de gebruikers.
tegratie met intranetsystemen en het geschikt maken voor andere besturingssystemen dan Linux. Stuk voor stuk waren dit uitbreidingen die
De behoefte van klanten aan meer openheid en de toenemende populariteit van open source software enerzijds en de behoefte aan samenwerking met andere bedrijven anderzijds werpt de vraag op wat de voor- en nadelen zouden zijn van meer openheid en het delen van broncode tussen samenwerkende bedrijven en klanten, voor die bedrijven en hun klanten.
voor mijzelf en de andere gebruikers zeer nuttig waren, maar die er nooit gekomen waren, als de applicatie geen open source was geweest. Voor mij persoonlijk was open source dus een uitkomst. Tunez is inmiddels meer dan 20.000 keer gedownload en heeft naar schatting ongeveer 3000 actieve gebruikers. Inmiddels is de ontwikkeling grotendeels overgenomen door drie informaticastudenten uit de Verenigde Staten, omdat ik er zelf geen tijd meer voor had.
1
8>
zie http://tunez.sourceforge.net
Mijn professionele en persoonlijke ervaring met open source hebben de interesse in het delen van broncode gewekt. De directe aanleiding voor dit onderzoek echter, is mijn stage bij Media Nieuwe Stijl (MNS) in Rotterdam. In de loop
1.3
Vraagstelling
Wat zijn de voor- en nadelen van het delen van broncode met de deelnemers in een gesloten software-innovatienetwerk?
der jaren hebben zij een applicatieraamwerk ontwikkeld dat ingezet kan worden voor het bouwen van websites en webapplicaties. MNS
Om deze vraag te beantwoorden moet eerst antwoord worden gegeven op deze deelvragen:
wilde samen gaan werken met andere bedrijven
1.
om de investering in deze technologie verder
Wat wordt verstaan onder het delen van broncode?
te gelde te maken. Een praktisch probleem van 2.
technologische samenwerking was dat een groot
Wat wordt verstaan onder een gesloten innovatienetwerk?
gedeelte van de software geschreven was in een programmeertaal waarvan de broncode moei-
3.
lijk af te schermen is voor de partner, waardoor
Wat is het gevolg van het delen van broncode voor deler en ontvanger?
deze inzicht zou krijgen in de precieze werking
4.
van de technologie. Als de software wel afge-
Zijn deze gevolgen voor- of nadelen voor de deelnemers van een gesloten
schermd werd was de software voor de partner
software-innovatienetwerk?
te weinig flexibel. MNS vroeg zich af welke voor- en nadelen het delen van de broncode met een partner had. Hierop is in de stageopdracht
1.4
Onderzoeksgebied en aanpak
niet verder ingegaan, omdat deze beperkt was tot het in kaart brengen van mogelijke vormen en typen van samenwerking met partners.
1.4.1
Onderzoeksgebied
Onderzoeksgebied is het effect van het open-
Omdat ik het wel of niet delen van broncode een
stellen van de broncode van software door een
interessant vraagstuk vind en naar mijn mening
commerciële organisatie binnen een netwerk
meer ICT-bedrijven met dit vraagstuk worste-
van commerciële organisaties die zich bezig-
len, heb ik besloten mijn afstudeerscriptie hier
houden met de ontwikkeling of verkoop van
aan te wijden.
software of aanvullende diensten. De verdere afbakening van het soort netwerk wordt bespro-
1.2
Doelstelling
ken in hoofdstuk 5.
Het doel van deze scriptie is een onderbouwing te geven voor de beslissing van softwarebedrijven om wel of niet de broncode te delen met hun partners en klanten.
<9
1.4.2
Onderzoeksaanpak en -opzet
Over samenwerking in netwerken, innovatie
in figuur 1.1.
en open source is veel geschreven. De focus bij
De eerste vier volgende hoofdstukken vormen
het onderzoek naar het open-sourcefenomeen
de theoretische basis. In hoofdstuk 2 wordt in-
ligt vaak op de motivatie van individuen en be-
gegaan op de aard van software in het algemeen
drijven om te participeren in de open-sourcege-
en broncode in het bijzonder. Het doel van dit
meenschap of op de manieren waarop bedrijven
hoofdstuk is inzicht te krijgen in wat software
geld kunnen verdienen met open-sourceproduc-
en broncode is en wat het anders maakt dan an-
ten. Wat ontbreekt is onderzoek naar de gevol-
dere goederen. Het daaropvolgende hoofdstuk
gen van het delen van broncode tussen samen-
is gewijd aan het reeds genoemde open-source-
werkende bedrijven in een gesloten omgeving,
fenomeen. Dit wordt uitgebreid behandeld om-
zonder dat de broncode publiek gemaakt wordt,
dat dit het beste voorbeeld is van het delen van
zoals bij open source. Dit onderzoek is derhalve
broncode. De nadruk bij de behandeling van
exploratief van aard. Dit betekent dat niet direct
open source ligt op commerciële participanten
getest kan worden of een bepaalde theorie om-
omdat de deelnemers in het innovatienetwerk
trent het effect van open broncode juist is, maar
zoals bedoeld in de vraagstelling ook commer-
dat deze eerst ontwikkeld moet worden.
ciële organisaties zijn. Hoofdstuk 4 behandelt
Figuur 1.1: Structuur van de scriptie
10 >
De structuur van deze scriptie is weergegeven
de motieven van bedrijven om met andere bedrijven te gaan samenwerken. Dit wordt behandeld omdat het bij de uiteindelijke beoordeling van het resultaat noodzakelijk is om te weten wat het doel van samenwerking is. In hoofdstuk 5 wordt verder ingegaan op hoe bedrijven organisatorisch kunnen samenwerken en zal het innovatienetwerk en het delen van broncode
1.5 Wetenschappelijke en bedrijfskundige relevantie Zoals eerder in de inleiding is aangegeven is er over het specifieke gevolg van het delen van broncode in een gesloten omgeving niet veel bekend. Deze scriptie poogt op dit gebied een bijdrage te kunnen leveren.
daarbinnen zoals genoemd in de vraagstelling
De beantwoording van de vraagstelling is be-
afgebakend worden. Het delen van broncode
drijfskundig relevant, omdat softwarebedrijven
binnen een gesloten softwareinnovatienetwerk
op dit moment geconfronteerd worden met een
zal vanaf daar community source genoemd wor-
veranderende houding ten opzichte van het de-
den Dit hoofdstuk gaat ook kort in op hoe de
len van broncode. Bedrijven weten vaak niet
samenwerking er op technisch gebied uitziet.
hoe ze hier op moeten reageren. Door in kaart
In hoofdstuk 6 worden de interdependenties die gevonden zijn in hoofdstuk 2 en 3 weergegeven in een conceptueel model. Hoofdstuk 7 beschrijft een gevalstudie van TeamSoft, een jong
te brengen wat de voor- en nadelen zijn van het delen van broncode kunnen bedrijven een beter gemotiveerde keuze maken voor het al dan niet delen van de broncode van hun software.
Nederlands softwarebedrijf dat actief is met de ontwikkeling van software ter ondersteuning van bedrijfsprocessen en zij deelt de door haar ontwikkelde broncode met haar partners en klanten. Deze case vormt samen met hoofdstuk 6 de basis van het achtste hoofdstuk. Dit hoofdstuk begint met een empirische analyse van de case, hierbij zal bekeken worden in hoeverre de gevonden interdependenties uit de case gegeneraliseerd kunnen worden. Hoofdstuk 9 vormt het einde van de analyse en geeft door middel van een beoordeling van het resultaat voor de verschillende deelnemers in het innovatienetwerk het antwoord op de vraagstelling. Hoofdstuk 10 tenslotte dient voor discussie en
Het mediabericht in tekstkader 1.1 beschrijft de aankondiging van softwarebedrijf VMware op 10 augustus van dit jaar, dat zij de broncode van haar belangrijkste product gaat openstellen voor haar partners. Dit houdt in dit geval in dat externe organisaties waar zij mee samenwerkt de broncode mogen bekijken zonder dat zij hiervoor hoeven te betalen en dat zij door hen ontwikkelde code mogen aandragen voor opname in het product. Dit zeer recente bericht is een voorbeeld van de bedrijfskundige relevantie, het geeft aan dat bedrijven nadenken over en experimenteren van het openstellen van de broncode van hun software.
aanbevelingen.
< 11
Virtualization juggernaut opens code to partners By Matt Stansberry 10 Aug 2005 Virtualization software company VMware Inc. said Monday it opened up the source code to its flagship product, the VMware ESX Server, to its partners. The Palo Alto, Calif.-based subsidiary of EMC Corp. released its code to a large number of x86 vendors, including Advanced Micro Devices, BEA Systems, Inc. BMC Software Inc., Broadcom Corp., Cisco Systems Inc., Computer Associates International Inc., Dell Inc., Emulex Corp., Hewlett-Packard Co., IBM, Intel Corp., Mellanox Technologies, Novell Inc., QLogic and Red Hat Inc. The initiative, called VMware Community Source, provides industry partners with an opportunity to access VMware ESX Server source code under a royalty-free license. Those vendors can contribute shared code or create binary modules, and can participate in the governance of VMware ESX Server through an architecture board. VMware said this will accelerate the development of virtualization-ready applications and expand interoperability with VMware’s platform.
Tekstkader 1.1: Mediabericht over VMware Community Source (Stansberry, 2005
12 >
2
Software
Software is in veel opzichten een uniek product, zowel voor de gebruikers als voor de producenten ervan. In dit hoofdstuk zal software eerst bekeken worden vanuit technisch perspectief,
om een idee te krijgen hoe broncode en software zich tot elkaar verhouden en hoe van broncode door een computer uitvoerbare software gemaakt wordt. Daarna zal dieper worden ingegaan op de aard van broncode door het te benaderen vanuit kennisperspectief. Tot slot wordt software behandeld vanuit economisch perspectief. Het doel van dit hoofdstuk is inzicht te geven in de aard van software en het belang van broncode.
2.1
Technisch perspectief
Technisch gezien is software het programma
van machinecode zijn. Het transformatieproces
dat door de hardware uitgevoerd wordt. Dit
van broncode naar machinecode heet compile-
programma kan in verschillende vormen op de
ren en wordt gedaan door middel van een com-
hardware geïnstalleerd staan en verspreid wor-
piler. De machinecode is in een vorm die voor
den, met als uitersten de broncode enerzijds en
mensen zeer moeilijk interpreteerbaar is, wijzi-
machinecode anderzijds.
gen van machinecode is nog vele malen moei-
Het programma kan in principe alleen gewijzigd worden als de broncode beschikbaar is. De broncode is een verzameling van bestanden waarin het programma geschreven staat in een door mensen leesbare en interpreteerbare vorm.
lijker. Ontwikkelaars van software die willen voorkomen dat anderen hun code begrijpen of kunnen wijzigen zullen om deze reden de software alleen in gesloten vorm (in machinecode) verspreiden (Simon, 1996).
De code is vaak voorzien van documentatie,
In welke vorm de software geïnstalleerd staat
een korte beschrijving wat en hoe een bepaald
op de hardware hangt af van de programmeer-
stuk code werkt en hoe het aangesproken dient
taal waarin het programma is geschreven. De
te worden.
meeste software staat in gecompileerde vorm
Op het moment dat het programma door de hardware uitgevoerd wordt moet het in de vorm
geïnstalleerd, maar bijvoorbeeld software geschreven in Java is in bytecode, een vorm van
< 13
machinecode, die nog geen hardware- en plat-
Broncode is in de eerste plaats informatie, het
formspecifieke instructies bevat. Deze bytecode
is kennis die kan worden overgedragen zon-
wordt op het moment van uitvoeren geladen in
der verlies van integriteit, wanneer de ontvan-
een virtual machine. Programma’s geschreven
ger de syntactische regels voor het ontcijferen
in populaire webscriptingtalen als PHP, Python
kent (Kogut en Zander, 1992). De syntactische
en ASP staan in de originele broncode geïnstal-
regels voor het ontcijferen vormen de program-
leerd en worden op het moment van uitvoeren
meertaal. Iemand die deze taal beheerst kan in
geïnterpreteerd door de webserver.
ieder geval het programma lezen en van elke
Software valt grofweg onder te verdelen in systeemsoftware en applicatiesoftware. Systeemsoftware omvat alle basissoftware die de applicaties nodig hebben om te kunnen werken
regel begrijpen wat er staat. Broncode is een expliciete beschrijving van hoe een programma werkt, regel voor regel wordt exact beschreven wat het programma moet doen.
zoals besturingssystemen en programma’s die
Het beheersen van de programmeertaal waar-
randapparatuur
Applicatiesoft-
in de software geschreven is, is geen garantie
ware is alle software die gebruikers gebruiken
voor het daadwerkelijk begrijpen van de bron-
om specifieke taken uit te voeren, zoals tekst-
code. Dit komt doordat voor de creatie en het
verwerkers en databases. Met de opkomst van
onderhoud van software veel taciete kennis (tacit
het internet wordt web-based software steeds
knowledge) nodig is. Taciete kennis, of impli-
belangrijker. Het voordeel hiervan is dat de
ciete kennis zoals het ook wel genoemd wordt
software centraal beheerd kan worden en dat
is kennis die niet expliciet is, doordat het niet
de gebruiker geen andere software op zijn com-
gecodificeerd is of omdat het niet te codifice-
puter geïnstalleerd hoeft te hebben dan een web
ren valt. Know-how is een voorbeeld van tacie-
browser.
te kennis, het bestaat uit zich eigen gemaakte
aandrijven.
vaardigheden of expertise die het mogelijk ma-
2.2 Kennisperspectief
ken te weten hoe taken gemakkelijk en doelmatig uitgevoerd kunnen worden (Von Hippel,
14 >
Broncode wordt wel eens de blauwdruk van de
1988; Johnson en Lundvall, 2001) Motoriek is
software genoemd, verwijzend naar het con-
een voorbeeld van kennis die niet geleerd wor-
structieplan voor gebouwen en andere objec-
den uit een boek, omdat het enerzijds moeilijk
ten. (Edwards, 2001) De blauwdruk beschrijft
is dit expliciet te formuleren en anderzijds al-
in detail hoe het object gemaakt dient te worden
leen door oefening en ervaring te leren valt.
en is in die zin een correcte metafoor. Met de
Tegenover taciete kennis staat expliciete kennis.
broncode in handen en met behulp van de juiste
Deze vorm van kennis omvat informatie of in-
gereedschappen, materialen en kennis kan het
structies die geformuleerd kunnen worden in
eindproduct gemaakt worden.
woorden of symbolen en daarom opgeslagen,
gekopieerd en overgedragen kunnen worden
noodzakelijk om een taak (bijvoorbeeld pro-
door onpersoonlijke middelen als geschreven
grammeren) goed en doelmatig uit te voeren,
documenten en computerbestanden. (MacKen-
maar programmeurs die weten waarom bijvoor-
zie & Spinardi, 1995) Expliciete kennis wordt
beeld een bepaald component bepaalde resulta-
onthuld door het te communiceren. Taciete ken-
ten geeft zijn in principe in staat betere keuzes
nis wordt onthuld wanneer het toegepast wordt.
te maken ten aanzien van bijvoorbeeld wijzi-
(Grant, 1996; Johnson en Lundvall, 2001)
gingen of uitbreidingen dan programmeurs die
Hoe complexer een programma is, hoe meer taciete kennis nodig is om het programma te
slechts weten dat dat component die resultaten teruggeeft maar niet waarom.
begrijpen. Een deel hiervan bestaat uit erva-
Know-who is het weten wie bepaalde kennis
ring. Volgens Wood (1986) speelt ervaring een
heeft, bijvoorbeeld wie welk onderdeel van de
belangrijke rol in softwareontwikkeling omdat
applicatie geschreven heeft, wie bepaalde tech-
het invloed heeft op het vermogen van een indi-
nologieën beheerst en wie de eisen en specifica-
vidu om complexe informatie te verwerken.
ties kent.
Naast algemene programmeerervaring en er-
De grote aanwezigheid en het grote belang van
varing met de in de software gebruikte techno-
taciete kennis bij softwareontwikkeling is tot op
logieën speelt ook de kennis van de applicatie
zekere hoogte te vergelijken met de ontwikke-
zelf een grote rol. De kennis van de applicatie
ling van nucleaire wapens zoals beschreven
omvat know-how, know-why, know-who en be-
door MacKenzie en Spinardi (1995) als het
oordelingsvermogen.
gaat om het belang van beoordelingsvermogen.
Om software te kunnen ontwikkelen is allereerst know-how nodig in de vorm van programmeervaardigheden en beheersing van de programmeertalen. Om bestaande software te kunnen wijzigen is naast de broncode, ook begrip nodig van hoe de code opgezet is, hoe componenten interacteren enzovoort.
Voor beide geldt dat uitvoerenden te maken kunnen hebben met een grote complexiteit en dynamiek, waar men niet altijd precies kan weten wat de consequentie zal zijn van een verandering of ingreep in het systeem. Door ervaring kan het beoordelingsvermogen voor dergelijke zaken groeien, wat een erg belangrijke vorm van taciete kennis is.
Know-why slaat op het begrip van de principes die ten grondslag liggen aan een bepaald fenomeen (Garud, 1997). Bohn (1994) plaatst know-why op de één na hoogste plek op de kennisschaal die loopt van complete ignorance naar complete knowledge. Know-why geeft een dieper begrip dan know-how. Know-why is niet altijd
2.2.1
Expliciet maken van taciete kennis
Deze taciete kennis kan expliciet gemaakt worden door het te codificeren. Dit kan gedaan worden door de code te becommentariëren of de technische werking van het programma te
< 15
documenteren. Het becommentariëren is het
waarde van de documentatie snel. Een bijko-
opnemen van commentaar, verspreid door de
mend probleem is dat niet alle programmeurs
code zelf, waarin staat op welke manier de code
even goed kunnen of willen documenteren als
aangeroepen en gebruikt kan worden, wat er
dat ze programmeren.
precies gebeurt, wat het doel er van is en waarom het geschreven is zoals het is. Het verschil
2.2.2
Het delen van broncode
met technische documentatie is, dat deze als
Onder het delen van broncode in de vraagstel-
een los document wordt verspreid en dat het de
ling wordt verstaan het delen van de broncode
code op een hoger niveau beschrijft, het is geen
door de ontwikkelaar er van met een andere
commentaar op specifieke stukken code, maar
partij. Zoals in deze paragraaf is gesteld is bron-
een uitleg hoe de stukken code aangeroepen
code een vorm van kennis. Door de broncode te
worden en hoe ze in elkaar grijpen.
delen met een andere partij komt deze kennis in
Als meerdere mensen aan dezelfde software
handen van de andere partij.
werken is het expliciet maken van het hoe en waarom door middel van documentatie essentieel, zeker als deze mensen geen of weinig interpersoonlijk contact hebben. Maar ook voor de onderhoudbaarheid van de software is het expliciet maken van taciete kennis erg belangrijk, omdat deze snel verloren gaat doordat mensen van baan veranderen of de kennis simpelweg vergeten.
Economisch perspectief
Een economische onderverdeling kan gemaakt worden door onderscheid te maken tussen maatwerk en pakketsoftware. Maatwerk is software die ontwikkeld wordt voor een specifieke klant en probeert te voldoen aan de eisen en specificaties van de gebruikers. Pakketsoftware daarentegen is gestandaardiseerde software die
Volgens Cowan et. Al. (1999) is het wel of niet
voor eigen risico wordt ontwikkeld en bedoeld
codificeren van taciete kennis een kosten-ba-
is voor de externe verkoop. Het doel is zoveel
tenanalyse, in principe kan alle taciete kennis
mogelijk kopieën van de software te verkopen.
expliciet gemaakt worden, maar daar hangt wel
De functionaliteit zal in de meeste gevallen zo
een prijskaartje aan. Dat geldt ook voor het do-
generiek mogelijk zijn, zodat het geschikt is
cumentatieproces van software. Documenteren
voor een breed publiek.
kost veel tijd en het heeft meestal geen direct economisch voordeel (tenzij het in opdracht van een klant is, die ervoor betaald). Als de software na oplevering gewijzigd wordt, dient ook de documentatie aan de wijzigingen aangepast te worden, als dat niet gebeurt daalt de
16 >
2.3
Economisch gezien is software een informatiegoed. De creatie van de eerste eenheid van informatiegoederen gaat gepaard met hoge kosten, maar de marginale kosten van een reproductie zijn erg laag. (Shapiro en Varian, 1998) De hoge initiële kosten worden veroorzaakt
door de hoge arbeidsintensiteit. De complexiteit
sument voordeel heeft aan het feit dat andere
van het ontwikkelen van software zorgt ervoor
hetzelfde product gebruiken wordt netwerkexter-
dat de ontwikkeling veel tijd kost en bovendien
naliteiten genoemd. (Katz en Shapiro, 1986)
zijn ontwikkelaars duur (Brooks, 1987). De marginale kosten zijn echter bijna gelijk aan de verpakkingskosten en distributiekosten. Met het gebruik van het internet als distributiemedium zijn de marginale kosten zelfs nagenoeg verwaarloosbaar.
De consument heeft een voorkeur voor software die gezien wordt als de standaard (Farrell,1985). Het voordeel van het gebruik van de dominante standaard is dat de gebruiker de grootste kans op compatibiliteit met andere gebruikers heeft. Bovendien is de kans het grootst
De kostenstructuur van software is de reden
dat het product verder ontwikkeld zal worden
dat maatwerk zoveel duurder is dan pakketsoft-
en dat complementaire producten beschikbaar
ware, bij maatwerk moeten de initiële kosten in-
zullen komen. De voorkeur van de consument
eens worden terugverdiend, terwijl deze kosten
voor de dominante standaard zorgt er voor dat
bij pakketsoftware uitgesmeerd worden over
de producent een hogere prijs kan vragen. De
meerdere eenheden.
waarde van software voor de consument is de
Een andere eigenschap van informatiegoederen is dat de waarde ervan pas wordt ervaren tijdens
som van de intrinsieke waarde (de features) en de netwerkvoordelen. (Brynjolfsson, 1996)
de consumptie. Voor gebruik is deze moeilijk te
Een grote install-base (aantal installaties van de
beoordelen omdat de fysieke verschijningsvorm
software) is voor producenten van pakketsoft-
niks zegt over de werking van het product. (Va-
ware dus belangrijk omdat de initiële kosten
rian, 1998) Dit geldt ook voor software, de ver-
hoog zijn en omdat het mogelijk maakt een pre-
pakking of gebruikersinterface zegt op zichzelf
mium te kunnen vragen. Voor externe ontwik-
niets over de waarde die het product kan heb-
kelaars is veel gebruikte software ook interes-
ben voor de gebruiker.
sant omdat dit een markt creëert voor aanvul-
Daarnaast is software een niet-rivaliserend
lende producten.
goed, een ieder kan het goed gebruiken zonder dat het ten koste gaat van het nut voor een andere consument. (Von Hippel en Von Krogh, 2003) Sterker nog, bij veel software heeft de consument er juist baat bij dat andere consumenten hetzelfde product gebruiken. Hij kan dan gegevensbestanden geproduceerd door die software uitwisselen met andere gebruikers van die software. Het verschijnsel dat de ene con-
2.4 Conclusie Om software te kunnen wijzigen is de oorspronkelijke broncode nodig. De broncode is een set van bestanden die in voor mensen begrijpelijke taal de instructies bevatten voor de exacte werking van de software. De broncode wordt omgezet in door computers uitvoerbare bestanden, de machinecode. Deze machinecode is de soft-
< 17
ware zoals gebruikers deze in handen krijgen. De broncode is op zichzelf een vorm van expliciete kennis. Om de broncode te kunnen wijzigen is ook taciete kennis nodig. Hoe beter de taciete kennis over de broncode ontwikkeld is, hoe efficiënter wijzigingen gedaan kunnen worden. Taciete kennis is voor een deel expliciet te maken door de broncode de becommentariëren en te documenteren. Softwareontwikkeling is arbeidsintensief en vereist specifieke kennis in de vorm van informatie en know-how. Dit maakt de initiële investering hoog, terwijl de kosten voor reproductie laag zijn. Om het rendement op deze investering zo groot mogelijk te maken moet de software zo veel mogelijk verkocht worden. Software die veel gebruikers heeft verworven is aantrekkelijker voor potentiële gebruikers.
18 >
3
Open source
In het vorige hoofdstuk is behandeld wat broncode is en is gesteld dat broncode door de ontwikkelaar in het algemeen niet gedeeld wordt met anderen. In de inleiding is al kort gesproken over open source, een softwareontwikkelingsmodel dat gebaseerd is op de vrije beschikbaarheid van broncode en de uitwisseling daarvan. Het doel van dit hoofdstuk is duidelijk te maken wat voor ontwikkelaars en gebruikers de vooren nadelen zijn van het delen van broncode in een open software-innovatienetwerk. De uitkom-
sten hiervan zullen in een later hoofdstuk gebruikt worden om mede te bepalen wat de voor- en nadelen zijn van het delen van broncode in een gesloten software-innovatienetwerk.
3.1
Opbouw van het hoofdstuk
Dit hoofdstuk start met de definitie van open
voortgebracht is dat bij OSS wel het geval. OSS
source, aan de hand hiervan zullen drie bepa-
wordt niet alleen gebruikt door bedrijven, maar
lende kenmerken worden vastgesteld. Na een
ze dragen er ook aan bij of verspreiden hun ei-
korte bespreking van de belangrijkste open-
gen software als OSS. De motieven hiervoor
sourcelicenties komt de open-sourcegemeen-
zijn aanwijzingen voor de voor- en nadelen die
schap aan bod. In deze paragraaf zullen enkele
zij hiervan ondervinden of verwachten. Daar-
begrippen worden verduidelijkt en zal worden
om zal de motivatie voor open-sourceparticipa-
ingegaan op de samenstelling en werking van
tie uitgebreid besproken worden.
de open-sourcegemeenschap.
Omdat de onderzoeksvraag zich richt op com-
Hierna wordt open source benaderd vanuit eco-
merciële organisaties ligt in dit hoofdstuk de
nomisch perspectief. In deze paragraaf zal blij-
nadruk ook op commerciële organisaties. De
ken dat open source software (OSS) een publiek
laatste paragraaf is gewijd aan de nadelen die
goed is. Hoewel publieke goederen doorgaans
bedrijven ondervinden als ze door hen ontwik-
niet door commerciële organisaties worden
kelde software als OSS willen verspreiden.
< 19
die onder een open-sourcelicentie verspreid
3.2 Definitie van open source De definitie van open source is door The Open Source Initiative (OSI) vastgelegd. De volledige tekst hiervan is opgenomen als bijlage (zie hoofdstuk 12). Deze definitie stelt enige criteria waaraan de bepalingen van de softwarelicentie moeten voldoen om zich open source te mogen noemen. Deze criteria zijn er op gericht om beperkingen die in de licentie voor zouden kunnen komen, wat betreft openheid van de broncode, vrijheid van de gebruiker en herverspreiding van de software uit te sluiten. De criteria zullen aan de hand van deze kenmerken besproken worden. Een overzicht van de criteria geordend naar kenmerk is te vinden in tabel 3.1. 3.2.1
wordt, maar anderen mogen dat ook. Dat deze software meestal gratis is komt omdat de licentie volgende de definitie vrije herverspreiding van de originele software moet toestaan. Dit betekent dat degene die de software ontvangt deze, zonder verdere toestemming van of betaling aan de copyrighthouder, aan anderen mag verspreiden (1. free redistribution). Ook het verspreiden van modificaties en afgeleide werken moet toegelaten zijn, (3. derived works) al mag wel geëist worden dat deze afzonderlijk en onder een andere naam verspreid worden (4. Integrity of The Author’s Source Code). De licentie waaronder de software verspreid is werkt automatisch tegen een ieder aan wie de software wordt herverspreid (7. Distribution of License).
Vrije herverspreidbaarheid
Hoewel nagenoeg alle OSS gratis verkrijgbaar is, is dat geen bepalend kenmerk van open source (Stallman, 1996). Het is de copyrighthouder toegestaan om geld te vragen voor zijn software
Het is niet verplicht de broncode en de gecompileerde code altijd samen te verspreiden, maar het mag een gebruiker niet meer moeite en geld kosten om de broncode te verkrijgen dan de gecompileerde code.
Kenmerk
Criteria uit de definitie
vrije herverspreidbaarheid
1. Free Redistribution 3. Derived Works
4. Integrity of The Author’s Source Code vrijheid
7. Distribution of License 3. Derived Works
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavor 8. License Must Not Be Specific to a Product
9. License Must Not Restrict Other Software openheid Tabel 3.1: Categorisering criteria open source
20 >
10. License Must Be Technology-Neutral 2. Source Code
3.2.2
Vrijheid
3.3
Licenties
De definitie dwingt enkele vrijheden voor de
Er bestaat een grote verscheidenheid aan licen-
gebruiker af. Zo mag de licentie niet bepalen
ties die voldoen aan de genoemde criteria en
voor welk doel of door wie de software wel of
die door het OSI goedgekeurd zijn. De meest
niet gebruikt mag worden, er mag ook niet ge-
gebruikte licenties zijn de GNU General Pu-
steld worden dat de software alleen in combina-
blic License (GPL), de Berkeley Software Dis-
tie met een specifiek product of technologie ge-
tribution License (BSD) en de Mozilla Public
bruikt mag worden en ze mag andere software
License (MPL).
niet beperken (5. No Discrimination Against Persons or Groups, 6. No Discrimination Against Fields of Endeavor, 8. License Must Not Be Specific to a Product, 10. License Must Be Technology-Neutral en 9. License Must Not Restrict Other Software). Deze criteria zorgen er voor dat de software naar believen aangepast mag worden. De herverspreidbaarheidsbepalingen staan de gebruiker toe ook de aangepaste versie te verspreiden (3. derived works). 3.2.3
Openheid
OSS is software waarvan de broncode beschikbaar is voor de gebruiker. Beschikbaarheid alleen is niet genoeg, de definitie eist ook dat de broncode in een vorm moet zijn waar een programmeur mee uit de voeten kan, het mag niet expres zo gewijzigd worden dat het voor een programmeur lastig wordt om de code te begrijpen, bijvoorbeeld door namen van functies en variabelen in de broncode cryptische namen te geven. (2. Source Code) (OSI, 2005)
De GPL geeft gebruikers de rechten om de software te verkopen, kopiëren en wijzigen, zolang de gebruiker dezelfde rechten ook doorgeeft. Als de gebruiker slecht wijzigingen doet of laat doen voor eigen gebruik hoeft de broncode niet openbaar gemaakt te worden (Henkel, 2003). Wijzigingen aan GPL software vallen automatisch ook onder deze licentie, als men de software in gewijzigde vorm wil herverspreiden moet de broncode van de wijzigingen ook openbaar gemaakt worden. Dit geldt ook als GPL broncode gebruikt wordt in een ander product, het gehele product valt dan automatisch onder de GPL. Als dit product openbaar gemaakt wordt, dan moet de gehele broncode hiervan openbaar gemaakt worden. Wijzigingen voor eigen gebruik hoeven niet openbaar gemaakt te worden. De openbaarmakingvereiste van de GPL wordt copyleft genoemd, het tegenovergestelde van copyright. Waar copyright het reproduceren tegengaat, zorgt copyleft juist dat alle gebruikers zowel het originele als gemodificeerde werk kunnen gebruiken, wijzigen en herverspreiden. (Free Software Foundation, 2005) Het copyleftprincipe is de reden dat deze licentie door Microsoft viraal wordt genoemd,
< 21
de broncode die ‘besmet’ is met GPL-code moet
product te ontwikkelen zonder de broncode
in zijn geheel vrijgegeven worden.
daarvan vrij te geven.
De BSD licentie staat verspreiding en gebruik
Tabel 3.2 bevat een overzicht van deze licenties.
in welke vorm dan ook toe en kent dus geen
Ter vergelijking is ook het publieke domein op-
copyleft. Het is zelfs mogelijk afgeleide werken
genomen, code die hier onder valt is vrij door
onder een andere licentie te verspreiden of de
iedereen zonder beperkingen te gebruiken.
broncode te gebruiken in proprietary (gesloten) software. De oude BSD licentie had als vereiste
3.4 De open-sourcegemeenschap
dat in alle reclame-uitingen voor software waarin BSD code was gebruikt dit gebruik vermeld
De definitie van open source zegt niks over de
moest worden. In de laatste versie van deze li-
wijze waarop de software ontwikkeld wordt.
centie is de advertentieclausule verwijderd.
Toch kennen veel open-sourceprojecten een
De MPL tenslotte is speciaal ontwikkeld door Netscape toen zij de broncode van haar in ontwikkeling zijnde browser, Netscape Communicator 5 openbaar wilde maken. Het is een duale licentie, waarbij onderscheid gemaakt wordt tussen bronbestanden die onder een open-sour-
soortgelijk ontwikkelproces. Een open-sourceproject is de gebruikelijke naam voor het samenwerkingsverband van ontwikkelaars met als doel een bepaald OSS-product te creëren. Rond het project kan zich dan een community vormen van geïnteresseerden.
celicentie vallen en de delen die een gebruiker
Wanneer gesproken wordt over ‘de open source
zelf heeft toegevoegd. Men kan deze nieuwe
community’ wordt in ruime zin de verzameling
bestanden in gesloten vorm verspreiden als de
mensen en organisaties bedoeld die op de een
overige bestanden niet zijn gewijzigd. Dit stelt
of andere manier actief zijn met de ontwikke-
bedrijven in staat om uitbreidingen voor het
ling of het gebruik van OSS in het algemeen.
Licentie
Broncode kan opgenomen worden in gesloten software
GPL
nee
BSD
ja
LGPL
MPL
Publieke domein
Wijzigingen kunnen in gesloten vorm herverspreid worden
nee
ja
nee
nee
ja
ja
nee
ja
Tabel 3.2: Vergelijking open-sourcelicenties (Perens, 2002)
22 >
nee
Kan een nieuwe licentie krijgen
ja
ja
nee ja
De community in enge zin is de gemeenschap
te kunnen doen is het noodzakelijk goed ‘in de
die zich vormt rond een bepaald open-source-
code te zitten’, de ontwikkelaar moet zich een
project.
grote hoeveelheid taciete kennis eigen maken.
De open source community in ruime zin kan beschouwd worden als een netwerk van innovatienetwerken, de open-sourceprojecten. Anderzijds kan een open-sourceproject dus gezien worden als een partieel netwerk van de open source community.
Kleine verbeteringen en oplossingen voor foutjes (bug fixes) worden aangedragen door een grote diverse groep mensen. Om te bevorderen dat een grotere groep mensen aan de software kan ontwikkelen wordt de software vaak modulair opgebouwd. De functionaliteiten worden dan zoveel mogelijk onafhankelijk van elkaar
De structuur van en de coördinatie binnen een open source innovatienetwerk hangt sterk af van de initiator. Veel open-sourceprojecten zijn
gemaakt, zodat wijzigingen aan één stuk van de code geen gevolgen heeft voor andere delen. (Gawer en Cusumano, 2002)
wat Von Hippel (2001, 2002) user innovation networks noemt. Dit zijn netwerken die bestaan uit
3.4.1
gebruikers die zelf innoveren en de producten
De rollen binnen een open-sourceproject zijn
maken waar ze behoefte aan hebben. De ge-
in te delen in één van de volgende categorieën:
bruikers delen hun innovaties vrijelijk met de
coördinatoren, programmeurs, kwaliteitsbe-
andere gebruikers in het netwerk. Participatie
wakers en gebruikers. Eén actor kan meerdere
in een dergelijk netwerk is volkomen vrijwil-
rollen hebben binnen het project (Lattemann
lig. Dit betekent ook dat de coördinatie op een
en Stieglitz, 2005). Zoals al eerder aangegeven
andere manier gaat dan in bijvoorbeeld een
zijn in niet commerciële open-sourceprojecten
commerciële omgeving. Actoren kunnen niet
de ontwikkelaars ook gebruikers van de soft-
gedwongen worden om een bepaalde taak uit te
ware.
voeren, de taakverdeling moet tot stand komen door middel van consensus. De producenten van commerciële open source software projecten daarentegen zijn betaalde werknemers en kunnen veel beter dan vrijwilligers aangestuurd worden. De kans dat deze ontwikkelaars zelf gebruikers zijn is veel lager dan bij niet commerciële open-sourceprojecten. Het grootste gedeelte van de code in open-sourceprojecten wordt geschreven door een kleine kern ontwikkelaars. Om interne wijzigingen
Rollen
De maintainer is vaak degene die op het idee voor de software is gekomen, de initiator. De maintainer is het persoonlijke aanspreekpunt voor het project. Vaak is hij degene die het laatste woord heeft over welke functionaliteiten opgenomen zullen worden in de software. (Edwards, 2001) De release manager zorgt voor het vrijgeven van een nieuwe verbeterde versie. Hij zorgt niet alleen dat de software gedownload kan worden, maar zorgt vaak ook voor de interne coördi-
< 23
natie tijdens het toewerken naar een release.
aangelopen en daar een oplossing voor gevon-
Vaak wordt voorafgaand aan een release de
den hebben en deze vervolgens aandragen.
code afgetakt (branch), er wordt dan een kopie gemaakt van de huidige ontwikkelversie waar dan geen nieuwe functionaliteit aan toegevoegd mag worden en waaraan geen belangrijke interne wijzigingen mogen gebeuren. Fouten die ontdekt worden, worden wel opgelost. Op deze manier stabiliseert de code en kan er na enige tijd een stabiele, kwalitatief goede versie uitgebracht worden. Het werk aan de stam (de huidige ontwikkelversie, ook wel trunk genoemd) gaat vaak gelijktijdig door.
De actoren die niet programmeren maar wel op allerlei manieren waarde toevoegen aan het product noem ik kwaliteitsbewakers. Belangrijk voor de kwaliteit van software is het veelvuldig en systematisch testen van de software. Dit is de taak van de testers, zij vinden bugs, geven feedback en gaan na of bugs daadwerkelijk opgelost worden. Steeds meer groeit ook bij open source software het besef dat software een goede, heldere gebruikersinterface moet hebben. Dit is de taak van usability-experts. Gerelateerd aan
Het grootste gedeelte van het programmeer-
usability is accessibility, accessibility-experts
werk wordt gedaan door de core developers, de
controleren of de software ook geschikt is voor
ontwikkelaars die samen de kern van het ont-
mensen met een handicap, zoals slechtzienden.
wikkelteam vormen. Zij worden geholpen door
Andere kwaliteitsbewakers zijn de actoren die
bug fixers, meestal zijn dat gebruikers van de
bijvoorbeeld de grafische vormgeving verzor-
software die tegen een fout in de software zijn
gen of de handleiding schrijven.
Figuur 3.1: Economische classificatie van goederen (Aangepast van: Van Wendel de Joode et. al., 2002)
24 >
3.5 Open source vanuit economisch perspectief In het hoofdstuk ‘Software’ is software geclassificeerd als informatiegoed, wat onder meer betekent dat de initiële kosten van productie hoog zijn terwijl de marginale kosten erg laag zijn.
proportioneel groot zouden zijn. Voor gemeenschappelijke goederen geldt dat dit niet mogelijk is omdat het toewijzen van eigendomsrechten erg lastig is. (Selz, 1999) Ook uitsluitbare goederen kunnen worden onderscheiden naar consumptie, goederen met
Goederen zijn verder te onderscheiden door
niet-rivaliserende consumptie heten tol- of club-
deze in te delen naar consumptie en uitsluit-
goederen. Een voorbeeld hiervan is een toltun-
baarheid. Consumptie kan, zoals in paragraaf 2.3 reeds genoemd, rivaliserend of niet-rivaliserend zijn. Bij rivaliserende consumptie heeft de consumptie van het goed door de één invloed op de mogelijkheid tot consumptie ervan door
nel of tolweg. Uitsluitbare goederen waarvan de consumptie door de één consumptie door een ander uitsluit tenslotte worden privé-goederen genoemd. Veruit de meeste producten zijn privé-goederen.
iemand anders. Bij niet-rivaliserende consump-
Het probleem van gemeenschappelijke goede-
tie is dat niet het geval. Uitsluitbaarheid geeft
ren ligt voornamelijk aan de vraagkant, mensen
aan of gebruikers uitgesloten kunnen worden
zijn geneigd om te veel van de gemeenschappe-
van de consumptie. Deze indeling is schema-
lijke goederen voor zichzelf te gebruiken, zodat
tisch weergegeven in figuur 3.1.
er te weinig overblijft voor anderen. Bovendien
Goederen waarvan mensen niet uitgesloten kunnen worden zijn publieke goederen (ook wel collectieve goederen genoemd) en gemeenschappelijke goederen. Eén van de bekendste voorbeelden van een publiek goed is defensie, het leger verdedigt het hele land, niemand kan daar van uitgesloten worden en de verdediging van de één gaat niet ten koste van de verdediging van de ander. Gemeenschappelijke goederen zijn bijvoorbeeld water waarin iedereen kan vissen of bossen waarin iedereen hout kan kappen. Consumptie van de één gaat hierbij wel ten koste van de consumptie van de ander. De reden dat niemand van consumptie uitgesloten kan worden van publieke goederen is dat de kosten hiervan buiten-
vertonen veel mensen freeridergedrag, ze gebruiken te veel van de gemeenschappelijke goederen zonder er zelf aan bij te dragen. Dit fenomeen wordt wel the tragedy of the commons (tragedie van de meent) genoemd. (Hardin, 1977) Het probleem van publieke goederen ligt meer aan de aanbodkant. Omdat er via de markt geen goede opbrengst uit investeringen kan worden verwacht is het noodzakelijk dat het aanbieden van publieke goederen op een andere manier wordt aangemoedigd. De collectieve-actietheorie houdt zich bezig met de voorziening van publieke goederen door samenwerking van individuen in een groep. Het doel van de groep is het voortbrengen van het publiek goed, terwijl het doel van het individu het maximaliseren
< 25
van de persoonlijke welvaart is. Door de indi-
software een informatiegoed is, waardoor de
viduen een persoonlijke beloning te geven, op
marginale kosten minimaal zijn, maakt het
voorwaarde dat ze helpen de kosten te dragen
niet-rivaliserend. Het niet-rivaliserende karak-
die het bereiken van de doelen van de groep met
ter van OSS samen met de onmogelijkheid van
zich mee brengt, wordt het belang van het indi-
uitsluiting maakt dat OSS economisch gezien
vidu gelijk aan het belang van de groep en zul-
een publiek goed is. Het voortbrengen van OSS
len de groepsleden gemotiveerd zijn om het pu-
door niet-commerciële actoren is een voorbeeld
blieke goed voort te brengen. Deze beloning kan
van collectieve actie.
monetair zijn, maar ook op basis van reputatie, zoals in de wetenschap bijvoorbeeld gebruike-
3.6 Motivatie voor participatie
lijk is. (Olson, 1965; Levacic, 1991) Bedrijven en personen innoveren in de hoop daar geld mee te verdienen. Ze worden daarin aangemoedigd en beloond door de maatschappij die hen beschermt door middel van wetten die het intellectueel eigendom regelen. Voorbeelden hiervan zijn patenten, octrooien en auteursrechten. Deze wetten geven de innovator tot op zekere hoogte voor een bepaalde tijd exclusieve rechten voor het gebruik van de innovatie. Dit model om innovatie aan te moedigen en te belonen heet het private investment model.
worden bevredigd, in de meeste gevallen is dat door geld. Motivatie is intrinsiek als een activiteit wordt ondernomen voor het onmiddellijk bevredigen van een behoefte. Het kan voortkomen uit het plezier dat het uitvoeren van de activiteit geeft. Het kan ook voortkomen uit de behoefte een zelfgedefinieerd doel te bereiken. Tenslotte kan men zich genoodzaakt voelen zich te houden aan bepaalde normen. (Osterloh et al, 2001)
De innovator zal er in dit model alles aan doen
De motivatie om te participeren in een open-
om te voorkomen dat de door hem verworven
sourcegemeenschap is voor bedrijven anders
kennis uitlekt, alhoewel dat nooit in zijn geheel
dan voor individuele programmeurs. Laatst-
voorkomen kan worden. Tegenover de winst die
genoemden worden voor hun bijdrage aan
de innovator haalt doordat hij het alleenrecht
open-sourceprojecten maar zelden betaald. Zij
op zijn innovatie heeft staat het verlies van de
worden dus intrinsiek gemotiveerd. Raymond
maatschappij heeft van het niet vrij kunnen ge-
(2000) omschrijft de open-sourcegemeenschap
bruiken van deze kennis. (Von Hippel en Von
als een gift culture waar altruïsme en reciprociteit
Krogh, 2003)
belangrijk zijn. Vaak genoemde motieven zijn
De vrije herverspreidbaarheid van open source veroorzaakt dat niemand van de consumptie van OSS uitgesloten kan worden. Het feit dat
26 >
Motivatie is extrinsiek als behoeften indirect
het verkrijgen van een goede reputatie onder gelijken, het publiekelijk laten zien van kunnen, het leren en het ontwikkelen van vaardigheden, of simpelweg het plezier dat het uitoefenen van
hun hobby hen geeft. (Bonaccorsi et al, 2004;
merking te komen voor venture capital. (Lerner
Raymond, 2000, Lerner en Tirole, 2002)
en Tirole, 2002)
Veel mensen die bijdragen aan OSS zijn geavan-
Aangezien bedrijven als doel hebben de winst
ceerde gebruikers voor wie het verhelpen van
te maximaliseren moet de ultieme drijfveer om
een bug of het aanpassen van software aan hun
te participeren in de open-sourcegemeenschap
eigen behoeften weinig moeite kost wanneer
zijn om er op de een of andere manier econo-
ze toegang hebben tot de broncode, terwijl het
misch van te profiteren (Bonaccorsi & Rossi,
hen onmiddellijk helpt in hun dagelijkse werk.
2003). Het is te verwachten dat alle motieven
Als de verbetering gering is, is het vaak niet de
in essentie economisch en opportunistisch van
moeite waard om het idee te beschermen of te
aard zijn, omdat het ultieme doel van bedrijven
proberen te verkopen aan anderen. Bovendien
winstmaximalisatie is. Hierbij moet wel opge-
biedt het internet een goedkope en efficiënte
merkt worden dat het economische voordeel
manier om de innovatie te delen met anderen.
veelal indirect van aard is.
(Schmidt et al, 2002, Kollock 1999) Volgens Raymond (1999) heeft iemand die een patch heeft voor een open source programma twee keuzes. Hij kan er niks mee doen en schiet er dan ook niks mee op, of hij kan het vrijgeven in de hoop dat reciprociaal gedrag bevordert en dat iemand anders een patch bijdraagt voor een probleem waar hij zelf mee zit. Hoewel de laatste optie altruïstisch lijkt is het eigenlijk optimaal egoïstisch, gezien vanuit de speltheorie.
3.7 Commerciële open source participatie Hoewel OSS door haar definitie een publiek goed is blijken bedrijven deze goederen toch aan te bieden, wat in tegenstelling is met wat in eerste instantie op grond van de economische theorie omtrent publieke goederen verwacht zou worden. Wat echter niet vergeten moet worden is dat de marginale kosten van het aanbieden
Naast deze directe private benefits groeit het
van OSS erg laag zijn. Dit heeft grote invloed op
besef dat het actief participeren in een open-
de kosten- en batenafweging. Als de kosten van
sourceproject ook kan zorgen dat men opge-
het vrijgeven van de kennis, die opgeslagen is
merkt wordt in de arbeidsmarkt. (Lerner and
in de broncode en daarbij inbegrepen de kosten
Tirole, 2002) Zo zijn recentelijk twee ontwikke-
van het niet langer kunnen ‘verkopen’ van de
laars van Mozilla Firefox, een populaire open
software zelf, lager zijn dan de opbrengsten die
source browser in dienst genomen door Google
via een andere weg behaald kunnen worden,
(Olsen, 2005). Dit signaleringseffect is ook een re-
juist door het vrijgeven van de code, kan het
den voor individuen om hun eigen software als
vrijgeven voor een bedrijf een zinvolle, logische
open source te verspreiden. Zij hopen de adop-
en winstgevende actie zijn.
tie en zichtbaarheid te vergroten om zo in aan-
< 27
Grand et al. (2004) geven vier niveaus van
is er niet altijd van op de hoogte. De adoptie van
open-sourceparticipatie door bedrijven. Op het
het besturingssysteem Linux bijvoorbeeld in het
eerste niveau neemt het bedrijf slechts deel in
bedrijfsleven is in veel gevallen van onderop ge-
de gemeenschap als gebruiker van de software.
komen, doordat bijvoorbeeld mensen van de
Op het tweede niveau gebruikt het bedrijf open
technische staf uit eigen beweging Linux op ser-
source software in het eigen productaanbod.
vers introduceerden voor niet-bedrijfskritische
Op het derde niveau wordt open source een ont-
toepassingen. Ook gebeurt het dat program-
werpkeuze voor de manier waarop het bedrijf
meurs die OSS gebruiken foutrapportages en
bepaalde producten ontwikkelt. Op het hoogste
oplossingen sturen naar de ontwikkelaars van
niveau van participatie tenslotte is open source
het OSS project zonder expliciete goedkeuring
niet langer een keuze voor bepaalde projecten
en medeweten van het management.
maar is het totale business model op open source gebaseerd. Deze niveaus zijn grafisch weergegeven in figuur 3.2. Bedrijven die op de eerste twee niveaus participeren doen dit niet altijd bewust, het gebruik van open source software is niet altijd een bewuste keuze van het management en het management
3.8 Niveau één: motieven voor gebruiken van OSS Open source software heeft een aantal voordelen voor gebruikers ten opzichte van gesloten software. Deze voordelen worden veroorzaakt
Figuur 3.2: Verschillende niveaus van participatie voor bedrijven (Aangepast van: Grand et. al., 2004)
28 >
door de kenmerken die eerder in dit hoofdstuk
bruiker niet afhankelijk is van de leverancier
genoemd werden, vrijheid, openheid en vrije
van de software, voor het leveren van ondersteu-
herverspreidbaarheid. Vanuit het gezichtspunt
ning, doorontwikkelen en compatibiliteit met
van de gebruikers kunnen deze kenmerken ver-
andere systemen. Onafhankelijkheid betekent
taald worden naar eigenschappen van vrijheid,
ook dat de gebruiker de volledige beschikking
kwaliteit en kosten.
heeft over de data die opgeslagen zit in het systeem. De meeste open source software maakt
3.8.1
Vrijheidseigenschappen
gebruik van open standaarden. Een open stan-
De vrijheidseigenschappen zijn flexibiliteit, onaf-
daard voldoet aan de volgende eisen:
hankelijkheid en continuïteit. Deze eigenschappen
De standaard is goedgekeurd en wordt
worden rechtstreeks veroorzaakt door de open-
gehandhaafd door een organisatie zonder
sourcelicentie. De vrijheidseigenschappen zijn
winstoogmerk en de ontwikkeling gebeurt
in tegenstelling tot de kwaliteitseigenschappen
op basis van een open besluitvormingspro-
objectief vast te stellen, hoewel het nut en de
cedure die toegankelijk is voor alle belang-
wenselijkheid verschilt per situatie.
hebbende partijen;
De openheid van de broncode en de vrijheid
De standaard is gepubliceerd en over het
zorgen voor een grote mate van flexibiliteit, om-
specificatiedocument van de standaard
dat de gebruiker de software naar eigen inzicht
kan vrijelijk worden beschikt of het is te
kan (laten) wijzigen. Dit betekent niet alleen dat
verkrijgen tegen een nominale bijdrage.
de software aangepast kan worden aan de wen-
Het moet voor een ieder mogelijk zijn om
sen en eisen van de gebruikers, maar ook dat
het te kopiëren, beschikbaar te stellen en
de mogelijkheid tot interoperabiliteit en compa-
te gebruiken om niet of tegen een nominale
tibiliteit wordt vergroot. Veel bedrijven willen
prijs;
hun verschillende systemen met elkaar inte-
Het intellectuele eigendom - m.b.t. moge-
greren. Het integreren van systemen voorkomt
lijk aanwezige patenten - van (delen van)
dat data dubbel bijgehouden hoeft te worden en
de standaard is onherroepelijk ter beschik-
verkleint zo de kans op fouten en vergroot de
king gesteld op een royalty-free basis;
doelmatigheid. Bovendien maakt het integreren van systemen het makkelijker om verschillende data aan elkaar te koppelen, wat de waarde van de informatie vergroot. De flexibiliteit zorgt er voor dat OSS veel eenvoudiger te integreren is met andere systemen dan gesloten software. Onafhankelijkheid tenslotte houdt in dat de ge-
Er zijn geen beperkingen omtrent het hergebruik van de standaard; (Ossoss, 2005)
Het staat iedereen dus vrij om software te ontwikkelen die de open standaard implementeert om de data zo te ontsluiten zonder verlies van kwaliteit of informatie. Bedrijven als Microsoft hebben belang bij gesloten standaarden. Het be-
< 29
kendste voorbeeld van een gesloten standaard is
de continuïteit van de ontwikkeling van OSS
het Word .doc formaat. Geen enkele organisa-
waarborgt. Doordat bij niet commerciële pro-
tie is het nog gelukt om hun software honderd
jecten een financiële prikkel ontbreekt kunnen
procent compatibel te maken met dit formaat.
de ontwikkelaars elk moment stoppen met de
Bedrijven die veel data hebben opgeslagen in
ontwikkeling. Voorstanders brengen daar te-
Word bestanden zijn daarvoor huiverig om over
genin dat de continuïteit juist wel gewaarborgd
te stappen op alternatieve software als OpenOf-
is, doordat de laatst openbaar gemaakte bron-
fice. Het fenomeen dat vendors proberen klan-
code altijd beschikbaar is. Het staat iedereen
ten aan zich te binden door gebruik te maken
vrij deze code op te pakken en verder te ontwik-
van gesloten standaarden wordt vendor-lock-in
kelen. Als het een voor meerdere mensen nuttig
genoemd.
product is zal dat zeker gebeuren. Als niemand
Zelfs als een OSS product geen open standaard gebruikt volgens de definitie, kan in ieder geval de broncode bestudeerd worden om uit te vinden hoe de data opgeslagen en ontsloten wordt. Met open source is er kortom veel minder sprake van vendor-lock-in. (Lerner & Tirole, 2002)
het product verder ontwikkelt, kan de organisatie die het product gebruikt en het wenselijk acht dat het verder ontwikkeld wordt, deze taak op zich nemen, door programmeurs in dienst te nemen of dit uit te besteden. Proprietary producten daarentegen kunnen opgekocht worden door concurrenten of het bedrijf kan failliet
De overheid is een grote en belangrijke klant voor ICT-bedrijven. Op Europees niveau stimuleert de Europese Commissie met het IDABC (Interoperable Delivery of European eGovern-
gaan, waardoor de continuïteit ernstig in gevaar komt. Als continuïteit gedefinieerd wordt als de mogelijkheid tot doorontwikkeling, dan is zij hoger bij OSS dan bij gesloten software.
ment Services to public Administrations, Businesses and Citizens) programma het gebruik van en de bewustwording van het belang van open standaarden en open source software bij overheidsinstellingen. (IDABC, 2005) Op Nederlands niveau probeert OSOSS (Open Standaarden en Open Source Software voor de overheid) datzelfde te doen (OSOSS, 2005). Voor overheidsinstellingen zal dit de keuze voor OSS positief beïnvloeden. Continuïteit tenslotte is een argument dat zowel voorstanders als tegenstanders van open source gebruiken. Tegenstanders werpen op dat niets
30 >
3.8.2
Kwaliteitseigenschappen
De kwaliteitseigenschappen zijn subjectiever en staan meer ter discussie dan de vrijheidseigenschappen, omdat deze niet rechtstreeks door de open-sourcelicentie worden veroorzaakt, de licentie schept alleen de voorwaarden die een open ontwikkelingsmodel mogelijk maken. Deze openheid kan leiden tot software die van hogere kwaliteit is dan software die in een gesloten omgeving ontwikkeld wordt. Tegenstanders van open source brengen hier tegen in dat alleen de licentie bepaalt of iets open
source is of niet en dat het feit dat een product
De openheid van de code zorgt voor een gro-
onder een dergelijke licentie wordt verspreid
tere transparantie voor de gebruikers. Deze
niet noodzakelijk de kwaliteitseigenschappen
transparantie kan gebruikers zekerheid verschaf-
heeft die worden veroorzaakt door de open-
fen over de interne kwaliteit en veiligheid van de
heid.
software. Veiligheid is een veelgenoemde reden
Een belangrijk gevolg van openheid is dat de code inspecteerbaar voor derden is, hetgeen peer-review mogelijk maakt. Peer-review in softwareontwikkeling houdt in dat de code die door de ene programmeur geschreven is, nagekeken en gecontroleerd wordt door anderen. In traditionele softwarehuizen blijft dit beperkt tot de directe collega’s, voor open source geldt daarentegen dat iedereen die over de juiste kennis en vaardigheden beschikt peer-review kan toepassen op de broncode. Het belangrijkste doel van peer-review is het opsporen van bugs en algemene kwaliteitsbewaking. Een beroemde quote in het kader van peer-review is die van Eric S. Raymond: “given enough eyeballs, all bugs are shallow” (Raymond, 2000). Hiermee bedoelt hij dat doordat zoveel verschillende mensen
om OSS te gebruiken (Fink, 2003). Programmeurs zijn in staat om de code te inspecteren op veiligheidslekken en de aanwezigheid van backdoors. Bedrijven en personen die de software willen gebruiken kunnen iemand inhuren om dit te doen of ze kunnen het zelf doen. Deze fouten kunnen ook bij toeval ontdekt worden door programmeurs die om een andere reden met de code bezig waren. Tegenstanders van open source voeren aan dat het feit dat peer-review mogelijk is nog niet wil zeggen dat het ook gebeurt. Er is een grote mate van technische expertise nodig om veiligheidslekken te ontdekken en lang niet iedereen die de code doorloopt heeft die expertise. Bovendien heeft niet iedereen die wel over deze expertise beschikt goede bedoelingen. (Payne, 2002)
naar de code kijken, bugs snel gevonden en op-
Een ander veiligheidsargument voor OSS, te-
gelost kunnen worden. Peer-review voorkomt
vens veroorzaakt wordt door de openheid, is
dat ‘lelijke oplossingen’ opgenomen worden in
dat je de software zelf kunt compileren, je hoeft
de code. Lelijke oplossingen zijn oplossingen
niemand anders te vertrouwen om dat voor je
die goed genoeg zijn om een bepaald probleem
te doen. Op deze manier weet je zeker dat de
op te lossen, maar die in een latere fase proble-
software die je gebruikt dezelfde is als waarvan
men kunnen veroorzaken. Doordat alle code
je de bron hebt geïnspecteerd. (Lawton, 2002,
publiekelijk inzichtelijk is, wordt er minder snel
Payne, 2002)
lelijke oplossingen opgenomen in de code, omdat de reputatie van de ontwikkelaar op het spel staat. Vaak is het versiebeheersysteem publiek toegankelijk en kan precies bekeken worden wie welke wijziging heeft gedaan.
OSS-ontwikkelaars ontvangen vaak hulp van geïnteresseerden, in de vorm van nieuwe features, bug reports, bug diagnoses en oplossingen voor bugs. Als dit gebeurt kan dit resulteren in een grotere ontwikkelsnelheid en lagere ontwikkelkosten. (Shivaprakash, 2003)
< 31
3.8.3
Kosten
Een andere reden die veel gegeven wordt voor
via internet.
het verkiezen van OSS boven commerciële ge-
Kogut en Metiu (2001) noemen de mogelijk-
sloten software is de prijs. Zoals aangegeven
heid van een fork als gevaar van OSS. De vrije
eerder in dit hoofdstuk is gratis beschikbaar-
herverspreidbaarheid maakt het mogelijk dat
heid geen bepalend kenmerk van open source,
wanneer ontwikkelaars van mening verschillen
maar de meeste open source software is wel
over de verdere ontwikkeling zij onafhankelijk
gratis te verkrijgen. Ondersteuning bij instal-
van elkaar de software verder gaan ontwik-
latie, onderhoud en gebruik is natuurlijk niet
kelen (dit wordt een fork genoemd), waardoor
gratis maar dit hoort wel gerekend te worden
er twee versies ontstaan die incompatible met
bij de totale kosten die gemaakt moeten worden
elkaar zijn. Of dit per definitie een slechte ei-
om de software te gebruiken. De total cost of
genschap is, is onduidelijk, omdat het ook posi-
ownership (TCO), zoals dit vaak genoemd hebt
tief kan werken voor de ontwikkeling. Eén van
verschilt per product. Als bijvoorbeeld voor een
de versies wordt dan vaak de meest populaire
gratis open source product twee mensen nodig
versie, waarna de code na enige tijd vaak weer
zijn om het te implementeren en te onderhou-
samengevoegd wordt tot één versie. Samba, een
den en voor een proprietary product van 10.000
open-source implementatie van het Windows
euro maar één persoon, zal de TCO van het
netwerkprotocol bijvoorbeeld heeft bewust voor
proprietary product lager zijn dan die van het
een fork gekozen, zodat in één van de versies een
gratis open source product.
nieuwe feature ontwikkeld kon worden zonder
Dedrick en West (2003) wijzen wat betreft de adoptie van OSS op de trialability-factor. De lage initiële kosten maken het makkelijk het product uit te proberen, bovendien is de meeste
dat dat effect had op de stabiliteit van de andere versie. Omdat het wel als reden genoemd wordt om OSS te vermijden wordt het hier wel genoemd.
Motief voor gebruik
Oorzaak
Flexibiliteit door aanpasbaarheid Interoperabiliteit en compatibiliteit Continuïteit van doorontwikkeling en ondersteuning Onafhankelijkheid van ontwikkelaar Mogelijkheid broncode te inspecteren op kwaliteit en fouten Voordelen van peer-review Ontbreken licentiekosten
vrijheid, openheid vrijheid, openheid vrijheid, openheid vrijheid, openheid openheid openheid vrije herverspreidbaarheid
Tabel 3.3: Motieven voor gebruikers
32 >
OSS eenvoudig, snel en anoniem te verkrijgen
In tabel 3.3 zijn de motieven voor het gebruik
van is Red Hat, één van de vele bedrijven die
van OSS samengevat. In de tweede kolom staat
een zogenaamde Linux-distributie ontwikkeld.
waardoor het voordeel veroorzaakt wordt dat
Een Linux-distributie bestaat uit het Linux-be-
een motief voor het gebruik van OSS is. Bij dit
sturingsysteem en een verzameling applicaties.
overzicht is getracht alleen de zaken die gelden
Red Hat’s toegevoegde waarde bestaat uit het
voor alle OSS te noemen en die voortkomen uit
zorgvuldig samenstellen van het aanbod, het
de definitie. Hoewel factoren als veiligheid en
zorgdragen voor de totale kwaliteit van de sa-
ontwikkelsnelheid wel motieven zijn om be-
menstelling en het leveren van ondersteuning
paalde OSS te gebruiken, ontbreken ze in dit
bij installatie en problemen en het verzorgen
overzicht, omdat ze niet generaliseerbaar zijn
van updates.
voor alle OSS.
Een Independent Software Vendor (ISV) is een ontwikkelaar en verkoper van software. Een recent
3.9 Niveau twee: motieven voor exploiteren van OSS Op het tweede niveau bevinden zich de bedrijven die OSS exploiteren, ze gebruiken het in hun eigen producten- en dienstenaanbod. Deze bedrijven vallen grofweg uiteen in Value Added Resellers, System Integrators, Independent Software Vendors en Original Equipment Manufacturers.
voorbeeld hiervan is SugarCRM, een bedrijf dat een open source web-based CRM pakket ontwikkelt. In hun software hebben zij andere open source functionaliteit, voor bijvoorbeeld loggen en het werken met templates verwerkt. Het geheel heeft Apache, PHP en MySQL (resp. de webserver, script-interpreter en database) nodig om te kunnen functioneren. Ter illustratie is in de bijlagen is een behandeling van het busi-
Een Value Added Reseller (VAR) is een bedrijf dat
nessmodel van SugarCRM opgenomen. Dit
bestaande technologie afneemt en dan waarde
bedrijf is zeer succesvol geweest in het krijgen
toevoegt door iets aan het product toe te voe-
van een grote naamsbekendheid en populariteit
gen, zodat er een nieuw product ontstaat in de
door hun open source CRM-pakket.
ogen van de gebruikers. Het resultaat wordt dan als standaardoplossing verkocht. De toegevoegde waarde kan onder meer liggen in de verkoop en marketing capaciteiten van de VAR, haar kennis van de markt en behoeftes of het aanbieden van ondersteuning aan haar klanten. In het geval van OSS bestaat de toegevoegde waarde vaak uit het leveren van ondersteuning bij de installatie, het onderhoud en het gebruik van de software. Een bekend voorbeeld hier-
Een System Integrator (SI) gebruikt de technologie als onderdeel van een op maat gemaakte totaaloplossing voor een klant. Het verschil met een ISV is, dat een SI in principe maatwerk levert. Het is niet de bedoeling nieuwe producten te ontwikkelen om die onafhankelijk verder te gaan verkopen. Een voorbeeld van een dergelijk bedrijf is Outdare Internet Services uit Rotterdam (mijn huidige werkgever). Outdare maakt
< 33
gebruik van verschillende OSS om haar oplos-
zienlijke verkorting van de ontwikkeltijd bete-
singen mee te ontwikkelen. Vaak is de gelever-
kent, omdat de code niet zelf ontwikkeld hoeft
de maatwerkoplossing gebaseerd op een open-
te worden, de ISV kan profiteren van de inspan-
sourceproduct.
ningen van anderen. (Hawkins, 2003; Lakhani et.
Original Equipment Manufacturers tenslotte zijn de bedrijven die open source software gebruiken in hun hardware producten. Embedded Linux bijvoorbeeld wordt gebruikt in allerlei consumentenelektronica, van netwerkrouters tot
al., 2003) Niet alleen wordt geprofiteerd van de programmeerinspanningen van anderen, maar ook van het feit dat de software al uitgebreid getest is door vele andere gebruikers. Bovendien ontbreken licentiekosten en vaak is de software al uitvoerig getest. Uiteraard is de vrije herver-
mobiele telefoons.
spreiding ook van groot belang, ISV’s maken de producten immers om ze zoveel mogelijk af te De motivatie van bedrijven op dit participatie-
zetten. Het grootste nadeel is dat OSS die onder
niveau om te kiezen voor OSS komt voor een
de GPL-licentie valt niet gebruikt kan worden
groot deel overeen met de motivatie van bedrij-
als het bedrijf de totale broncode van het pro-
ven op het eerste niveau, die de software alleen
duct niet wil vrijgeven. Broncode die verspreid
gebruiken. Belangrijk voor alle typen bedrijven
wordt onder de BSD-licentie kan zonder meer
is de onafhankelijkheid van softwareproducen-
gebruikt worden in het eigen product. De be-
ten (Lerner en Tirole, 2002). De flexibiliteit
schikbaarheid van goede open source program-
door aanpasbaarheid is ook voor bedrijven op
meurs is volgens Wichmann (2002) een andere
dit niveau van groot belang, ze verdienen im-
reden waarom bedrijven kiezen voor het ont-
mers hun geld met het aanpassen en implemen-
wikkelen op basis van open source producten.
teren van de software.
Feller en Fitzgerald (2002) noemen de lage
Voor ISV’s is het gebruiken van OSS in het ei-
hardwarevereisten van open source producten
gen product aantrekkelijk omdat het een aan-
als reden om deze software te gebruiken, dit is
Motief voor gebruik Flexibiliteit door aanpasbaarheid
Profiteren van inspanningen van anderen. Onafhankelijkheid van ontwikkelaar
Mogelijkheid broncode te inspecteren op kwaliteit en fouten Voordelen van peer-review Ontbreken licentiekosten
Tabel 3.4: Motieven voor gebruik op tweede niveau
34 >
belangrijk voor OEM’s omdat het helpt de kos-
Het Duitse Sitecom werd door de rechter ge-
ten van het product te beperken, doordat goed-
dwongen haar wijzigingen openbaar te maken,
kopere hardware gebruikt kan worden. Hoewel
nadat een consument dit geëist had.
het klopt dat de hardwarevereisten van bepaalde OSS zoals bijvoorbeeld de Linux-kernel laag zijn, is dit geen kenmerk van OSS als zodanig. Het is dus wel een reden om bepaalde OSS te kiezen kan het niet gegeneraliseerd worden voor alle OSS.
Zoals al eerder gesteld verplicht alleen de GPLlicentie gebruikers hun aanpassingen openbaar te maken als zij de aangepaste software verder willen verspreiden. Toch doen veel bedrijven dit uit eigen beweging. Hiervoor zijn economische, sociale, technologische motieven voor aan te
In tabel 3.4 zijn de motieven voor de keuze voor
wijzen (Feller en Fitzgerald 2002; Bonaccorsi
OSS door bedrijven op het tweede niveau weer-
en Rossi, 2004).
gegeven voor zover ze generaliseerbaar zijn. De meeste bedrijven op het tweede niveau van
3.10.1
Economische motieven
participatie dragen niet op frequente basis en
Bijdragen aan OSS heeft meestal geen directe
grote schaal direct bij aan OSS. Wel zorgt het
private benefits. Indirecte private benefits zijn
gebruik door hen voor een grotere adoptie en
er zeker wel, vooral op de langere termijn. Als
acceptatie voor OSS, wat indirect bijdraagt aan
voorbeeld hiervan zal in tekstkader 3.1 de inves-
het succes van open-sourceprojecten. In de vol-
tering in Linux door bedrijven als IBM en HP
gende paragraaf zal behandeld worden waarom
behandeld worden.
bedrijven op het tweede niveau van participatie
De genoemde bedrijven dragen bij aan de ont-
besluiten bij te dragen aan open source.
wikkeling van een open-sourceproduct omdat zij er belang bij hebben dat dit product een stan-
3.10 Motieven voor bijdragen aan OSS Niet alle fabrikanten hebben hun veranderingen aan de broncode van OSS uit eigen beweging openbaar gemaakt. Uit een studie van Henkel (2004) naar het gedrag van fabrikanten die Embedded Linux gebruiken blijkt dat de meest genoemde reden voor het openbaar maken van de code is dat de GPL-licentie dit eist. De Nederlandse fabrikant van Tom Tom navigatiesy-
daard wordt, of om te voorkomen dat een product van een concurrent een standaard wordt. Het vergroten van compatibiliteit met een eigen softwareproduct kan ook een reden zijn voor bedrijven om bij te dragen aan de ontwikkeling van een OSS product. Op deze manier wordt de inzetbaarheid en dus de potentiële markt van het eigen softwareproduct vergroot en wordt de kans verminderd dat een alternatief gebruikt zal worden.
stemen openbaarde haar wijzigingen pas nadat een gebruiker van het systeem hier om vroeg.
< 35
Bijdragen aan Linux door IBM en HP IBM en HP zijn twee bedrijven die veel geïnvesteerd hebben in de ontwikkeling en promotie van Linux. Op het eerste gezicht is dit vreemd, omdat beiden besturingssystemen ontwikkelen en verkopen die direct met Linux concurreren. Deze op UNIX gebaseerde besturingsystemen (AIX van IBM en HP HP/UX of Tru64 van HP) hebben zij speciaal ontwikkeld voor hun eigen servers en mainframes. Beide bedrijven zijn van oorsprong producenten van hardware. Lange tijd was juist het besturingssysteem een reden voor klanten om de hardware aan te schaffen. De versplintering van UNIX was een voordeel voor de producenten, omdat dit de overstap naar een ander besturingssysteem belemmert en de klanten dus min of meer gedwongen waren om de hardware van dezelfde producent af te blijven nemen. De toenemende concurrentie van Linux en Microsoft Windows veranderde deze situatie. Het voordeel voor gebruikers van deze besturingssystemen is dat beide draaien op de X86 (Intel pc) architectuur. Door de grote concurrentie op deze markt is deze hardware goedkoop vergeleken met de hardware van bedrijven als IBM en HP. Bovendien is men door te kiezen voor één van deze besturingssystemen niet langer afhankelijk van één hardwarefabrikant. In tegenstelling tot Windows en de meeste UNIX-soorten werkt Linux bovendien op bijna elk denkbare computer architectuur. Verschillende platformen leiden tot hogere kosten en een minder grote keus aan software die beschikbaar is voor het gekozen platform. De kosten zijn hoger omdat er meer gespecialiseerd personeel nodig is om systeembeheertaken uit te kunnen voeren. Producenten van software zijn bovendien niet altijd bereid of in staat om hun software geschikt te maken voor al deze platformen en ondersteuning te bieden. Gebruikers hebben dus de behoefte aan standaardisatie wat betreft het platform. Wijde adoptie van Windows in de servermarkt zou Microsoft een te grote macht geven naar de zin van bedrijven als IBM en HP. Bovendien zou het een grote bedreiging voor de afzet van dure servers betekenen, omdat deze hardware niet ondersteund wordt door Windows. Met het dalende marktaandeel van de eigen besturingssystemen en de dreiging van Windows was het succes van Linux dus van een bedreiging verworden tot een kans om de eigen positie te handhaven en te verbeteren. Om hiervoor te zorgen hebben zij besloten naast hun eigen besturingssysteem ook Linux te ondersteunen. Zij hebben veel geld geïnvesteerd in het geschikt maken van Linux voor hun hardwarearchitectuur en het verbeteren van Linux, om de performance op het zelfde niveau te brengen als dat van hun eigen besturingssysteem. Bedrijven als IBM hebben een grote rol gespeeld om Linux te verbeteren op de gebieden die voor veeleisende zakelijke bedrijven belangrijk zijn, zoals performance en schaalbaarheid.
Tekstkader 3.1: Bijdragen aan Linux door IBM en HP ( Wichmann, 2002)
36 >
3.10.2 Technologische motieven
3.10.3
De meeste softwareproducten zijn continu in
Bedrijven die OSS exploiteren die zij niet zelf
ontwikkeling, het wordt steeds verbeterd en uit-
ontwikkelen of waarvan zij de ontwikkeling
gebreid. In de loop der tijd worden steeds nieu-
niet sterk sturen zijn afhankelijk van de inzet
we versies uitgebracht. Dat geldt misschien nog
van de community. De leden van deze com-
wel meer voor OSS dan proprietary software.
munities zijn vaak intrinsiek gemotiveerd, de
Het OSS mantra release early, release often wordt
communities zijn gebaseerd op normen en ver-
door veel open-sourceprojecten nageleefd. Bug-
trouwen. Dit betekent dat wanneer een bedrijf
fixes en nieuwe features komen beschikbaar
iets gedaan wil krijgen van de community, zich
op het moment dat ze af zijn, in tegenstelling
moet gedragen als een goed communitylid en
tot proprietary software waar deze zaken vaak
zich moet conformeren naar de waarden van de
opgespaard worden tot één nieuwe versie. Be-
community. (Osterloh et al, 2001)
drijven die OSS exploiteren en willen profiteren van deze verbeteringen moeten wanneer ze privé-aanpassingen hebben gedaan deze veranderingen verwerken in hun eigen versie. Dit is meestal geen eenvoudige opgave, omdat de veranderingen door anderen zijn gedaan zonder rekening te houden met de privé-aanpassingen. Dit betekent dat interne structuren en werkingen van de software dermate veranderd kunnen zijn dat de privé-aanpassingen geheel opnieuw geïmplementeerd moeten worden. Zelfs als er aan de interne structuur niet veel is veranderd is het samenvoegen van beide codebases een arbeidsintensief en risicovol (stabiliteit, testen, afhankelijkheden) karwei. Als de kosten hiervan niet opwegen tegen het onthullen van de privé-
Sociale motieven
Binnen een dergelijke community is er geen ruimte voor opportunistisch gedrag. Als het vertrouwen één keer beschaamd is zal de samenwerking hier sterk onder lijden. De leden van de open source community reageren sterk op breuken met regels of normen. De sancties kunnen bestaan uit het verlaten van het project, uitsluiting van degene die de normen heeft geschaad of andere acties die de samenwerking belemmeren. Het belang van conformering wordt bevestigd door het eerdergenoemde onderzoek van Henkel (2004) onder hardwareproducenten die embedded Linux gebruiken in hun producten. “to appear as a good OSS player” wordt het meest genoemd als reden om bij te dragen, na “the GPL requires it”
innovatie is het verstandig te zorgen dat de privé-aanpassing van het bedrijf wordt opgenomen in de officiële standaarddistributie. Niet alleen spaart dit een hoop tijd en moeite uit, ook bestaat de kans dat andere externe ontwikkelaars de contributie van het bedrijf verder ontwikkelen. (met functionaliteit die ze wellicht zelf nog
Eén van de waarden die belangrijk is in de open source community is reciprociteit, het teruggeven aan de community. In de ogen van de community hebben leden en vooral bedrijven de morele verplichting om wanneer het product van de community waardevol voor hen is iets
niet eens bedacht hadden) (Henkel, 2002)
< 37
terug te geven aan de community. Dit kunnen
Steeds vaker gebeurt het dat bedrijven niet al-
donaties zijn, bijvoorbeeld geld, servers of hos-
leen bijdragen aan de ontwikkeling van open
ting, maar belangrijker nog is dat zij de verbete-
source software, maar dat ze ook eigen software
ringen of relevante uitbreidingen op de software
verspreiden onder een open-sourcelicentie en
die ze gedaan hebben aanbieden aan de com-
het open source ontwikkelingsmodel gebruiken
munity. Het is belangrijk voor de leden van de
(Von Hippel en Von Krogh, 2003). Het bedrijf
community dat zij met respect behandeld wor-
accepteert, of wordt er zelfs beter van, dat het
den en dat ze niet het gevoel hebben uitgebuit te
intellectueel eigendom in de broncode publiek
worden. (Kuster et al., 2002; Lerner en Tirole,
beschikbaar wordt. (Henkel 2004)
2002; Franck en Jungwirth, 2002)
Het vrijelijk onthullen van de innovatie van het
In tabel 3.5 zijn de motieven voor bijdragen aan
bedrijf op deze niveaus gebeurt niet per onge-
OSS door bedrijven zoals besproken in deze pa-
luk, het is een strategische keuze van het bedrijf.
ragraaf weergegeven.
Hierbij kan onderscheid gemaakt worden tussen marketingstrategie, ontwikkelstrategie en
3.11 Niveau drie en vier: motieven voor initiëren van OSS
concurrentiestrategie.
Niveau drie en vier worden in deze paragraaf
Een bedrijf dat haar software verspreid onder
samen besproken omdat het op beiden niveaus
een open-sourcelicentie kan dit doen omdat
gaat om het initiëren van een OSS-product. Het
zij hoopt dat het product daardoor bekendheid
maakt in dit onderzoek niet veel uit of het be-
krijgt, een groter marktaandeel, of zelfs een stan-
treffende bedrijf dit doet met één of enkele pro-
daard wordt in een marktsegment. Een groot
ducten en verder nog gesloten software ontwik-
aantal installaties van de software zorgt voor een
keld, of dat zij uitsluitend OSS ontwikkelt.
vraag naar aanvullende diensten en producten.
3.11.1
Marketingstrategie
Motieven voor bijdragen aan OSS Vereiste GPL-licentie
Belang hebben bij grotere adoptie
Niet willen blijven doorvoeren privé-aanpassingen
Profiteren van doorontwikkeling bijgedragen code door anderen Belang hebben bij goede reputatie in OSS-community Iets teruggeven aan de community
Tabel 3.5: Motieven voor bijdragen aan OSS
38 >
Het leveren van deze diensten en producten is
erg risicovol, door de hardwarespecificiteit is
dan de bron van inkomsten voor deze bedrijven.
de software van weinig waarde voor concur-
Dit lijkt sterk op de strategie die wel loss leader
renten.
strategy genoemd wordt, waar een product of dienst tegen een verliesgevend bedrag wordt aangeboden in de verwachting dat in de toekomst met andere producten en diensten dit verlies wordt gecompenseerd. (opensource.org, 2005; Hecker, 2000)
Deze strategie wordt toegepast voor consumentenelektronica, maar ook voor de zakelijke markt. Zo heeft Hewlett Packard verschillende ontwikkeltools als open source vrijgegeven om de open source community te helpen om Linux geschikt te maken voor HP’s RISC-architectuur
Het verschil met normale (niet software) pro-
(Lerner en Tirole, 2001), om zo deze architec-
ducten en proprietary software is dat het intel-
tuur aantrekkelijker te maken zonder zelf te in-
lectueel eigendom in de broncode publiek be-
vesteren in de port.
schikbaar wordt, niet alleen voor consumenten maar ook voor concurrenten (Henkel, 2003). Open source software is dus een stap verder dan bijvoorbeeld freeware, waarbij wel het product gratis wordt verspreid, maar de interne werking verborgen blijft. 3.11.1.1
Complementaire producten verkopen
Bij complementaire producten kan gedacht worden aan hardware en software. Het verspreiden van de broncode van software die behoort bij bepaalde hardware vergroot de aantrekkelijkheid van deze hardware, omdat het mensen en bedrijven in staat stelt om de software aan te passen en zo de hardware voor henzelf meer waardevol te maken. Er kunnen dan communities van enthousiastelingen rond een dergelijk product ontstaan, wat een goede stimulans voor de verkoop is, omdat een product met een dergelijke community aantrekkelijker is ook voor andere mensen, ook als die zelf niet in staat
Het aanbieden van verschillende versies van een product is een gebruikelijke marketingstrategie. Voor informatiegoederen zoals software is niet alleen het aanbieden van verschillende versies eenvoudig, er kan door de lage marginale kosten ook een gratis versie worden aangeboden. Deze versie kan gebruikt worden om mensen op de hoogte te stellen van het bestaan van het product en om ze kennis met de software, de technologie of het bedrijf te laten maken. Van veel computer games bijvoorbeeld wordt een gelimiteerde versie gratis verspreid om gebruikers te verleiden de volledige versie te kopen. Een gratis versie kan ook gebruikt worden om een band met de klant op te bouwen en deze zo te bewegen andere producten van het bedrijf te kopen. Ook software die afhankelijk is van netwerkeffecten kan veel baat hebben bij de proliferatie van een basisversie van het product. (Shapiro en Varian, 1998b)
zijn of geen behoefte hebben om de software te wijzigen. Het vrijgeven van de software is niet
< 39
Dit verklaart echter nog niet waarom bedrijven
wikkelaar van de software niet kan bepalen wie
ook de broncode vrijgeven van de gratis versie.
deze diensten aanbiedt heeft zij wel een voor-
Het community-effect zoals hierboven beschre-
sprong op concurrenten door haar reputatie,
ven kan een reden hiervoor zijn. Als de gratis
haar kennis van het product en de invloed die
versie open source is kunnen mensen het aan-
ze heeft op de ontwikkeling van het product.
passen en kan er een community ontstaan van mensen die hun innovatie met elkaar (en de
3.11.2
Ontwikkelingsstrategie
rest van de wereld) delen. Dit kan een impuls
Een primaire reden voor individuele (privé)
geven aan de adoptie van de software en daar-
ontwikkelaars om hun software open source
mee aantrekkelijk zijn voor producten die van
te maken is dat ze het werk niet alleen kunnen
netwerkeffecten afhankelijk zijn. In tekstkader
of willen doen. Door het als open source vrij
3.2 wordt besproken hoe Trolltech met verschil-
te geven hopen ze geïnteresseerden te vinden
lende versies werkt.
die mee willen helpen met de ontwikkeling. Deze individuen zien niet de mogelijkheid om
3.11.1.2
Complementaire diensten verkopen
de software commercieel uit te buiten, of zijn
Voor veel zakelijke software is specifieke ken-
hierin niet geïnteresseerd. Voor bedrijven voor
nis nodig om het te installeren, te beheren,
wie de belangrijkste bron van inkomsten de ver-
aan te passen en te integreren met de overige
koop van software is, ligt dit natuurlijk anders.
systemen. Daarnaast is het vaak nodig om de
Toch wordt het krijgen van hulp bij de ontwik-
eindgebruikers te trainen in het gebruik. Er zijn
keling door verschillende auteurs genoemd als
dus allerlei aanvullende diensten denkbaar die
motief. (Hawkins, 2003; Lakhani et al., 2003;
gebruikers van de software willen afnemen.
Dahlander, 2004)
Hoewel in het geval van OSS de originele ont-
Duaal licentiemodel Het Zweedse bedrijf Trolltech verspreidt twee versies van QT, een cross-platfrom raamwerk voor C++ applicatieontwikkeling. De twee versies zijn identiek op de licentie na. De één is open source en mag alleen gebruikt worden voor open source applicaties. Ontwikkelaars die QT willen gebruiken en bereid zijn om de broncode van hun applicaties te verspreiden onder een open source licentie mogen QT gratis gebruiken. Wanneer zij de broncode gesloten willen houden, dan moeten er commerciële QT licenties aangeschaft worden. Volgens Trolltech speelt de open source community een belangrijke rol in het verzekeren van de stabiliteit en kwaliteit van hun producten, welke grondig getest worden door duizenden open source ontwikkelaars verspreid over de wereld. Een dergelijk duaal licentiemodel wordt ook gebruikt door MySQL en Sleepycat, twee commerciële open source databaseontwikkelaars. Tekstkader 3.2: Duaal licentiemodel van Trolltech (Trolltech.com, 2005)
40 >
Een groot voordeel van het ontwikkelen van
Onder meer Aoki et al. (2001) en von Hippel
OSS is dat code van andere OSS gebruikt kan
(2002) bevestigen dit.
worden, wat een aanzienlijke tijdwinst en besparing van geld kan betekenen. Er zijn erg veel open source libraries beschikbaar voor uiteenlopende doeleinden. Software libraries kunnen gezien worden als kant en klaar te gebruiken brokken functionaliteit, die door andere software gebruikt kunnen worden door zich daar aan te linken. Het voordeel van deze libraries is
Fink (2003) Henkel (2004) en tenslotte geven als motivatie de beschikbaarheid van goede open source ontwikkelaars. Henkel bekijkt het ook van de kant van de ontwikkelaars, zij vinden het volgens hem aantrekkelijk om voor hun werk OSS te ontwikkelen. OSS is dus ook een manier om goed en gemotiveerd personeel te vinden.
dat ze door veel andere programma’s gebruikt worden en daarom vaak goed getest en van
3.11.3
Concurrentiestrategie
hoge kwaliteit zijn. Fouten in libraries worden
Commerciële softwareproducten ondervinden
daarom ook snel gevonden en deze fouten kun-
geduchte concurrentie van hun open tegen-
nen centraal opgelost worden. Naast libraries
hangers. Databaseservers als PostgreSQL en
kunnen ook gedeeltes van de broncode van
MySQL, bijvoorbeeld nemen plaatsen in die
andere open-sourceprojecten overgenomen en
voordien door commerciële databaseservers
aangepast worden. OSS ontwikkeling heeft
werden ingenomen. In tekstkader 3.3 worden
dus het voordeel dat kosteloos geprofiteerd kan
een aantal voorbeelden behandeld van bedrij-
worden van de inspanningen van de innovaties
ven die hun proprietary producten als open
van andere ontwikkelaars en OSS bedrijven.
source hebben verspreid om hun concurrenten
Het al eerder besproken Trolltech geeft aan dat
te dwarsbomen.
het testen van de software door de open source
In tabel 3.6 zijn de motieven voor het initiëren
community voor hen erg waardevol is. De ge-
van OSS door bedrijven zoals besproken in deze
bruikers van bètakwaliteit OSS zijn vaak zelf
paragraaf weergegeven.
programmeur en zij zijn daarom in staat goede feedback te geven, of oplossingen aan te dragen.
Motieven voor initiëren van OSS Verkoop complementaire producten en diensten Mogelijkheid gebruik bestaande OSS-code Beschikbaarheid van goede open-source ontwikkelaars Krijgen van hulp bij ontwikkeling in de vorm van code en feedback Dwarszitten van concurrenten Iets teruggeven aan de community Tabel 3.6: Motieven voor initiëren van OSS
< 41
Offensief SAP is de grootste vendor op het gebied van Enterprise Resource Planning software (ERP). Klanten kunnen uit een aantal merken databases kiezen voor deze software. Het merendeel van de SAP installaties draait op database software van Oracle. SAP is niet gelukkig met deze situatie omdat Oracle, naast databases, ook ERP software verkoopt en op dat gebied (na de overname van PeopleSoft eind 2004) de grootste concurrent van SAP is. Oracle gebruikt deze positie om klanten van SAP te bewegen om over te stappen op Oracle. SAP wilde dit ondervangen, en kocht daartoe de Adabas database software van Software AG, om deze onder de naam SAP DB aan haar klanten aan te bieden. Door de database software open source te maken en gratis aan te bieden stimuleert klanten om voor SAP DB te kiezen in plaats van Oracle. SAP kon dit doen omdat ze het ontwikkelen van databasesoftware niet als een kerntaak ziet, en het is ook niet een belangrijke bron van inkomsten, zoals bij Oracle wel het geval is. Bijkomend voordeel is dat SAP bespaart op ontwikkelkosten, doordat dit nu voor een gedeelte gedaan wordt door de community die zich rondom het product gevormd heeft. Een belangrijke zet hierbij was het partnerschap dat ze is aangegaan met MySQL. SAP DB is met de naam MAX DB in 2004 verdergegaan onder de vlag van en in de community van MySQL. Dit heeft waarschijnlijk een belangrijke rol gehad bij het succes van deze software, vaak vormt zich niet zo snel een community om voormalig proprietary software. Een ander bedrijf dat open source ingezet heeft in de concurrentiestrijd is Sun Microsystems. In 1999 kocht Sun het product StarOffice van het Duitse bedrijf StarDivision, om het snel daarna gratis beschikbaar te stellen voor persoonlijk gebruik. Halverwege 2000 maakte Sun bekend de broncode beschikbaar te stellen onder zowel de Lesser General Public License (LGPL) als de Sun Industry Standards Source License (SSSL) met de bedoeling een open-source-ontwikkelgemeenschap te bouwen rond de software. De software is inmiddels bekend als OpenOffice. Sun is zelf niet erg actief in de desktop software markt, maar aartsrivaal Microsoft wel. Door OpenOffice gratis ter beschikking te stellen wordt de positie van Microsoft binnen het bedrijfsleven bedreigd. (Wichmann, 2002)
Deffensief Computer Associates (CA) is een bedrijf dat een groot aantal IT management software producten ontwikkelt. Veel van deze producten maken gebruik van CA’s Ingres database-server.In februari 2005 heeft CA de broncode van Ingres vrijgegeven als open source. De klanten van CA betalen geen licentiekosten meer, maar blijven betalen voor ondersteuning. De producten van CA die gebruik van Ingres blijven gesloten. CA neemt op deze manier de wind uit de zeilen van de concurrenten die CA’s klanten proberen te bewegen om over te stappen naar een andere database-server. Omdat er voor het gebruik van Ingres geen licentiekosten meer betaald hoeven te worden en het open source is, met ondersteuningsgarantie, is overstappen naar een andere database-server niet aantrekkelijk. (Marson, 2005) De motivatie van CA is defensief omdat het hoopt haar huidige klanten te behouden, het is niet bedoeld om een directe concurrent dwars te zitten. Tekstkader 3.3: Offensieve en defensieve concurrentiestrategiën
42 >
3.12 Nadelen voor initiatoren van commerciële OSS-ontwikkeling Uit de vorige paragraaf is gebleken dat het voor
broncode bedoeld die ontwikkeld is door een
commerciële organisaties moeilijk is om recht-
extern bedrijf, waar een licentie voor is gekocht.
streeks geld te verdienen met OSS-ontwikke-
Als het externe bedrijf niet toestaat dat deze
ling. Bedrijven geven hun software vrij onder
code onder een OSS-licentie verspreid wordt,
een open-sourcelicentie om te verdienen aan de
wat meestal het geval zal zijn, kan deze code
verkoop van aanvullende producten en dien-
niet gebruikt worden in de software. De code
sten, als onderdeel van de ontwikkelingsstra-
van Netscape Communicator 5 bijvoorbeeld
tegie, of om een voordeel op de concurrentie
bevatte externe, gelicenseerde code voor onder
te behalen. De reden dat het moeilijk is rechts-
andere encryptie en spellingscontrole. Toen
reeks aan de verkoop van OSS te verdienen is
Netscape op 31 maart 1998 de broncode van
de vrije herverspreidbaarheid, niemand kan
het nog in ontwikkeling zijnde programma vrij-
hierdoor uitgesloten worden van het product.
gaf, was dit zonder deze code. Hierdoor was de
Voor bedrijven die geld willen verdienen met de
broncode op dat moment zo goed als waarde-
verkoop van de technologie zelf is dit nadeel on-
loos. De gaten die het verwijderen van de ex-
overkomelijk. Een ander nadeel van OSS is de
terne code had achtergelaten moesten opgevuld
slechte bescherming van het intellectueel eigen-
worden door nieuwe open source broncode.
dom. Hoewel door middel van de licentiekeuze
De genoemde nadelen zijn opgesomd in tabel
kan worden voorkomen dat de code wordt ge-
3.7.
bruikt in gesloten (concurrerende) producten staat niets concurrenten in de weg de kennis die in de broncode is opgeslagen te internaliseren.
O’Reilly (1999) oppert de term “gated open source community” voor bedrijven die de voordelen van open source willen benutten zonder
Tegenover het voordeel van het kunnen gebrui-
toe te staan dat hun software volledig vrij kan
ken van externe OSS-code staat het nadeel dat
worden herverspreid en ingezien door concur-
externe gesloten broncode niet gebruikt kan
renten. Hoe een dergelijk afgeschermde ge-
worden. Met externe gesloten broncode wordt
meenschap er uit kan zien is het onderwerp van
Nadeel Moeilijk rechtstreeks geld te verdienen met de verkoop van OSS Slechte bescherming intellectueel eigendom
Gebruik van externe, gesloten broncode is onmogelijk Tabel 3.7: Nadelen voor initiatoren van commerciële OSS-ontwikkeling
< 43
het volgende hoofdstuk. Wat er in een gesloten
Deze voordelen gelden ook voor bedrijven die
netwerk overblijft van het voordeel van open-
de software gebruiken in hun eigen producten
heid en vrijheid zal geanalyseerd worden in de
of aanvullende diensten en producten leveren.
daaropvolgende hoofdstukken.
Deze bedrijven zijn niet altijd freeriders, sommigen dragen ook bij aan de ontwikkeling van
3.13 Conclusie
OSS. Redenen hiervoor lopen uiteen van het niet willen blijven doorvoeren van privé-aan-
Open source kent drie bepalende kenmerken:
passingen bij het verschijnen van een nieuwe
vrije herverspreidbaarheid, vrijheid en open-
versie tot belang hebben bij grote adoptie.
heid. Deze kenmerken betekenen voor gebruikers een grotere flexibiliteit dan bij gesloten software. Bovendien zijn ze onafhankelijker van de ontwikkelaar van de software omdat hun data
Voor softwareontwikkelaars kleven aan open source enkele grote nadelen, het belangrijkste nadeel is dat het onmogelijk is om de gebruiker voor de software zelf te laten betalen.
niet gevangen zit in gesloten software en omdat ze niet afhankelijk van de ontwikkelaar zijn voor het doen van wijzigingen in de software. Het gegeven dat de broncode inspecteerbaar is zorgt ervoor dat de interne werking van de software beoordeeld en gecontroleerd kan worden. De software op zich is in de meeste gevallen gratis verkrijgbaar, voor ondersteuning en het laten doen van aanpassingen moet vanzelfsprekend wel betaald worden.
44 >
De voor- en nadelen van het delen van broncode in een open software-innovatienetwerk zijn nu in kaart gebracht. De afhankelijkheden tussen de genoemde kenmerken en voor- en nadelen en de gevolgen daarvan zullen in hoofdstuk 6 geconceptualiseerd worden, wat de basis zal vormen van analyse van de voor- en nadelen van het delen van broncode in een gesloten software-innovatienetwerk.
Motivatie voor samenwerken
4
In de inleiding is al kort gesproken waarom softwarebedrijven samenwerken met andere bedrijven. Het doel van dit hoofdstuk is verder inzicht te geven in de motivatie voor bedrijven om samen te gaan werken. Dit inzicht is relevant omdat het helpt bij de beoordeling of bepaalde gevolgen van het delen van broncode voor- of nadelen zijn. Eerst zal behandeld worden wat bedrijven willen bereiken met het aangaan van een strategische
alliantie. In de daaropvolgende paragraaf zal ingegaan worden op software-innovatie en de mogelijke rol van partners daarbij. De laatste paragraaf gaat in op het risico van samenwerken.
4.1 Samenwerking in een strategische alliantie Het primaire doel van een strategische alliantie
op neer dat iedere partij zich afzonderlijk richt
is het creëren van waarde. Doz en Hamel (1998)
op het ontwikkelen van de eigen kernvaardig-
noemen drie manieren hoe waarde gecreëerd
heden en activiteiten. Als deze gecombineerd
kan worden. De eerste is coöptatie, dit is het
worden zijn ze waardevoller dan als elke partij
verschijnsel dat concurrenten tot bondgenoten
alle vaardigheden zelf zou hebben ontwikkeld.
worden gemaakt. Door potentiële concurrenten in de alliantie te brengen wordt hun dreiging geneutraliseerd. Producenten van complementaire goederen moeten ook in de alliantie worden verenigd. Een tweede doel kan co-specialisatie zijn, dit is de waardecreatie die optreedt als afzonderlijke unieke gedifferentieerde middelen van de partners, zoals vaardigheden, merken, relaties, posities en tastbare goederen in worden gebracht om de alliantie tot een succes te maken. Het komt er
Het derde doel dat behandeld wordt is leren en internalisatie. Hier is sprake van wanneer partnerschappen worden aangegaan om competenties en vaardigheden aan te leren die niet op de markt te koop zijn. Naast de hierboven genoemde primaire doelen zijn er nog secundaire doelen. Dit zijn de meer specifieke doelen die bedrijven proberen te bereiken. Bedrijven denken dat ze deze doelen kunnen verwezenlijken door het aangaan van relaties met andere bedrijven.
< 45
Mohr en Spekman (1994) noemen als belang-
te werken met andere bedrijven. Deze bedrijven
rijkste redenen voor samenwerken het halen
willen dat hun producten de basis (het platform)
van concurrentievoordeel. Verder zijn ook de
vormen van de producten en diensten van ande-
toegang tot nieuwe technologie, de mogelijk-
re bedrijven. Een platformleider kan profiteren
heid meer producten en diensten aan te bieden,
van de innovaties die ontwikkeld worden door
schaalvoordelen in gezamenlijk onderzoek en
andere bedrijven, maar kan er ook erg afhan-
productie, toegang naar kennis en complemen-
kelijk van zijn. Platformleiders en hun partners
taire vaardigheden en delen van risico van be-
hebben een grote drijfveer om samen te (blijven)
lang.
werken, omdat hun gecombineerde inspannin-
De belangrijkste redenen om een strategisch partnerschap aan te gaan volgens McLellan en Adams (2001) zijn voor ICT-bedrijven weergegeven in tabel 4.1, aangevuld met de bevindingen van Mohr en Spekman. In de tabel is
veren dan wanneer ze hun inspanningen niet zouden combineren, zowel de platformleider als haar partners hebben belang bij het succes van het platform.
gekozen voor de naamgeving van McLellan en
Het bereiken van nieuwe klanten, het vergroten van
Adams, aangevuld met het delen van risico. De
het bereik en het creëren nieuwe markt hebben in
andere redenen die Mohr en Spekman noemen
essentie allemaal betrekking op het doel meer
kunnen worden onderverdeeld bij de redenen
omzet te genereren, zonder dat de kosten even-
die McLellan en Adams noemen.
redig stijgen. Ook belangrijk is vertrouwenswaar-
Het verkrijgen van platformleiderschap is voor softwarebedrijven is volgens Gawer en Cusumano (2002) een belangrijke reden om samen
digheid naar klanten. Door te partneren met een bedrijf dat aanzien en respect geniet, stijgt de eigen vertrouwenswaardigheid.
meer strategisch
meer tactisch
Concurrentievoordeel
Vergroten capaciteit
Vertrouwenswaardigheid naar klanten
Vergroten bereik
Platformleiderschap
Creëren nieuwe markt
Bereiken van nieuwe klanten Uitbreiding bekwaamheden Delen van risico
Tabel 4.1: Redenen voor samenwerken
46 >
gen meer voordeel voor hen afzonderlijk ople-
Uitbreiding aanbod
Verminderen van kosten
4.2 Software-innovatie Software-innovatie is het maken van nieuwe
De grijze kubus stelt de thuisbasis voor, dit is
software, of het aanpassen van bestaande soft-
het uitgangspunt vanuit waar de innovaties ge-
ware zodat een ander, nieuw product ontstaat.
daan kunnen worden langs de dimensies.
Productinnovaties kunnen gedaan worden op de dimensies van hoe (de technologie die nodig is om het product te ontwerpen, ontwikkelen en te produceren) wat (de toepassing of klantbehoefte die bediend wordt) en wie (de klantengroep die bediend wordt). Dit kan geïllustreerd worden door de dimensies driedimensionaal weer te geven zoals in figuur 4.1. (Cooper, 1993)
Op elk van deze dimensies kan worden samengewerkt met een partner. Technologiepartners kunnen de technologie leveren die nodig is voor een bepaalde innovatie, wederverkoop- en implementatiepartners kunnen ingezet worden om gezamenlijk producten te ontwikkelen die in de behoeften voorzien van klanten in hun bedrijfstak.
Tabel 4.1: De Innovatiearena
< 47
4.3
Risico
4.4 Conclusie
Een bedrijf dat wil gaan samenwerken met een
De belangrijkste doelen die bedrijven willen be-
andere organisatie moet het risico afwegen te-
reiken met een strategische alliantie zijn coöp-
gen de opbrengst. De mogelijke opbrengsten
tatie, co-specialisatie en leren en internalisatie.
zijn eerder in dit hoofdstuk genoemd. Het risico kan bestaan uit opportunistisch of zelfs illegaal gedrag van de partner, of het verlies van de investering van tijd en geld in een relatie die om een andere reden stukloopt. Redenen voor het mislukken van een partnerschap kunnen onder meer liggen in een gebrek aan vertrouwen tussen de partners, het niet uit handen kunnen geven van de controle en de complexiteit van het gezamenlijke project (Powell et al, 1996). Als een samenwerking stukloopt kan het zijn dat de schade niet beperkt blijft tot de tot dan toe geïnvesteerde tijd en geld. Een specifiek risico voor softwarebedrijven is het oneigenlijk gebruik door de partner van haar intellectueel eigendom in de vorm van kennis, software of broncode.
Voor een bedrijf dat een product heeft ontwikkeld of wil gaan ontwikkelen is samenwerking een aantrekkelijke optie. Als hij het product zelf al ontwikkeld heeft kan hij door samenwerking de opbrengst van de gedane investering vergroten, doordat de afzetmogelijkheden worden vergroot. Wanneer het product nog ontwikkeld moet worden, kan samenwerking op het gebied van de ontwikkeling de kosten verlagen en het risico verkleinen. Wanneer een bedrijf platformleiderschap nastreeft is het belangrijk zoveel mogelijk partners aan het platform te binden. Voor de partners van een platformleider is samenwerking aantrekkelijk omdat het de kosten van ontwikkeling en marketing vermindert en geprofiteerd kan worden van de innovaties van anderen. Productinnovaties kunnen gedaan worden op drie dimensies: technologie, toepassing en klantengroep. Op al deze dimensies kunnen partners van dienst zijn. Tegenover deze mogelijke voordelen staat het nadeel dat samenwerking ook het risico van opportunistisch gedrag met zich meebrengt.
48 >
Vormen van samenwerken
5
In dit hoofdstuk wordt dieper ingegaan op hoe samenwerking tussen softwarebedrijven organisatorisch en technisch kan verlopen. Het doel van de eerste paragraaf is een afbakening te geven van wat in deze scriptie bedoeld wordt met een gesloten software-innovatienetwerk. De tweede paragraaf behandelt de samenwerking vanuit technisch perspectief
5.1
Organisatorisch perspectief
Preece (1995) noemt structuren, functies en doelen
de markt en de hiërarchische organisatie. Een
als variabelen voor de conceptualisatie van stra-
innovatienetwerk bestaat vaak uit loosely coupled
tegische allianties.
organisaties met zowel sterke als zwakke ban-
De structuur bepaalt de organisationele vorm die wordt gekozen voor de samenwerking, zoals joint ventures, licentieovereenkomsten, managementcontracten, onderaannemerschappen of gezamenlijke productie-, onderzoek- of
den tussen de gezamenlijke leden. De banden zijn coöperatief van aard. Het verschil met een losse verzameling partnerschappen van één bedrijf is dat de andere leden van het netwerk ook banden met elkaar onderhouden.
ontwikkelingsinspanningen. De functies zijn
Onder anderen Powell et al. (1996) en Gulati et
de activiteiten waarmee de alliantie zich gaan
al (2000) stellen dat in tijden van snel verande-
bezighouden. Het gaat hier om zaken als tech-
rende en complexe kennisbases, de benodigde
nologie- en productontwikkeling en marketing.
expertise voor innovatie en concurrentievoor-
De doelen bepalen de algehele invloed die de
deel moet worden gezocht in netwerken en niet
alliantie zou moeten hebben op de strategische
bij individuele bedrijven.
richting en de vaardigheden van het bedrijf, oftewel de significantie op de lange termijn.
De term netwerk is een abstract begrip dat een verzameling onderling verbonden componenten aanduidt. Deze componenten worden nodes
5.1.1
Het netwerkperspectief
genoemd in netwerkterminologie. Het netwerk
Volgens Imai en Baba (1991) kunnen innovatie-
als concept wordt in verschillende vakgebieden
netwerken gezien worden als tussenvorm van
gebruikt als perspectief om fenomenen te bestu-
< 49
deren. Deze netwerken zijn vaak abstract en ze worden gedefinieerd door de onderzoeker. Hoe het netwerk er uit ziet, wat de nodes zijn, welke nodes wel of niet worden opgenomen hangt af van het te bestuderen fenomeen. Elke benadering levert een andere abstractie van het totale netwerk op, een partieel netwerk zoals Mitchell (1969) het noemt.
5.1.2
Netwerkclassificaties
Interorganisationele netwerken worden door verscheidene auteurs verschillend geclassificeerd. Grandori en Soda (1995) doen dat op basis van de mate van formaliteit. Zij onderscheiden social, bureaucratic en proprietary networks. Binnen deze drie typen netwerken maken zij nog onderscheid naar de vorm van coördina-
Ook in de sociale wetenschap en de organisa-
tiestructuur. Deze kan symmetrisch of asym-
tietheorie wordt het netwerkperspectief veel
metrisch zijn, waar asymmetrische netwerken
gebruikt om een verzameling organisaties en
een centrale coördinerende organisatie kennen
personen en de onderlinge relaties die hen ver-
en symmetrische niet. Social networks zijn
binden van personen en organisaties in kaart te
netwerken die draaien om persoonlijk contact
brengen. (Fombrun, 1982; Grandori, 1995)
tussen leden van verschillende organisaties. Dit
Een bedrijf bestaat niet in isolement, maar is
kunnen persoonlijke netwerken van onderne-
onderdeel van zijn omgeving. Vanuit een net-
mers en managers zijn, maar ook bijvoorbeeld
werkperspectief is een bedrijf onderdeel van een
een netwerk van gespecialiseerde onderaanne-
netwerk van andere organisaties zoals leveran-
mers. Voorbeelden van bureaucratic networks
ciers, afnemers, brancheorganisaties, overheden
zijn handelsorganisaties en consortia. In deze
en concurrenten. De actoren zijn verbonden
netwerken zijn de onderlinge relaties formeel en
door de relaties die zij met elkaar onderhouden.
contractueel vastgelegd. Proprietary networks
Deze verbindingen worden gebruikt om te com-
kennen de grootste mate van formaliteit. Het
municeren. Bij formele netwerken is het doel
verschil met bureaucratic networks is, dat in dit
van communicatie ook coördinatie. (Nohria,
type de organisaties een economisch belang in
1992)
elkaar hebben. Voorbeelden hiervan zijn joint-
Als organisatievorm wordt het netwerk wel geplaatst tussen de hiërarchie enerzijds en de markt anderzijds. De coördinatie in de relatie
ventures en capital ventures. Dit wederzijds belang werkt als prikkel om de samenwerking te stimuleren.
is niet geheel hiërarchisch en niet geheel trans-
Rosenfeld (1996) onderscheidt harde netwerken
actioneel, maar houdt het midden tussen deze
van zachte netwerken. Het eerste type gebruikt hij
uitersten. (Cravens et al., 1996)
om een netwerk van bedrijven aan te duiden die samenwerken om gezamenlijk een product te produceren of te vermarkten, gezamenlijk in te kopen of om een markt te ontwikkelen. Zachte
50 >
netwerken daarentegen bestaan uit drie of meer
ren onderdeel zijn van het te bestuderen net-
bedrijven om gemeenschappelijke problemen
werk (definitional focus), of de focus op één actor
op te lossen, informatie te delen of om nieuwe
ligt of op een groep (nodal-anchoring) en wat de
vaardigheden te leren. Harde netwerken zijn
het maximaal te volgen aantal links is (cut-off
meer formeel georganiseerd dan zachte netwer-
distance. Zonder afspraken over de kenmerken
ken.
waaraan de actoren, hun relaties of activiteiten
Hinterhuber en Levin (1994) onderscheiden vijf typen netwerken. Het eerste type netwerk is het
moeten voldoen is het netwerk vrijwel onbeperkt en daardoor onmogelijk te bestuderen.
interne netwerk. De actoren in dit type zijn een-
De basis voor het selecteren van welke actoren
heden zoals strategic business units of project-
wel en welke niet in het partiële netwerk opge-
teams. De overige netwerken zijn externe net-
nomen worden, kunnen kenmerken zijn van één
werken, die zij opdelen in verticale, horizontale
of meer van de volgende componenten: actoren,
en diagonale netwerken. Het verticale netwerk
relaties of activiteiten (Laumann et. al., 1983).
bestaat uit organisaties die een afnemer-leve-
Zo linken attribute networks actoren op basis van
rancierrelatie met elkaar hebben. Als voorbeeld
een gemeenschappelijkheid van de actoren. In
van een succesvol verticaal netwerk noemen zij
transaction networks daarentegen worden actoren
het Japanse Keiretsu systeem, waarvan Toyota
geselecteerd op basis van hun participatie in een
als bekendste voorbeeld geldt. Horizontale net-
bepaald type social exchange. De inhoud van de
werken bestaan uit soortgelijke bedrijven met
transactie kan onder andere bestaan uit invloed,
soortgelijke markten en hebben als doel om
macht, informatie en goederen. In action-set net-
een bepaalde technologie te exploiteren of geza-
works tenslotte zijn die actoren opgenomen die
menlijk een geografisch marktsegment te bedie-
participeren in een bepaalde specifieke gebeur-
nen. Diagonale netwerken tenslotte bestaan uit
tenis of activiteit. Deze netwerken worden op-
bedrijven uit verschillende bedrijfstakken die
gericht om een bepaald einddoel te bereiken en
zoeken naar synergie om op die manier inter-
zijn in die zin dus tijdelijk.
disciplinaire markten te creëren. 5.1.4 Het gesloten software-innovatienetwerk 5.1.3
Netwerkabstractie Het netwerk zoals bedoeld in de vraagstelling
Om een netwerk te kunnen analyseren moet eerst vastgesteld worden op welk niveau gekeken wordt, wat het netwerk omvat en vanuit welk gezichtspunt wordt gekeken. Conway en Steward (1998) noemen drie beslissingen die genomen moeten worden om het netwerk af te bakenen. Er moet besloten worden welke acto-
is een formeel netwerk, de actoren gaan formele, contractuele relaties met elkaar aan. Het doel van de samenwerkingsverbanden is de het ontwikkelen en vermarkten van software. Het is gesloten omdat het netwerk zelf en het resultaat van deze samenwerkingsverbanden niet publiekelijk toegankelijk is. In de terminologie
< 51
van Grandori en Soda (1995) zou het beoogde
Wat betreft de abstractie ligt de focus op een
netwerk het best als bureaucratic omschreven
groep, te weten de initiator, zijn partners en
worden. Waarschijnlijk zal in de meeste geval-
hun klanten. Verder dan de klanten worden de
len in het begin de coördinatiestructuur sym-
links niet gevolgd, dit is dus de maximale cut-
metrisch zijn, de initiator (degene die het initia-
off-afstand. Actoren die bestudeerd worden zijn
tief neemt om zijn broncode te openen voor zijn
gekozen op basis van hun participatie in een be-
partners) zal de rol van centrale coördinerende
paald type social exchange, dus het netwerk is
organisatie op zich nemen. Het netwerk is for-
een transaction network.
meel georganiseerd en is in de terminologie van Rosenfeld (1996) dus te kenmerken als een hard netwerk. Als type netwerk in de classificatie van Hinterhuber en Levin (1994) tenslotte kan het netwerk zowel horizontaal als verticaal zijn, afhankelijk van de voorkeuren van de betrok-
In figuur 5.1 is schematisch een dergelijk netwerk weergegeven. In het midden bevindt zich het bedrijf dat haar broncode openstelt voor haar partners. De partners zijn in dit figuur aangeduid met de letter P, de klanten met de letter K.
ken partijen.
Figuur 5.1: Schematische voorstelling van gesloten software-innovatienetwerk
52 >
5.2
Technisch perspectief
Met technische samenwerking wordt hier be-
waar programma’s aan kunnen linken. Met de
doeld de manier waarop software geschikt wordt
opkomst van internet en netwerktoepassingen
gemaakt om met een ander programma samen
worden webservices populairder, dit zijn API’s
te werken. Meestal gebeurt dit door middel van
die het internet en het http-protocol gebruiken
application programming interfaces. Hierop wordt
om te communiceren. Deze API’s stellen ex-
verder ingegaan in de volgende paragraaf.
terne ontwikkelaars in staat de functionaliteit
5.2.1
Application programming interfaces
Een application programming interface (API) is een set van definities van de manieren waarop een programmeur van het ene programma de functionaliteiten van een ander programma aan kan roepen en zo deze functionaliteiten kan gebruiken in het eigen programma. De API’s worden vaak gebruikt als methode om abstractie te bereiken en zo complexiteit te verhullen. Het is het een manier om interne functionaliteit extern te ontsluiten. Bovendien maken API’s het mogelijk verschillende programma’s te integreren zonder dat de broncode van beide programma’s nodig is. Als beide componenten op dezelfde computer geïnstalleerd staan, nemen de API’s vaak de vorm aan van softwarebibliotheken,
te gebruiken zonder deze zelf te hoeven ontwikkelen. Een API is een goed voorbeeld van wat Von Hippel en Katz (2002) een ‘toolkit for user innovation’ noemen. (Bessen, 2004) Een dergelijke gereedschapkist stelt externen in staat de technologie te gebruiken op manieren die de uitvinder zelf niet bedacht had, of voor wie het niet opportuun was. Bovendien hoeft de externe de inwendige werking van de technologie niet te begrijpen, maar kan hij deze benaderen als een zwarte doos. Een goed voorbeeld hiervan is de Google Maps Api, (zie tekstkader 5.1) die door externen gebruikt wordt voor toepassingen die Google zelf niet verzonnen had of die niet in haar aanbodstrategie passen.
Google Maps API Een goed voorbeeld van een succesvolle webservice is de Google Maps API. Google Maps is een website die zowel kaarten als satellietfoto’s toont en waarmee routes gepland kunnen worden. Niet lang na de lancering gaf Google een API vrij die externe ontwikkelaars kunnen gebruiken om de kaarten op de eigen website te tonen aangevuld met eigen informatie of eigen kaarten. Inmiddels wordt de API door derden gebruikt om talloze uiteenlopende zaken in kaart te brengen. Bijvoorbeeld om de hoogte van criminaliteit in Amerikaanse steden weer te geven, om beschikbare appartementen te tonen of om de New-Yorkse metro weer te geven
Tekstkader 5.1: De Google Maps API
< 53
Wanneer twee bedrijven (A en B) samenwerken
Het ontwikkelen van een API door bedrijf A
en bedrijf B maakt software dat gebaseerd is op
voor extern gebruik is een complexe en dure
de software van bedrijf A, dan gaat dit door-
opgave. De software moet stabiel zijn, in de zin
gaans door gebruik te maken van de API’s die
dat het niet meer aan voortdurende verandering
door bedrijf A zijn vastgesteld.
onderhevig is, omdat een veranderende API
De vastgestelde API is een subset van de totale interne functionaliteit van de software. Onder meer om de complexiteit te verminderen wordt slechts een deel van de functies extern toegankelijk gemaakt. De keuze voor welke functies dat zijn en hoe deze aangeroepen dienen te worden
software zou breken. Als de broncode gedeeld wordt kan door de grotere kennisdeling de API in nauwer overleg worden vastgesteld en kan beter rekening gehouden worden met de wensen van degenen die de API moeten gebruiken.
wordt gemaakt door degene die de API vaststelt
Een API kan deel uitmaken van een Software
en is niet te veranderen door de programmeur
Development Kit (SDK). Een SDK is een ver-
die met de API moet werken.
zameling hulpmiddelen die gebruikt kunnen
API’s stellen programmeurs in staat om snel en flexibel te ontwikkelen met een lagere kans op fouten door de abstractie en modulariteit. Anderzijds betekent het werken met API’s ook een beperking van de flexibiliteit en innovativiteit van de externe ontwikkelaar, omdat deze afhankelijk is van de definitie van de API door het andere bedrijf. De API wordt door bedrijf A vastgesteld zonder dat zij op dat moment pre-
worden voor het ontwikkelen van computerprogramma’s op basis van bepaalde software, zonder dat de broncode geopenbaard wordt. Als de broncode beschikbaar is, is de noodzaak van de ontwikkeling van een SDK veel kleiner, omdat de software dan sowieso aangepast kan worden. 5.2.2
Conclusie
cies kan weten hoe en waarvoor bedrijf B deze
Hoewel samenwerken op technologisch gebied
zou willen gebruiken.
zonder broncode te delen goed mogelijk is door
In het geval dat de broncode beschikbaar is, is de externe programmeur in mindere mate afhankelijk van de API-definitie van bedrijf A. Hij kan dan aanroepen wijzigen, toevoegen of functionaliteit op een andere manier ontsluiten. Dit betekent overigens niet dat waneer de broncode beschikbaar is, bedrijf A geen API hoeft te definiëren, het blijft een verstandige werkwijze om functionaliteiten modulair op te bouwen en via een stabiele API te ontsluiten.
54 >
aanroepen hiervan door externe software deze
het gebruik van API’s, heeft het delen van de broncode enkele voordelen. De innovativiteit van de partij die met de API werkt wordt in het geval van gedeelde broncode niet gehinderd door de vooraf bedachte definitie van de API. Door verhoogd inzicht in de interne structuur van de software kan de partij die de API wil gebruiken wijzigingen doen of in ieder geval suggesties aandragen, zodat beter op de wensen ingespeeld kan worden.
6
Analyse
Dit hoofdstuk dient als overgang van de theorie naar de analyse. Eerst zullen voor de begripsbepaling verschillende niveaus van het delen van broncode besproken worden. In de tweede paragraaf zal uiteengezet worden wat de verdere aanpak is om antwoord te kunnen geven op de onderzoeksvraag. Verder in dit hoofdstuk wordt de eerste stap gezet van deze aanpak, het conceptualiseren van de bevindingen van hoofdstuk 2 en 3.
6.1 Begripsbepaling van het delen van broncode Broncode die open is, is in te zien door der-
De naam community source is geïnspireerd op
den en wordt in deze scriptie open broncode ge-
Sun Microsystem’s Community Source, die
noemd. Als de derde partij de open broncode
de naam als eerste opperde in 1998, maar er
ook mag wijzigen wordt de broncode aanpasbaar
wordt net iets anders mee bedoeld. Ook Sun
genoemd. Als de aanpasbare broncode ook vrij
deelt broncode binnen een gemeenschap, maar
herverspreid mag worden is er sprake van open
deze gemeenschap is niet gesloten, iedereen kan
source, de code is dan publiek toegankelijk, zoals
zich aanmelden om lid te worden. Community
in hoofdstuk 3 is besproken. Het delen, binnen
source zoals hier bedoeld wordt duidt daarente-
een gesloten innovatienetwerk, van open bron-
gen op een gesloten netwerk, zoals het in de in-
code die aangepast mag worden wordt in deze
leiding reeds genoemde VMware Community
scriptie community source genoemd. In figuur 6.1
Source.
zijn deze verschillende niveaus van het delen van broncode weergegeven.
< 55
6.2 Aanpak Om antwoord te krijgen op de onderzoeksvraag
De bevindingen van deze gevalstudie worden
en dus om achter de voor- en nadelen van het
in hoofdstuk 8 gebruikt om het model (van in-
delen van broncode te komen zullen in de ana-
terdependenties van open source) aan te passen
lyse de volgende stappen genomen worden.
aan de veranderde kenmerken om zo een ver-
Eerst wordt in de volgende paragraaf de interdependenties van open source geconceptuali-
stellen.
seerd, om duidelijk te maken welke voor- en na-
De inzichten die dit oplevert vormen samen met
delen voor de deelnemers afhangen van welke
de theorie over waarom bedrijven samenwerken
kenmerken.
uit hoofdstuk 4 de basis van de beoordeling wat
Vervolgens wordt in hoofdstuk 7 een gevalstudie van Teamsoft besproken. TeamSoft is een vorm van community source waarbij het netwerk draait rondom één actor.
Figuur 6.1: Het delen van broncode
56 >
gelijkbaar model voor community source op te
voor- en nadelen zijn voor de verschillende participanten in community source.
6.3 Interdependenties in open source
6.3.1
Op basis van de theorie uit hoofdstuk 2 en 3
ken, gekenmerkt door drie factoren: openheid,
worden hier de interdependenties van open
vrijheid en vrije herverspreidbaarheid.
source in kaart gebracht. De diverse factoren en hun effecten die aan de orde zijn gekomen worden gegroepeerd en hun interdependenties geconceptualiseerd. Per gedefinieerde factor wordt besproken wat die factor omvat en door
Kenmerken
Open source wordt, zoals in hoofdstuk 3 bespro-
Openheid Openheid slaat op het feit dat de gehele broncode in te zien is voor iedereen die ook de gecompileerde code heeft verkregen.
welke factoren deze beïnvloed wordt en wat de
Vrijheid
aard van deze invloed is. Figuur 6.2 is een weer-
Vrijheid is de vrijheid die ontvangers van de
gave van het conceptueel model.
broncode genieten om deze te gebruiken naar
Het doel hiervan is het verduidelijken wat de
eigen inzicht, zonder beperkingen van het doel
oorzaken zijn van de adoptie van OSS door
waarvoor deze ingezet kan worden.
gebruikers en externe ontwikkelaars en hoe de commerciële actoren hier aan verdienen. Er wordt hier geen nieuwe theorie geïntroduceerd, het dient om inzichtelijk te maken wat de gevolgen zijn van het delen van broncode zoals dat in het open-sourcemodel gebeurd.
Vrije herverspreidbaarheid Vrije herverspreidbaarheid staat voor de vrije herverspreiding van de code. OSS mag volgens de definitie altijd door derden herverspreid worden, zonder toestemming van of betaling aan de originele ontwikkelaar.
Figuur 6.2: Conceptueel model open source
< 57
6.3.2
Gevolgen
In paragraaf 3.6, 3.7 en 2.2.2 is vastgesteld dat deze kenmerken gevolgen hebben die voor gebruikers, externe ontwikkelaars en exploitan-
zonder dat daar toestemming van de originele ontwikkelaar voor nodig is bestaat de kans dat een product zich opsplitst naar twee producten.
ten van de software redenen zijn om de soft-
Bescherming intellectueel eigendom
ware te gebruiken. Deze gevolgen staan in de
Eén van de grootste nadelen van OSS voor com-
linkerkolom in tabel 6.1. In de rechterkolom is
merciële softwareontwikkelaars is de slechte be-
aangegeven hoe deze terug komen in het model.
scherming van het intellectueel eigendom. Dit
Bij het behandelen van de factoren, later in deze
wordt veroorzaakt door de vrije herverspreidbaar-
paragraaf, zal op deze indeling verder worden
heid, waardoor het onmogelijk is om het intel-
ingegaan.
lectueel eigendom, opgeslagen in de broncode,
Mogelijkheid van fork De vrijheid zorgt er voor dat ontvangers van de broncode deze kunnen wijzigen. Als zij deze wijzigen niet teruggeven aan de originele ontwikkelaar ontstaan verschillende versies van de software. Omdat het iedereen is toegestaan om een eigen versie van de software te verspreiden
voor anderen geheim te houden. Het betekent in het geval van onder andere de GPL-licentie niet dat de broncode één op één gekopieerd kan worden in gesloten software, maar ook in dat geval kan in ieder geval de interne werking bestudeerd worden en op eigen wijze geïmplementeerd worden.
Gevonden in theorie
Weergegeven in model als
Bescherming intellectueel eigendom
Bescherming intellectueel eigendom
Flexibiliteit door aanpasbaarheid
flexibiliteit
Mogelijkheid van fork
Interoperabiliteit en compatibiliteit
Continuïteit van doorontwikkeling en ondersteuning Onafhankelijkheid van ontwikkelaar
Mogelijkheid broncode te inspecteren op kwaliteit en fouten Voordelen van peer-review Ontbreken licentiekosten
Profiteren van inspanningen van anderen. Delen van kennis
Tabel 6.1: Gevonden factoren en naamgeving in model
58 >
mogelijkheid van fork flexibiliteit
onafhankelijkheid onafhankelijkheid
inspecteerbaarheid inspecteerbaarheid prijs
kennisdeling kennisdeling
Prijs
Flexibiliteit
Prijs is de hoogte van de prijs die gevraagd kan
Flexibiliteit is een ruim begrip en omvat aanpas-
worden voor het product door de ontwikkelaar.
baarheid, interoperabiliteit en compatibiliteit.
Deze wordt negatief beïnvloed door vrije herver-
Flexibiliteit wordt positief beïnvloed door vrijheid
spreidbaarheid. Een OSS-ontwikkelaar kan wel
en openheid. De openheid zorgt er voor dat de
een hoge prijs vragen voor de software, maar
code aangepast kan worden, vrijheid zorgt er
hij kan de verkrijger van de software niet van
voor dat dit ook daadwerkelijk toegestaan is.
gratis herverspreiding weerhouden. Wanneer
Verbeterde interoperabiliteit en compatibiliteit
de verkrijger dit doet, beïnvloedt dat de prijs die
zijn het gevolg van de aanpasbaarheid en zorgen
de ontwikkelaar voor de software kan vragen
er voor dat de software beter kan samenwerken
negatief, omdat gebruikers de software dan er-
met andere software, dat het beter integreert en
gens anders gratis kunnen krijgen. Prijs wordt
dat de inzetbaarheid van de software vergroot
ook negatief beïnvloed door bescherming intel-
wordt.
lectueel eigendom. De lage bescherming van het intellectueel eigendom (vanwege het negatieve effect van herverspreidbaarheid) maakt het onmogelijk een hoge prijs te vragen voor de software op zich.
Inspecteerbaarheid Door de openheid kunnen derden de broncode bekijken. Inspecteerbaarheid wordt dus positief beïnvloed door openheid. Dit zorgt voor een grotere transparantie, de software is niet langer als
Onafhankelijkheid
een zwarte doos, maar de werking kan precies
Onafhankelijkheid is de mate waarin gebruikers
worden nagegaan. Dit maakt een betere beoor-
en externe ontwikkelaars onafhankelijk zijn
deling van de kwaliteit mogelijk door derden die
van de ontwikkelaar van het product. Onaf-
de software willen gebruiken. Doordat externe
hankelijkheid van de gebruikers op het eerste
programmeurs de code kunnen inzien, maakt
niveau wordt positief beïnvloed door zowel vrij-
het peer-review mogelijk. De code wordt dan
heid en openheid. Door de openheid is het moge-
niet alleen beoordeeld, maar de ontwikkelaars
lijk om zonder de inzet van de ontwikkelaar het
ontvangen ook terugkoppeling over gevonden
product aan te (laten) passen. De vrijheid zorgt
softwarefouten en mogelijke andere problemen.
er voor dat dit ook is toegestaan. Onafhanke-
Een goed werkend peer-reviewmodel heeft een
lijkheid van externe ontwikkelaars en exploi-
positief effect op kwaliteit. Ook de veiligheid
tanten wordt daarnaast positief beïnvloed door
van de software kan hierdoor verbeterd wor-
herverspreidbaarheid, het is hun toegestaan om
den, omdat de code door meer mensen ingezien
onafhankelijk van de originele ontwikkelaar de
worden en daarom veiligheidsfouten eerder
door hen aangepaste versie te verspreiden.
aan het licht kunnen komen, maar ook omdat door de inspecteerbaarheid de mogelijkheid dat
< 59
de software ‘achterdeuren’ bevat kleiner wordt.
die anderen ook gebruiken en met toenemende
Bovendien kunnen gebruikers de software zelf
adoptie stijgt de waarde van het product door
compileren, zodat ze zeker weten dat de code
de gebruiker. De mogelijkheid van een fork kan een
die door hen geïnspecteerd is dezelfde is als
negatieve invloed hebben op de adoptie door ge-
waarvan de binaire code gecompileerd is.
bruikers.
Kennisdeling
Behoefte aan complementaire producten en
Kennisdeling doet zich voor op het moment dat
diensten
de ene partij zijn broncode openstelt voor een
Behoefte aan complementaire producten en diensten is
andere partij, de kennis opgeslagen in de bron-
de behoefte van huidige gebruikers van het pro-
code wordt gedeeld met iedereen die de soft-
duct aan producten en diensten die de waarde
ware ontvangt. Het stelt de ontvanger in staat
van het product verder kunnen vergroten. Deze
om te profiteren van de onderzoeks- en ontwik-
wordt positief beïnvloed door adoptie door gebrui-
kelingsinspanningen van de ander. Kennisde-
kers, immers hoe groter het aantal gebruikers
ling wordt positief beïnvloed door openheid.
van een product, des te groter de kans dat de behoefte aan aanvullende producten en diensten
6.3.3
Adoptie
Zoals gesteld in de vorige paragraaf hebben de genoemde gevolgen invloed op de adoptie van de software door gebruikers en externe ontwikkelaars en exploitanten.
60 >
groeit. Dit komt overeen met de marketingstrategie zoals besproken in paragraaf 3.11. Adoptie
door
externe
ontwikkelaars
en
exploitanten Adoptie door externe ontwikkelaars en exploitanten
Adoptie door gebruikers
is de mate waarin externe ontwikkelaars of ex-
Adoptie door gebruikers duidt op de mate waarin
ploitanten het product toepassen in hun eigen
het product door gebruikers wordt opgepikt,
producten- en dienstenaanbod. De adoptie door
hoe meer mensen het product gebruiken, hoe
externe ontwikkelaars en exploitanten wordt net
hoger de adoptie. Zoals in dit hoofdstuk geble-
als de adoptie door gebruikers positief beïnvloed
ken is, zijn prijs, onafhankelijkheid, flexibiliteit en
door prijs, onafhankelijkheid, flexibiliteit en inspec-
inspecteerbaarheid allemaal factoren die de adop-
teerbaarheid ook positief beïnvloed door behoefte
tie door gebruikers positief beïnvloeden. Door
aan complementaire producten en diensten omdat de
de negatieve invloed van herverspreidbaarheid is
gegroeide behoeften van gebruikers aan externe
de prijs van OSS laag, wat aantrekkelijk is voor
ontwikkelaars en exploitanten de kans biedt om
gebruikers en de adoptie dus bevordert. Adoptie
in deze behoeften te voorzien. In paragraaf 3.7 is
door gebruikers wordt ook positief beïnvloed door
ook duidelijk geworden dat één van de redenen
zichzelf vanwege netwerkexternaliteiten, ge-
van adoptie door externe partijen de mogelijkheid
bruikers hebben een voorkeur voor producten
te profiteren van inspanningen van derden was. Dit
is weergegeven in het model door kennisdeling.
om aan te geven dat de lage prijs een negatief
De externe ontwikkelaar kan zelf initiator van
effect op de omzet van de ontwikkelaar heeft.
een ander product zijn. Zoals in paragraaf 3.9 besproken is de mogelijkheid externe OS-code te gebruiken voor initiatoren een reden om hun eigen software OSS te maken.
Omzet externe ontwikkelaars en exploitanten Omzet externe ontwikkelaars en exploitanten tenslotte is de omzet van degene die gemaakt wordt door de externe partijen. Ook zij verdienen niet
Doorontwikkeling en continuïteit
rechtstreeks aan de verkoop van OSS. Hun om-
Doorontwikkeling en continuïteit staat voor de
zet wordt alleen positief beïnvloed door te voor-
kans dat het product doorontwikkeld zal wor-
zien in de behoefte aan complementaire producten
den en de mate waarin continuïteit van het
en diensten van gebruikers.
product is gegarandeerd. Het staat ook voor de mate en snelheid van innovatie van en rondom het product. Dit wordt positief beïnvloed door adoptie door externe ontwikkelaars en exploitanten, omdat een groter aantal van externe actoren de kans vergroot dat het product zal worden doorontwikkeld en ondersteund. Een groter aantal ontwikkelaars die bezig zijn het product te verbeteren betekent ook snellere innovatie. Doorontwikkeling en continuïteit wordt alleen positief beïnvloed als de externe ontwikkelaar zijn wijzigingen verspreid binnen de gemeenschap. Motieven hiervoor zijn behandeld in tabel 3.5. Omzet initiator Omzet initiator is de omzet van degene die de ontwikkeling van het product geïnitieerd heeft. Doordat het moeilijk is een hoge prijs te vragen voor het product zelf, zal de prijs laag zijn. In de meeste gevallen is het product zelfs gratis. Dit betekent dat de omzet alleen positief beïnvloed wordt door te voorzien in de behoefte aan complementaire producten en diensten. Voor het overzicht is in het model geen directe lijn tussen prijs en omzet initiator getekend, al zou dit wel kunnen
< 61
Gevalstudie TeamSoft
7
In dit hoofdstuk zal de omgang met en de motivatie voor het delen van broncode door TeamSoft behandeld worden. TeamSoft is een bedrijf dat de broncode van haar software ter beschikking stelt aan haar partners. Eerst zal de werkwijze en het door TeamSoft gebruikte ‘conditionalopen-sourcemodel’ besproken worden, daarna volgt een overzicht van de voor- en nadelen van het delen van broncode zoals dat wordt ervaren door TeamSoft.
7.1
Methodologie
Het doel van dit onderzoek is het verkrijgen van
weten te komen over de kennis en de informatie
kwalitatieve informatie om inzicht te krijgen
die de ondervraagde heeft over het onderwerp.
in de aard van de effecten van open broncode.
Hierbij is gekozen voor een open vraaggesprek,
Een gevalstudie is hier een geschikte methode
er zijn van tevoren geen gestructureerde vra-
voor (Van Engeldorp Gastelaars, 1998). Om
gen opgesteld. Eén reden hiervoor is dat dit
een uitspraak te kunnen doen over de mate van
het enige vraaggesprek was en dat er dus geen
de effecten zou een grotere groep noodzakelijk
antwoorden van verschillende ondervraagden
zijn, maar op dit moment zijn er niet voldoende
vergeleken hoefde te worden. De andere reden
geschikte gevallen bekend van bedrijven die op
is dat ik de mogelijke antwoorden, gezien het
een dergelijke manier werken.
exploratieve karakter van het onderzoek, zo
De informatie van de gevalstudie komt van de website van TeamSoft, uit emailwisseling met directeur Ab Troost en juridisch adviseur Theo
breed mogelijk wilde houden. Het geluid van het vraaggesprek is vastgelegd, een transcriptie hiervan is opgenomen als bijlage.
Talboom en een vraaggesprek gehouden met
De empirisch gevonden effecten zullen worden
Theo Talboom op het kantoor van TeamSoft in
verwerkt in het conceptueel model dat in het
Alblasserdam.
volgende hoofdstuk wordt opgebouwd. Hierbij
Het doel van het vraaggesprek was om meer te
zal een oordeel geveld worden over in hoeverre de gevonden effecten generaliseerbaar zijn.
< 63
7.2
Inleiding
Teamsoft is een Nederlandse producent van software voor het automatiseren en ondersteunen van bedrijfsprocessen. Het bedrijf is eind 2002 opgericht door Ab Troost, samen met het oude ontwikkelteam dat bij Exact verantwoordelijk was voor Paymate, een systeem voor hu-
van de nieuwe technologie is dat applicaties sneller ontwikkeld kunnen worden, met een lagere kans op fouten. Een ander voorbeeld van het voordeel van nieuwe technologie is dat de software via internet aangestuurd kan worden, zonder dat daar externe hulpmiddelen voor nodig zijn.
man and financial resource management.
7.2.1
Teamsoft is vanaf nul begonnen met de ontwik-
De TeamSoft E-Business Suite is een raamwerk
keling van haar software. Enerzijds betekent dit
waar modules voor specifieke bedrijfsproces-
dus een grote investering omdat alle code zelf
ondersteunende functies ‘ingehangen’ kunnen
geschreven moest worden, anderzijds betekent
worden. Momenteel zijn er onder meer modules
dit dat er ook geen rekening gehouden hoeft te
voor financiële administratie, relatiebeheer, lo-
worden met legacy code. Legacy code betekent
gistiek en productieprocessen, projectplanning,
de erfenis van code, die in het verleden geschre-
urenverantwoording, payroll en personeelsma-
ven is en waar nu, omdat het in productie ge-
nagement. Daarnaast zijn bedrijfstakspecifieke
bruikt wordt rekening mee gehouden dient te
modules gebouwd voor reïntegratiebedrijven,
worden. In de meeste gevallen duidt legacy op
zoals een cliëntvolgsysteen en een detachering-
een last voor de ontwikkelaars, die zij het liefst
module.
zouden verwijderen, maar dat is niet mogelijk
7.2.2
doordat de afhankelijkheden van deze code niet helemaal bekend zijn. Dit leidt tot moeilijk onderhoudbare en weinig flexibele oplossingen. Teamsoft had deze last niet en kon opnieuw beginnen, met de ervaring die ze in het verleden hadden opgedaan, om een geïntegreerde suite te ontwikkelen gebaseerd op moderne technologie. Bovendien was er de extra luxe dat er voldoende kapitaal was om de tijd te nemen om de software te kunnen ontwikkelen, zonder dat er omzet gemaakt hoefde te worden. Ze heeft geïnvesteerd in nieuwe technologie in een tijd dat bij concurrenten daar het geld, durf en tijd voor ontbrak. Een voorbeeld van het voordeel
Het product
Technologie
Teamsoft gebruikt een ontwikkelomgeving van Progress om haar software te bouwen. Progress Dynamics is een softwareontwikkelgereedschap waarbij de nadruk ligt op ‘dynamische programmatuur’. De software wordt opgeslagen in een database, de zogenaamde repository. Progress maakt gebruik van een 4GL programmeertaal. 4GL staat voor vierde generatie taal, deze taal kent een nog grotere abstractie dan hogere programmeertalen (3GL) zoals Java. Deze abstractie maakt het mogelijk snel en efficiënt te ontwikkelen met een kleinere kans op fouten. Daar staat tegenover dat het minder flexibel is, omdat de programmeur niet elk detail zelf programmeert.
64 >
7.3
Conditional Open Source
Het feit dat Teamsoft met een schone lei begonnen is, betekent ook dat er geen rekening gehouden hoefde te worden met traditionele opvattingen over licenties, samenwerken met partners en bescherming van intellectueel eigendom.
OSS-alternatieven voor bedrijfsspecifieke applicaties zijn echter niet of nauwelijks beschikbaar. De ontwikkeling van dergelijke applicaties kost vele manjaren ontwikkeling en vergt specialistische kennis van bedrijfsprocessen. Voor open-sourceontwikkelaars is het eenvoudigweg in veel gevallen niet mogelijk voor dit soort be-
Bij de oprichting van TeamSoft was één van de
drijfsspecifieke software alternatieven aan te
doelstellingen het afwijken van de traditionele
bieden, omdat zij de specifieke situatie van een
geslotenheid van softwarehuizen. De ervaring
bedrijf niet (kunnen) kennen. Een ander nadeel
had geleerd dat klanten volledig afhankelijk
is, dat een ontwikkelaar met commerciële be-
worden gemaakt van hun softwareleverancier
langen zijn investering in open source nauwe-
doordat deze de broncode niet meelevert. Om
lijks te gelde kan maken.
klanten zekerheid te geven in geval van faillissement van de leverancier wordt soms een escrow-overeenkomst gesloten. Dit houdt in dat de broncode, bouwinstructies, handleidingen en andere zaken die noodzakelijk zijn voor het bouwen van de software geleverd wordt aan een onafhankelijke derde partij. In het geval dat de leverancier failliet gaat kan de klant deze zaken opvragen bij deze derde partij. Een escrow-overeenkomst lijkt weliswaar uitkomst te bieden voor de continuïteit van de software in het geval de onderneming failliet gaat, maar in praktijk wordt de broncode eenmalig in escrow gegeven en zelden of nooit met de actuele updates of patches bijgewerkt. Hierdoor daalt de waarde die de escrow biedt met elke update voor de gebruiker en hierdoor stijgt het risico voor de gebruiker. Volgens Teamsoft duidt de adoptie van OSS
Dit is de reden dat TeamSoft gekozen heeft voor een eigen variant van open source software: TeamSoft’s Conditional Open Source (TCOS). Conditional staat voor de leveringsvoorwaarden van de broncode en de voorwaarden voor doorontwikkeling door derden. De broncode wordt geleverd onder voorwaarde dat deze niet verder wordt verspreid. Voorwaarden voor ontwikkeling door derden omvatten regels voor partners met als doel de voortgang en kwaliteit van de software te bewaken. Deze voorwaarden komen later nog aan de orde. In tegenstelling tot open source is TCOS niet gratis, TeamSoft rekent marktconforme bedragen voor het gebruik van haar software. Ook voor een ontwikkelingslicentie van de partner moet betaald worden.
7.4
Partnernetwerk
door grote bedrijven en overheidsinstellingen
Teamsoft wil puur een technologieleverancier
er op dat deze geslotenheid én afhankelijkheid
blijven, het verzorgen van implementaties en
steeds minder geaccepteerd wordt.
maatwerkoplossingen laat zij het liefst over
< 65
aan partners. Tot de tijd dat het partnernetwerk
voor veel doeleinden en markten en TeamSoft is
voldoende groot is doet zij nog wel zelf imple-
hard op zoek naar partners die voor deze tech-
mentaties en maatwerkoplossingen. Dit doet zij
nologie willen kiezen om hun oplossingen op te
om ook voor die tijd omzet te maken en om de
baseren.
technologie te bewijzen. Voor implementaties heeft TeamSoft maar beperkte mankracht, het
7.4.1
is expliciet niet haar wens om daar verder in te
De rollen die partners van TeamSoft kunnen
groeien.
vervullen zijn hoofdzakelijk die van Value Ad-
TeamSoft ziet het liefst dat het partnernetwerk
ded Reseller (VAR) en implementatiepartner
de vorm krijgt van een community waarvan de
(ook wel System Integrator genoemd).
leden ook relaties met elkaar onderhouden en
VARs zijn de partners die de software van
kennis met elkaar delen.
TeamSoft aanpassen aan de wensen van een
Momenteel is TeamSoft actief en succesvol in
bepaalde bedrijfstak of van een specifieke klant.
de sociale-reïntegratie- en detacheringmarkt.
In het eerste geval wordt een apart product ont-
Deze niche heeft TeamSoft voor zichzelf afge-
wikkeld dat zelfstandig vermarkt wordt, met de
bakend, het is niet de bedoeling dat hun part-
bedoeling het zelfde product aan meerdere be-
ners actief worden in deze markt. Op andere
drijven te verkopen. In het laatste geval wordt
terreinen zal TeamSoft altijd voorkomen dat
het product in opdracht aangepast aan de wen-
zich kanaalconflicten voordoen. Wanneer een
sen van een specifieke klant. De door TeamSoft
potentiële klant bijvoorbeeld zowel TeamSoft
gebruikte definitie van een VAR is ruimer dan
als één van de partners benadert zal TeamSoft
de definitie die in hoofdstuk 3 werd gehanteerd,
de opdrachtgever naar de partner verwijzen,
volgens die definitie programmeert de VAR
als die geschikt is. Als de partner TeamSoft’s
niet zelf. De definitie van een VAR volgens
software, of software die daar op gebaseerd is
TeamSoft omvat de rol van independent soft-
verkoopt gaat een deel van de opbrengst naar
ware vendor (ISV)
TeamSoft, deze marges zijn contractueel afge-
In de loop der tijd heeft TeamSoft ervaren dat
dekt.
deze partners niet altijd zelf willen ontwikke-
Belangrijk voor TeamSoft is steeds af te blijven
len en dat ze liever zouden zien dat TeamSoft
wegen welke expertise en functionaliteiten zij
de wijzigingen zelf doet op basis van hun ken-
zelf wil behouden en opbouwen en op welke
nis van de markt en de wensen en eisen van de
terreinen voor partners wordt gekozen. Het is
beoogde gebruikers. In plaats van TeamSoft is
voor haarzelf en voor haar partners van groot
het echter ook mogelijk dat deze functie ver-
belang hier duidelijk en rechtlijnig in te zijn.
vuld wordt door weer een andere partner. De
De software van TeamSoft is inmiddels geschikt
66 >
Typen partners
openheid van de broncode maakt het mogelijk
voor partners om in plaats van TeamSoft met
Speciale wijzigingen zoals het toevoegen van
een andere partner uit de TeamSoft-community
enkele schermen kunnen door TeamSoft zelf ge-
in zee te gaan om samen op basis van de tech-
daan worden. Dat is sneller dan wanneer daar
nologie van TeamSoft software te ontwikkelen
eerst mensen voor opgeleid moeten worden.
en te implementeren. TeamSoft heeft hier geen
Als de implementatiepartner heel grote wijzi-
problemen mee, sterker nog ze moedigt dit zelfs
gingen wil doorvoeren dan haakt TeamSoft af
aan. Wanneer de ontwikkeling en implementa-
en verwijst zij de partner door naar een VAR.
tie onafhankelijk van TeamSoft door partners
De generieke functionaliteit is inmiddels zo
wordt gedaan dragen deze het risico. TeamSoft
groot dat een gemiddeld of groot MKB-bedrijf
loopt in een dergelijk geval geen risico, maar
daar prima mee uit de voeten kan, zonder dat
ontvangt wel licentieopbrengsten per geïmple-
de software gewijzigd hoeft te worden.
menteerd product.
Het partnernetwerk van TeamSoft is schema-
Implementatiepartners veranderen in tegenstel-
tisch weergegeven in figuur 7.1. In dit figuur
ling tot de VAR’s niets aan de software zelf,
zijn de volgende actoren opgenomen: TeamSoft
maar implementeren het zoals het is bij een
(T), de VAR (V), de implementatiepartner (I) en
klant. Zonder dat er iets aan de code veranderd
de klant (K). Links in de figuur is een voorbeeld
hoeft te worden, kan de werking van de soft-
opgenomen van een implementatiepartner die
ware aangepast worden aan de wensen van de
samenwerkt met een VAR om haar klanten te
klant door het te configureren en in te stellen.
bedienen.
Figuur 7.1: Partnernetwerk van TeamSoft
< 67
7.5 Innovatiedeling in het netwerk Alle door een VAR ontwikkelde code wordt door TeamSoft gecontroleerd, gevalideerd en gecertificeerd. Zij controleert door middel van Progress Roundtable (het versiebeheersysteem van Progress) of de software aan haar specificaties voldoet, zodat updates en patches van TeamSoft zelf blijven werken. Roundtable controleert of de wijzigingen geen gevolgen hebben voor andere componenten. Het staat de VAR vrij zelf functionaliteit te ontwikkelen in een vorm die hij wil. Voorwaarde is dat de software aan TeamSoft’s specificaties moet blijven voldoen om de continuïteit te kunnen waarborgen. Is dat niet het geval, dan moet de VAR de door hem ontwikkelde software aanpassen. TeamSoft behoudt het recht voor om door een VAR ontwikkelde generieke verbeteringen te incorporeren. De verbeteringen worden in ieder geval ter beschikking gesteld aan de andere leden van de TeamSoft community. Een generieke verbetering kan een wijziging zijn in een kernmodule, zoals bijvoorbeeld het documentenbeheer, maar ook een verbetering betreffen van het applicatieraamwerk zelf. TeamSoft wordt automatisch eigenaar (auteursrechthebbende) van de totale code. De VAR houdt wel het auteursrecht over door hen ontwikkelde niet-generieke code. 7.5.1
Opleiding
De programmeurs van de VARs worden opgeleid in het gebruik en de logica van de TeamSoft
software. Door het stellen van voorwaarden en het opleiden van de programmeurs die werken aan de uitbouw van de software van TeamSoft kan zij de kwaliteit blijven waarborgen. De opleiding bestaat uit een cursus die op de locatie van TeamSoft wordt gegeven. Allereerst moeten de programmeurs leren werken, voor zover ze dat nog niet kunnen, met de Progress-ontwikkelomgeving, Progress Dynamics. Deze omvat de programmeertaal en de database. Progress Dynamics heeft een andere manier van ontwikkelen dan gebruikelijk, het is volledig dynamisch object georiënteerd. De gemaakte objecten kunnen dynamisch aangepast worden, in een grafische interface. Dat is iets anders dan het invoeren van regels code, waardoor het voor programmeurs die hier geen ervaring mee hebben een flinke omschakeling is. Uiteraard betekent het werken met dynamische objecten niet dat er geen regels code meer worden geschreven, specifieke logica moet nog steeds geprogrammeerd worden en aan de objecten worden toegevoegd. Met de cursus worden programmeurs wegwijs gemaakt in het gebruik, de logica, de functionaliteiten en de broncode van de software van Teamsoft. 7.5.2
Kennisoverdracht en -uitwisseling
TeamSoft heeft veel werk gemaakt van het inzichtelijk structureren, opzetten en goed documenteren van de code. Hierbij helpt dat de tijd genomen is voor het schrijven van de software en dat er niet van verloop van tijd onder druk eigenaardigheden in zijn geslopen. Deze eigen-
68 >
schap, samen met de hoge abstractie van de pro-
den is wat aantal klanten en leveranciers betreft
grammeertaal zorgt dat programmeurs vrij snel
beperkt en dit maakt de kans dat een partner
met de code aan de slag kunnen. Veel kennis
een dergelijke opportunistische actie onopge-
die nodig is voor het werken met de code is dus
merkt zou kunnen ondernemen klein. De code
expliciet gemaakt en impliciete kennis als ei-
is auteursrechtelijk beschermd, wat volgens
genaardigheden in de structuur en werking van
TeamSoft genoeg mogelijkheden biedt om een
de software zijn zo veel mogelijk voorkomen.
overtreder aan te pakken. Bovendien is de soft-
Dit moet er voor zorgen dat partners zo veel
ware verbonden aan het Progress platform, wat
mogelijk zelfstandig kunnen werken. Bij vragen
betekent dat een Progress partner nodig is voor
of problemen kunnen de programmeurs van de
de verdere ontwikkeling en implementatie van
partner persoonlijk contact op nemen met pro-
het product en ook de Progress partner commu-
grammeurs van TeamSoft.
nity is ‘een klein wereldje’
Nadat de code door TeamSoft gecontroleerd is gewijzigd en nieuw geschreven heeft.
7.6 Voordeel open broncode ten opzichte van gesloten broncode
Doordat de code van TeamSoft nog vol in ont-
Naar klanten communiceert TeamSoft het voor-
wikkeling is en daarom aan verandering onder-
deel van conditional open source voornamelijk
hevig, is het belangrijk voor TeamSoft en haar
als zekerheid. Het feit dat de klant altijd over de
VARs om intensief contact te houden. Op die
laatste broncode beschikt kan worden werkt als
manier kunnen de ontwikkelinspanningen be-
continuïteitswaarborg, voor ondersteuning en
ter op elkaar worden afgestemd. Zo wordt voor-
verdere ontwikkeling. Mocht TeamSoft failliet
komen dat er dubbel werk wordt gedaan of dat
gaan of mocht de relatie met TeamSoft dermate
er van zaken uitgegaan worden die later kunnen
verstoord raken, dat deze niet meer voortgezet
wijzigen.
kan worden, kan de klant in zee gaan met een
ontvangt de partner feedback op de code die hij
7.5.3
Bescherming intellectuele eigendom
andere Progress-partner. TeamSoft is een jong bedrijf en de afgelopen twee en half jaar is er al-
Met de broncode in handen zouden partners
leen maar geïnvesteerd, het bedrijf is weliswaar
het product zonder toestemming een op deze
financieel gezond, maar het blijft voor klanten
broncode gebaseerd product kunnen verkopen
een verhoogd risico. Door aan klanten de bron-
zonder de contractueel verplichte vergoeding af
code te leveren wordt onzekerheid weggenomen
te dragen. Toch is TeamSoft niet bang voor het
en het risico verkleind.
uitlekken van de broncode of het oneigenlijke gebruik van haar intellectuele eigendom. De markt waarop het product verkocht kan wor-
Zoals eerder beschreven in het hoofdstuk over open source is de overheid een grote klant van ICT-bedrijven en begint zij steeds meer het ge-
< 69
bruik van open standaarden en open broncode mee te wegen in haar software- en leverancierkeuze. Met Conditional open source en het gebruik van open standaarden kan TeamSoft aan deze voorkeur voldoen. Het gegeven dat partners volledige inzicht hebben in de broncode en deze naar eigen inzicht en behoefte aan kunnen passen (zolang aan de specificaties van TeamSoft voldaan wordt, wanneer ze compatibel met updates willen blijven) maakt TeamSoft een aantrekkelijke technologieleverancier voor VARs. De helder opgezette en goed becommentarieerde code maakt dat programmeurs zich de code snel eigen kunnen maken. Het voordeel dat TeamSoft heeft bij conditional open source is dus dat ze een minder risicovol alternatief wordt voor klanten en een aantrekkelijke technologiepartner voor partners.
70 >
In ter d e p e nd e n t i e s in c ommu ni t y s ou r c e
8
Eerder zijn de voor- en nadelen van het delen van broncode voor de deelnemers van een open
software-innovatienetwerk aan de orde gekomen (open source). De vraagstelling draait echter om de voor- en nadelen van het delen van broncode in een gesloten software-innovatienetwerk (community source). De bevindingen van de gevalstudie uit het vorige hoofdstuk zullen worden gebruikt om het in hoofdstuk 6 geïntroduceerde model (van interdependenties van open source) aan te passen aan de kenmerken van community source om hier een vergelijkbaar model voor op te stellen. Ten eerste zal er besproken worden waarom Teamsoft’s conditional open source een voorbeeld van community source is. Vervolgens zal er een vergelijking worden gemaakt tussen community source en open source. Daarna zullen aan de hand van de kenmerken en gevolgen open source en community source met elkaar vergeleken worden.
8.1 Vergelijking TeamSoft’s conditional open source en community source Volgens de begripsbepaling uit hoofdstuk 5 is
doet. Zo zijn er meer restricties op de vrijheid,
conditional open source (TCOS) een vorm van
de code wordt immers altijd door Teamsoft ge-
community source (CS). De broncode is open,
controleerd en geaccordeerd. Deze restricties
hij is aanpasbaar, maar mag niet herverspreid
hebben voornamelijk te maken met de con-
worden buiten het netwerk, daarbij is er sprake
tinuïteit van de software. Veranderingen die
van een gesloten netwerk.
een partner doet aan het generieke gedeelte
De vrijheid van de gebruikers en externe ontwikkelaars is bij TCOS minder groot dan bij CS door de voorwaarden die zij stelt. Teamsoft legt meer restricties op aan de participerende partijen dan community source dat per definitie
van de code moeten op een zodanige wijze gebeuren dat patches en updates hierop die door TeamSoft vrijgegeven worden blijven werken. Als een partner meer vrijheid wil op dit gebied wordt hem de mogelijk gegeven de broncode te
< 71
kopen. Wat betreft de gebieden waarop de software ingezet mag worden en hoe het gebruikt mag worden zijn er geen beperkingen gesteld. Teamsoft legt in zijn TCOS dus regels en verplichtingen op aan zijn partners, dit is mogelijk binnen CS, echter dit is niet per definitie een van de kenmerken van CS. In het model zal hier dan ook geen rekening mee worden gehouden. Het model richt zich op de algemene aspecten van CS.
8.2 Vergelijking community source en open source Om een vergelijkbaar model voor community source op te stellen zoals is gedaan voor open source zal aan de hand van de volgorde zoals in hoofdstuk 6 is aangehouden open source en community source vergeleken worden en zullen de verschillen aangeduid worden. Eerst wordt er weer gekeken naar de kenmerken en vervolgens naar de gevolgen en ten slotte naar de
Bij zowel OS als TCOS is er gesproken over
adoptie. Het aangepaste model zal vervolgens
verschillende participanten, ondanks het feit
worden gepresenteerd.
dat zij verschillende namen hebben vervullen zij dezelfde functie. Tabel 8.1 geeft een over-
8.2.1
Kenmerken
zicht van deze participanten aangevuld met de
Zoals gebleken is uit hoofdstuk drie wordt open
naamgeving voor community source.
source gekenmerkt door drie factoren: openheid, vrijheid en vrije herverspreidbaarheid. In deze paragraaf zullen deze kenmerken besproken worden voor community source. Voor de
open source
conditional open source
community source
externe ontwikkelaar
VAR
partner
initiator
auteursrechthebbende
externe exploitant
implementatiepartner
gebruiker
klant
auteursrechthebbende partner klant
Tabel 8.1: Vergelijking actoren in open source, conditional open source en community source
openheid
vrijheid
vrije herverspreidbaarheid
open source
conditional open source
community source
ja, publiek
ja, binnen het netwerk
ja, binnen het netwerk
ja
ja
voor zover er geen conflicten zijn
niet vrij
Tabel 8.2: Vergelijking open source, conditional open source en community source
72 >
ja
niet vrij
volledigheid zijn in tabel 8.2 zijn open source
naar eigen inzicht, zonder beperkingen van het
(OS), conditional open source (TCOS) en com-
doel waarvoor deze ingezet kan worden. Voor
munity source (CS) naast elkaar gezet om de
CS wordt van een zelfde definitie uitgegaan,
kenmerken te vergelijken. De aanpassing die
hoewel door TeamSoft enige restricties zijn ge-
nodig is om de gewijzigde kenmerken en de
zet, zoals besproken in paragraaf 8.1.
directe gevolgen daarvan terug te laten komen in het model is weergegeven in figuur 8.1. Het gewijzigde model zelf is grafisch weergegeven in figuur 8.2.
Vrije herverspreidbaarheid De vrije herverspreidbaarheid die zo kenmerkend is voor OS gaat voor CS niet op, de broncode wordt alleen binnen de community en klanten-
Openheid
kring verspreid en mag door dezen niet zonder
Openheid betekent dat de gehele broncode in te
toestemming of betaling van de auteursrech-
zien is voor iedereen die ook de gecompileerde
hebbende herverspreid worden. De broncode
code heeft verkregen. Hoewel de openheid van
wordt door de partners wel herverspreid aan
OS meestal een meer publiek karakter heeft dan
hun klanten, maar hiervoor moeten wel royal-
CS, komt dat alleen doordat OS vaak herver-
ties afgedragen worden aan de auteursrechtheb-
spreid wordt. Strikt genomen heeft CS dezelfde
bende. Of dit gebeurt door de partner, of dat de
openheid als OS.
klanten een licentieovereenkomst sluiten met de auteursrechthebbende maakt voor het model
Vrijheid
niet uit.
Vrijheid, in OS, is de vrijheid die ontvangers van de broncode genieten om deze te gebruiken
Figuur 8.1: Vergelijking kenmerken en gevolgen open source en community source
< 73
8.2.2
worden. Aangezien de broncode en software in
Gevolgen
In deze paragraag komt het effect aan de orde van de wijziging in de kenmerken om de gevolgen van deze kenmerken. Incompatibiliteit
versies
CS niet vrij herverspreidbaar is, wordt bescherming intellectueel eigendom hier niet langer meer negatief beïnvloed. Daar de broncode wel open is, wordt het intellectueel eigendom niet be-
(mogelijkheid
van
schermd ten opzichte van de partners en klan-
fork)
ten. Het intellectueel eigendom is uiteraard nog
Als geen restricties aan de vrijheid worden ge-
steeds beschermt met auteursrecht en licentie-
zet, dan bestaat het risico dat de codebases van
overeenkomsten, maar de broncode komt wel
de partner en de auteursrechthebbende te veel
in handen van de partner. De partner zou in de
van elkaar gaan verschillen en dat deze incom-
vereleiding kunnen komen om deze broncode
patible met elkaar worden. Dit is de reden dat
bijvoorbeeld in eigen software te verwerken, of
TeamSoft wat betreft de vrijheid eist dat haar
te verkopen zonder de auteursrechthebbende
updates voor de kern van de software moeten
hiervan op de hoogte te stellen of royalties af
blijven werken. Als haar partner te veel wil af-
te dragen.
wijken, dan is dat wel mogelijk, maar dan moet
TeamSoft is niet bang dat de code uitlekt of
de partner daar voor betalen en kan bijvoorbeeld
dat het onrechtmatig gebruikt zal worden door
afgesproken worden dat deze met de afwijkende
partners. Zij is hier niet bang voor omdat de ge-
code in een bepaalde sector exclusiviteit krijgt.
bruikte technologie aan het Progress-platform
Deze afwijkende code gaat dan zelfstandig ver-
gebonden is. De code op zich kan niet eenvoudig
der als een fork.
ingezet worden buiten dit platform. Bedrijven
Voor elke instantie van community source zul-
die dit platform gebruiken maken deel uit van
len de betrokken partijen afspraken moeten
de Progress-community. Dit is een community
maken over hoe met dit probleem omgegaan
waarvan de leden veelvuldig contact met elkaar
zal worden. Omdat de software niet vrij herver-
hebben, wat het moeilijk maakt om uitgelekte
spreid mag worden is het risico van een daad-
code onopgemerkt onrechtmatig in te zetten bij
werkelijke fork niet zo groot, maar het gevaar
klanten of te verwerken in producten. Boven-
van incompatibiliteit tussen de versies is wel
dien is de markt waarin de software ingezet kan
aanwezig.
worden er één die door weinig partijen bediend wordt, ook hier geldt dat het lastig zou zijn om
Bescherming intellectueel eigendom In het conceptueel model van interdependenties binnen open source heeft vrije herverspreidbaarheid een negatief effect op bescherming intellectueel eigendom, omdat het intellectueel eigendom zonder meer aan een ieder verspreid mag
74 >
uitgelekte code onopgemerkt te gebruiken. Bedrijven die minder gebonden zijn aan een dergelijk specifiek platform lopen door de openheid binnen het gesloten netwerk wel een groter risico dan bij gesloten software.
Prijs
Kennisdeling
Doordat de broncode in CS niet vrij herver-
De openheid van de broncode heeft kennisdeling
spreid mag worden, wordt de ontwikkelaar niet
ten gevolg. TeamSoft houdt het niet alleen bij
gedwongen om de software gratis te versprei-
open broncode, maar heeft ook werk gemaakt
den. Zoals aangegeven in het vorige hoofdstuk
van het documenteren en helder opzetten van
vraagt TeamSoft marktconforme prijzen voor
de code, bovendien worden de partners opge-
haar software. De hoogte van de prijs die ge-
leid.
vraagd kan worden wordt niet beïnvloed door de kenmerken van CS. Onafhankelijkheid In CS is het de partners niet toegestaan om de software en broncode vrij te herverspreiden. De partners in CS zijn daarom minder onafhankelijk als de externe ontwikkelaars en exploitanten van OSS. Doordat de partners officiële contractuele betrekkingen met de auteursrechthebbende onderhouden, zijn de banden sterker. In de volgende paragraaf zal verder op de rol van onafhankelijkheid in CS worden ingegaan.
8.2.3
Adoptie
Adoptie door gebruikers Eén van de grote voordelen van CS is de onafhankelijkheid. Doordat de klanten in CS toegang hebben tot de broncode kunnen ze deze aan passen zonder dat ze afhankelijk zijn van de auteursrechthebbende om deze wijzigingen door te voeren. Ze kunnen dit zelf doen, of ze kunnen hiervoor een partner inschakelen. In het geval dat de auteursrechthebbende failliet gaat of dat de relatie ernstig verstoord is betekent het hebben van de broncode dat de software wel
Flexibiliteit
doorontwikkeld kan worden. Deze zekerheid is
Hoe groot de flexibiliteit is bij CS hangt sterk
voor professionele gebruikers van groot belang.
af van de vrijheid, als deze wordt ingeperkt dan
Het kunnen bieden van deze zekerheid is voor
wordt ook de flexibiliteit minder. Zonder inper-
TeamSoft één van de belangrijkste redenen voor
king van de vrijheid geldt dezelfde flexibiliteit
het gebruik van CS.
voor CS als voor OS.
Doorontwikkeling en continuïteit heeft ook een po-
Inspecteerbaarheid De mogelijkheid de code te inspecteren is door de openheid ook in CS aanwezig, wat betekent dat de interne werking van de software nage-
sitieve invloed op adoptie door gebruikers. Doordat meerdere bedrijven ontwikkelen op basis van de zelfde software wordt deze software aantrekkelijker, omdat de innovatiesnelheid hoger is.
gaan kan worden. Het totaal aantal mensen dat
De positieve invloed van flexibiliteit, inspec-
de broncode kan inspecteren en beoordelen is
teerbaarheid en adoptie door gebruikers zelf is
wel minder dan bij OS omdat de software niet
hetzelfde als bij OS en zal hier niet opnieuw be-
gratis beschikbaar en de broncode niet publiek
sproken worden.
toegankelijk.
< 75
Adoptie door partners
zorgt ervoor dat de voordelen die een netwerk-
Adoptie door partners wordt positief beïnvloed
structuur biedt benut kunnen worden.
door dezelfde factoren als adoptie door externe ontwikkelaars en exploitanten in OS, met uitzondering van prijs. De prijs van CS is niet per definitie lager (of hoger) dan de prijs van gesloten software.
Doorontwikkeling en continuïteit TeamSoft behoudt het recht voor om door een VAR ontwikkelde generieke verbeteringen te incorporeren. Deze verbeteringen worden ter beschikking gesteld aan de andere leden van
Adoptie door partners wordt ook positief beïnvloed door doorontwikkeling en continuïteit. Doorontwikkeling van het product betekent dat de waarde van de technologie stijgt, wat het aantrekkelijker maakt voor bedrijven om partner te worden.
adoptie door partners een positief effect kan hebben op de doorontwikkeling en continuïteit. De partners en auteursrechthebbende profiteren van elkaars contributies. Doordat meerdere bedrijven aan het zelfde softwareplatform wer-
TeamSoft staat haar partners toe dat zij zonder
ken is de omvang en snelheid van de innovatie
de bemoeienis van TeamSoft met elkaar samen-
hoger dan wanneer één bedrijf de ontwikkeling
werken. Als een implementatiepartner bijvoor-
doet. Overigens zou dit gedeeltelijk teniet ge-
beeld aanpassingen nodig heeft aan de software
daan worden als de bedrijven de software for-
kan zijn deze laten uitvoeren door een VAR.
ken. Doordat dan verschillende incompatibele
Deze vrijheid maakt de actoren in het netwerk
versies ontstaan is de kans groter dan innova-
veel flexibeler dan wanneer alle coördinatie
tieinspanningen dubbel en onafhankelijk van
via TeamSoft zou lopen. Deze onafhankelijkheid
elkaar gebeuren.
Figuur 8.2: Conceptueel model community source
76 >
de TeamSoft community. Dit betekent dus dat
Behoefte aan complementaire producten en diensten De behoefte aan complementaire producten en diensten wordt ook in CS positief beïnvloed door het aantal gebruikers. Hoe meer gebruikers hoe groter de behoefte aan complementaire producten en diensten. Zowel de auteursrechthebbende als de partners kunnen in deze behoefte voorzien. Omzet auteursrechthebbende Doordat de software in het community-sourcemodel in tegenstelling tot het open-sourcemodel niet gratis verspreid wordt leidt adoptie door gebruikers rechtstreeks tot omzet voor de auteursrechthebbende, de gebruikers moeten immers betalen voor het gebruik van de software. De omzet is dus niet meer puur afhankelijk van het aanbieden van complementaire producten en diensten. TeamSoft krijgt een marge van de omzet die de partner maakt op de verkoop van haar software. De omzet van partners heeft dus een positieve invloed op de omzet van de auteursrechthebbende Omzet partners Ook voor de partners geldt dat adoptie van de software door hun klanten rechtsreeks leidt tot omzet. Ook zij zijn niet puur afhankelijk van het leveren van complementaire producten en diensten.
< 77
Beoordeling resultaat
9
In dit hoofdstuk worden de uitkomsten van de analyse beoordeeld vanuit het gezichtspunt van
de verschillende deelnemers in een gesloten software-innovatienetwerk en geeft daarmee antwoord op de onderzoeksvraag.
9.1 Voor- en nadelen voor de partner Als ontvanger van community source heeft
Zekerheid
de partner eigenlijk alleen maar voordelen ten
Het in handen hebben van de broncode is voor
opzichte van gesloten software. Zoals uit het
partners een groot voordeel, omdat het zeker-
vorige hoofdstuk is gebleken zorgt community
heid geeft over de continuïteit van de soft-
source voor onafhankelijkheid, flexibiliteit, in-
ware. Als de auteursrechthebbende besluit de
specteerbaarheid en kennisdeling. In deze pa-
software niet langer door te ontwikkelen of te
ragraaf zal behandeld worden wat dit concreet
ondersteunen omdat het voor hem niet langer
betekent wat betreft voor- en nadelen voor de
profijtelijk is of omdat hij failliet gaat of over-
partner.
genomen wordt kan de partner onafhankelijk van de auteursrechthebbende de software door-
9.1.1
Onafhankelijkheid
Samenwerking binnen het netwerk Community source maakt het mogelijk voor partners om samen te werken met andere bedrijven in het netwerk zonder dat daar de auteursrechthebbende direct bij betrokken is. Dit vergroot de doelmatigheid omdat minder coör-
ontwikkelen. Het kiezen voor ontwikkeling op basis van gesloten software van een ander bedrijf maakt de partner in grote mate afhankelijk van dat bedrijf. Met community source is deze afhankelijkheid veel minder groot en heeft de auteursrechthebbende derhalve minder macht over de partner.
dinatie nodig is en dat ze niet afhankelijk zijn van de auteursrechthebbende voor het doen van aanpassingen.
< 79
9.1.2
Flexibiliteit
9.1.3
Inspecteerbaarheid
Vrije innovatie en integratiemogelijkheden
Peer-review
Zoals in hoofdstuk 5 is besproken gaat samen-
De inspecteerbaarheid stelt de partners in staat
werking tussen gesloten software door middel
om peer-review op de code toe te passen. Door-
van API’s. Om de functionaliteit van een pro-
dat meerdere ontwikkelaars van verschillende
gramma te ontsluiten voor andere program-
bedrijven dit doen is de kans groter dat fouten
ma’s wordt deze functionaliteit aanroepbaar
aan het licht komen en opgelost kunnen wor-
gemaakt door API’s te definiëren. Welke func-
den.
tionaliteit wordt ontsloten en de manier waarop dat gebeurt wordt vastgesteld door de ontwikkelaar van de software zonder exact te weten hoe de externe ontwikkelaars de functionaliteit willen gaan gebruiken. De partner wordt hierdoor geremd in zijn mogelijkheden om te innoveren. Als de broncode gedeeld wordt echter
Vertrouwen Omdat de partners de broncode kunnen inspecteren kunnen ze zelf een oordeel vellen over de kwaliteit en hoeven wat dat betreft de auteursrechthebbende niet op zijn woord te geloven. 9.1.4
Kennisdeling
kan de externe ontwikkelaar zelf bepalen hoe hij de functionaliteit aanspreekt. Dit maakt het mogelijk de beide programma’s beter en nauwer te integreren.
Voordeel van kennisdeling Het delen van de broncode vergroot de kennisdeling, waardoor de partner de software zich sneller eigen kan maken, omdat hij meer inzicht
Mogelijkheid tot co-specialisatie
heeft in de interne werking. Dit betekent dat hij
Eén van de doelen van samenwerking die be-
sneller en doelmatiger kan ontwikkelen op ba-
sproken zijn in hoofdstuk 4 is co-specialisatie.
sis van de verkregen software.
Door zijn software te baseren op de software die ontwikkeld wordt door een andere partij kan de partner zich puur richten op de ontwikkeling van zijn eigen specialisme. Het voordeel van toegang tot de broncode van de software van de andere partij is dat het resulterende programma
De openheid maakt het mogelijk dat beter omgegaan kan worden met veranderende API’s in het begin van de ontwikkeling. Er kan dus eerder begonnen worden met gelijktijdige ontwikkeling en de ontwikkelingen kunnen beter op elkaar worden afgestemd.
goed geïntegreerd is zonder dat het gehele programma zelf gebouwd moet worden
Partners profiteren niet alleen van de innovaties van de auteursrechthebbende, maar ook van de innovaties van andere partners, als deze hun wijzigingen onthullen.
80 >
Nadeel van kennisdeling
dat onmogelijk is door een andere externe partij.
Op het moment dat de partner iets verbetert
Daarnaast verschaft het bezit van de broncode
aan de broncode van de auteursrechthebbende
ook de zekerheid dat hij altijd over zijn data kan
wordt hij zelf verantwoordelijk voor het verwer-
beschikken die opgeslagen is in het systeem.
ken van updates aan de oorspronkelijke code. Hij kan dit voorkomen als hij zijn wijzigingen teruggeeft en deze op laat nemen in de oorspronkelijke code. Als hij dat doet geeft hij zijn verbeteringen prijs en kunnen ook de andere bedrijven in het netwerk profiteren van zijn verbeteringen. Dit kan een nadeel zijn omdat de andere partijen in het netwerk potentieel concurrenten zijn. Op zijn beurt profiteert de partner weer als een andere partner zijn verbeteringen deelt met de andere bedrijven in het netwerk.
Keuze uit meerdere leveranciers Doordat meerdere partijen de software aan kunnen passen, kan de gebruiker kiezen welke leverancier voor hem het beste is. Bij gesloten software is er slechts één bedrijf die de software aan kan passen. Of deze de software voor één specifieke klant aan zal willen passen hangt af van de belangrijkheid van de klant voor dit bedrijf. De in de vorige paragraaf genoemde mogelijkheid van co-specialisatie betekent voor de ge-
Voordelen ten opzichte van open source Community source is voor partners aantrekkelijker dan open source, omdat het niet publiek is.
bruiker zowel een verbreding als een verdieping van het aanbod van functionaliteiten en mogelijkheden.
Community source is alleen toegankelijk voor leden van het netwerk, deze bedrijven hebben dus een voordeel ten opzichte van niet-leden.
9.2.2
Flexibiliteit
Aanpasbaarheid Een ander belangrijk voordeel is aanpasbaar-
9.2 Voor- en nadelen voor de gebruiker
heid, community source is veel meer dan gesloten software aan te passen aan de wensen van de gebruiker. Niet alleen het aanpassen van
9.2.1
Onafhankelijkheid
functionaliteit maar ook de mogelijkheid om de software beter te integreren met andere sy-
Zekerheid Het voornaamste directe voordeel voor gebrui-
stemen is een groot voordeel ten opzichte van gesloten software.
kers van community source ten opzichte van gesloten software is zekerheid. In het geval van faillissement of verstoorde relaties is de gebruiker er zeker van dat de software verder ontwikkeld kan worden, door een andere partner of als
9.2.3
Inspecteerbaarheid
Het bezit van de broncode zorgt ook dat de gebruiker zekerheid heeft over de interne kwaliteit van de software, doordat zij deze kan laten in-
< 81
specteren. De gebruiker hoeft de ontwikkelaar
Distributiekanaal
wat betreft de kwaliteit van de software niet
Ook als de ambities beperkter zijn dan plat-
op zijn woord te geloven. Dit betekent niet dat
formleiderschap is het belangrijk om partners
community source software per definitie veili-
te binden aan het platform. Een implementatie-
ger is, maar het kan in ieder geval geïnspecteerd
partner van de auteursrechthebbende is bijvoor-
worden.
beeld een consultant die bij zijn klanten problemen oplost door het inzetten van software. De
9.2.4 Voordelen ten opzichte van open source
keuze voor de gebruikte technologie wordt vaak
Voor de gebruikers zijn er geen voordelen ten
niet door de klant bepaald, maar door deze con-
opzichte van open source, mits het gebruikte
sultant. Door te zorgen dat dit soort bedrijven
open-sourceproduct dezelfde commerciële on-
een voorkeur heeft voor de technologie van de
dersteuning heeft als community source.
auteursrechthebbende, verkoopt deze meer licenties.
9.3 Voor- en nadelen voor de auteursrechthebbende
Coöptatie
De auteursrechthebbende heeft geen direct
tatie is, het tot bondgenoten maken van concur-
voordeel bij het delen van zijn broncode met
renten, kan het delen van de broncode helpen
partners en klanten. Het voordeel dat hij onder-
om de concurrenten over de streep te trekken,
vindt is dat zijn product aantrekkelijker wordt
om partner te worden. De partner is met gedeel-
voor partners en klanten dan gesloten software.
de broncode immers veel minder afhankelijk
Hierdoor kan hij partners makkelijker aan zich
van de auteursrechthebbende dan met gesloten
binden en zullen klanten het product eerder ko-
software. Door de deling van de kennis en de
pen waardoor zijn afzet stijgt.
mogelijkheid aanpassingen aan de software te
Als het doel van de auteursrechthebbende coöp-
doen, zonder daarbij afhankelijk te zijn van de Platformleiderschap
welwillendheid van de auteursrechthebbende
In hoofdstuk 4 zijn de motieven besproken
is de noodzaak van vertrouwen veel minder
waarom bedrijven samenwerking zoeken met
groot.
andere bedrijven. Eén van deze motieven is het nastreven van platformleiderschap. Om dit
Platforminnovatie
te bereiken is het belangrijk zo veel mogelijk
Een voordeel voor de auteursrechthebbende is
partners te binden aan dat platform. Het delen
dat hij kan profiteren van de ontwikkeling en
van broncode met deze partners kan helpen om
innovatie van zijn partners. Wanneer de part-
dit te bereiken, omdat toegang tot de broncode
ners verbeteringen die zij doen delen met de
aantrekkelijk is voor partners.
auteursrechthebbende, stijgt de waarde van het product. Zoals eerder besproken kan het delen
82 >
van verbeteringen en aanpassingen in het eigen
letterlijk overnemen en zonder toestemming
belang van de partner zijn. Ook innovaties en
gebruiken in zijn eigen software, leert hij wel
uitbreidingen die partners doen op basis van het
over de interne werking van de software. Expli-
product, maar niet aan het product zelf, vergro-
ciete kennis is te beschermen met auteursrecht,
ten de waarde van het product zelf, omdat het
maar taciete kennis niet. Door samen te wer-
de uitbreidbaarheid voor de gebruiker vergroot
ken en broncode te delen wordt taciete kennis
en daarmee de mogelijkheden van het product
uitgewisseld. Zoals besproken is een partner
als platform.
een potentiële concurrent. Als het partnerschap stukloopt kan de ex-partner de kennis die hij
Peer-review De broncode die binnen het netwerk wordt gedeeld staat bloot aan peer-review door ontwik-
vergaart heeft over de interne werking van het product gebruiken in een voor de auteursrechthebbende schadelijke manier.
kelaars van verschillende organisaties, wat de kwaliteit ten goede komt. De auteursrechtheb-
Nadeel van het delen van broncode
bende profiteert hier van.
Een ander belangrijk nadeel is meer praktisch van aard en dat is het versiebeheer. Doordat
Ontwikkelingskosten Zoals in hoofdstuk 5 aangegeven is voor het aanpasbaar maken van de software de noodzaak van het ontwikkelen van een Software Development Kit (SDK) kleiner in het geval dat
verschillende bedrijven onafhankelijk van elkaar de broncode wijzigen kunnen conflicten en incompatibiliteit ontstaan. Het kost veel tijd en afstemming om deze complexiteit te beheren en het ontstaan van een fork te voorkomen.
de broncode gedeeld wordt. Aangezien het ontwikkelen van een SDK een dure en complexe zaak is kan het aanzienlijk in de ontwikkelkosten schelen als deze niet ontwikkeld hoeft te worden. Doordat community source co-specialisatie bevordert hoeft niet alle functionaliteit zelf ontwikkeld te worden. Dit scheelt ook in de ontwikkelingskosten.
9.3.1 Voordelen ten opzichte van open source Het voordeel van community source ten opzichte van open source is dat het niet de nadelen heeft zoals opgesomd in tabel 3.7. Zo kan er een marktconforme prijs voor de software zelf gerekend kan worden. Het intellectueel eigendom wordt alleen gedeeld binnen een gesloten net-
Nadeel van kennisdeling
werk en is dus beter beschermd. Daarnaast is
Het meest voor de hand liggende nadeel voor de
het gebruik van externe gesloten broncode mo-
auteursrechthebbende is de beperkte bescher-
gelijk, omdat het niet publiek gedeeld wordt.
ming van zijn intellectueel eigendom. Door de broncode de delen, deelt hij een deel van zijn kennis. Ook al mag de partner de broncode niet
< 83
10
Discussie en aanbevelingen
Dit hoofdstuk dient om beperkingen van het onderzoek aan te geven en het doen van aanbevelingen voor verder onderzoek.
10.1
Methodologie
10.3 Netwerkconfiguratie
Dit onderzoek is kwalitatief en verkennend van
Deze scriptie behandelt een netwerk dat zich
aard, omdat community source nog op zeer be-
vormt rondom een centrale actor, het bedrijf dat
perkte schaal wordt toegepast. Als meer bedrij-
besluit de broncode van haar software te gaan
ven het gaan toepassen kan vervolgonderzoek
delen met haar partners. Er is niet ingegaan
de voor- en nadelen kwantificeren, zodat bedrij-
op het delen van broncode in andere netwerk-
ven beter kunnen bepalen of community source
configuraties. Een voorbeeld hiervan is Project
voor hen aantrekkelijk is.
Avalanche, een coöperatie waarin de leden hun in-house ontwikkelde software onderbrengen.
10.2
Behandeling van open source
Bedrijven betalen USD 30.000 voor hun lidmaatschap en kunnen vervolgens putten uit de
Open source roept bij veel mensen de associatie
software die door de leden is ingebracht. Deze
met particuliere vrijwilligersinitiatieven op. In
coöperatie is opgericht om tegenwicht te bieden
dit onderzoek is uitgegaan van de pure defini-
aan de macht van externe softwareproducen-
tie van open source. Dit is de reden waarom
ten. (Avalanche Cooperative, 2004)
veel gehoorde nadelen van open source zoals slechte ondersteuning en onzekere ontwikkeling niet behandeld zijn. Dit zijn immers geen
10.4 Toepasbaarheid
kenmerken van open source, zeker niet als de
Uit verder onderzoek zou moeten blijken voor
ontwikkeling geleid wordt vanuit een commer-
welk soort bedrijf en voor welk soort product
ciële organisatie. Omdat community source
community source het meest geschikt is. Com-
toegepast wordt door commerciële organisaties
munity source is geschikt voor platform-pro-
dient de vergelijking alleen gemaakt te worden
ducten, producten waar op verder gebouwd kan
met commerciële open source.
< 85
worden, maar wellicht is het juist ook geschikt
als ze besluiten dat wel te doen. Het effect van
voor ‘plug-ins’, software die een bepaalde func-
regels hieromtrent zou verder onderzocht moe-
tionaliteit vervullen die aan een ander product
ten worden.
toegevoegd kan worden. De open broncode is hier voor heel geschikt, omdat het betere integratie toestaat.
10.5 Bescherming intellectueel eigendom
Het effect van community source op de kwaliteit van de ontwikkelde software is niet onderzocht. Wel staat vast dat peer-review een
Omdat de bescherming van het intellectueel
positieve invloed heeft op de kwaliteit en com-
eigendom in community source minder groot
munity source maakt dit mogelijk. Als meer
is dan bij gesloten software, moet er meer on-
bedrijven community source gaan toepassen, is
derzoek gedaan moeten worden naar het nadeel
vervolgonderzoek noodzakelijk.
van deze beperktere bescherming van intellectueel eigendom, en voor welke technologieën en producten strikte bescherming belangrijk is. Als er enige ‘spillover’ plaatsvindt, maar daar tegenover staat een veel snellere innovatie, dan is het mogelijk dat dit nadeel minder belangrijk wordt, omdat het niet opweegt tegen de voordelen.
10.6 Vrijheid van de partners Vervolgonderzoek moet duidelijk maken of het noodzakelijk is om de vrijheid van de partners wat betreft het wijzigen van de broncode in te perken. TeamSoft stelt nu als regel dat bij wijzigingen in de broncode haar updates moeten blijven werken. Deze scriptie heeft als uitgangspunt dat partners de door hen ontwikkelde broncode niet hoeven te delen met de centrale actor, er is alleen gekeken naar wat de voor- en nadelen zouden zijn
86 >
10.7 Effect op kwaliteit van de software
Referenties
11
Ackoff, R. L. (1989) ‘From Data to Wisdom’, Journal of Applied Systems Analysis, vol. 16, pp. 3-9 Adler, P. S. (2001) ‘Market, Hierarchy, and Trust: The Knowledge Economy and the Future of Capitalism’, Organization Science, vol. 12, no. 2, pp. 215-34 Anderson, J. C. & Narus, J. A. (1991) ‘Partnering as a Focused Market Strategy’, California Management Review, vol. 33, no. 3, pp. 95-113 Aoki, A., Hayashi, K., Kishida, K., Nakakoji, K., Nishinaka, Y., Reeves, B., Takashima, A. & Yamamoto3, Y. (2001) ‘A Case Study of the Evolution of Jun: an Object-Oriented Open-Source 3D Multimedia Library’, paper presented to International Conference on Software Engineering (ICSE2001), Toronto, CA Avalanche Cooperative (2004) The Avalanche Corporate Technology Cooperative, Avalanche Corporate Technology Cooperative, laatst bezocht op 2 november 2004 2004,
Baarsma, B., Beemsterboer, M. & Nooij, M. d. (2003) Samenwerking stimuleren, maar hoe?, laatst bezocht op 24 augustus 2004 Banker, R. D., Davis, G. B. & Slaughter, S. A. (1998) ‘Software Development Practices, Software Complexity, and Software Maintenance Performance: A Field Study’, Management Science, vol. 44, no. 4, pp. 433-50 Behlendorf, B. (1999) ‘Open source as a business strategy’, in C Dibona, S Ockman & M Stone (eds), Opensources: Voices from the open source revolution, O’Reilly, Sebastopol, CA, pp. 149-70 Beije, P. (1998) Technological change in the modern economy, Edward Elgar Publishing, Cheltenham Bergstrom, T., Blume, L. & Varian, H. (1986) ‘On the private provision of public goods’, Journal of Public Economics, vol. 29, pp. 25-49 Bessen, J. (2004) Open Source Software: Free Provision of Complex Public Goods, laatst bezocht op 5 juli 2005 Bohn, R. E. (1994) ‘Measuring and managing technological knowledge’, Sloan Management Review, vol. 36, no. 1, pp. 61-73
< 87
Bonaccorsi, A. & Rossi, C. (2003) ‘Why Open Source software can succeed’, Research Policy, vol. 32, no. 7, pp. 1243-58 Bonaccorsi, A. & Rossi, C. (2005) Comparing motivations of individual programmers and firms to take part in the Open Source movement. From community to business, Laboratory of Economics and Management Sant’Anna School of Advanced Studies, laatst bezocht op 13 mei 2005 Boulding, K. E. (1956) ‘General Systems Theory - The Skeleton of Science’, Management Sciences, vol. 2, no. 3, pp. 197-208 Brooks, F. P. (1987) ‘No Silver Bullet: Essence and Accidents of Software Engineering’, IEEE Computer, vol. 20, no. 4, pp. 10-19 Brynjolfsson, E. (1996) ‘Network Externalities in Microcomputer Software: An Econometric Analysis of the Spreadsheet Market’, Management Science, vol. 42, no. 12, pp. 1627-47 Conway, S. & Steward, F. (1998) ‘Mapping Innovation Networks’, International Journal of Innovation Management, vol. 2, no. 2, pp. 223-54 Cooper, R. G. (1993) Winning at New Products: Accelerating the Process from Idea to Launch, AddisonWesley, Reading, MA Cravens, D. W., Piercy, N. F. & Shipp, S. H. (1996) New Organizational Forms for Competing in Highly Dynamic Environments: the Network Paradigm., laatst bezocht op 20 maart 2005, Dahlander, L. (2004) ‘Appropriating Returns From Open Innovation Processes: A Multiple Case Study of Small Firms in Open Source Software’, Working paper thesis, Chalmers University of Technology, laatst bezoch 17 januari 2005, Dedrick, J. & West, J. (2003) Adoption of Open Source Platforms: An Exploratory Study, laatst bezocht op 17 januari 2005 Doney, P. M. & Cannon, J. P. (1997) ‘An examination of the nature of trust in buyer-seller relationships’, Journal of Marketing, vol. 61, no. 2, pp. 35-42 Donoghue, A. (2004) Novell sees a ‘both-source’ future, CNET News.com, laatst bezocht op 14 september 2004 2004, Doz, Y. L. & Hamel, G. (1998) Alliance advantage : the art of creating value through partnering, Harvard Business School Press, Boston, MA, 0-87584-616-5 Edwards, K. (2001) Epistemic Communities, Situated Learning and Open Source Software Development, laatst bezocht op 9 februari 2005
88 >
Engeldorp Gastelaars, P. v. & Leede, E. d. (1998) Theorievorming en methoden van onderzoek binnen de sociale wetenschappen : een introductie in het doen van onderzoek in bedrijfskundig perspectief, ServicePost, Nieuwerkerk a/d IJssel Farrell, J. & Saloner, G. (1985) ‘Standardization, compatibility, and innovation’, Rand Journal of Economics, vol. 16, no. 1, pp. 442-55 Farrell, J. & Saloner, G. (1986) ‘Installed Base and Compatibility: Innovation, Product Preannouncements, and Predation’, American Economic Review, vol. 76, no. 5, pp. 940-55 Feller, J. & Fitzgerald, B. (2002) Understanding Open Source Software Development, Addison Wesley, Boston, MA Feringa, W. J., Piëst, E. & Ritsema, H. A. (1990) Management van innovatie, Wolters Noordhoff Management, Groningen Fink, M. (2003) The business and economics of Linux and Open Source, Prentice Hall, Upper Saddle River, NJ Foundation, F. S. (2005) What is Copyleft?, laatst bezocht op 26 april 2005 Franck, E. & Jungwirth, C. (2002) Reconciling investors and donators - The governance structure of open source, 8, Zürich, Juni 2002, Working Paper Freeman, C. (1991) ‘Networks of Innovators: a Synthesis of Research Issues’, Research Policy, vol. 20, no. 5, pp. 5-24 Gabriel, R. P. & Joy, W. N. (1998) Sun Community Source License Principles, laatst bezocht op 16 november 2004 Garud, R. (1997) ‘On the Distinction Between Know-how, Know-why and Know-what’, in JP Walsh & AS Huff (eds), Advances in Strategic Management, Vol. 4, Blackwell, Oxford, vol. 4, pp. 81-101 Gawer, A. & Cusumano, M. A. (2002) Platform leadership: how Intel, Microsoft, and Cisco drive industry innovation, Harvard Business School Press, Boston Gilsing, V. A. (2003) ‘Exploration, Exploitation and Co-evolution in Innovation Networks’, Erasmus Universiteit Rotterdam Gomes, L. (2004) ‘Project Avalanche clears way for tech cooperation’, The Wall Street Journal, 12 april 2004 Goold, M. & Campbell, A. (2002) Designing effective organizations : how to create structured networks, Jossey-Bass, San Francisco, CA Grabher, G. (1993) The embedded firm : on the socioeconomics of industrial networks, Routledge, London
< 89
Grandori, A. & Soda, G. (1995) ‘Inter-firm Networks: Antecedents, Mechanisms and Forms.’ Organization Studies, vol. 16, no. 2, p. 183 Gulati, R. (1995) ‘Does familiarity breed trust? The implications of repeated ties for contractual choice in alliances’, Academy of Management Journal, vol. 38, no. 1, pp. 85-112 Gulati, R., Nohria, N. & Zaheer., A. (2000) ‘Strategic Networks’, Strategic Management Journal, vol. 21, pp. 203-15 Hakansson, H. & Johansson, J. (1993) ‘The network as governance structure - interfirm cooperation beyond markets and hierarchies’, in G Grabher (ed.), The embedded firm - on the socio-economics of industrial networks, Routledge, London Hardin, G. (1977) ‘The Tragedy of the Commons’, in Hardin & J Baden (eds), Managing the Commons, W.H. Freeman, New York Harhoff, D., Henkel, J. & von Hippel, E. (2003) ‘Profiting From Voluntary Information Spillovers: How Users Benefit by Freely Revealing their Innovations’, Research Policy, vol. 32, no. 10 Hawkins, R. E. (2003) The Economics of Open Source Software for a Competitive Firm - Why give it away for free?, laatst bezocht op 18 november 2004 Hecker, F. (1999) ‘Setting up shop: The business of open-source software’, IEEE Software, vol. 16, no. 1, pp. 45-51 Henkel, J. (2004) The Jukebox Mode Of Innovation – A Model Of Commercial Open Source Development, Centre for Economic Policy Research, laatst bezocht op 5 oktober 2004 2004, Henkel, J. (2004) Patterns of Free Revealing – Balancing Code Sharing and Protection in Commercial Open Source Development, laatst bezocht op 11 november 2004 Hinterhuber, H. H. & Levin, B. M. (1994) ‘Strategic networks--The organization of the future’, Long Range Planning, vol. 27, no. 3, pp. 43-53 Hoffman, W. H. & Schlosser, R. (2001) ‘Success Factors of Strategic Alliances in Small and Medium-sized Enterprises - An Empirical Survey’, Long Range Planning, vol. 34, no. 3, pp. 357-81 Humphrey, W. S. (1989) Managing the software process, Addison-Wesley, Reading, Mass., 0-201-18095-2 IDABC (2005) Open Source Observatory, laatst bezocht op 7 maart 2005
90 >
Imai, K. & Baba, Y. (1991) ‘Systemic Innovation and Cross-Border Networks: Transcending Markets and Hierarchies to create a new techno-economic system’, paper presented to Conference on Science Technology and Economic Growth, Parijs, Juni 1989 Kanter, R. M. (1994) ‘Collaborative Advantage: The Art of Alliances’, Harvard Business Review, vol. 72, no. 4, pp. 96-108 Katz, M. L. & Shapiro, C. (1986) ‘Technology Adoption in the Presence of Network Externalities’, The Journal of Political Economy, vol. 94, no. 4, pp. 822-41 Kogut, B. & Metiu, A. (2001) ‘Open-source software development and distributed innovation’, Oxford Review of Economic Policy, vol. 17, no. 2, p. 248 Kollock, P. (1999) ‘The economics of online cooperation: Gifts and public goods in cyberspace’, in M Smith & P Kollock (eds), Communities in Cyberspace, Routledge, London, p. 220 – 42 Krishnamurthy, S. (2003) ‘A Managerial Overview of Open Source Software’, Business Horizons, no. September-October 2003 Lakhani, K. & Hippel, E. v. (2003) ‘How Open Source Software Works: ‘Free’ User-to-User Assistance?’ Research Policy, vol. 32, no. 6, pp. 923-43 Lattemann, C. & Stieglitz, S. (2005) ‘Framework for Governance in Open Source Communities’, paper presented to The 38th Hawaii International Conference on System Sciences, Hawaii Laumann, E., Marsden, P. & Prensky, D. (1983) ‘The Boundary Specification Problem in Network Analysis’, in RBM Minor (ed.), Applied Network Analysis: A Methodological Introduction, Sage, Beverly Hills, pp. 18-34 Lawton, G. (2002) ‘Open source security: opportunity or oxymoron?’ IEEE Computer, vol. 35, no. 3, pp. 1821 Lerner, J. & Tirole, J. (2002) The Scope Of Open Source Licensing, National Bureau Of Economic Research, laatst bezocht op 26 oktober 2004 Lerner, J. & Tirole, J. (2002) ‘Some Simple Economics Of Open Source’, The Journal Of Industrial Economics, vol. L, no. 2 Levavic, R. (1991) ‘Markets and governemnt: An overview’, in FJ Thompson G., Levacic R., Mitchell J., (ed.), Markets, Hierarchies and Networks: The Coordination of Social Life, Sage Publications, London, pp. 35-47 Lubit, R. (2001) ‘The keys to sustainable competitive advantage: Tacit knowledge and knowledge management’, Organizational Dynamics, vol. 29, no. 3, pp. 164-78 Lundvall, B. (1993) ‘Explaining interfirm cooperation and innovation: limits of the transaction-cost approach’, in G Grabher (ed.), The Embedded Firm: On the Socioeconomics of Industrial, Routledge
< 91
Markus, M. L., Brook Manville, and Carole Agres (2000) ‘What Makes a Virtual Organization Work Lessons from the Open Source World’, Sloan Management Review, vol. 42, no. 1, pp. 13-26 Marson, I. (2005) CA talks the open source talk, laatst bezocht op 12 mei 2005 McLellan, L. & Adams, C. (2001) The Five Major Failure Points of Strategic Partnerships, 96912, Gartner Dataquest McQuiston, D. H. (2001) ‘A Conceptual Model for Building and Maintaining Relationships between Manufacturers’ Representatives and Their Principals’, Industrial Marketing Management,, vol. 30, no. 2, pp. 165-81 Mendys-Kamphorst, E. (2002) Open vs. closed: some consequences of the open source movement for software markets, CPB Netherlands Bureau for Economic Policy Analysis, The Hague, 90-5833-112-1 Mitchell, J. C. (1969) Social networks in urban situations: analyses of personal relationships in Central African towns, University of Zambia. Institute for Social Research, Manchester Mohr, J. & Spekman, R. (1994) ‘Characteristics of partnership success: partnership attributes, communication behavior, and conflict resolution techniques’, Strategic Management Journal, vol. 15, no. 2, pp. 135-52 Morgan, G. (1993) Images of organization, Sage Publications, Beverly Hills Morgan, T. P. (2005) VMware Opens Up ESX Server Code to Partners, laatst bezocht op 10 augustus 2005 Netscape (1998) Netscape accelerates communicator evolution with first release of next-generation communicator source code to developer community via mozilla.org, laatst bezocht op 14 september 2004 Nohria, N. & Eccles, R. G. (1992) Networks and organizations : structure, form, and action, Harvard Business School Press, Boston, MA, 0-87584-324-7 / 0-87584-578-9 Nooteboom, B. (2004) Learning And Governance In Inter-firm Relations, ERS-2004-003-ORG, Erasmus Universiteit Rotterdam, Rotterdam Nooteboom, B. (2004) Inter-firm collaboration, learning and networks: an integrated approach, Routledge, London Nooteboom, B. & Jacobs, I. (1998) Management van partnerships : over allianties tussen bedrijven, 2e ed edn, Academic Service economie en bedrijfskunde, Schoonhoven, 90-5261-241-2 Olson, M. (1965) The logic of collective action: public goods and the theory of groups, Harvard Economic Studies
92 >
Open Source Initiative (2004) The Open Source Definition, Open Source Initiative, laatst bezocht op 10 december 2004 O’Reilly, T. (1999) ‘Lessons from open-source software development’, Communications of the ACM, vol. 42, no. 4 Ososs (2005) Wat zijn open standaarden?, laatst bezocht op 22 april 2005 Osterloh, M. & Rota, S. (2005) Trust and Community in Open Source Software Production, University of Zurich, laatst bezocht op 1 juni 2005 Osterloh, M., Rota, S. & Wartburg, M. V. (2001) Open Source – New Rules In Software Development, laatst bezocht op 1 juni 2005 Payne, C. (2002) ‘On the security of open source software’, Information Systems Journal, vol. 12, no. 1, pp. 61-79 Perens (2005) The Open Source Definition, laatst bezocht 18 februari 2004, Powell, W. W. (1990) ‘Research in Organizational Behaviour’, Research in Organizational Behaviour, vol. 12, pp. 314-36 Powell, W. W., Koput, K. W. & Smith-Doerr, L. (1996) ‘Interorganizational Collaboration and the Locus of Innovation: Networks of Learning in Biotechnology’, Administrative Science Quarterly, vol. 41, no. 1, pp. 116-45 Preece, S. (1995) ‘Incorporating International Strategic Alliances into Overall Firm Strategy’, in B De Wit, Meyer, R. (ed.), Strategy - Process, Content, Context, International Thomson Business Press, Londen, pp. 543-52 Rai, A., Borah, S. & Ramaprasad, A. (1996) ‘Critical success factors for strategic alliances in the information technology industry: An empirical study’, Decision Sciences, vol. 27, no. 1, pp. 141-55 Raymond, E. S. (1999) The Magic Cauldron, laatst bezocht op 18 januari 2005 Raymond, E. S. (2000) The Cathedral and the Bazaar, laatst bezocht op 20 september 2004 Riggs, W. & Von Hippel, E. (1994) ‘Incentives to Innovate and the Sources of Innovation: the Case of Scientific Instruments’, Research Policy, vol. 23, no. 4, p. 459–69 Rosen, L. (2004) Open Source Licensing: Software Freedom and Intellectual Property Law, Prentice Hall PTR
< 93
Rosenfeld, S. A. (1996) ‘Does cooperation enhance competitiveness? Assessing the impacts of inter-firm collaboration’, Research Policy, vol. 25, no. 2, pp. 247-63 Sawyer, S. & Guinan, P. J. (1998) ‘Software development: Processes and performance’, IBM Systems Journal, vol. 37, no. 4 Selz, D. (1999) ‘Value webs: Emerging forms of fluid and flexible organizations’, University of St. Gallen Shah, S. K. (2003) Understanding the Nature of Participation & Coordination in Open and Gated Source Software Development Communities., laatst bezocht op 20 januari 2004 Shapiro, C. & Varian, H. R. (1998) Information rules: a strategic guide to the networked economy, Harvard Business School, Boston Shapiro, C. & Varian, H. R. (1998) ‘Versioning: The Smart Way to Sell Information’, Harvard Business Review, vol. 76, no. 6, pp. 106-14 Shivaprakash, A. (2003) The Open Source Initiative : Impact on the Software Industry, laatst bezocht op 12 oktober 2004 Simon, E. (1996) ‘Innovation and intellectual property protection: The software industry perspective’, Columbia Journal of World Business, vol. 31, no. 1, pp. 30-7 Stallman, R. (1996) What is free software?, laatst bezocht op 18 maart 2005 Stansberry, M. (2005) Virtualization juggernaut opens code to partners, laatst bezocht op 11 augustus 2005 Teece, D. J. (1986) ‘Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy’, Research Policy, vol. 15, no. 6, pp. 285-352 Thomke, S. & Hippel, E. v. (2002) ‘Customers as Innovators. A New Way to Create Value’, Harvard Business Review, no. april 2002 Thompson, G. F. (2003) Between hierarchies and markets : the logic and limits of network forms of organization, Oxford University Press, Oxford Trajtenberg, M. (1990) Economic analysis of product innovation : the case of CT scanners, Harvard University Press, Cambridge, MA Trolltech (2005) Trolltech’s Dual Licensing Business Model, laatst bezocht op 19 mei 2005 Tzouris, M. (2002) ‘Software Freedom, Open Software and the Participant’s Motivation’, The London School of Economics and Political Science
94 >
Van Wendel de Joode, R., De Bruijn, H. & Van Eeten, M. (2002) Protecting The Virtual Commons (Draft Version), Delft Varian, H. R. (1998) Markets for Information Goods, University of California, Berkely, Berkeley Von Hippel, E. (1988) The Sources of Innovation, Oxford University Press, New York Von Hippel, E. (2001) ‘Innovation By User Communities’, MIT Sloan Management Review, vol. 42, no. 4, pp. 82-6 Von Hippel, E. (2002) Horizontal innovation networks - by and for users, laatst bezocht op 10 december 2004 Von Hippel, E. (2005) Democratizing Innovation, The MIT Press, Cambridge, MA Von Hippel, E. & Katz, R. (2002) ‘Shifting Innovation to Users via Toolkits’, Management Science, vol. 48, no. 7, p. 821–33 Von Hippel, E. & Von Krogh, G. (2003) ‘Open Source Software and the “Private-Collective” Innovation Model: Issues for Organization Science’, Organization Science, vol. 14, no. 2, pp. 209-23 West, J. (2003) ‘How open is open enough? Melding proprietary and open source platform strategies’, Research Policy, vol. 32, no. 7, pp. 1259-85 Wichmann, T. (2002) FLOSS Final Report, Berlecon Research, laatst bezocht op 21 juli 2005 Wood, R. E. (1986) ‘Task Complexity: Definition of a Construct’, Organizational Behavior and Human Decision Processes, vol. 37, no. 1, pp. 60-82
< 95
Bijlage The Open Source Definition Version 1.9
12
Introduction
output of a preprocessor or translator are not allowed.
Open source doesn’t just mean access to the
Rationale: We require access to un-obfuscated
source code. The distribution terms of open-
source code because you can’t evolve
source software must comply with the follo-
programs without modifying them. Since
wing criteria:
our purpose is to make evolution easy, we
1. Free Redistribution
require that modification be made easy. 3. Derived Works
The license shall not restrict any party from selling or
a royalty or other fee for such sale.
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: By constraining the license to require free
Rationale: The mere ability to read source isn’t
redistribution, we eliminate the temptation to throw
enough to support independent peer review
away many long-term gains in order to make a few
and rapid evolutionary selection. For rapid
short-term sales dollars. If we didn’t do this, there
evolution to happen, people need to be able to
would be lots of pressure for cooperators to defect.
experiment with and redistribute modifications.
giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require
2. Source Code 4. Integrity of The Author’s 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
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
< 97
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 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.
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
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
Rationale: This clause is intended to forbid
diversity of persons and groups should be
closing up software by indirect means such
equally eligible to contribute to open sources.
as requiring a non-disclosure agreement.
Therefore we forbid any open-source 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.
98 >
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.
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.
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 aimed 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
Rationale: Distributors of open-source
licenses must allow for the possibility that (a)
software have the right to make their own
redistribution of the software will take place
choices about their own software.
over non-Web channels that do not support
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.
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.
Origins: Bruce Perens wrote the first draft of this document as “The Debian Free Software Guidelines”, and refined it using the comments of the Debian developers in a month-long e-mail conference in June, 1997. He removed the Debian-specific references from the document to create the “Open Source Definition.” Copyright © 2005 by the Open Source Initiative (opensource.org)
< 99
13
Bijlage SugarCRM SugarCRM is een bedrijf dat Sugar Suite ont-
steuning als de software in gebruik genomen is,
wikkelt, een open source customer relationship
biedt SugarCRM verschillende supportcontrac-
management (CRM) pakket, dat in korte tijd
ten aan.
erg bekend en populair geworden is. Door het succes van de open source versie heeft dit bedrijf een grote naamsbekendheid gekregen en een goede reputatie. In deze case zal ik SugarCRM’s motieven bespreken om hun innovatie ‘freely te revealen’. Het feit dat het bedrijf is opgericht met het idee een open source CRM product te ontwikkelen, maakt deze case interessant. Het gaat hier dus niet om een proprietary product wat op een gegeven moment is vrijgegeven als open source en het is ook geen product dat ontwikkeld is door een aantal programmeurs om in hun ei-
Het open source karakter van Sugar Suite stelt IT bedrijven in staat de software voor hun klanten aan te passen en andere diensten aan te bieden. Aan deze bedrijven biedt SugarCRM, tegen betaling, ondersteuning om hen hierbij te helpen. Een voorbeeld van een complementair product, dat niet gratis wordt aangeboden is de Microsoft Outlook Email Plug-in, die voor een koppeling tussen Outlook en Sugar Suite zorgt, zodat e-mail conversaties bij de betreffende relatie in het CRM systeem opgeslagen kunnen worden.
gen behoefte te voorzien. In dit geval heeft een
Naast de gratis open source versie van het pro-
commerciële organisatie heel bewust gekozen
duct heeft SugarCRM ook een ‘pro’-versie, waar
om de innovatie die ze gingen doen ‘freely te
per eindgebruiker per jaar voor betaald moet
revealen’.
worden, zoals in deze bedrijfstak gebruikelijk
Via haar website biedt SugarCRM een aantal complementaire diensten en producten aan. Zo kunnen gebruikers hulp krijgen bij de installatie van de software op hun software via telefoon of e-mail. Voor klanten die meer hulp nodig heb-
is. Deze versie heeft alles wat ook in de open source versie zit plus een aantal extra features, zoals uitgebreidere rapportagefunctionaliteit. Daarnaast krijgt de klant de Outlook plugin en ondersteuning.
ben bestaat er de Remote Login Installation
In tabel 13.1 en 13.2 is een overzicht van de
dienst, waarbij een technicus van SugarCRM
diensten en producten die SugarCRM levert en
via internet inlogt op de server van het bedrijf
de prijzen die ze rekent
om de software daar te installeren. Voor onder-
< 101
Dienst
Prijs
Installation Guidance
$245,00
Sugar Open Source Support Case
$95,00
Remote Login Installation
Sugar Open Source Support Pack
Developer Support & Maintenance
$345,00 $245,00
$875,00
Tabel 13.1: Complementaire diensten en prijzen van SugarCRM
Product
Prijs
Sugar Professional
$239,00
per gebruiker per jaar
Microsoft Outlook Email Plug-in
$39,95
per gebruiker
Sugar On-Demand Sugar Cube
$39,95
per gebruiker
$4.495,00 excl. licentiekosten
Tabel 13.2: Complementaire producten en prijzen van SugarCRM
102 >
Bijlage Interview TeamSoft Transcriptie van het interview gehouden met Theo Talboom van Teamsoft op 20 juni 2005 te Alblasserdam. Het eerste stuk bestaat uit kennismaking en het toestemming vragen voor het opnemen van het vraaggesprek. In onze email uitwisseling van december 2004 gaf u aan nog geen bedrijven te kennen die op een zelfde manier werken als TeamSoft. Bent u inmiddels wel op de hoogte van bedrijven die op een dergelijke manier werken? Nee, voor zover ik weet zijn wij nog steeds de enige. Is TeamSoft vanaf het begin volgens Conditional Open Source gaan werken? Ab Troost wou eind 2002 nog één keer bedrijf beginnen. Dat is samen gebeurd met het oude ontwikkelteam [Man of 10] van Paymate [Onderdeel van Exact] Wij hebben toen gekeken naar de ontwikkelbranche en bedacht wat we anders wilden gaan en wat we vooral niet meer wilden. Wij wilden niet meer onze klanten volledig afhankelijk van ons maken. Afhankelijkheid van software vendors was heel erg in die jaren. Escrow, het brengen van broncode in een veilige situatie, werkt in de praktijk helemaal niet, dat is heel vaak een wassen neus. Daarbij kwam op dat moment, dat er geen internet-based applicaties waren, maar geschikt gemaakt met schilletje. Dat is niet de manier. Daarom zijn we aan de slag gegaan met Progress Dynamics, het allermodernste in die tijd. Dynamics stelt
14
ons in staan om meteen internet-based te ontwikkelen, zonder dat een Citrix of Terminal Services oplossing nodig is. Direct via internet over een beveiligde connectie. Verder signaleerde wij dat veel oplossingen op een houtje touwtje manier gemaakt waren, aan elkaar geknoopte applicaties, terwijl ook rekening gehouden moest worden met legacy applicaties. Daar wilden we van af. We wilden starten met een leeg vel papier, met de ervaring die we in het verleden hadden opgedaan, en die was vrij groot, met voorkoming van de fouten die in het verleden gemaakt zijn. Vanaf nul begonnen met ERP suite. Alles geïntegreerd en gaan ontwikkelen. Eén van de achterliggende gedachtes was dat wij altijd een softwareontwikkelinghuis willen blijven, we hebben niet de ambitie een tweede Unit 4 te worden, of noem het maar op. We wilden zuiver de techniek ontwikkelen en die dan via partners te distribueren. Partners kunnen van alles zijn, implementatiepartners, resellers, Value Added Resellers. Wat is het verschil tussen een implementatiepartner en een Vallue Added Reseller? Var bouwt zelf aan software verder, die ontwikkelt zelf. Jullie product zelf is wel in één keer te implementeren?Ik neem aan dat je toch te maken hebt met erg bedrijfsspecifieke zaken,
< 103
dat er eigenlijk altijd wel iets bijgebouwd moet worden, bijvoorbeeld middleware? Bij het ontwikkelen van de applicatie zijn we van een aantal basisfactoren uitgegaan: het eerste was dat alle data heel goede geïmporteerd en geëxporteerd moest kunnen worden. Omdat je in de praktijk altijd met derde systemen zult moeten aanhaken. Daarom is er de ingebouwde importexporttool en daar kan alle soorten logica gekoppeld worden. Door middel van queries, gebaseerd op open standaarden, is het heel eenvoudig gegevens in te lezen en op de juiste manier te verwerken Ik denk aan XML en een aantal open standaarden Waarom gaan andere bedrijven zo krampachtig om met de bescherming van hun broncode en het gebruik van gesloten standaarden en het zorgen dat ze lock-in krijgen. Waarom zien jullie die openheid niet als bedreiging en waarom hebben jullie die lock-in niet nodig? Dat heeft te maken met hoe je je aan de buitenwereld wilt presenteren. Wij zijn een jong bedrijf zijn, wij kunnen dat. Als ik Microsoft zou zijn, zou ik het waarschijnlijk ook niet doen, omdat je een heel stuk van je install-base misschien kwijt kunt raken. Het is ook ingegeven door het feit dat we als jong bedrijf zekerheid willen bieden. Omdat het voor de klant ook een gok is om met jullie in zee te gaan? [4:42] Ja absoluut, we zijn nog een jong bedrijf, financieel weliswaar gezond, maar onze Dun & Bradstreet rating hoef je niet naar te vragen natuurlijk, we bestaan twee en half jaar en er is alleen maar geïnvesteerd, dus dan hoef je niet te verwachten dat daar iets positiefs uit komt. Verder is er natuurlijk veel kennis aanwezig, maar je blijft een hoog risico, voor partijen om te implementeren. Daar moet je dus iets tegenover stellen. Eén van die dingen is inzichtelijke goed becommentarieerde broncode. Dit is door
104 >
iedereen die Progress beheerst te lezen... dus dat is wel een beperking. Dus het Progress platform is eigenlijk wel een grote lock-in? Niet per definitie, als je ziet hoeveel Progress partners er zijn. Je kunt makkelijk switchen naar een andere. Elke andere programmeur of database expert kan er ook mee werken. Wat de samenwerking betreft, jullie leiden jullie partners op? [6:30] Ja, die komen dan hier en die krijgen een cursus. Allereerst, omdat wij in Progress Dynamics werken, wat een totaal andere manier van ontwikkelen is dan gebruikelijk, het is echt dynamisch object georiënteerd. De objecten die je maakt kun je dynamisch aanpassen, dat is iets totaal anders dan regels code inkloppen. Daarom kun je het zo inzichtelijk maken, omdat dat echt blokjes zijn die je oppakt en die je ergens inzet. Het is een grafische interface, waarin je de eigenschappen van objecten aan kan passen, waar de logica aangehangen wordt. Waarin verschilt dat dan met andere talen als bijvoorbeeld Delphi? Waar zit het verschil in? Dit is veel verder gestructureerd is en over een uitgebreide library beschikt met controlefunctie. Roundtable waar je de code doorheen haalt, controleert of alles blijft werken. Het beheer en de manier waar mee je kunt ontwikkelen is dermate efficiënt ingericht, dat je heel snel kunt ontwikkeling. Voor programmeur is het wel een omschakeling, van normaal naar object georiënteerd programmeren. Daarom krijgen partners die een opleiding krijgen eerst een Progress basis en daarboven een Dynamics basis. En dan worden ze nog opgeleid in hoe wij onze software hebben ingericht hebben, hoe ze daar zo snel en efficiënt mogelijk mee om kunnen gaan. Als zij eenmaal aan het ontwikkelen zijn,
hoe gaat het contact dan? [7:55] Dat loopt voornamelijk via de techneuten. Het ligt er ook aan wat zij ontwikkelen. In wezen hebben wij gekozen om een generieke basis weg te zetten, met grote generieke functionaliteit. Willen partijen heel specifiek gaan ontwikkelen in een specifieke branche dan bieden we daarvoor VARschap aan, zodat zij met hun specifieke kennis na hun opleiding zelf functionaliteit kunnen gaan ontwikkelen. Die overigen wel weer door Roundtable heen moet, zodat het wel compatible blijft. Jullie zeggen ook dat als zij generieke functionaliteit ontwikkelen, dan moet het in ieder geval aan jullie aangeboden worden? Wij bekijken het sowieso, en wanneer zij een generiek verbetering, die voor de hele suite van toepassing zou kunnen zijn, dan houden wij het recht voor om deze te incorporeren. Dat is tot op heden nog niet gebeurd? Nee, nog niet, maar er ontwikkelen nog niet zo heel veel partners, dat zijn er nog maar twee of drie. De overige partners zijn implementatiepartners. Een VAR moet op een gegeven moment een project hebben, waar hij het weg kan gaan zetten. Hij kan wel de intentie hebben iets te gaan doen, maar daar moet dan wel markt voor zijn. De luxe om zo te gaan ontwikkelen vanaf nul zoals wij gedaan hebben, die hebben maar weinig bedrijven. Waarom hadden jullie die luxe wel? Omdat er het kapitaal was. TeamSoft zegt New Age E-business software te leveren. Wat is er New Age aan TeamSoft? Het feit dat het van nul is ontwikkeld en volledig internet-based is en dus eigenlijk totaal nieuw is. Het is de eerste echte ASP mogelijke suite, die ontwikkeld is. In zekere zin is het wel een soort nieuw tijdperk. Baan
etc gaat allemaal via Citrix tunneloplossingen en dat is met deze applicatie dus niet nodig, die werkt zo efficient met zijn data, die doet dat zelf en dat is een enorm voordeel. Dat gecombineerd met het feit dat je met één centrale relationele database werkt. Je hebt dus geen terminal services nodig om documenten op je netwerk te benaderen. Alle autorisaties en processen zitten in database, daarboven zit de bedrijfslogica, daarboven presentatielaag, dat kan een webinterface zijn of een gui-client. Hebben jullie zelf ook klanten, of gaat alles via de partners? Jazeker, TeamSoft is zeer actief in sociale reïntegratie en detacheringsmarkt We konden bij een paar grote bedrijven beginnen als pilot en dat was heel succesvol uitgepakt. Omdat we heel snel kunnen ontwikkelen en aanpassen, hadden we in no time een absolute marktleiderpositie in de branche van client-volgsystemen voor reïntegratietrajecten. Deze klanten zijn particuliere en semi-overheidsinstellingen. Die moeten aan een aantal criteria voldoen om bijvoorbeeld subsidies te krijgen, het Borea keurmerk heet dat. Wij hebben er voor gezorgd dit hele traject in een proces te omvatten. Het is een grotendeels generiek proces, maar er zijn afwijkingen mogelijk en dat is allemaal mogelijk. Daarin zijn we heel succesvol en hebben we een behoorlijk aantal klanten opgebouwd en recentelijk zelfs de allergrootste van Nederland binnengehaald, Hudson uit Amsterdam. Hoe gaan jullie om met kanaalconflicten?Als bijvoorbeeld een potentiële klant zowel jullie als één van jullie partners benadert? We hebben wel onze terreinen afgebakend, maar het maakt ons in principe niet uit, wie de software verkoopt. Als een VAR daar business
< 105
uithaalt, dan helen wij daar ook business uit. Daar zijn we absoluut niet krampachtig in. De marges zijn contractueel afgedekt. Sowieso hebben we voor implementaties maar beperkte mankracht. Het is expliciet niet onze wens om daar nog verder in te groeien. Voor het implementatietraject hebben we onze partners. In een dergelijk geval gaat de opdracht sowieso naar een partner? Ook als een klant alleen naar jullie toekomt, verwijzen jullie dan ook door naar de partner? [14:15] Ja zeker, als er een partner is die het beter kan dan dat wij dat kunnen, natuurlijk. Het is in de praktijk nog niet voorgekomen omdat we nog een jong bedrijf zijn en omdat we zelf een kleine niche voor onszelf hebben. Maar ik kan me voorstellen dat dat in de toekomst wel gaat gebeuren. Is jullie niche, de reïntegratiemarkt een bewuste strategische keuze, of is dat zo gegroeid? Reïntegratiemarkt is de enige markt waarop ze zelf heel erg actief zijn. Omdat dat zo gegroeid is, niet zo zeer een strategische keuze. Van oudsher zijn we erg goed in payroll, maar dat hebben we het eerste jaar niet kunnen doen vanwege concurrentiebedingen. Inmiddels is dat niet meer van toepassing. Dat wordt het volgende waarop we ons gaan focussen, om die markt terug te gaan pakken. En dat kunnen we ook zelf omdat we daar de mensen voor hebben en de consultancy en de expertise. Op andere gebieden, als we de breedte in willen zullen we echt met partners gaan werken. En daar zijn we actief in aan het werven. Dat is dus een bedreiging voor gevestigde partijen? Ja, er zijn een aantal partijen, die ons niet leuk vinden. Onder anderen voor de Raad van rechtbijstand, daar leveren we ons financieel pakket aan, daar hebben we toch alle grote namen verslagen.
106 >
Wat is voordeel voor jullie partners dat jullie broncode leveren? Is dat iets Progress’ specifieks? Nee, absoluut niet Het is niet gebruikelijk, meestal gaat het toch via API’s, wat is dan het voordeel van het meeleveren van de broncode? Het meeleveren is niet het voordeel, maar het feit dat het goed becommentarieerd is, dat het helder opgezet is en dat het dus eigenlijk voor je ontwikkelingspartners een stuk makkelijker om daar bij aan te haken. Het is geen vereiste voor Roundtable, dat de broncode ook nodig is, als partners daarmee willen werken? Als partners met onze codes willen gaan werken, dat kan en daar staat natuurlijk iets tegenover. Wil dat op TeamSoftvlak blijven, dat moeten wij toch iets van een garantie moeten geven op het gebied van updates. Als ze volledig buiten hun code om gaan werken, dan willen we daar wel controle op blijven houden. Om updates en continuïteit te garanderen. Vandaar dat het conditional open source heet, er zit wel een voorwaarde aan. Kwaliteitsbewaking en doorontwikkelgarantie. Als in de toekomst er een partij komt die heel erg wil afwijken, dan zal gekeken worden naar een constructie dat zij de source krijgen voor een bepaald deelgebied, een hele smalle sector, en dan ook exclusiviteit kunnen claimen. Maar daar staat een prijs tegenover. Binnen onze software is al heel veel mogelijk alleen al met inrichting, er zijn heel veel vrije velden en tabellen en dergelijke die je kunt definiëren. Je kunt heel veel opnemen bij de inrichting. Een implementatiepartner kan al heel veel configureren? Dat is natuurlijk ook nodig bij ERP software. [17:53] Ja. Als er een paar schermen bij ontwikkeld moeten worden kunnen de programmeurs
van teamsoft dat doen. Dat is sneller dan wanner daar eerst drie mensen voor opgeleid moeten worden. Als ze heel erg de diepte in willen dan moeten wij afhaken. En dat is iets waar VARS voor in gedachten hadden. Maar, onze generieke functionaliteit is inmiddels zo groot dat een gemiddeld of groot MKBbedrijf daar prima mee uit de voeten kan. Voor integratie van andere systemen en ontwikkelen voor middleware kun je VARs gebruiken. Je zit dan met koppelingen. Volgend jaar gaan we een technische sprong maken naar de laatste versie van dynamics en daarin wordt ook duidelijk aansluiting gezocht bij .Net, dan wordt het nog makkelijker om allerlei dingen aan elkaar te knopen. Ook live, naast import export. Kan nu al, met SonicMQ. Dat biedt mogelijkheid om verschillende databases real-time met elkaar te laten praten, dat werkt fantastisch, is echt een state-of-the-art tool. Progress is een 4GL taal, maakt zeer snelle ontwikkeling mogelijk, omdat je niet steeds alles aan moet gaan passen zoals bij 3GL talen als Java. Objecten zijn zeer eenvoudig te wijzigen en benodigde veranderingen worden automatisch op alle plekken waar dat nodig is aangepast. In hoeverre is het dan nog broncode? Is wel absoluut broncode, onder de grafische objecten zit de broncode, die op het moment dat je met de objecten werkt alleen niet zichtbaar is, maar die is er natuurlijk wel. Zijn jullie niet bang dat de code uitlekt? Nee, er zit een auteursrechtbeperking op. Als wij merken dat er met onze codes dingen gebeuren die niet in de haak zijn, dan grijpen we wel in. Het is een kleine wereld, Progress partners, dus daar ben je heel snel achter. Je zit natuurlijk vast aan het Progress platform Ja, het is niet zo dat elke willekeurige
programmeur daarmee kan gaan werken, het is geen General Public License, dus dat is een voordeel. Het risico is daarmee dus ook beperkt. Is het beperkt omdat het specifiek is voor markt en omdat het aan Progress vastzit? Ja. Als een VAR gaat ontwikkelen. Hoe gaat het contact dan? Hoe intensief is dat?. Veel Kennis niet expliciet. Waarschijnlijk niet eens gedocumenteerd. Moet van man tot man gaan? Zou hij niet weten, hoe dat precies in zijn werk gaat. Meestal is er pas feedback op het moment dat de code teruggeleverd wordt en gecontroleerd wordt. Tussentijds hebben VARs de vrijheid om te doen en laten wat ze willen. Met code zit je met specifieke vragen als wat het doen en waarom iets op bepaalde manier gebeurd. Dat je kunt inzien dat als je wat verandert wat dat voor gevolgen zou hebben. Allen het begrijpen van de taal is niet genoeg om dingen aan te kunnen passen? Ja, maar daar is de opleiding voor geweest. In opleiding leer je alles. Dat is genoeg, want je werkt met ervaren programmeurs. Bij de opleiding wordt dieper ingegaan op onze functionaliteiten en de logica enzovoort. Je begint dan op een basisniveau en in wezen wat je doet, is verder invullen van... En dat heeft tot op heden in de praktijk nog geen problemen opgeleverd.
Hoe dynamisch is jullie codebase nog, hoe stabiel is het, is het nog erg in verandering? [23:20] Ik denk dat je kunt stellen dat het nog steeds heel erg verandert. Als je relatie met ander bedrijf hebt, moet die goedmoet kunnen volgen wat er verandert? Ja klopt, nauwe band nodig. Tot op heden weet ik niet precies hoe die onderhouden wordt, dat kan ik niet in detail vertellen.
< 107
Daar zijn we natuurlijk ook nog tamelijk jong voor en het aantal VARs dat we hebben is beperkt en wat ze ontwikkelen is ook op een klein specifiek deelgebied, dus daar kan ik niet echt antwoord op geven. Als je samen ontwikkelt en het is nog redelijk dynamisch ener veranderen nog veel dingen en zij zijn erg belangrijk voor Teamsoft, en Teamsoft voor hen als zij eenmaal strategisch gekozen hebben voor hun platform... Ja, nou is het meestal zo dat die VARs al Progress partners waren, Progress is eigenlijk de onderliggende factor. Pas zijn wij echter benaderd door een Belgisch bedrijf, die alles met Oracle deed, die zochten naar een functionele oplossing en dat dachten ze bij ons gevonden te hebben en waren eigenlijk niet zo geïnteresseerd in dat daar Progress onder zat omdat het naar andere soort landen toe gaat waar de prijs voor Oracle niet echt acceptabel waren. Het komt dus niet alleen meer uit de Progress community maar ook uit een andere hoek. Kijken hoe we daar een modus voor te vinden. Teamsoft heeft nog niet overal een uitgewerkt scenario voor. In de praktijk blijkt dat het varschap zoals Teamsoft dat in gedachten had anders geïnterpreteerd wordt. Als voorbeeld: we kwamen in contact gekomen met een andere partner die ook in dynamics ontwikkeld heeft, een volledige transportapplicatie. Die wilde op zich wel verder gaan met onze broncodes, om zijn applicatie daar in te integreren, maar het leek dit bedrijf beter om haar kennis ter beschikking te stellen aan onze ontwikkelaars, in plaats van zelf te gaan bouwen op basis van de code van Teamsoft. Eerder zei u dat Teamsoft niet meer implementaties wilde doen? Nee, de implementatie niet, maar het ontwikkelen wel. Partner leek het sneller dan hun code zich eigen te maken en dat
108 >
dan gaan integreren dan het aan Teamsoft over te laten. Met de kennis die wij hebben, en misschien dat je bepaalde objecten kunt hergebruiken. Dat was dus eigenlijk een andere invulling dan dat wij voor ogen hadden gehad, iets waar we eigenlijk niet bij stil gestaan hadden. ...een reseller die puur alleen de marktkennis heeft en weet wat er nodig is, maar niet zelf aan de slag gaat... Nee, daar moet je natuurlijk ook de tijd en het geld voor vrij kunnen maken en dat is een behoorlijke investering vraagt. Waar komt dat verschil in interpretatie van het varschap vandaan? Dachten jullie te technisch? Ik denk dat de tijd er gewoon nog niet rijp voor is, voor veel bedrijven om te gaan investeren, terwijl het economische klimaat niet optimaal is. Jullie zijn wat dat betreft op een slechte tijd begonnen... Teamsoft is tegen de stroom ingegroeid en dat geeft ons nu een competitive edge. Niemand anders heeft vanaf nul ontwikkeld, omdat ze niet het geld of tijd hadden of het überhaupt niet durfden. Er zijn maar weinig bedrijven die in deze tijd geïnvesteerd hebben in technologie. Dat dwingt Exact bijvoorbeeld er toe om nu aan de lopende band andere bedrijven over te nemen, Wij lopen nu tegen het probleem aan dat onze technologie heel veel kan, in heel veel verschillende markten, maar we niet de mankracht hebben om die volledig uit te buiten en in die markten te springen. Daarom zijn we nu aan het kijken hoe we partners kunnen vinden die dat wel kunnen en hoe we dat naar buiten toe kunnen communiceren. Dat vergt natuurlijk wel continue bijstelling van je strategische doelen. En je moet beslissingen maken wat je zelf wilt ontwikkelen en wat absoluut niet, op welke terreinen wil ik zelf
mijn expertise blijven behouden en op welke terreinen wil ik voor een partner kiezen. Daar moet je ook heel duidelijk in zijn voor je zelf. En je inzichten veranderen naarmate je bezig bent. Bijvoorbeeld wat betreft de partners, die moet je heel actief aan blijven sturen, want ze gaan zelf niet lopen. We merken nu dat we daar een actievere rol in moeten gaan spelen. Het is jammer dat partners tijd en geld en licenties investeren en daar vervolgens niks mee doen. Is dat omdat ze het product niet weg kunnen zetten, of omdat ze er achter komen dat de investering toch groter is dan ze dachten? Dat laatste denk ik niet, de gelegenheid moet zich voordoen dat een klant ook bereid is een dergelijke applicatie weg te zetten. Wij zijn een bedrijf met een hoog risicoprofiel, ook voor een implementatiepartner. Je moet wel een klant hebben die bereid is dat risico te nemen. Hoewel dat allemaal afgedekt is, zal zo’n partner pas stappen ondernemen op het moment dat hij 100% zeker weet dat het hem gaat lukken, anders loopt hij te veel risico. Is het feit dat jullie software op Progress gebaseerd is een sterkte of een zwakte? Geen van beide. Het probleem is dat niemand Progress kent, wat niet zo vreemd is, omdat het puur een techneutenclub is. Veel software is gebaseerd op Progress, maar dat wordt verder niet gecommuniceerd. Instellingen als Coca-Cola en het Ministerie van Justitie draaien op Progress. Deze referenties werken wel in je voordeel. Hoe zit het met het juridische eigendom van de code. Jullie behouden het recht voor om generieke code van de VAR op te nemen in jullie eigen codebase? Ja, van dat stuk worden wij automatisch eigenaar, of auteursrechthebbende eigenlijk. Van de specifieke extra (voor een branche) functionaliteit blijft de VAR eigenaar en dat kunnen wij niet zonder toestemming kopiëren
en verkopen. Maar andere generieke zaken zoals bijvoorbeeld een goede snelle manier voor documentenopslag dan kunnen wij dat inbouwen. Als onze VAR verkoopt, dan verkopen wij ook, wij willen een software-ontwikkelingshuis blijven. Wij doen eigenlijk hetzelfde als Progress, we zijn daar een trapje onder gaan zitten. Over TeamSoft’s benadering van broncode / Conditional Open source: Verschillende benaderingen afhankelijk van je doelgroep. De broncode geeft vrijheid ten aanzien van je eindgebruikers. Voor hen heeft het veel meer het karakter van een escrow, maar beter want bij iedere updates staan ook weer de bijbehorende codes erbij, je krijgt altijd actuele codes bij je software. Dat geeft een zekere continuïteitswaarborg. Als de relatie met TeamSoft dermate verstoord is, dat die niet meer verder gezet kan worden, kan de klant alsnog met die codes uit de voeten, met een andere Progress partner. Ten aanzien van je VARs: de code is helder opgezet en becommentarieerd, wat het gemakkelijker maakt om snel te ontwikkelen, je kunt het je heel snel eigen maken, zeker na een korte opleiding. In die zin is het ook open source. Ten derde is het een verkoopargument om aan te haken aan open source. Zo wordt gekeken of we OpenOffice volledig kunnen integreren in de software. De roep om open source wordt vooral bij de overheid steeds groter. Op alle fronten kijken we hoe we onze applicatie zo open mogelijk kunnen houden. Zo wordt ook een client voor Linux en Java ontwikkeld.
< 109
